|
AORTA 2011 |
|
|
|
|
|
Datum: |
12 oktober 2011 |
|
Versie: |
6.10.0.0 |
|
Referentie: |
|
|
|
|
Nictiz is het landelijke
expertisecentrum dat ontwikkeling van ICT in de zorg faciliteert. |
|
AORTA 2011 |
|
|
|
|
|
Datum: |
12 oktober 2011 |
|
Versie: |
6.10.0.0 |
|
Referentie: |
|
|
|
|
Nictiz is het landelijke
expertisecentrum dat ontwikkeling van ICT in de zorg faciliteert. |
1 Inleiding 4
1.1 Doel en scope 4
1.2 Doelgroep voor dit document 4
1.3 Documenthistorie 4
2 Kaders en uitgangspunten 5
2.1 Externe normen en kaders 5
2.2 Relatie met AORTA-principes en –beslissingen 5
3 Context van Opvragen Patiëntgegevens 6
4 Interfaces (koppelvlakken) 8
4.1 Systeeminterfaces 8
4.1.1 Systeeminterface 1 – LSP.OPV.i1010 : Opvragen patiëntgegevens 8
4.1.2 Systeeminterface 2 – GBX.OPV.i1010 : Opvragen patiëntgegevens 10
4.2 Eindgebruikersinterfaces 10
5 Services en functies 11
5.1 Primaire services 11
5.1.1 Opvragen van patiëntgegevens 11
5.1.2 Opleveren van patiëntgegevens 15
5.2 Ondersteunende functies 17
5.3 Beheersfuncties 17
6 Configuratieaspecten 18
7 Ontwerpaspecten ten behoeve van niet-functionele eisen 20
8 Interne componentenstructuur en werking 21
9 Procedurele beheersaspecten 22
Dit document beschrijft het ontwerp Opvragen Patiëntgegevens (OPV) in de ZIM. De OPV is verantwoordelijk voor het opvragen van patiëntgegevens. Uit dit ontwerp volgen generieke programma’s van eisen aan de betrokken systemen.
De volgende zaken omtrent het ontwerp worden besproken:
Het opvragen van patiëntgegevens is bedoeld als abstract scenario dat geconcretiseerd wordt binnen een zorgtoepassing. Een zorgtoepassing geeft invulling aan het scenario door concrete berichten en specifieke categorieën van op te vragen patiëntgegevens voor te schrijven.
Dit document beperkt zich tot het ontwerp van de component, maar schetst wel een minimaal beeld van de context.
In dit document wordt schuingedrukte tekst gebruikt, zoals <opvragenPatiëntgegevens-bericht>, om abstracte berichten aan te duiden. De concrete implementatie hiervan wordt ingevuld in systeemroldocumenten.
De doelgroep van dit document bestaat uit:
|
Versie |
Datum |
Omschrijving |
|
V6.10.0.0 |
12-okt-2011 |
Nieuw document na herstructurering van AORTA documentatie |
|
V6.10.0.0 |
12-okt-2011 |
RfC 35171: Versiebeheer |
|
V6.10.0.0 |
12-okt-2011 |
RfC 46035: opt-in voor beschikbaar maken en opvragen van gegevens via AORTA |
|
12-okt-2011 |
RfC 46657: herziening afhandeling flexibele time-out |
Er zijn geen specifieke kaders en normen van toepassing op het OPV buiten de genoemde kaders en normen in het document [Arch AORTA].
De AORTA-principes en –beslissingen zijn beschreven in Hoofdstuk 3 van de [Arch AORTA].
De OPV stelt zorgverleners in staat patiëntgegevens op te vragen bij andere zorgverleners. Daarnaast kunnen patiënten hun eigen gegevens opvragen. Wanneer patiëntgegevens via de OPV worden opgevraagd, stuurt de ZIM de opvraag door naar alle bronsystemen, die volgens de verwijsindex over de gevraagde gegevens beschikken. De OPV verzamelt vervolgens de resultaten en stuurt de opgeleverde patiëntgegevens door naar het initiërende systeem. Een overzicht van het opvragen van patiëntgegevens is weergegeven in contextdiagram LSP.OPV.d2010.
Diagram LSP.OPV.d2010 – interacties met de ZIM
De applicatiecomponent OPV ondersteunt de volgende services voor externe systemen:
· Opvragen van patiëntgegevens
De service Opvragen van patiëntgegevens wordt uitgebreid beschreven in Hoofdstuk 5.1.
Deze service wordt aangesproken door het Patiëntgegevens raadplegend systeem. De systeemrol Bronsysteem patiëntgegevens bevat de gewenste patiëntgegevens. De eisen die gelden voor beide systeemrollen worden beschreven in respectievelijk Hoofdstuk 3.1 en 3.2 van [PvE GBx Rollen]
De ZIM biedt voor de service Opvragen van patiëntgegevens één abstracte interface met het Patiëntgegevens raadplegend systeem:
Daarnaast is er nog een interface met het Bronsysteem patiëntgegevens:
Voor de beheerder is er een specifieke interface:
· User interface beheerder.
De interfaces worden beschreven in Hoofdstuk 4.
De OPV component roept interne componenten binnen de ZIM aan. Interne interfaces vallen buiten scope van dit document.
De systeemrollen interageren met de OPV via een interface. Naast deze systeeminterfaces, beschreven in paragraaf 4.1, is er ook sprake van een eindgebruikersinterface. De eindgebruikersinterface is de interface tussen een gebruiker en de OPV zonder tussenkomst van een systeemrol. De eindgebruikersinterface wordt beschreven in hoofdstuk 4.2.
De systeemrol Patiëntgegevens raadplegend systeem communiceert met de service Opvragen van patiëntgegevens via de interface LSP.OPV.i1010. De systeemrol Bronsysteem patiëntgegevens maakt gebruik van de interface GBX.OPV.i1010. De interfaces worden beschreven in respectievelijk Hoofdstuk 4.1.1 en Hoofdstuk 4.1.2.
In LSP.OPV.d2020 wordt de afhandeling van het opvragen van patiëntgegevens weergegeven in een sequentiediagram. Voor het opvragen van patiëntgegevens wordt het <opvragenPatiëntgegevens-bericht> verstuurd door het Patiëntgegevens raadplegend systeem.
De attributen die zijn opgenomen in het <opvragenPatiëntgegevens-bericht> zijn vermeld in tabel LSP.OPV.t2010. Afhankelijk van de gegevenssoort die verbonden is aan het interactietype is het eventueel nog mogelijk om specifieke criteria toe te voegen.
Dit bericht wordt afgehandeld door de interface LSP.OPV.i1010 opvragenPatiëntgegevens.
Diagram LSP.OPV.d2020 – OPV sequentiediagram
De ZIM orchestratieservice ontvangt het bericht, doet de standaard berichtcontroles en zet het bericht door naar de OPV.
Afhankelijk van de uitkomst van een aantal controles in de VWI en APR, zoals beschreven in Hoofdstuk 5.1, wordt het bericht doorgezet naar een bronsysteem. Het doorzetten van het bericht wordt gelogd zoals beschreven in [Arch AORTA]. Het bericht wordt afgehandeld door de GBX.OPV.i1010 interface, beschreven in Hoofdstuk 4.1.2.
LSP.OPV.t2010 - Attributen in opvragenPatiëntgegevens-bericht
|
Systeeminterface 1 – opvragenPatiëntgegevens- bericht |
|||
|
Attribuut |
Definitie |
Herkomst |
Additionele informatie |
|
patiëntgegevens-id (0..1) |
Unieke identificatie van de op te vragen patiëntgegevens |
- |
Was in versie 6 patiëntgegevens-id |
|
Patiënt-id (1) |
Unieke identificatie van de patiënt (BSN) van de op te vragen patiëntgegevens |
- |
- |
|
Actualiteit (0..1):
|
|
|
Dit is in te vullen door een specifieke zorgtoepassing. Het is mogelijk om hier verschillende tijden op te geven. In de VWI staan de verschillende tijden voor actualiteit opgeslagen, [Ontw VWI]. |
|
Uiterste-oplevertijd-GBZ(t)(1) |
Het tijdstip waarop het GBZ uiterlijk een antwoord verwacht op een opvraag. |
|
Dit is een configuratie-item die wordt beschreven in LSP.OPV.t2070 |
Naast het <opvragenPatiëntgegevens-bericht> handelt de interface LSP.OPV.i1010 het <opleverenPatiëntgegevens-bericht> af. De OPV bundelt alle, van de bronsystemen ontvangen, opleverberichten samen en stuurt deze door naar het Patiëntgegevens raadplegend systeem.
De OPV zet een <opvragenPatiëntgegevens-bericht> door naar de bronsystemen waar de patiëntgegevens zich bevinden. Hierbij verschillen een oorspronkelijk bericht en een doorgezet bericht op het niveau van:
· bericht-id;
Daarnaast wordt in het <opvragenPatiëntgegevens-bericht> de attribuutwaarde uiterste_oplevertijd_GBZ uit het bericht verwijderd.
Het bericht verzonden door het OPV wordt afgehandeld door de interface GBX.OPV.i1010.
De functionele attributen die in het bericht opgenomen zijn, blijven onveranderd met het orginele <opvragenPatiëntgegevens-bericht>, vermeld in Tabel LSP.OPV.t2010.
Naast het <opvragenPatiëntgegevens-bericht> handelt de interface ook het <opleverenPatiëntgegevens-bericht> af. In het opleverbericht zijn de opgevraagde gegevens opgenomen.
De OPV stelt naast systeeminterfaces ook eindgebruikersinterfaces ter beschikking. Deze worden vermeld in LSP.VWI.t2030.
Tabel LSP.VWI.t2030 - Eindgebruikersinterfaces
|
Type gebruikersinterface |
Doelgroep (gebruikersrol) |
Beschrijving |
|
Web-interface |
Beheerder |
Instellen configuratieparameters. |
De OPV stelt een service beschikbaar voor externe systemen zoals beschreven in Hoofdstuk 5.1. Hoofdstuk 5.2 beschrijft de ondersteunde functies van de OPV component. Daarnaast is er nog een beheerfunctie, die op systematische wijze wordt beschreven in Hoofdstuk 5.3.
De activiteitendiagrammen in dit hoofdstuk zijn gebaseerd op de standaard berichtafhandeling zoals beschreven in [Arch AORTA] . In de activiteitendiagrammen wordt op sommige plaatsen verwezen naar de betreffende diagrammen in [Arch AORTA].
De primaire service is generiek opgezet en de hiernavolgende scenario’s zijn gebaseerd op niet-bestaande, abstracte berichten. Per zorgtoepassing worden de benodigde concrete berichten gedefinieerd.
Het Patiëntgegevens raadplegend systeem stuurt een <opvragenPatiëntgegevens-bericht>, LSP.OPV.i1010, naar de orchestratieservice in de ZIM. Hier worden de berichtcontroles uitgevoerd zoals beschreven in het [Arch AORTA] diagram AORTA.ZIM.d1050. De orchestratieservice zet vervolgens het bericht door naar de OPV.
Diagram LSP.OPV.d2030 – Opvragen van patiëntgegevens.
LSP.OPV.d2030 geeft in een activiteitendiagram de afhandeling van het bericht binnen de ZIM weer.
Het opvragenPatiëntgegevens-bericht kan een Uiterste-oplevertijd-GBZ bevatten. Dit is de tijd waarin het initiërende systeem een antwoord van de ZIM terug verwacht. Indien er geen Uiterste-oplevertijd-GBZ in het bericht is meegegeven, of deze is groter dan systeem-max-sessie-onbruik ([Config-inst]), wordt de waarde systeem-max-sessie-onbruik gebruikt als Uiterste-oplevertijd-GBZ. Systeem-max-sessie-onbruik is de maximum duur dat een SSL/TLS-sessie ongebruikt kan blijven, voordat de sessie wordt beëindigd.
De OPV component zal als eerste aan de hand van de interactie-id de gegevenssoort bepalen, zoals beschreven in [Ontw VWI]. Vervolgens vraagt de OPV de benodigde verwijzingen op in de VWI. De juiste verwijzingen worden bepaald aan de hand van de attributen zoals opgenomen in LSP.OPV.t2040.
Tabel LSP.OPV.t2040 : Controle attributen op basis van gegevens in VWI
|
Parameters |
Eisen parameters |
|
Patiënt-id |
Het gevraagde patiënt-id komt overeen met die in de verwijzing. |
|
Gegevenssoort |
De uit de gegevenssoortentabel opgezochte gegevenssoort-id komt overeen met die in de verwijzing. |
|
Actualiteit |
De gevraagde actualiteit valt binnen de geregistreerde actualiteit in de verwijsindex. |
In het geval er geen verwijzingen voldoen aan de criteria opgenomen in LSP.OPV.t2040, zal er een melding “niks gevonden” (fout-id 5b [Foutentabel]) worden verstuurd naar het Patiëntgegevens raadplegend systeem. In het geval er een patiëntgegevens-id is meegestuurd en deze komt niet voor in de VWI, dan wordt er een foutmelding “bestaat niet” verstuurd.
Als een verwijzing(en) aan de opvraageisen voldoet, dan dienen de applicaties van de bronsystemen waar de verwijzingen naar verwijzen gecontroleerd te worden door de APR-component. De APR-component controleert of de applicatie van het bronsysteem actief en gekwalificeerd is om het <opvragenPatiëntgegevens-bericht>, LSP.OPV.i1010, te verwerken. Mocht dit niet het geval zijn, dan zal er een foutmelding “doel applicatie niet gekwalificeerd of interactie niet geactiveerd” (fout-id 6b [Foutentabel]) worden opgenomen in het uiteindelijke batch opleverbericht onder vermelding van de applicatie-id van de onbereikbare applicatie. In geval er geen enkele gevonden applicatie actief en gekwalificeerd is, dan zal er een foutmelding “antwoord onvolledig” (fout-id 12a [Foutentabel]) worden opgeleverd in het opleverbericht. Dit opleverbericht zal ook elke individuele fout per applicatie opleveren (fout-id 6b [Foutentabel]) in het batch opleverbericht.
Daarnaast wordt gecontroleerd of er voor de applicatie van het bronsysteem een whitelist beschikbaar is behorende bij de interactie-id van het opvraagbericht ([Ontwerp APR]). Mocht dit het geval zijn, dan moet gecontroleerd worden of de URA van de overseer van het opvraagbericht ook voorkomt op de whitelist. In het geval dat niet zo is, zal het betreffende bronsysteem ook niet bevraagd worden en krijgt het initiërende systeem in het opleverbericht een melding “U bent niet geautoriseerd voor het opvragen van patiëntgegevens door zorgaanbieder %3” (fout-id 5cc [Foutentabel]), waarbij %3 de URA van de eigenaar van het bronsysteem representeert die niet bevraagd mocht worden.
Aanvullend controleert de APR-component per bronsysteem welke versies van het bericht door de bronsystemen worden ondersteund en meldt dat ook terug aan de OPV-component.
Mocht de applicatie wel actief en gekwalificeerd zijn en een eventuele whitelist geeft toestemming om de gegevens op te vragen dan wordt naar het bronsysteem een <opvragenPatiëntgegevens-bericht>, LSP.OPV.i1010, verzonden. Het gaat hierbij om een nieuw opvraagbericht met dezelfde inhoud als het initiële opvraagbericht van het Patiëntgegevens raadplegend systeem. Dit houdt in dat elk door de ZIM aan een bronsysteem verstuurd bericht een nieuw bericht-id krijgt. De ZIM wordt als afzender in het bericht opgenomen. In het geval het hier gaat om verschillende bronsystemen, zal het bericht naar elk bronsysteem gedirigeerd worden. Elk bericht heeft hetzelfde opvraag-id.
Er zal geen <opvragenPatiëntgegevens-bericht> doorgezet worden naar de initiële afzender van het opvraagbericht.
Het GBP kan ook optreden als initiërend systeem. Sommige bronsystemen kunnen echter een opvraag van het GBP niet verwerken. Zolang een GBZ-applicatie er niet op aangepast is dat het bevraagd wordt door een patiënt (met een BSN) doet de ZIM het vóórkomen dat het bevraagd wordt door een zorgverlener. Als gevolg zal de ZIM de waardes van de berichtverantwoordelijke vervangen zoals vermeld in LSP.OPV.t2050. In het geval alle reagerende GBZ-applicaties ook opvragen van een GBP kunnen verwerken, dan zal de ZIM de berichten ongewijzigd laten.
Tabel LSP.OPV.t2050 – Attributen die vervangen worden in geval GBZ-applicatie kleiner is dan zim-release-einde-burger-uzi-ura
|
Te vervangen attributen |
Vervangende attributen |
Configuratieparameter |
|
Zorgverlener-id |
Configureerbaar UZI-nummer |
zim-uzi-ura-burger-uzi-nummer |
|
Zorgaanbieder-id |
Configureerbaar URA-nummer |
zim-uzi-ura-burger-ura-nummer |
|
Zorgverlener-functie |
Configureerbare rolcode |
zim-uzi-ura-burger-rolcode |
Per bronsysteem wordt die versie van het <opvragenPatiëntgegevens-bericht> gestuurd die gelijk is aan of precies een versie lager is dan de berichtversie die is ontvangen van het raadplegende systeem. Dit betekent dat de component het bericht mogelijk moet vertalen naar een lagere versie.
Mocht een <opvragenPatiëntgegevens-bericht> niet ontvangen worden door het bronsysteem of het bronsysteem reageert niet binnen ZIM-oplever-time-out (de tijd die voor de ZIM nodig is om te kunnen opleveren binnen Uiterste-oplevertijd-GBZ aan de GBZ, zie LSP.OPV.t2070), dan moet de ZIM een foutbericht “antwoord onvolledig” (fout-id 12a [Foutentabel]), onder vermelding van de applicatie-id van de onbereikbare applicatie, sturen naar het Patiëntgegevens raadplegend systeem. Deze foutmelding moet ook verstuurd worden in het geval het reagerende systeem een foutmelding als respons stuurt. In beide gevallen zal de fout worden geregistreerd in de systeemlog.
Afhankelijk van het interactietype is het mogelijk voor een Patiëntgegevens raadplegend systeem om extra opvraagcriteria mee te zenden. De systeemrol Bronsysteem patiëntgegevens bepaalt aan de hand van alle meegestuurde opvraagcriteria welke gegevens opgevraagd worden.
Het bronsysteem verwerkt het <opvragenPatiëntgegevens-bericht>, LSP.OPV.i1010 en stuurt de opgevraagde gegevens naar de ZIM door middel van een <opleverenPatiëntgegevens-bericht> terug.
Binnen de ZIM ontvangt de OPV-component het <opleverenPatiëntgegevens-bericht>. De afhandeling van het bericht wordt weergegeven in Diagram LSP.OPV.d2040.
Diagram LSP.OPV.d2040 : Afhandeling opleveren patiëntgegevens in ZIM
In het geval de OPV meerdere antwoorden verwacht, wacht de OPV tot alle opgevraagde gegevens binnen zijn of tot de maximale wachttijd is aangebroken, uiterste_oplevertijd_ZIM (t) (zie LSP.OPV.t2070). Vervolgens convergeert de OPV de verschillende berichten en foutmeldingen in één <opleverenPatiëntgegevens-bericht>. De verschillende opleverberichten die door de verschillende bronsystemen zijn opgeleverd worden onveranderd overgenomen in het door de OPV te versturen opleverbericht.
In het door de ZIM gecreërde opleverbericht wordt de ZIM als afzender opgenomen. Vervolgens wordt er een nieuw bericht-id toegekend aan het bericht. Aan de hand van het opvraag-id kan de initiërende systeemrol het opleverbericht koppelen aan een opvraagbericht. Het uiteindelijke bericht wordt naar de initiërende GBZ gestuurd.
Wanneer de component twee verschillende versies van <opvragenPatiëntgegevens-bericht> heeft verstuurd, is het ook mogelijk dat er twee verschillende versies van het <opleverenPatiëntgegevens-bericht> ontvangen wordt. De component convergeert dan nog steeds alle berichten (van mogelijk verschillende versies) en foutmeldingen tot één <opleverenPatiëntgegevens-bericht>.
De OPV component stelt geen functies beschikbaar ter ondersteuning van andere componenten binnen de ZIM.
Alle beheersfuncties die een LSP-beheerder kan uitvoeren worden vermeld in LSP.OPV.t2060.
Tabel LSP.OPV.t2060 – OPV Beheersfuncties
|
Beheersfunctie |
Type gebruikersinterface |
Beschrijving |
|
Instellen configuratie-parameters |
Web-interface |
Het moet mogelijk zijn om de configuratieparameters zoals beschreven in Hoofdstuk 6 in te kunnen stellen. |
GBZ-beheerders zijn ook in staat om patiëntgegevens te kunnen opvragen zoals beschreven in Hoofdstuk 5.1.1. Dit kunnen echter alleen maar inhoudelijk fictieve patiëntgegevens betreffen van fictieve patiënten. Hiervoor zijn speciale verwijzingen opgenomen in de VWI.
De configuratieaspecten die van belang zijn bij OPV zijn weergegeven in LSP.OPV.t2070. In de eerste kolom worden de parameters weergeven. De waardes behorende bij de parameters zijn in te stellen door de beheerder. De initiële waardes worden beschreven in [Config-inst]. De tweede kolom geeft een beschrijving van de specifieke parameter.
Tabel LSP.OPV.t2070 – Configuratieparameters
|
Configuratieparameter |
Betekenis van parameter |
Datatype |
Domein (mogelijke waarden) |
|
Uiterste-oplevertijd-ZIM (t) |
Het tijdstip waarop het ZIM uiterlijk een antwoord verwacht op een opvraag. |
Time |
hh/mm/ss |
|
Uiterste-oplevertijd-GBZ(t) |
Het tijdstip waarop het GBZ uiterlijk een antwoord verwacht op een opvraag (huidige tijd is actuele systeemtijd). |
Time |
hh/mm/ss |
|
Responstijd-ZIM |
De tijd in seconden die de ZIM nodig heeft om binnengekomen antwoorden op een query te verwerken. Deze parameter wordt gebruikt om de uiterste_oplevertijd_ZIM te bepalen en is niet leidend voor de daadwerkelijke responstijd van de ZIM, maar werkt juist andersom. |
Integer |
Groter dan nul in seconden. |
|
zim-uzi-ura-burger-uzi-nummer |
Specifiek UZI-nummer dat een willekeurige burger aanduidt. Aan de hand van dit nummer is het duidelijk dat er sprake is van een opvraag door een burger. |
Integer |
Een bij het UZI register bekend UZI-nummer |
|
zim-uzi-ura-burger-ura-nummer |
Specifiek URA-nummer dat een willekeurige burger aanduidt. Aan de hand van dit nummer is het duidelijk dat er sprake is van een opvraag door een burger. |
Integer |
Een bij het UZI register bekend URA-nummer |
|
zim-uzi-ura-burger-rolcode |
Specifieke rolcode die wordt toegekend in het geval er een opvraag wordt gedaan door een willekeurige burger. |
Integer |
Een bij het UZI-register bekende rolcode |
|
ZIM-opvraag-retry |
Aantal maal dat mislukte opvraag van ZIM aan GBZ wordt herhaald. |
Integer |
0 (wordt momenteel niet gebruikt) |
Er zijn geen specifieke ontwerpaspecten ten behoeve van niet-functionele eisen. De generieke zaken worden beschreven in [Arch AORTA].
De interne structuur van de component moet door de leverancier ontworpen worden op basis van functionele en non-functionele eisen.
Er worden geen beheersaspecten voorzien waarvan is te verwachten dat deze tot bijzondere beheersprocedures leiden.
|
Referentie |
Document |
Versie |
|
6.10.0.0 |
||
|
6.10.0.0 |
||
|
6.10.0.0 |
||
|
6.10.0.0 |
||
|
Foutentabel |
6.10.0.0 |
|
|
6.10.0.0 |
||
|
6.10.0.0 |