|
AORTA 2012 (v6·11) |
|
|
|
|
|
Datum: |
5 december 2012 |
|
Versie: |
6.11.0.0 |
|
Referentie: |
|
|
|
|
Nictiz is het landelijke
expertisecentrum dat ontwikkeling van ICT in de zorg faciliteert. |
|
AORTA 2012 (v6·11) |
|
|
|
|
|
Datum: |
5 december 2012 |
|
Versie: |
6.11.0.0 |
|
Referentie: |
|
|
|
|
Nictiz is het landelijke
expertisecentrum dat ontwikkeling van ICT in de zorg faciliteert. |
1 Inleiding.............................................................................................. 5
1.1 Doel en scope.......................................................................................... 5
1.2 Doelgroep voor dit document...................................................................... 5
1.3 Documenthistorie...................................................................................... 5
2 Kaders en uitgangspunten................................................................ 7
2.1 Relatie met AORTA-principes en –beslissingen................................................. 7
3 Context van het Applicatieregister................................................... 8
4 Interfaces (koppelvlakken)............................................................. 11
4.1 Systeeminterfaces................................................................................... 11
4.1.1 Systeeminterface - LSP.APR.i1040: Opvragen zorgaanbiederapplicatie.. 12
4.1.2 Systeeminterface – LSP.APR.i1060: Opvragen interactieversie............ 13
4.1.3 Systeeminterfaces - LSP.APR.i1020 en GBX.APR.i1020: Verifiëren applicatiekoppeling 15
4.1.4 Systeeminterfaces - LSP.APR.i1010 en GBX.APR.i1010: Verifiëren communicatiekoppeling 16
4.1.5 Systeeminterface - LSP.APR.i1070: Wijzigen applicatiesysteemrol........ 16
4.1.6 Systeeminterface - LSP.APR.i1080: Toevoegen applicatiesysteemrol.... 17
4.2 Eindgebruikersinterfaces........................................................................... 19
5 Services en functies......................................................................... 20
5.1 Primaire services..................................................................................... 20
5.1.1 Opvragen van zorgaanbiederapplicatie............................................ 20
5.1.2 Opvragen van hoogst ondersteunde interactieversie.......................... 22
5.1.3 Opvragen van zorgaanbiederapplicatie details.................................. 25
5.1.4 Wijzigen applicatie...................................................................... 26
5.1.5 Verifiëren applicatiekoppeling (ping –pong)...................................... 28
5.1.6 Verifiëren communicatiekoppeling (tick – tock)................................ 30
5.1.7 Wijzigen applicatiesysteemrol....................................................... 30
5.1.8 Toevoegen applicatiesysteemrol.................................................... 32
5.2 Beheersfuncties...................................................................................... 34
5.2.1 Gebruikscenario voor het toevoegen van een systeemrol................... 34
5.2.2 Gebruikscenario toevoegen van een XIS-typekwalificatie-ID............... 34
5.2.3 Gebruikscenario voor het beëindigen van een XIS-typekwalificatie-ID... 35
5.2.4 Gebruiksscenario toevoegen/wijzigen applicatie................................ 35
5.2.5 Gebruiksscenario verwijderen applicatie.......................................... 35
5.2.6 Gebruiksscenario voor toevoegen en toekennen samenwerkingsverband 35
6 Gegevensmodel................................................................................ 36
6.1 (Logisch) model van entiteiten en relaties..................................................... 36
6.2 Gegevensautorisatiemodel......................................................................... 43
7 Configuratieaspecten....................................................................... 44
8 Ontwerpaspecten ten behoeve van niet-functionele eisen......... 45
9 Interne componentenstructuur en werking.................................. 46
10 Procedurele beheersaspecten......................................................... 47
Bijlage A Referenties.......................................................................... 48
De ZIM stelt aangesloten applicaties in staat om geregistreerde applicatie gegevens te achterhalen.
AORTA stelt zorgverleners in staat om via hun eigen informatiesysteem gegevens over de door hen behandelde patiënten op te sturen naar de informatiesystemen van andere zorgverleners.
Voorafgaand aan het verzenden van patiëntgegevens heeft de zender de mogelijkheid om de voor het adresseren benodigde informatie op te zoeken over de ontvanger.
Het applicatieregister (APR) is nodig om:
De doelgroep voor dit document bestaat uit XIS-leveranciers en de LSP-leverancier. De LSP-leverancier heeft dit document nodig om het Applicatieregister te kunnen bouwen en bijbehorende interacties te kunnen implementeren. De XIS-leverancier heeft dit nodig om de werking van het applicatieregister te begrijpen en hierop wijzigingen te kunnen aanbrengen die het functioneren van zijn applicatie beïnvloeden.
|
Versie |
Datum |
Omschrijving |
|
6.10.0.0 |
18-okt-2011 |
Initiële opzet ontwerp document |
|
6.10.0.0 |
18-okt-2011 |
RFC 35171 – Versiebeheer; Highest Common Version query |
|
6.10.0.0 |
18-okt-2011 |
RFC 42949 – Herzien datamodel applicatieregister |
|
6.10.0.0 |
18-okt-2011 |
RFC46035 – opt-in voor beschikbaar maken en opvragen van gegevens via AORTA |
|
6.10.0.0 |
18-okt-2011 |
RfC 46544 De filterparameter EffectiveTime in PRPM_IN907030NL
(Opvragen interactieversie) moet worden gekoppeld aan Actualiteit GBZ en niet
aan Actualiteit VWI, zodat de VWI-selectie waarop het antwoord is gebaseerd
gelijk is aan de selectie die zou worden opgeleverd met de filterparameter
EffectiveTime in de opvraagberichten QUMT_IN020010
en QUMT_IN020011NL. |
|
6.10.0.0 |
12-okt-2011 |
RfC 46688: Foutmelding in LSP.APR.t2220 aangepast n.a.v. commentaar |
|
6.11.0.0 |
5-dec-2012 |
RfC 51692: In tabel LSP.APR.t2210.
Het attribuut port en prefixServicePath is productieomgeving anders gevuld
dan in de toelichting beschreven. Additionele informatie voor
authenticatiewijze aangepast aan implementatie. |
Dit component houdt relevante gegevens bij over de informatiesystemen van zorgaanbieders waarmee de ZIM kan communiceren, ofwel de ‘aangesloten’ zorgsystemen.
Dit applicatieregister bevat gegevens over de gekwalificeerde GBZ-en, XIS-en en hun applicatiegegevens.
De ZIM bewaart de informatie over aangesloten applicaties in een applicatieregister. Opname in het applicatieregister is een voorwaarde voor berichtenuitwisseling met de ZIM. Op basis van een uniek kenmerk is een applicatie en zijn context terug te vinden in het APR en kan deze geautoriseerd worden voor berichtuitwisseling, zie [Arch AORTA] paragraaf Authenticatie en autorisatie van de zorgverlenerapplicatie
Het APR is de centrale component binnen AORTA waarbinnen de gegevens van gekwalificeerde applicaties en GBZ’en zijn vastgelegd. Daarmee is het APR de centrale plaats waaruit gegevens te raadplegen zijn voor autorisatie van de applicatie.
Het APR biedt ook informatie om een bericht te kunnen adresseren. Een zorgverlener weet bijvoorbeeld naar welke zorgaanbieder een bericht gestuurd moet worden maar kent niet het technische postbusadres. Om dit adres te kunnen bepalen is een functie nodig die het APR kan raadplegen.
Voor de VWI geldt iets vergelijkbaars. In de VWI zijn de verwijzingen vastgelegd waarbij het technische postbusadres gebruikt wordt. Om de ZIM en andere applicaties in staat te stellen om uiteindelijk een bericht te kunnen verzenden naar de betreffende applicatie(s) zijn aanvullende gegevens, bijvoorbeeld een volledige hostnaam nodig. Deze zullen uit het APR opgehaald moeten worden, voordat een bericht verzonden kan worden.
Applicatiegegevens zijn uit het APR opvraagbaar door zorgverleners, door middel van het gebruik van de systeemrol Applicatieregister raadplegend systeem.
Voor GBx-applicatiebeheerders zijn functies nodig om meer specifieke applicatiegegevens op te vragen
Om voor de GBx- en LSP-beheerders een functie te bieden om te bepalen of er een fout in de communicatie tussen de verschillende applicaties optreed, wordt de mogelijkheid geboden om de applicatie- en communicatiekoppeling te verifiëren. Op basis van de eventuele foutmeldingen uit deze berichten kan een beheerder een probleem oplossen. De ontvangen en verzonden HL7-berichten naar het applicatieregister worden gelogd in de toegangslog.
Een belangrijke doelstelling van het applicatieregister is een reagerend GBZ te beschermen tegen berichten die deze niet kan of mag verwerken. De ZIM-orchestratieservice raadpleegt hiertoe het APR om de status van de bestemmingsapplicatie te bepalen.
In het onderstaande diagram LSP.APR.d1010. is de omgeving van het applicatieregister weergegeven.
Diagram LSP.APR.d1010.3
– overzicht van APR
De applicatie component APR ondersteunt de volgende services voor externe systemen:
De services Opvragen van zorgaanbiederapplicatie en Opvragen interactieversie worden aangesproken door een Applicatieregister raadplegend systeem. De services Opvragen van zorgaanbiederapplicatie details, Wijzigen applicatie, Toevoegen applicatiesysteemrol en Wijzigen applicatiesysteemrol worden aangesproken door een Applicatieregister bewerkend systeem.
Tot slot worden de services Verifiëren communicatiekoppeling en Verifiëren applicatiekoppeling aangeroepen door een Koppeling verifiërend systeem. Het Koppeling bevestigend systeem geeft antwoord op deze service-aanvragen.
De samenhang tussen alle componenten is weergegeven in diagram LSP.APR.d1010..De services en functies worden uitgebreid beschreven in paragraaf Primaire services.
Beheerder ZIM beheert het APR via de User interface beheerder. Deze beheerder krijgt via de AORTA-kwalificaties en –publicatie en GBx–beheerders informatie om de applicatiegegevens in te stellen binnen het APR. Het gaat daarbij om systeemrollen en de ondersteuning van interacties uit de AORTA release documentatie.
De kwalificatiegegevens komen vanuit het kwalificatieteam, die bijhouden welke versie van een XIS-applicatie voor welke systeemrollen is gekwalificeerd.
Naast externe raadplegingen is het ook mogelijk dat APR-services intern worden getriggerd door andere componenten binnen de ZIM. Interne interfaces vallen buiten bereik van dit document. De services die functioneel worden uitgewisseld tussen/met andere componenten worden wel opgenomen in paragraaf 5.2 Interfaces (koppelvlakken)
In onderstaande tabellen wordt per systeemrol aangegeven welke berichten en via welke interface de systeemrol kan uitwisselen met het APR. In sommige gevallen wordt er een response gegeven vanuit de APR component.
Tabel 1 LSP.APR.t1010 : Interactie tussen Applicatie Raadplegend Systeem en Service
|
Logisch bericht |
Interface |
Response bericht |
APR Service |
|
Opvragen zorgaanbiederapplicatie |
OpleverenzorgaanbiederApplicatie |
Opvragen van zorgaanbiederapplicatie |
|
|
opvragen InteractieVersie |
Opvragen interactieversie |
Opleveren InteractieVersie |
Opvragen hoogst ondersteunde interactieversie |
Tabel 2LSP.APR.t1030: Interacties tussen Koppeling verifiërend Systeem en Service
|
Logisch bericht |
Interface |
Response bericht |
APR Service |
|
Verifiëren Applicatie Koppeling |
Verifiëren
applicatiekoppeling |
verifiërenApplicatie Koppeling antwoord (Pong) |
Verifiëren applicatie koppeling (ping – pong) |
|
Verifiëren CommunicatieKoppeling |
Verifiëren communicatie
koppeling |
verifiërenCommunicatieKoppeling antwoord (Tock) |
Verifiëren communicatie Koppeling (tick – tock) |
Tabel 3 LSP.APR.t1040 : Interacties tussen Koppeling bevestigend Systeem en Service
|
Logisch bericht |
Interface |
Response bericht |
APR Service |
|
Verifiëren Applicatie Koppeling antwoord (pong) |
Verifiëren applicatiekoppeling |
Niet van toepassing |
Verifiëren applicatie koppeling (ping – pong) |
|
Verifiëren Communicatie koppeling antwoord (tock) |
Verifiëren communicatiekoppeling |
Niet van toepassing |
Verifiëren communicatie |
De interfaces moeten de berichten die naar het APR worden gestuurd kunnen verwerken. Verschillende attributen in de berichten zijn daarom verplicht of worden aangemerkt als optioneel. Hieronder volgt in de tabellen per logisch bericht een beschrijving van de verplichte of optionele attributen. Het verplichte of optionele karakter van een attribuut wordt weergegeven door middel van de minimum kardinaliteit.
Onderstaand diagram LSP.APR.d1060 toont welke interacties in welke volgorde plaatsvinden voor deze interface van het APR.
De interface ‘opvragen zorgaanbieder applicatie’ kan worden aangeroepen vanuit de module ‘applicatieregister raadplegend systeem’ van een op de ZIM aangesloten GBx.
Het doel van de interface is om de applicatie van een zorgaanbieder op te vragen die aan bepaalde zoekcriteria voldoen.
Diagram LSP.APR.d1060 Afhandelen interface opvragen zorgaanbiederapplicatie
Tabel 4 LSP.APR.t1050: opvragenZorgaanbiederApplicatie-bericht
|
Attribuut |
Inhoud |
|
organisatie-id (0..1) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. |
|
interaction-id (0..1) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. |
|
Systeemrolcode (0..1) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. |
Opmerking minimaal één van de attributen moeten aanwezig zijn in het opvragenZorgaanbiederApplicatie-bericht.
Tabel 5 LSP.APR.t1060: opleverenZorgaanbiederApplicatie-bericht
|
Attribuut |
Inhoud |
|
organisatie-id (1) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. |
|
applicatie-id (1) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. |
|
Systeemrolcode (1) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. |
|
actiemodus (1) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. |
|
Systeemrolstatus (1) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. |
|
URI (1) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. op basis van FQDN. Dus https://FQDN. |
|
HL7v3 Conformanceregel (1..n) |
Zie paragraaf 6.1 en diagram LSP.APR.d2030. |
Diagram LSP.APR.d1040 toont de werking van interface LSP.APR.i1060. De interface ‘opvragen interactieversie’ kan worden aangeroepen vanuit de module ‘applicatieregister raadplegend systeem’ van een op de ZIM aangesloten GBx.
Het doel van de interface is om voor een set van op de ZIM aangesloten GBx’en op te vragen wat de hoogste versie is van een bepaalde interactie die door die gehele set van aangesloten systemen, inclusief het interactie-initiërend systeem, wordt ondersteund. Op deze wijze kan worden vastgesteld welke interactieversie succesvol door alle betrokken systemen kan worden verwerkt.
Bij het aanroepen van de interface worden als parameters opgegeven:
Of:
De ZIM-orchestratieservice ontvangt het bericht, doet de standaard berichtcontroles en roept de APR-service ‘Opvragen van hoogst ondersteunde interactieversie’ aan.
In het geval dat de te sturen interactie een opvraaginteractie is, zal geen applicatie-id in het bericht aanwezig zijn. De applicaties moeten dan worden bepaald op grond van de verwijsindex; het APR vraagt de applicaties op bij de verwijsindex op basis van de opgegeven patiënt-id en gegevenssoort (die eerst moet worden afgeleid uit het interactie-id).
Het APR stelt nu vast wat de hoogste versie is van de gevraagde interactie die wordt ondersteund door:
Het APR geeft het antwoord terug aan de ZIM-orchestratieservice die het antwoord teruggeeft aan het ‘applicatie raadplegend systeem’.
Diagram LSP.APR.d1040 – opvragen interactieversie
Tabel 6 LSP.APR.t2020: opvragen-interactieversie-bericht
|
Attribuut [1] |
Inhoud |
|
interaction-id (1) |
Het id van de interactie waarvan de hoogste gemeenschappelijke versie moet worden bepaald (het versienummer is onderdeel van het interactie-id) |
|
applicatie-id (0..1) |
De applicatie waarvoor moet worden nagegaan wat de hoogste versie is van de interactie die wordt ondersteund door zowel de gegeven applicatie en de afzender. |
|
Patiënt-id (0..1) |
Het burgerservicenummer van een patiënt; de ZIM kan op basis van dit BSN zelf via de verwijsindex vaststellen welke set van applicaties relevante gegevens bevat voor het opgegeven interactie-id. |
|
Actualiteit (0..1) |
Aanduiding van de actualiteit van de voor de patiënt aangemelde gegevens, op basis waarvan de lijst van applicaties waarvoor de versie-controle relevant is, kan worden ingeperkt. Het gaat hierbij om de in de VWI geregistreerde Actualiteit GBZ. |
Tabel 7 LSP.APR.t2030: opleveren-interactieversie-bericht
|
Attribuut |
Inhoud |
|
interaction-id (1) |
Het id van de interactie dat de hoogste ondersteunde versie aangeeft (het versienummer is onderdeel van het interactie-id) |
Merk op dat het interactie-id wordt opgehoogd naar een nieuwe versie indien de berichtdefinitie structureel is gewijzigd. Het interactie-id kan dus over AORTA-versies heen ongewijzigd blijven.
Voor het verifiëren van een applicatiekoppeling wordt een verifiëren applicatiekoppeling bericht verstuurd door een koppeling verifiërend systeem, zoals weergegeven in sequencediagram LSP.APR.d1090. Dit bericht wordt afgehandeld door de interface Verifiëren applicatiekoppeling. De ZIM-orchestratieservice ontvangt het bericht, doet de standaard berichtcontroles en zet het bericht door naar bestemmingsapplicatie zoals in het bericht genoemd. Het systeem dat dit bericht moet ontvangen is het koppelingsbevestigend systeem.
Diagram LSP.APR.d1090 – Afhandelen interfaces voor verifiëren applicatie-/communicatiekoppeling
Voor het verifiëren van de communicatiekoppeling geldt een vergelijkbare afhandeling als bij verifiëren applicatiekoppeling. Zie weergave in sequencediagram LSP.APR.d1090.
De interface ‘wijzigen applicatiesysteemrol’ kan worden aangeroepen vanuit de module ‘applicatieregister bewerkend systeem’ van een op de ZIM aangesloten GBx. Deze inter face geeft de beheerder de om de status van een aan de applicatie toegekende systeemrol te wijzigen. Daarnaast biedt deze interface de mogelijkheid om de geregistreerde XIS-kwalificatie te wijzigen.
Diagram LSP.APR.d1210 toont welke interacties er voor toevoegen applicatiesysteemrol in welke volgorde plaatsvinden voor deze interface van het APR. Voor de interface wijzigen applicatiesysteemrol is de berichtafhandeling hetzelfde. Bij deze interactie zijn twee antwoorden mogelijk. Een bevestiging, als de wijziging is doorgevoerd of een afwijzing als de wijziging niet is doorgevoerd.
Tabel LSP.APR.t2060: wijzigen applicatiesysteemrol
|
Attribuut |
Inhoud |
|
applicatie-id (1)
|
De applicatie identificatie van het systeem waar een systeemrol gewijzigd moet worden Zie verder paragraaf 6.1 |
|
Systeemrolcode (1) |
Een identificatie van een systeemrol, die is toegekend aan een bepaalde set aan interacties. Zie paragraaf 6.1 |
|
Status systeemrol (1) |
Zie paragraaf 6.1 |
|
XIS-kwalificatie-ID (1) |
Zie paragraaf 6.1 |
Tabel LSP.APR.t2070: Accepteren/Afwijzen- applicatiesysteemrolverzoek-bericht
|
Attribuut |
Inhoud |
|
Systeemrolcode (1) |
Zie paragraaf 6.1 |
|
applicatie-id (1) |
Niet wijzigbaar, zie verder paragraaf 6.1 |
De interface ‘toevoegen applicatiesysteemrol’ kan worden aangeroepen vanuit de module ‘applicatieregister bewerkend systeem’ van een op de ZIM aangesloten GBx en geeft de mogelijkheid aan een beheerder van het aangesloten informatiesysteem om de ondersteuning van een systeemrol door de applicatie aan te geven.
Onderstaand sequencediagram LSP.APR.d1210 toont welke interacties er in welke volgorde plaatsvinden voor de afhandeling van toevoegen applicatiesysteemrol interface van het APR. Bij deze interactie zijn twee antwoorden mogelijk. Een bevestiging, als de wijziging is doorgevoerd of een afwijzing als de wijziging niet is doorgevoerd.
Diagram LSP.APR.d1210 – Afhandelen interface toevoegen applicatiesysteemrol
Tabel LSP.APR.t2040: toevoegen applicatiesysteemrol
|
Attribuut |
Inhoud |
|
Systeemrolcode (1) |
Zie paragraaf 6.1 |
|
applicatie-id (1) |
Niet wijzigbaar, zie verder paragraaf 6.1 |
|
Status systeemrol |
Zie paragraaf 6.1 |
|
XIS-kwalificatie-ID |
Zie paragraaf 6.1 |
Tabel LSP.APR.t2050: Accepteren/Afwijzen- applicatiesysteemrolverzoek-bericht
|
Attribuut |
Inhoud |
|
Systeemrolcode (1) |
Zie paragraaf 6.1 |
|
applicatie-id (1) |
Niet wijzigbaar, zie verder paragraaf 6.1 |
De functie beheerservice APR is de eindgebruiker interface voor LSP-beheerders in de rol van kwalificatiebeheerder en beheerder van het APR. Via deze beheerservice kunnen nieuwe XIS-typekwalificatie, systeemrollen en applicatie-id’s worden toegevoegd..
De beheerservice maakt het mogelijk om de status van een specifieke applicatie-id te blokkeren. in het geval de applicatie fouten veroorzaakt of beschikbaarheid van de ZIM beïnvloed.
Bij een wijziging van de XIS-typekwalificatie geldt dat de betreffende applicaties geen andere HL7-interacties kunnen uitvoeren dan de XIS-typekwalificatie toe staat.
De functies die het APR beschikbaar stelt aan de buitenwereld zijn opgedeeld in primaire services en beheerfuncties.
Aan de hand van activiteitsdiagrammen beschrijft hoofdstuk 5.1 de services en de functies die het APR beschikbaar stelt.
Hoofdstuk 5.2 beschrijft de beheerfuncties die het APR beschikbaar stelt.
In de onderstaande activiteitendiagram LSP.APR.d1010. zijn de afzonderlijke stappen weergeven die binnen het APR doorlopen worden om de service ‘Opvragen zorgaanbiederapplicatie’ in te vullen.
Voordat het bericht wordt verwerkt worden er een aantal attributen gecontroleerd. De controles en de eventuele foutmeldingen die worden opgenomen in het antwoordbericht zijn opgenomen in de onderstaande tabel.
Tabel 8 LSP.APR.t2220 – Controles tijdens opvragenZorgaanbiederApplicatie
|
Attribuut |
Controle |
Foutmelding |
|
applicatie-id |
Bevat het zoekresultaat meer dan zim-max-opleveren-zorgaanbiederapplicaties aantal applicatie-id’s |
Zoekresultaat bevat teveel gegevens. U dient het zoekresultaat te beperken door de zoekcriteria te verfijnen. |
Diagram LSP.APR.d1010: Opvragen zorgaanbiederapplicatie
Het activiteitendiagram LSP.APR.d1140.1 geeft de afzonderlijke stappen weer die binnen het APR worden doorlopen bij het uitvoeren van de service ‘Opvragen hoogst ondersteunde interactieversie’.
Na het uitvoeren van de gebruikelijke berichtcontroles zoals aangegeven in [Arch AORTA] controleert het APR eerst of de opgegeven interactie wel bekend en/of ondersteund wordt door de ZIM zo niet dan volgt een foutmelding. Vervolgens bepaalt de service of een applicatie is opgegeven als argument. In dat geval wordt gecontroleerd of het opgegeven applicatie-id bekend is binnen de ZIM, zo niet dan volgt een foutmelding.
Als dat niet het geval is, dan moet het zoekargument een patiënt-id zijn .
Het APR zoekt via de functie Zoek gegevenssoort bij interactie van de VWI bij de opgegeven interactie de gegevenssoort en vraagt vervolgens bij de verwijsindex op door welke applicaties patiëntgegevens van deze gegevenssoort zijn aangemeld voor het gegeven patiënt-id en eventueel opgegeven tijdspanne. De te controleren applicaties zijn daarmee bekend.
In het geval dat zowel geen applicatie-id als patiënt-id wordt meegegeven als parameter krijgt de applicatie een foutmelding “De vraag voldoet niet aan de gestelde business rules”.
Vervolgens wordt per applicatie gecontroleerd of de interactieversie van de afzender wordt ondersteund. Zodra één applicatie wordt gevonden die alleen een lagere interactieversie ondersteunt, is verder controleren van de interactieversies van de applicaties niet nodig; de lagere versie kan nu als antwoord worden geretourneerd aan de afzender (de ZIM ondersteunt maximaal 2 versies; een nog lagere versie kan dus niet worden gevonden).
Indien blijkt dat alle applicaties de versie van de afzender ondersteunen wordt de versie van de afzender als antwoord gegenereerd.
Een bijzondere situatie doet zich voor als één of meer applicaties noch de interactieversie van de afzender, noch een lagere interactieversie ondersteunen. De gemeenschappelijk ondersteunde versie is dan onbepaald.
Indien het applicatie-id is opgegeven in de query en de versie is onbepaald, dan wordt dit teruggemeld aan de afzender, zie activiteitendiagram LSP.APR.d1140.1.
Indien het applicatie-id niet is opgegeven, is sprake van een opvraaginteractie. Indien in dit geval door één of meer applicaties geen enkele versie van de interactie wordt ondersteund, dan kunnen deze applicaties voor het resultaat genegeerd worden, aangezien een opvraaginteractie toch niet aan deze applicaties zal worden doorgestuurd. Het resultaat is dat de hoogste gemeenschappelijke versie wordt geretourneerd die wordt ondersteund door alle applicaties (inclusief de afzender) die tenminste één versie ondersteunen.
Tabel 9 LSP.APR.t2230 – Controles tijdens opvragen interactieversie
|
Attribuut |
Foutsituatie |
Herstelacties |
Foutmelding |
|
applicatie-id of patiënt-id |
Een van beide argumenten ontbreekt in de vraag |
Het gewenste argument toevoegen in de vraag. |
code=”BUS” |
|
applicatie-id of patiënt-id |
Vraag is niet eenduidig |
Eén van argumenten, applicatie-id of patiënt-id, gebruiken in de vraag. |
code=”BUS” |
|
interaction-id |
Onbekend interactie-id |
Vraag nogmaals stellen met een wel ondersteunde interaction-id |
code="HL7INTERACTIONNOTSUPPORTED" "HL7 interactie %1 zal niet tot een antwoord leiden, omdat deze niet wordt ondersteund." |
|
applicatie-id |
Applicatie-id onbekend |
Eerst een applicatie-id achterhalen via Opvragen zorgaanbiederapplicatie |
code="APPUNKNOWN" |
Om de eerst lagere interactieversie te kunnen vinden houdt het APR een configuratietabel bij waarin voor elke interactie-id-versie wordt bijgehouden wat de vorige interactie-id-versie is.
Diagram LSP.APR.d1140.1 – inhoudelijke afhandeling versiecontrole
In de onderstaande activiteitendiagram LSP.APR.d2020 zijn de afzonderlijke stappen weergeven die binnen het APR doorlopen worden om de service ‘Opvragen van zorgaanbiederapplicatie details’ in te vullen. In het diagram is aangegeven dat bepaalde gegevens gefilterd worden uit het antwoord. Zo wordt de naam van het softwareproduct uit het antwoord gefilterd als de vragende applicatie niet tot dezelfde GBX behoort als de applicatie die de vraag stelt.
Voordat het bericht wordt verwerkt wordt het attribuut applicatie-id gecontroleerd. De controles en de eventuele foutmeldingen die worden opgenomen in het antwoordbericht zijn opgenomen in de tabel LSP.APR.t2160.
Tabel LSP.APR.t2160 Controles Fout! Verwijzingsbron niet gevonden.
|
Attribuut |
Controle |
Foutmelding |
|
applicatie-id |
Het resultaat bevat meer dan zim-max-opleveren-zorgaanbiederapplicaties aantal applicatie-id’s |
Zoekresultaat bevat teveel gegevens. Als er behoefte is aan meer specifieke resultaten, voer meer parameters in. |
|
applicatie-id |
Het resultaat bevat minder dan één applicatie-id |
ZIM kan op basis van zoekcriteria geen match vinden in applicatieregister |
|
applicatie-id |
applicatie-id uit het bericht bestaat niet in het APR |
ZIM kan opgegeven applicatie niet vinden in het applicatieregister |
Diagram LSP.APR.d2020 – inhoudelijke afhandeling service opvragen zorgaanbiederapplicatie details
Het activiteitendiagram van de service ‘Wijzigen applicatie’ is weergegeven in diagram LSP.APR.d1120. De afzonderlijke stappen die binnen de component APR doorlopen zijn weergegeven om de service Wijzigen applicatie in te vullen.
Diagram: LSP.APR.d1120.1 Afhandelen interface Wijzigen applicatie
In het activiteitendiagram zijn de controles weergegeven op de applicatie wijzigingsopdracht. De allereerste stap haalt de huidig geregistreerde applicatiegegevens op van het opgegeven applicatie-id. De allereerste controle is of de betreffende applicatie de status geblokkeerd heeft. Deze status kan alleen ingesteld worden via de beheer service van het APR. Het betreft het applicatie attribuut geblokkeerd door LSP-beheerder is waar of de GBX koppelingsstatus is (Geblokkeerd of Afgesloten). Deze blokkering heeft tot gevolg dat er geen wijziging doorgevoerd kan worden.
In de volgende controle wordt bepaald of de te wijzigen applicatie onderdeel is van het geverifieerde GBZ. Dit komt neer dat de applicatie die het wijzigingsverzoek verstuurt , dezelfde applicatie is of onder hetzelfde GBZ valt.
Dat is het geval als de applicatie die het wijzigingsverzoek stuurt dezelfde applicatie is, of als deze deel is van hetzelfde GBZ.
De volgende test controleert of er een geldige statuswijziging wordt gevraagd. Geldige statuswijzigingen zijn:
- actief naar inactief met de mededeling (Onderhoud of Storing)
- inactief naar actief
Als de status hetzelfde blijft of de mededeling bij inactief wordt gewijzigd zijn dit ook geldige statuswijzigingen.
De toevoeging mededeling onderhoud of storing is alleen relevant en van toepassing als de applicatie de status inactief krijgt of heeft.
Als de applicatie wijzigingsopdracht door alle controles is heen gekomen, wordt de betreffende wijzigingsopdracht doorgevoerd in het applicatieregister en wordt een acceptatie bericht teruggestuurd. In de andere gevallen wordt een afwijzingsbericht verzonden.
In het activiteitendiagram LSP.APR.d1240 zijn de afzonderlijke stappen weergegeven die binnen het APR doorlopen worden om de service ‘Verifiëren applicatiekoppeling’ in te vullen.
Bij binnenkomst van een verificatiebericht wordt na de controles het verificatiebericht (verifiëren applicatiekoppeling of verifiëren communicatiekoppeling) door gezonden naar de APR service verifiëren applicatiekoppeling. Daarna wordt gekeken of de bestemming de ZIM betreft, zo niet dan vindt nog een controle plaats door het applicatieregister te raadplegen voor de bestemmingsapplicatie. Als de status van de applicatie actief is wordt het betreffende bericht doorgezonden.
De ZIM kan zelf ook verificatie berichten versturen en ontvangen en daarmee de beide systeemrollen vervullen. Bij het versturen van deze berichten zal de status van de applicatie waarnaar de ZIM deze berichten stuurt niet gecontroleerd worden. Dit om het mogelijk te maken de bereikbaarheid te verifiëren met de ingestelde waarde in het applicatieregister en om de beschikbaarheid van andere applicaties te monitoren.
Diagram LSP.APR.d1240 : Verifiëren applicatie- / communicatiekoppeling
In activiteitendiagram LSP.APR.d1240 zijn de afzonderlijke stappen weergeven die binnen het APR doorlopen worden om ook de service ‘Verifiëren communicatiekoppeling’ in te vullen. Deze stappen zijn hetzelfde als bij het afhandelen van Verifiëren applicatiekoppeling.
In activiteitendiagram LSP.APR.d1180 zijn de afzonderlijke stappen weergeven die binnen het APR doorlopen worden om ook de service ‘Wijzigen applicatiesysteemrol’ in te vullen.
Diagram LSP.APR.d1180 : activiteitendiagram wijzigen applicatiesysteemrol
De eerste controle bekijkt of de te wijzigen applicatie overeenkomt met de afzender.
De tweede controle bekijkt of de gebruikte systeemrol en XIS-kwalificatie-id al wel geregistreerd zijn in het applicatieregister, zie 5.2.1 en 5.2.2.
De derde controle bekijkt of de te wijzigen applicatie niet geblokkeerd is door een LSP-beheerder of dat de GBX koppelingsstatus (Afgesloten of Geblokkeerd) is zie 5.2.
De volgende controles zijn functioneler:
· controle of de systeemrol al is geregistreerd als onderdeel van dit applicatie-id;
· controle of de systeemrol en XIS-kwalificatie-id bij elkaar horen;
· laatste controle bekijkt of de statusovergang van een systeemrol wel voldoet aan de spelregels.
Valide statusovergangen zijn:
De status beëindigd (terminated) kan alleen via de beheerinterface ingesteld
worden.
In activiteitendiagram LSP.APR.d1190 en LSP.APR.d1180 zijn de afzonderlijke stappen weergeven die binnen het APR doorlopen worden om ook de service ‘Toevoegen applicatiesysteemrol’ in te vullen.
De eerste controle bekijkt of de te wijzigen applicatie overeenkomt met de afzender.
De tweede controle bekijkt of de gebruikte systeemrol en XIS-typekwalificatie-id al wel geregistreerd zijn in het applicatieregister, zie paragraaf 5.2.1 en 5.2.2.
De derde controle bekijkt of de te wijzigen applicatie niet geblokkeerd is door een LSP-beheerder of dat de GBX koppelingsstatus (Afgesloten of Geblokkeerd) is zie 5.2.
De volgende controles zijn functioneler:
· Controle of de systeemrol nog niet is geregistreerd als onderdeel van dit applicatie-id
· Controle of de systeemrol en XIS-kwalificatie-id bij elkaar horen
· Laatste controle bekijkt of de status van een systeemrol wel voldoet aan de spelregels.
Valide statussen bij het toevoegen van een systeemrol zijn:
Het toevoegen van een applicatiesysteemrol met de status beëindigd (terminated) is niet mogelijk.
Diagram LSP.APR.d1190 : activiteitendiagram toevoegen applicatiesysteemrol
In tabel LSP.APR.t2150 zijn de beheerfuncties beschreven die de LSP-beheerder kan uitvoeren op het APR. De beheerder kan de functies op de APR uitvoeren via de ZIM-beheerapplicatie (ZBA). De ZBA heeft een interface met de beheerservice APR in het APR component.
Tabel LSP.APR.t2150 – APR Beheerfuncties
|
Beheersfunctie |
Type gebruikersinterface |
Beschrijving |
|
Toevoegen wijzigen systeemrollen, XIS-kwalificaties, |
Beheerderinterface |
Het vullen van stamtabellen, die het uitgangspunt zijn voor een AORTA-release en kwalificatie gegevens van een XIS. |
|
Toevoegen, wijzigen van GBx’en |
Beheerderinterface |
Het toevoegen, wijzigen van GBZ’en inclusief de bijbehorende applicaties identifiers, koppeling met een ZSP en opt-in registratie. |
|
Toevoegen, toekennen en wijzigen samenwerkingsverbanden |
Beheerderinterface |
Met deze beheersfunctie kan de LSP-beheerder samenwerkingsverbanden tabellen toevoegen en toekennen aan een organisatie. |
|
Verwijderen verwijzingen ZSP-gegevens |
Beheerderinterface |
ZSP-kwalificatie gegevens registeren |
Daarnaast zal via de beheerfunctie op het applicatieregister ook:
Een LSP-beheerder van het APR krijgt vanuit de oplevering van een AORTA release of de oplevering van een release van een zorgtoepassing een nieuwe systeemrolprofiel. Deze systeemrolspecificatie geeft aan welke interacties-id’s hiervan onderdeel uitmaken en de betreffende interactie verzonden, ontvangen of beide moet kunnen worden.
Vanuit het XIS-typekwalificatie proces komt de mededeling dat een specifieke versie van een XIS-softwarepakket is gekwalificeerd voor een systeemrol. Vanuit het typekwalificatie proces is aangegeven wat de betreffende XIS-applicatie ondersteund op het moment van kwalificeren. De kwalificatiemanager zal voor alle interacties in de specifieke modus, ontvanger of verzender moeten vastleggen of de XIS-typekwalificatie deze ondersteund.
De LSP-beheerder van het APR geeft na registratie een XIS-typekwalificatie-ID uit en registreert de begindatum van de kwalificatie.
Een LSP-beheerder voegt daarbij de gewenste einddatum in voor het einde van de XIS-typekwalificatie.
De consequentie is dat alle geregistreerde applicaties na deze ingevoerde einddatum van typekwalificatie geen gebruik meer kunnen maken van de betreffende XIS-typekwalificatie-ID en op dat moment geblokkeerd moeten worden voor het gebruik van deze systeemrol(len).
Een kwalificatiebeheerder krijgt vanuit het kwalificatie/aansluit proces de melding dat een zorgaanbieder gekwalificeerd is om een set van systeemrollen te mogen gebruiken. Vanuit het kwalificatieproces krijgt hij daartoe de gegevens met betrekking tot deze applicatie, zoals de systeemrollen, de betreffende ZSP-leverancier voor de koppeling, het te gebruiken UZI/PKIO-servercertificaat, FQDN, applicatie-id en XIS-typekwalificatie-id’s. Op basis van deze gegevens wordt de betreffende applicatie geregistreerd en krijgt de betreffende applicatie de status actief.
Bij een wijziging aan een actieve applicatie waarbij al verwijzingen in de VWI
geregistreerd zijn zal voor de wijziging van de betreffende instelling
geverifieerd moeten zijn dat de geregistreerde verwijzingen nog op te vragen
zijn. Dit om de integriteit en volledigheid van de VWI te waarborgen.
Voor het verwijderen, het permanent deactiveren, van een applicatie in het APR moeten een aantal controles uitgevoerd worden. Zo zal bij een wijziging aan een actieve applicatie voor de verwijdering geverifieerd moeten zijn of de applicatie nog geregistreerde verwijzingen heeft. Als dit het geval is zal allereerst via de GBZ-beheerder verzocht moeten worden om deze verwijzingen te laten afmelden.
De LSP-beheerder krijgt samenwerkingsverbanden aangeleverd met daarin alle benodigde attributen. Het samenwerkingsverband-id dient, bij elke in de tabel voorkomende organisatie, in de lijst met samenwerkingsverbanden te worden toegevoegd. Aanpassingen aan een samenwerkingsverband dienen verwerkt te worden in de samenwerkingstabel en eventueel ook in de lijst met samenwerkingsverbanden die gekoppeld is aan een organisatie.
Daarnaast dient een LSP-beheerder, op verzoek van een zorgaanbieder, op te nemen of een organisatie zijn gegevens landelijk beschikbaar wil stellen of juist niet.
Het toevoegen, toekennen en wijzigen van samenwerkingsverbanden zou ook geautomatiseerd afgehandeld kunnen worden.
In deze paragraaf is het logische gegevensmodel voor het APR aangeduid. Daarnaast zijn in deze paragraaf de bijbehorende attributen in het gegevensmodel beschreven.
Het gegevensmodel, zie LSP.APR.d2030., voor het APR bevat gegevens van alle gekwalificeerde GBx’en en hun bijbehorende ZSP koppeling Daarnaast zijn ook specifieke gegevens voor de connectie en het servercertificaat opgenomen.
In diagram LSP.APR.d2030. is een applicatie het centrale gegeven met al zijn associaties weergegeven.
Diagram LSP.APR.d2030.5: Gegevensmodel applicatieregister.
Het gegevensmodel LSP.APR.d2030. geeft de verschillende relaties aan tussen de objecten. De in dit gegevensmodel gebruikte attributen zijn in de onderstaande tabellen toegelicht. Hierbij is per entiteit in het model een tabel opgenomen. Centraal in dit gegevensmodel is de entiteit Applicatie weergegeven. Deze entiteit heeft relaties met XIS-kwalificatie en een ZSP-profiel. Elke applicatie heeft per systeemrol een status. Deze met de applicatie gekoppelde systeemrol wordt gerealiseerd door een XIS-kwalificatie.
De registratie van alle zorgaanbieders gegevens vindt plaats in het ZAB, zie [Ontw ZAB].
Tabel 10 LSP.APR.t2210: Gegevensmodel Applicatieregister
|
Applicatie |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
applicatie-id (1) |
Unieke identifier van applicatie, zie [HL7v3 IH Wrp] |
|
|
actiemodus (1) |
actiemodus |
De mogelijke statussen zijn:
Zie ook 5.2.5 Gebruiksscenario verwijderen applicatie |
|
applicatie-naam (1) |
naam van de applicatie zoals bekend bij de daarvoor verantwoordelijke organisatie |
Bijvoorbeeld: Politheeksysteem of sys2034 |
|
aanmeldbevoegdheid (1) |
Indicatie (Ja/Nee (=verstekwaarde)) of de applicatie gegevens bij de VWI mag aanmelden |
Geeft aan of de GBZ-applicatie voldoet aan de eisen voor opt-in. De applicatie die hieraan voldoet kan nieuwe aanmeldingen in VWI registreren. |
|
Indicatie of de betreffende applicatie te wijzigen is door GBX-beheerder door middel van berichten. |
Bestaande functionaliteit, welke door het niet gebruiken van de wijzigingsberichten geen functie heeft. |
|
|
ingestelde authenticatiewijze (1) |
de authenticatiewijze (ofwel AORTA/UZI-tokenauthenticatie danwel
SAML2/PKIO-tokenauthenticatie danwel sessieauthenticatie) waarvoor de
applicatie is ingesteld Voor het GBP dient de authenticatiewijze bij eerste realisatie te worden ingesteld op BSN-tokenauthenticatie |
Voor een GBK, GBP en een GBO moet deze niet instelbaar zijn voor de authenticatiewijze AORTA/UZI tokenauthenticatie. |
|
intern gastgebruik toegestaan (1)[2] |
Voor een GBZ: Indicatie (Ja/Nee (=verstekwaarde)) dat intern gastgebruik is toegestaan |
(Ja/Nee (=verstekwaarde)). De instelling Intern gastgebruik is toegestaan (Ja), is alleen mogelijk in combinatie met de tokenauthenticatie als de ingestelde authenticatiewijze. |
|
Voor een GBZ: het UZI-nummer van het servercertificaat; Voor het GBK/GBP: een PKIO-servercertificaatnummer van het systeem |
Voor het GBO wordt geen servercertificaatnummer opgeslagen. Het certificaatnummer voegt geen extra waarde toe en leidt alleen maar tot extra beheerlast. |
|
|
Full Qualified Domain Name; de volledige hostnaam van de applicatieserver zoals deze in de domain name services en op het certificaat geregistreerd is. |
|
|
|
port (0..1) |
TCPIP port nummer waarop de applicatie bereikbaar is |
Port nummer kan alleen gebruikt worden in testomgevingen. Voor productieomgeving is deze met een standaardwaarde gevuld. |
|
prefixServicePath (0..1) |
Een standaard prefix die gebruikt moet worden om de webservice van de applicatie te benaderen |
Deze prefix kan in testomgevingen gebruikt om eenvoudig te schakelen tussen verschillende applicaties. Voor productieomgeving is deze leeg met uitzondering van de SBV-Z koppeling. |
|
opmerkingen (0..n) |
Vrije tekst |
|
|
Samenwerkingsverbanden |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
Samenwerkingsverband-id |
Unieke identificatie voor het samenwerkingsverband. |
Dit kunnen samenwerkingsverbanden zijn waarin de organisatie zelf voor komt, samenwerkingsverbanden die een uitzondering vormen op regionalisatie (zoals ziekenhuizen) of samenwerkingsverbanden waarmee een partnerschap mee is afgesloten. |
|
Naam samenwerkingsverband |
De naam van het samenwerkingsverband. |
|
|
zorgaanbieder-id lijst |
Een lijst met zorgaanbieders (op basis van organisatie-id’s) die binnen het samenwerkingsverband opvragingen kunnen doen. |
|
|
Gegevenssoort(en) |
Typering van een soort van patiëntgegevens. |
Het samenwerkingsverband kan alleen patiëntgegevens uitwisselingen met de in het samenwerkingsverband opgenomen gegevenssoort(en). |
|
GBX |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
GBx-id (1) |
een identificatie van het GBx |
|
|
koppelingsstatus (1) |
Aanduiding of het GBx als geheel gekoppeld is |
Een GBx kan de volgende koppelingstatussen hebben:
Alleen applicaties van GBx die de status Opengesteld kunnen berichten versturen of ontvangen. |
|
GBX-naam(1) |
naam van het GBx zoals bekend bij die organisatie |
|
|
type (GBK/GBP/GBZ/GBO) |
Aanduiding of de gekwalificeerde organisatie-eenheid een GBP, GBK, GBZ of GBO betreft |
|
|
Organisatie |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
organisatie-id (1) |
UZI-register abonneenummer voor de betreffende zorgaanbieder |
Voor GBK, en GBP is deze niet gevuld. Voor een GBO is dit veld gevuld met een organisatie-id uitgegeven door het LSP. |
|
organisatie-naam (1) |
naam van de organisatie die verantwoordelijk is voor het systeem |
Komt overeen met de formele naam van de zorginstelling geregistreerd bij het UZI-register, PKIO-CA. |
|
Landelijk uitwisseling(1) |
Het is mogelijk om gegevens landelijk beschikbaar te stellen. |
Initieel zal een organisatie zijn gegevens niet landelijk beschikbaar stellen. |
|
ZSP-profiel (per aangesloten DCN) |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
DCN-naam (1) |
naam van het DCN zoals bekend bij de ZSP en de aangesloten partij(en) |
|
|
IP-adresreeks DCN (1..n) |
IP-adresreeks voor het DCN |
|
|
kwalificatieniveau (1) |
refereert aan een bepaald AORTA release |
|
|
opmerkingen (0..n) |
Vrije tekst |
|
|
Systeemrol status |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
activatie begindatum (1) |
Datum initiële activatie |
|
|
activatie einddatum (1) |
Datum beëindiging systeemrol |
Alleen van belang bij definitief beëindigen van systeemrol (terminated) |
|
status (1) |
Ingestelde status van de betreffende systeemrol |
Het attribuut status van Systeemrol status kan alleen de waarden "Actief" en "Inactief" bevatten. Alleen dit attribuut bepaald of een systeemrol actief is, de attributen begin- en einddatum worden hierbij genegeerd. |
|
Systeemrolcode (1) |
Verwijzing naar stamgegevens van de betreffende systeemrol |
|
|
XIS-Applicatie |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
Ondersteunde authenticatiewijze (1 ..) |
Welke authenticatiewijze de XIS-kwalificatie ondersteunt |
Mogelijkheden: sessieauthenticatie of; tokenauthenticatie of beide. |
|
XIS-applicatienaam (1) |
Voor een applicatie zoals gevoerd door de leverancier |
Bijvoorbeeld: Scipio, Mira, ApoSys of CS-Ezis |
|
XIS-leveranciernaam (1) |
Naam van de applicatie leverancier |
|
|
XIS-versienummer (1) |
Voor een applicatie |
|
|
XIS-kwalificatie |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
begindatum kwalificatie (1) |
Datum waarop de kwalificatie is afgegeven |
|
|
einddatum kwalificatie (1) |
Datum waarop de kwalificatie is beëindigd/verlopen |
|
|
Systeemrolcode (1) |
Verwijzing naar Systeemrolcode |
Een XIS-kwalificatie geldt voor één en niet meer dan één systeemrolcode |
|
XIS-typekwalificatie-id(1) |
Verwijzing naar de XIS-typekwalificatie van het XIS (1) |
Voor
een applicatieversie per systeemrol. |
|
Systeemrolprofiel |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
HL7v3-release (1) |
gebruikte HL7v3-release (Profile-ID) |
Bijvoorbeeld: 810 |
|
Systeemrolcode (1) |
Identifier voor betreffende systeemrol |
Bijvoorbeeld: Hwg.VHS.2011, zie tabel AORTA.ZO.t1020 |
|
Systeemrolnaam (1) |
Functionele naam systeemrol |
Bijvoorbeeld Medicatie raadplegend systeem |
|
Systeemrolversie (1) |
Versie aanduiding systeemrol |
Bijvoorbeeld 2011 |
|
HL7-Conformanceregel |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
interaction-id (1) |
Identifier voor de HL7-interactie |
Bijvoorbeeld MCCI_IN0001 |
|
Type HTTP-SOAP Binding (1) |
Enkel- of tweevoudig l gebonden binding |
HL7v3-opdracht en de HL7v3-bevestiging te binden op één paar van HTTP/SOAP-request en HTTP/SOAP-respons (enkelvoudige binding). Voor tweevoudig binding wordt elke HL7-interactie gebonden aan één HTTP/SOAP-request en HTTP/SOAP-respons paar. |
|
Ontvangen (verplicht) (1) |
Aanduiding of de systeemrol het ontvangen van de interactie moet ondersteunen |
|
|
Verzenden (verplicht) (1) |
Aanduiding of de systeemrol het verzenden van de interactie moet ondersteunen |
|
|
Interactie |
||
|
Attribuut |
Definitie |
Additionele informatie |
|
interaction-id huidige versie (1) |
Identifier voor de HL7-interactie |
Een interactie heeft altijd een huidige versie en kan een voorgaande versie hebben. In het kader van versiebeheer dient de voorgaande versie (indien nodig) ook ondersteund te worden. Een interactie kan in sommige gevallen ook getransformeerd worden naar een andere interactie. |
|
interaction-id voorgaande versie (1) |
Identifier voor de HL7-interactie |
|
De entiteiten XIS-kwalificatie, Systeemrolprofiel, Interactie en HL7-Conformanceregel zijn stamgegevens. Deze gegevens worden gevuld vanuit de kwalificatie van XIS en ZSP alsook door de oplevering van een systeemroldefinitie vanuit AORTA documentatie. Deze stamgegevens zijn alleen te vullen vanuit de beheerinterface van het applicatieregister.
De LSP-beheerder van het APR moet toegang hebben tot de XIS-typekwalificatie, systeemrolprofielen en GBx-kwalificatie. De LSP-beheerder dient op aangeven vanuit het kwalificatieproces deze profielen toe te voegen of te kunnen wijzigen.
De LSP-beheerder van het APR zal applicaties-id’s moeten toedelen. Daarnaast wijzigt deze beheerder via gebruikersinterface de status van een applicatie of van de GBx- kwalificatie/koppeling en kan deze applicatie ook blokkeren. Met dit laatste wordt bedoeld dat een GBx-beheerder die niet meer te kan wijzigen.
De LSP-beheerder van het APR moet samenwerkingsverbanden kunnen toevoegen, verwijderen en wijzigen. Dit moet gebeuren op aangeven van het Servicecentrum Zorgcommunicatie. Daarnaast moet het mogelijk zijn om in opdracht van een zorgaanbieder in te stellen dat landelijke uitwisseling wel/niet mogelijk is.
Voor het toevoegen/verwijderen van een organisatie aan een samenwerkingsverband dient er een pointer te worden opgenomen/verwijderd bij de betreffende organisatie.
De gebruiksscenario’s voor de beheerinterface zijn onderkend in 5.2
De configuratieaspecten die van belang zijn bij APR zijn weergegeven in de onderstaande tabel.
Tabel 11 LSP.APR.t2040: Configuratieparameters APR
|
Configuratieparameter |
Betekenis van parameter |
Datatype |
Domein (mogelijke waarden) |
|
Maximaal aantal terug te geven resultaten bij een Opleveren Zorgaanbieder applicatie -bericht |
Integer |
Positief |
Daarnaast zal het APR register gevuld moeten worden met systeemrollen en XIS-typekwalificatie’s. Zie hiervoor paragraaf 5.2
Het APR houdt een configuratietabel bij waarin van elk meest recente interactie-id wordt bijgehouden wat de voorgaande versie van dit interactie-id is die door AORTA wordt ondersteund.
Ook moet er een beheerfunctie zijn om in het applicatieregister via een beheerinterface de aanmeldbevoegdheid en whitelists te configureren. Deze functie moe de mogelijkheid bieden om de aanmeldbevoegdheid van applicaties te raadplegen en te wijzigen en whitelists te raadplegen, toe te voegen, te wijzigen en te verwijderen.
Het applicatieregister maakt onderdeel uit van de ZIM en heeft dezelfde beschikbaarheid eisen als deze hoofdcomponent.
Beveiliging
De wijzigingen aan attributen van een geregistreerde applicatie die door de interfaces wijzigen applicatie, wijzigen applicatiesysteemrol en toevoegen applicatiesysteemrol worden ondersteund dienen alleen vanuit de betreffende applicatie gewijzigd te kunnen worden.
Vertrouwelijkheid
Detail gegevens over applicatie zijn alleen voor de eigen organisatie van belang.
De interne structuur van de component moet door de leverancier ontworpen worden op basis van functionele en non-functionele eisen.
Om de aansluitgegevens en kwalificatiegegevens in het APR te vullen zijn operationele procedures nodig voor bijvoorbeeld:
Deze wijzigingen zal een LSP-beheerder uitvoeren in opdracht van Servicecentrum Zorgcommunicatie.
De XIS-typekwalificaties worden aangeleverd vanuit kwalificatie proces en leveranciersmanagement (contactgegevens etc..) zoals vastgelegd in operationele procedures bij het Servicecetrum Zorgcommunicatie en de LSP-opdrachtnemer.
De ZSP kwalificatie gegevens worden aangeleverd vanuit de ZSP-kwalificatieproces.
De samenwerkingsverbanden zullen worden aanleverd door Servicecentrum Zorgcommunicatie. Deze zullen in een formaat worden aangeleverd zodat ze automatisch ingelezen kunnen worden in het APR.
|
Referentie |
Document |
Versie |
|
6.11.0.0 |
||
|
6.11.0.0 |
||
|
6.11.0.0 |
||
|
[Ontw Auth] |
Ontwerp authenticatie |
6.11.0.0 |
|
6.11.0.0 |
||
|
6.11.0.0 |