UC Resource Server (versie 0.6.14 - definitief)
HL7-FHIR Resource Server
Overzicht
Onderstaande figuur toont een overzicht van de interfaces, services en functies van de Resource Server t.b.v. HL7-FHIR-interacties.
De services zijn toegankelijk via een geboden interface en worden beschreven in de vorm van use cases. Responses die in een succes- of uitzonderingssituaties moeten worden geretourneerd zijn voor iedere situatie beschreven in de sectie "Gemeenschappelijke Interface onderdelen".
Een service wordt altijd vervult middels één of meerdere applicatiefuncties (AORTA systeemrollen), bijvoorbeeld "FHIR Verwerkend Systeem". Een Resource Server kan worden gekwalificeerd en geaccepteerd voor deze systeemrollen. Wanneer de ene systeemrol een andere vereist, dan is dit weergegeven middels een is used by relatie. Bijvoorbeeld: kwalificatie voor systeemrol "MedMij Ontvangend Systeem" vereist ook kwalificatie voor systeemrol "Ontvankelijkheidstatus Opleverend Systeem".
De Resource Server maakt zelf ook gebruik van een aantal interfaces, bijvoorbeeld van de Applicatie Register Interface.
Een aantal services maken gebruik van onderliggende services. Een dergelijk onderliggende service wordt dan beschreven in de vorm van een use case inclusion of als een use case extension.
Activeren TKID
Primaire actor: GBZ-beheerder
Secundaire actor: Resource broker
Systeem: TKID Activerend Systeem
Pre-condities:
- De resource server is aangesloten op de resource broker.
- De kwalificaties van de resource server zijn reeds geaccepteerd door VZVZ en zijn ook geregistreerd in de resource broker;
- De GBZ-beheerder beschikt over de juiste TKID's (ID's die zijn uitgereikt n.a.v. acceptatie van succesvol doorlopen kwalificaties) van alle te activeren AORTA systeemrollen.
Triggers:
- De primaire actor wil één of meerdere TKID's activeren.
Main flow:
- De primaire actor kiest de optie om één of meerdere TKID's te activeren voor een bepaalde resource server.
- Het systeem initieert de use case Verwerken TKID-activatie middels de Applicatie Register Interface.
- Uitzondering 1: De interactie kon niet succesvol worden verwerkt
- Het systeem ontvangt een response.
Postconditie bij succes:
- De verzonden TKID's zijn verwerkt door de resource broker, waardoor de resource server nu in de resource broker is gekoppeld aan de bijbehorende AORTA systeemrollen. Hiermee zijn tevens eventueel eerder doorlopen TKID activaties ongedaan gemaakt.
Post-condities bij falen:
- De bestaande koppelingen tussen AORTA systeemrollen met de resource server is ongewijzigd gebleven.
Uitzonderingen:
- De interactie kon niet succesvol worden verwerkt
- Het systeem ontvangt een toepasselijke foutcode (bijvoorbeeld niet geautoriseerd of ongeldig verzoek)
Opleveren AORTA CapabilityStatement
Primaire actor: Resource broker
Systeem: capabilities Operation Verwerkend Systeem
Pre-condities:
- Het systeem is aangesloten op de resource broker.
Triggers:
- De resource broker wil de operationele status van de resource server toetsen.
Main flow:
- Het systeem ontvangt een FHIR capabilities operation
- Uitzondering 1: Ongeldig request
- Het systeem retourneert een response.
Post-condities:
- Het systeem heeft een correcte response geretourneerd.
Uitzonderingen:
- Ongeldig request
- Het systeem genereert de vereiste foutresponse en keert terug naar de laatste stap van de main flow.
Verwerken AORTA FHIR-interactie
Primaire actor: Resource broker
Systeem: FHIR Verwerkend Systeem
Pre-condities:
- De vereiste TKID's voor deze resource server zijn geactiveerd op de resource broker.
Triggers:
- De resource broker initieert een FHIR-interactie.
Main flow:
- Het systeem ontvangt een AORTA FHIR-interactie.
- Het systeem controleert de geldigheid van het AORTA access_token, zoals omschreven in de toelichting "Controle en gebruik van het access_token".
- Uitzondering 1: Het access_token kan niet worden gevalideerd of is ongeldig
- Het systeem controleert de geldigheid van de AORTA-ID header.
- Uitzondering 2: AORTA-ID header ontbreekt of is ongeldig
- Het systeem controleert de geldigheid van de AORTA-Version header (vooralsnog mag slechts worden getoetst of de header aanwezig is, inhoudelijk wordt de header nog niet gebruikt).
- Uitzondering 2: AORTA-Version ontbreekt of is ongeldig
- Het systeem logt de ontvangen interactie, zoals beschreven in de "toelichting logging".
- Afhankelijk van het type FHIR-interactie wordt nu de juiste generieke extension flow doorlopen, d.w.z. opleveren gegevens, ontvangen gegevens of opleveren ontvankelijkheidstatus.
- Het systeem retourneert een response.
- Het systeem logt de geretourneerde response, zoals beschreven in de "toelichting logging".
Post-condities:
- Het systeem heeft een correcte response geretourneerd, zoals vereist voor de specifieke use case.
Uitzonderingen:
- Het access_token kan niet worden gevalideerd of is ongeldig
- Het systeem genereert de vereiste foutresponse en keert terug naar de laatste stap van de main flow.
- AORTA-ID header ontbreekt of is ongeldig
- Het systeem genereert de vereiste foutresponse en keert terug naar de laatste stap van de main flow.
- AORTA-Version ontbreekt of is ongeldig
- Het systeem genereert de vereiste foutresponse en keert terug naar de laatste stap van de main flow.
Use case extensions:
- Opleveren gegevens
- Ontvangen gegevens
- Opleveren ontvankelijkheidstatus
Controle en gebruik van het access_token
Om meta-informatie te kunnen meegeven bij een FHIR interactie en om het beveiligingsniveau te verhogen wordt bij iedere FHIR interactie een AORTA access_token meegestuurd. Een FHIR interactie die wordt ingestuurd door de ZIM en waar geen geldig access_token is bijgevoegd dient te worden geweigerd.
Het JWT-based access_token wordt op basis van RS256 (RSA Signature met SHA-256), digitaal ondertekend met de private key van de Autorisatie Server. De public key waarmee de digitale handtekening kan worden gecontroleerd wordt conform RFC 7517, als een JWK beschikbaar gesteld.
De URL van waarop de JWK Set kan worden opgevraagd (jwks_uri) is opgenomen in de metadata van de autorisatieserver, die via de AS Metadata Interface, kan worden opgehaald.
De iss van het token is opgenomen in het token zelf, maar wordt vanwege security redenen ook out-of-band bij de resource server aangemerkt als een vertrouwde issuer. De resource server mag geen tokens verwerken van niet-vertrouwde issuers. De resource server moet controleren dat de waarde van <iss> overeenkomt met de waarde van issuer in de ontvangen metadata.
Iedere JSON Web Key (JWK) in de set bevat een kid parameter. De juiste JWK in de JWK Set wordt gevonden o.b.v. de waarde van het kid attribuut in de header van de ontvangen JWT.
Het access_token dient door de ontvangende partij, acterend in de rol van resource server, worden gebruikt om vast te kunnen stellen of binnenkomend verzoek mag worden behandeld en om de gegevensverwerking te kunnen loggen.
Uit te voeren controles m.b.t. het access_token:
| Controle in LSP (in use case "Verzenden & Consolideren FHIR-interactie") | Controle in Reagerend GBZ |
|---|---|
Is het token uitgegeven door een voor mij vertrouwde partij (issuer, in dit geval door de autorisatieserver van LSP+, de autorisatieserver dient te worden opgenomen in de lijst met vertrouwde issuers). | |
| Juistheid van de digitale handtekening (signature), inclusief de geldigheid van het certificaat waarmee de handtekening is geplaatst. Hierbij worden ook maatregelen genomen om bedreiging 2.1 uit RFC 8725 tegen te gaan. | |
| Is dit token al eerder bij mij gebruikt? Een token mag slechts eenmaal worden gebruikt. | |
Wordt het token gebruikt door de partij (resource client) aan wie het is uitgegeven.
| Wordt het token gebruikt door de partij (resource client) aan wie het is uitgegeven.
|
Mag het token door mij worden geconsumeerd.
| Mag het token door mij worden geconsumeerd.
|
Is de geldigheidsduur van het token niet verstreken. Met betrekking tot het ingangstijdstip dient, wanneer problemen ontstaan door tijdsynchronisatie, een gracetime te kunnen worden gehanteerd. Deze bedraagt maximaal 15 seconden. Aanbevolen wordt om deze gracetime configureerbaar te maken. | |
Betreft het een interactie van een patiënt en ook m.b.t. zijn eigen gegevens. In geval van een JWT:
| Betreft het een interactie van een patiënt en ook m.b.t. zijn eigen gegevens. In geval van een JWT:
Toelichting: omdat machtigingen/mandateringen nog niet worden ondersteund, mag de |
- | Valt de interactie onder het type interacties waarvoor het access_token geldig is ( Bij ontvangst van een FHIR read interactie dient expliciet te worden getoetst of de gevraagde resource instance deel uitmaakt van het dossier van de patient die is aangegeven in het access_token. |
Toelichting logging
Een resource server dient een log bij te houden van alle ontvangen request en van alle retourneerde responses. Een dergelijke log bevat, t.b.v. de traceerbaarheid van berichten in de keten tenminste de volgende attributen.
| Te loggen attribuut | Vulling in Request Log | Vulling in Response Log |
|---|---|---|
| request-id | Uniek ID van het verzonden/ontvangen request. Wordt gevuld met het requestID dat werd ontvangen in de AORTA-ID request header. | Uniek ID van het request waartoe de verzonden/ontvangen response behoort. Wordt gevuld met het requestID dat werd ontvangen/verzonden in de AORTA-ID request header. |
| message-type | "request" | "response" |
| initial-message-id | Gelijk aan het request-id, waarmee de keten van messages werd gestart. In de MedMij use case is dit het Wordt gevuld met het Het | |
| sender_id | Het appID van de resource client die het request verstuurt of van de resource server die de response retourneert. | |
| receiver_id | Het appID van de resource server die het request ontvangt of van de resource client die de response ontvangt. | |
Generieke UC extension: Opleveren ontvankelijkheidstatus
Systeem: MedMij Ontvangend Systeem
Triggers:
- De resource server heeft een $is-allowed operation ontvangen
Main flow:
- Het systeem genereert de te retourneren response.
- Het systeem keert terug naar de main flow van de bovenliggende use case.
UC extension: Opleveren documenten
Systeem:
- DocumentManifest Search Verwerkend Systeem
- DocumentReference Search Verwerkend Systeem
- Binary Read Verwerkend Systeem
Triggers:
- De resource server heeft een FHIR-interactie ontvangen die deel uitmaakt van de gegevensdienst "Verzamelen documenten".
Main flow:
- Het systeem zorgt ervoor dat slechts (referenties naar) documenten worden geretourneerd die behoren tot de set van ondersteunde mimetypes (zie toelichting "Ondersteunde mimetypes").
- Het systeem zorgt ervoor dat wordt voldaan aan de toelichting "Vulling content.attachment.url".
- Het systeem keert terug naar de bovenliggende use case.
Ondersteunde mimetypes
De informatiestandaard van MedMij perkt het aantal mogelijke op te leveren mimetypes in tot application/pdf (en specifiek tot PDF/A, waarbij minimaal PDF/A1b wordt vereist).
Omdat de Resource Broker mimetypes kan vertalen is het voor Resource Servers toegestaan om documenten op te leveren conform de volgende mimetypes (let op! nog niet mogelijk in AoF 0.5, 0.6 en 0.7):
- application/pdf
- application/msword
- application/vnd.openxmlformats-officedocument.wordprocessingml.document
- application/rtf
- text/plain
- text/html
- image/jpeg
- image/tiff
Nader onderzocht zal worden of ook de volgende mimetypes kunnen worden opgeleverd:
- application/xml
- image/bmp
- image/png
- text/xml
Vulling content.attachment.url
Wanneer het Reagerend GBZ een DocumentReference retourneert, dan dient content.attachment.url als volgt te worden gevuld:
<base endpointadres van Reagerend xIS>/Binary/<id>, ofBinary/<id>
LSP+ transformeert content.attachment.url voor oplevering naar het volgende formaat:
<base endpointadres van LSP+>/<appID>/Binary/<id>
Waarbij <appID> het applicatie-id (zonder root OID) bevat van het Reagerend xIS.
Codering documenten
Binnen VIPP 5 bestaat correspondentie uit radiologieverslagen, specialistenbrieven, voortgangsbrieven en/of ontslagbrieven, opgesteld in de eigen organisatie. In onderstaande tabel zijn de bijbehorende, mogelijke, class en type coderingen opgenomen. De informatiestandaard stelt geen precieze eisen aan welke codes exact mogen worden toegepast.
Type correspondentie | SNOMED class- en typecodes die door MedMij zijn doorgegeven aan VIPP 5 | Mogelijke SNOMED class- en typecodes uit de Waardelijsten waarnaar wordt verwezen vanuit het functioneel ontwerp van de informatiestandaard | Mogelijke LOINC class- en typecodes uit de Waardelijsten waarnaar wordt verwezen vanuit het technisch ontwerp van de informatiestandaard (de FHIR profielen) |
|---|---|---|---|
| Radiologieverslag | class = 4201000179104 (Imaging reports) type = 722124004 (Radiology studies report) | diverse codes mogelijk, e.e.a. afhankelijk van het type onderzoek dat is uitgevoerd | class = 18726-0 (Radiology studies (set) type = 73575-3 (Radiology Consult note), 68604-8 (Radiology Diagnostic study note) |
| Specialistenbrief | class = 371534008 (Summary reports) type = 371535009 (Transfer summary) | class = 9531000146107 (brief) type = 11061000146105 (polibrief), 11081000146102 (brief chirurgie) | class = 11488-4 (Consult Note), 11504-8 (Surgical operation note) type = diverse specifieke codes mogelijk |
| Voortgangsbrief | class = 371534008 (Summary reports) type = 371532007 (Progress report) | class = 9531000146107 (brief) type = 11061000146105 (polibrief), 11081000146102 (brief chirurgie), 11091000146100 (brief dagverpleging) | class = ?? type = 68607-1 (Progress letter), ook meer specifieke codes mogelijk |
| Ontslagbrief | class = 371534008 (Summary reports) type = 373942005 (Discharge summary) | class = 9531000146107 (brief) type = 11071000146104 (ontslagbrief) | class = 18842-5 (Discharge summary) type = 28574-2 (Discharge Note), ook meer specifieke codes mogelijk |
Cardinaliteiten
Onderstaande tabel bevat een samenvatting van de gehanteerde cardinaliteiten in de informatiestandaard.
| DocumentManifest | DocumentReference | Document / Binary | |||
|---|---|---|---|---|---|
| Functioneel | FHIR | Functioneel | FHIR | Functioneel | FHIR |
| Identificatie (1..1) | masterIdentifier (1..1) | Identificatie (1..1) | masterIdentifier (1..1) | Identificatie (1..1) | id (1..1) |
| identifier (1..*), mag gelijk zijn aan de masterIdentifier | identifier (0..*) | - | |||
| Status (1..1) | status (1..1) | Status (1..1) | status (1..1) | - | - |
| Type (1..1) >> SNOMED Waardelijst typeCode | type (1..1) >> LOINC Document Type Valueset (preferred) | Type (1..1) >> SNOMED Waardelijst typeCode | type (1..1) >> LOINC Document Type Valueset (preferred) | - | - |
| - | - | Klasse (0..1) >> SNOMED Waardelijst classCode | class (0..1) >> LOINC Document Class Valueset (example) | - | - |
| Auteur (0..*) | author (0..1) | Auteur (1..*) - Verplicht indien aanwezig in bronsysteem | author (0..1) | - | - |
| - | subject (1..1) | - | subject (0..1) - Subject is desondanks wel verplicht bij kwalificatie | - | - |
| AanmaakDatum (1..1) | created (1..1) | IndexDatum (1..1) | indexed (1..1) | - | - |
| Bron (0..*) | source (1..1), is verplicht, FHIR profiel is op dit punt bepalend voor kwalificatie, gevuld met applicatie ID als een urn:oid | - | - | - | - |
| Inhoud.DocumentReferentie (1..*) | content.pReference (1..*) | - | - | - | - |
| - | - | Inhoud.Documentverwijzing (1..1) | content.attachment.url (1..1) | - | - |
| - | - | Inhoud.Documentformaat.mimeType (1..1) >> valueset | content.attachement.contentType (1..1) | ContentType.mimeType (1..1) >> valueset | contentType (1..1) |
| - | - | Inhoud.Documentformaat.formatCode (1..1) >> valueset | content.format (0..1) >> valueset (preferred) | ContentType.formatCode (1..1) >> valueset | - |
| - | - | - | - | Content (1..1) | content (1..1) |
HL7-v3 Resource Server
Overzicht
Onderstaande figuur toont een overzicht van de interfaces, services en functies van de Resource Server t.b.v. HL7v3-interacties.
Verschillen tussen een HL7-FHIR Resource Server en een HL7v3 Resource Server zijn hieronder beschreven.
- Een HL7v3 Resource Server biedt een AORTA v3-interface i.p.v. een AORTA FHIR Resource Interface.
- Deze interface biedt toegang tot de generieke service "Verwerken AORTA v3-interactie".
Verwerken AORTA v3-interactie
Primaire actor: Resource broker
Systeem: MedMij Opleverend Systeem of MedMij Ontvangend Systeem
Pre-condities:
- De vereiste TKID's voor deze resource server zijn geactiveerd op de resource broker.
Triggers:
- De resource broker initieert een v3-interactie.
Main flow:
- Het systeem ontvangt een AORTA v3-interactie.
- Het systeem logt de ontvangen interactie.
- Afhankelijk van het HL7v3 interactie-id wordt nu de juiste generieke extension flow doorlopen, d.w.z. opleveren gegevens of ontvangen gegevens.
- Het systeem retourneert een response.
- Het systeem logt de geretourneerde response.
Post-condities:
- Het systeem heeft een correcte response geretourneerd, zoals vereist voor de specifieke use case.
Uitzonderingen:
- Beschreven in reguliere AORTA PvE en Implementatiehandleidingen.
Use case extensions:
- Opleveren gegevens
- Ontvangen gegevens
Resource Server Algemeen
Generieke UC extension: Opleveren gegevens
Systeem: MedMij Opleverend Systeem
Triggers:
- De resource server heeft een FHIR-read of een FHIR-search interactie ontvangen, OF
- De resource server heeft een v3-interactie ontvangen, waarmee gegevens worden opgevraagd
Main flow:
- Het systeem verifieert of de gevraagde gegevens mogen worden opgeleverd, zoals omschreven in de onderstaande "Toelichting beschikbaarheidsvoorwaarde".
- Uitzondering 1: De gevraagde gegevens mogen niet worden opgeleverd.
- Afhankelijk van de gegevensdienst waar de interactie deel van uitmaakt (FHIR-interactie), of van het interactie-id (v3-interactie)
- wordt de ontvangen interactie nu verwerkt conform de gegevensdienst-specifieke implementatiehandleiding, zoals benoemd in de toelichting "Gegevensdienst-specifieke UC extensions en implementatiehandleidingen".
- wordt (indien van toepassing) de juiste extension flow doorlopen, zoals aangegeven in de toelichting "Gegevensdienst-specifieke UC extensions en implementatiehandleidingen".
- Het systeem zorgt ervoor dat bij eventueel op te leveren Patient resource instances de identifier is gevuld met het BSN van de betroffen persoon (zie "Toelichting vulling BSN bij opleveren van gegevens").
- Het systeem keert terug naar de main flow van de bovenliggende use case.
Uitzonderingen:
- De gevraagde gegevens mogen niet worden opgeleverd
- Het systeem genereert de vereiste foutresponse (situatie "niet voldaan aan (MedMij) beschikbaarheidsvoorwaarde") en keert terug naar de laatste stap van de main flow van de bovenliggende use case.
Toelichting beschikbaarheidsvoorwaarde
In de programma's van eisen die gelden voor bronsystemen zijn een aantal eisen opgenomen die gaan over het al dan niet beschikbaar stellen van bepaalde gegevens voor opvragende partijen:
- Patiëntgegevens mogen pas worden opgeleverd nadat het BSN van patiënt door de zorgaanbieder is geverifieerd.
- Patiëntgegevens moeten na vastlegging, automatisch of op commando van een zorgverlener/medewerker, vrijgegeven kunnen worden. Vrijgegeven patiëntgegevens moeten ook weer kunnen worden afgeschermd. Vrijgeven en afschermen moet kunnen op dossierniveau. Vrijgeven en afschermen moet mogelijk zijn per individuele patiënt. Bij afschermen dient onderscheid gemaakt te kunnen worden tussen bevragingen door patiënten en bevragingen door zorgverleners/medewerkers.
- Alvorens gegevens van een patiënt op te leveren, dient er gecontroleerd te worden of de patiënt hiervoor toestemming heeft verstrekt. Dit kan worden afgeleid van het access_token in combinatie met het AORTA vertrouwensmodel.
- Indien de opvrager een patiënt is, dan dient de resource server (het GBZ) te controleren of een behandelrelatie bestaat (danwel heeft bestaan) tussen patiënt en zorgaanbieder, en of de leeftijd van de persoon van wie gegevens worden opgevraagd minimaal 16 jaar is.
- Bij het al dan niet beschikbaar stellen van gegevens mag het systeem dat de patiënt gebruikt, en de organisatie dit dit systeem aanbiedt niet als een criterium worden gehanteerd.
Tevens moet de resource server borgen dat gegevens die worden opgeleverd daadwerkelijk betrekking hebben op de patiënt (BSN), zoals opgenomen in het AORTA access_token.
Indien de opvrager een patiënt, is dan geldt dat in de volgende situaties niet wordt voldaan aan de MedMij beschikbaarheidsvoorwaarde:
- Er bestaat geen behandelrelatie tussen zorgaanbieder en patiënt en een behandelrelatie heeft ook nooit bestaan.
- De leeftijd van de opvrager is niet toereikend.
- De gevraagde gegevens zijn afgeschermd of niet vrijgegeven.
Gegevensdienst-specifieke UC extensions en implementatiehandleidingen
De gegevensdienst-specifieke delen van deze use cases maken deel uit van de betreffende <resourcetype> <interactietype> Verwerkend systeemrollen, bijvoorbeeld Observation Search Verwerkend Systeem of MedicationStatement Search Verwerkend Systeem.
FHIR-interacties: de implementatiehandleiding die van toepassing is voor een specifieke gegevensdienst is opgenomen in onderstaande tabel.
| Gegevensdienstnaam | ID | Implementatiehandleiding | UC extension |
|---|---|---|---|
| Verzamelen Documenten 3.0 | 51 | IH FHIR_PDFA_2020 | Opleveren Documenten |
| Delen Meetwaarden vitale functies 2.0 | 53 | IH FHIR_VitalSigns_2020 | - |
| Verzamelen Meetwaarden vitale functies 2.0 | 54 | - | |
| Verzamelen Basisgegevens zorg 3.0 | 48 | IH FHIR_BGZ_2017 | - |
| Verzamelen Basisgegevens GGZ 2.0 | 50 | IH FHIR_GGZ_2020 | - |
| Verzamelen verwijzingen naar vragenlijsten 2.0 | 59 | IH FHIR_Questionnaire_and_Questionnaire_Response_2020 | - |
| Delen antwoorden op vragenlijsten 2.0 | 60 | - | |
| Verzamelen Afspraken 2.0 | 47 | IH FHIR_eAfspraak_2020 | - |
HL7v3-interacties: de implementatiehandleiding die van toepassing is, is opgenomen in onderstaande tabel.
| Interactie-ID request | Interactie-ID response | Implementatiehandleiding | UC extension |
|---|---|---|---|
| ZTZM_IN000004NL | MCCI_IN000002 | IH HL7v3 Delen Zelfmetingen | - |
| QUAF_IN990001NL01 | QUAF_IN990003NL01 | IH HL7v3 Verzamelen ContactAfspraken | - |
Toelichting vulling BSN bij opleveren van gegevens
Alle use cases waarin de resource server gegevens op dient te leveren zijn gebaseerd op de MedMij FHIR informatiestandaarden van Nictiz. Omdat het de bedoeling is dat gegevens (op termijn) zowel kunnen opgeleverd aan PGO Servers in MedMij als aan Initiërende GBZ'en binnen AORTA gelden een aantal specifieke AORTA aanvullingen op de informatiestandaarden.
Het profiel voor nl-core-patient bevat een attribuut Patient.identifier, waarin het BSN van een persoon kan worden opgenomen. De MedMij FHIR informatiestandaarden beschrijven echter dat geen BSN mag worden opgenomen in de Patient resource, omdat PGO Servers geen wettelijke grondslag hebben om deze te mogen verwerken.
Omdat voor uitwisseling tussen zorgaanbieders onderling het BSN juist wel verplicht is, is het gewenst dat de Patient.identifier daarom wel wordt gevuld met het BSN van de betreffende persoon. LSP+ zal het BSN filteren voordat de gegevens worden geretourneerd aan een PGO Server.
Generieke UC extension: Ontvangen gegevens
Systeem: MedMij Ontvangend Systeem
Triggers:
- De resource server heeft een FHIR-create of een FHIR-update interactie ontvangen, OF
- De resource server heeft een v3-interactie ontvangen, waarmee gegevens worden gestuurd
Main flow:
- Afhankelijk van de gegevensdienst waar de interactie deel van uitmaakt (FHIR-interactie), of van het interactie-id (v3-interactie)
- wordt de ontvangen interactie nu verwerkt conform de gegevensdienst-specifieke implementatiehandleiding, zoals benoemd in de toelichting "Gegevensdienst-specifieke UC extensions en implementatiehandleidingen".
- wordt (indien van toepassing) de juiste extension flow doorlopen, zoals aangegeven in de toelichting "Gegevensdienst-specifieke UC extensions en implementatiehandleidingen".
- Het systeem verwerkt bij eventueel ontvangen Patient resource instances ook de identifier die is gevuld met het BSN van de betroffen persoon (zie "Toelichting vulling BSN bij ontvangen van gegevens").
- Het systeem keert terug naar de main flow van de bovenliggende use case.
Toelichting vulling BSN bij ontvangen van gegevens
Alle use cases waarin de resource server gegevens dient te ontvangen zijn gebaseerd op de MedMij FHIR informatiestandaarden van Nictiz. Omdat het de bedoeling is dat gegevens (op termijn) zowel kunnen worden ontvangen van PGO Servers in MedMij als van Initiërende GBZ'en binnen AORTA gelden een aantal specifieke AORTA aanvullingen op de informatiestandaarden.
Het profiel voor nl-core-patient bevat een attribuut Patient.identifier, waarin het BSN van een persoon kan worden opgenomen. De MedMij FHIR informatiestandaarden beschrijven echter dat geen BSN mag worden opgenomen in de Patient resource, omdat PGO Servers geen wettelijke grondslag hebben om deze te mogen verwerken.
Omdat voor uitwisseling tussen zorgaanbieders onderling het BSN juist wel verplicht is, zal de Patient.identifier daarom wel worden gevuld met het BSN van de betreffende persoon. LSP+ zal het BSN toevoegen voordat de gegevens worden verzonden richting een resource server.