Skip to main content
Skip table of contents

Interfaces Resource Server

HL7-FHIR Resource Server

Generiek voor alle FHIR resource server interfaces

De volgende eisen gelden voor alle interfaces van de resource server:

  1. De waarde van de base-URL van de FHIR endpoints die een resourceserver biedt ( [base] dus ), dient voor alle FHIR-interacties gelijk te zijn aan:

    1. Indien <fhir-version> gelijk is aan STU3: https://<FQDN>/fhir, dus bijvoorbeeld "http://myhost.customer.org/fhir"

    2. Indien <fhir-version> hoger dan STU3: https://<FQDN>/fhir/<fhir-version>, dus bijvoorbeeld "http://myhost.customer.org/fhir/R4"

De waarde van <fhir-version> is dan bijvoorbeeld "R4" of "R5".

AORTA CapabilityStatement Interface

Feature

capabilities

Type

Service

Versie

1.0.0

Groep

GBZ

Gepubliceerd

Delta

Initiële versie van feature.

Resource server biedt op zijn endpoint een CapabilityStatement aan. Een resource client kan het statement als volgt bij de resource server opvragen:

GET [base]/metadata {?_format=[mime-type]}

Het gaat hier om een CapabilityStatement van het type "Instance", oftewel het bevat informatie over de daadwerkelijke installatie die benaderbaar is. Bovenstaande capabilities interactie is binnen FHIR verplicht voor FHIR servers en dient binnen AORTA als een equivalent van de Ping-Pong interactie in HL7v3.

Let op: de capabilities interactie wordt geboden in de <fhir-version> die geldt voor het betreffende endpoint.

Op deze interface worden de additionele HTTP headers, die gelden voor de AORTA FHIR Resource Interface, NIET toegepast.

AORTA FHIR Resource Interface

Feature

core-FHIR-interactie

Type

Abstracte Service

Versie

1.0.1

Groep

GBZ

Gepubliceerd

Delta

Retourneren van AORTA-Version header optioneel gemaakt voor Resource Servers (GBZ-applicaties).

Feature

Versie

Dependency

Aanbieder

Afnemer

core-FHIR-interactie

1.0.1

AORTA Stelseltoken

*

*

core-FHIR-interactie

1.0.1

AORTA-ID HTTP Header

*

*

core-FHIR-interactie

1.0.1

AORTA-Version HTTP Header

*

*

core-FHIR-interactie

1.0.1

Authorization HTTP Header

*

*

core-FHIR-interactie

1.0.1

AORTA access_token

3

-

core-FHIR-interactie

1.0.1

getMetadataZA

*

-

Generiek

Via de AORTA Resource Interface kunnen verschillende services worden aangeroepen op een resource server. Deze services zijn in een use case formaat omschreven op de UC Resource Server pagina. Op deze pagina wordt voor iedere service verwezen naar de van toepassing zijnde implementatiehandleiding, zoals opgesteld en beheerd door Nictiz.

Ten opzichte van de Nictiz implementatiehandleidingen gelden voor alle interacties de volgende uitzonderingen:

  • Wanneer een Bundle wordt gePOST, conform een specifiek FHIR-profiel, bijvoorbeeld "mp-MedicationPrescription-Bundle", dan dient Bundle.meta.profile te zijn gevuld met de juiste canonical.

Bij iedere interactie, worden in ieder HTTP-request, de volgende HTTP headers meegezonden:

Feature

Authorization HTTP Header

Type

Subfeature

Versie

1.0.0

Groep

HTTP Headers

Gepubliceerd

Delta

Initiële versie van feature.

Authorization: Bearer <AORTA access_token>

Een AORTA access_token is altijd een JSON Web Token (JWT).

Een JWT bestaat uit een aantal base64 strings, die aan elkaar zijn gekoppeld met punten. Indien een token een SAML Assertion zou zijn, dan dient het altijd base64url te worden gecodeerd conform RFC 4648. Omdat een base64url geëncodeerde SAMLv2 Assertion geen punten kan bevatten, is de ontvanger altijd in staat om het type token bepalen.

In het token, dat wordt ontvangen in een Authorization header, is informatie opgenomen over welke type inhoudelijk token het betreft en welke versie, dus bijvoorbeeld dat het gaat om een AORTA access_token.

Feature

AORTA-ID HTTP Header

Type

Subfeature

Versie

1.0.0

Groep

HTTP Headers

Gepubliceerd

Delta

Initiële versie van feature.

AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>

Het initialRequestID attribuut bevat het ID van het allereerste request in de hele keten en dient te worden opgenomen in de logbestanden van alle partijen in de keten, zodat bij foutopsporing de verschillende logbestanden aan elkaar kunnen worden gerelateerd.

Het requestID is voor iedere request message uniek. In requests wordt deze gegenereerd door de client. Ook het requestID dient te worden opgenomen in de verschillende logbestanden, zodat altijd duidelijk is op welk bericht een log entry van toepassing is.

Feature

AORTA-Version HTTP Header

Type

Subfeature

Versie

1.0.0

Groep

HTTP Headers

Gepubliceerd

Delta

Initiële versie van feature.

AORTA-Version: contentVersion=<versienummer>; acceptVersion=<versienummer>

Wanneer een Resource Server een FHIR interactie ontvangt, dan kan het a.d.h.v. de syntax van het ontvangen request afleiden om welke interactie het gaat, bijvoorbeeld "een FHIR-search naar Obervations", of "een FHIR-read van een Binary". Daarnaast is iedere interactie voorzien van een versienummer. Voor versienummering wordt gebruik gemaakt van semantic versioning.

De acceptVersion geeft aan conform welke versie(s) de interactie mag worden verwerkt en beantwoord. Het versienummer in de acceptVersion wordt gespecificeerd conform semver, dus bijvoorbeeld "2.x" of "~1.2.3 || ^2.1.0". In het algemeen geldt dat een resource server een interactie dient te verwerken conform de hoogst aangegeven acceptVersion die het zelf op dat moment kan toepassen.

De contentVersion geeft aan welke versie van de interactie daadwerkelijk is gehanteerd. In de contentVersion dient het versienummer de exacte versie van de interactie te bevatten die is gehanteerd, dus zonder wildcards of ranges, bijvoorbeeld “1”, of "2.2". De versie van een FHIR-interactie is opgenomen in het interactie-id.

Bij iedere interactie, worden in iedere HTTP-response, de volgende HTTP headers meegezonden:

Subfeature

AORTA-Version HTTP Header

Versie

1.0.0

AORTA-Version: contentVersion=<versienummer>

De contentVersion geeft aan welke versie van de interactie daadwerkelijk is gehanteerd. In de contentVersion dient het versienummer de exacte versie van de interactie te bevatten die is gehanteerd, dus zonder wildcards of ranges, bijvoorbeeld “1”, of "2.2". De versie van een FHIR-interactie is opgenomen in het interactie-id.

NB. voor Resource Servers (GBZ-applicaties) is het opnemen van een AORTA-Version Header in HTTP-responses optioneel. Resource Broker componenten zullen deze header wel retourneren, en zo nodig dus zelf met het juiste versienummer vullen.

Encodering van pipe symbolen

Wanneer zoekparameters van het type uri worden gebruikt, dan dienen eventuele "|" symbolen conform RFC 3986 te worden geëncodeerd. De Resource Broker componenten encoderen "|" symbolen in FHIR interacties die zij verzenden. Resource Broker MedMij-in dient echter ook om te kunnen gaan met situaties waarbij een PGO Server een "|" symbool niet encodeert.

Zie ook de vraag die hierover is gesteld in BITS.

AORTA FHIR read

De resource client initieert een FHIR read interactie bij de resource server en gebruikt hiervoor de HTTP GET Method op de volgende wijze:

GET [base]/[type]/[id]

Waarbij [type] het FHIR resourcetype aangeeft. Middels [id] wordt de juiste resource instance (op het betreffende FHIR endpoint) geïdentificeerd.

AORTA FHIR search

De resource client initieert een FHIR search interactie bij de resource server en gebruikt hiervoor de HTTP GET Method op de volgende wijze:

GET [base]/[type]{?[parameters]}

Waarbij [type] het FHIR resourcetype aangeeft. Middels [parameters] kan de zoekopdracht worden verfijnd.

AORTA FHIR create

De resource client initieert een FHIR create interactie bij de resource server en gebruikt hiervoor de HTTP POST Method op de volgende wijze:

POST [base]/[type]

Waarbij [type] het FHIR resourcetype aangeeft.

Wanneer de resource succesvol kan worden gecreëerd, dan retourneert de resource server ook de volgende location header:

  • Location: [base]/[type]/[id]/_history/[vid]

Waarbij [id] en [vid] het resource.id en het versie id zijn van de zojuist gecreëerde resource instance.

AORTA FHIR update

De resource client initieert een FHIR update interactie bij de resource server en gebruikt hiervoor de HTTP PUT Method op de volgende wijze:

PUT [base]/[type]/[id]

Waarbij [type] het FHIR resourcetype aangeeft. Middels [id] wordt de juiste resource instance (op het betreffende FHIR endpoint) geïdentificeerd.

AORTA FHIR batch/transaction

De resource client initieert een FHIR batch/transaction interactie bij de resource server en gebruikt hiervoor de HTTP POST Method op de volgende wijze:

POST [base]

De inhoud van de POST is een FHIR Bundle van het type batch of transaction. Iedere Entry in de Bundle bevat een specifiek FHIR interactie die moet worden uitgevoerd.

Binnen AORTA kan een resource server afzonderlijk worden gekwalificeerd en geaccepteerd voor een AORTA FHIR batch interactie en voor een AORTA FHIR transaction interactie.

Ondersteunde FHIR interacties binnen een batch type Bundle:

  • AORTA FHIR create.

Ondersteunde FHIR interacties binnen een transaction type Bundle:

  • AORTA FHIR create;

  • AORTA FHIR update.

Deze sets zullen in de loop van de tijd worden uitgebreid.

Interacties die zijn opgenomen in de Bundle dienen afzonderlijk te worden verwerkt conform de specificaties van de betreffende interactie. Daarnaast gelden de algemene FHIR verwerkingsregels voor batch en transaction type Bundles.

De HTTP-headers, zoals de Authorization, AORTA-ID en AORTA-Version headers gelden voor de gehele batch/transaction en zijn daarmee van toepassing op alle individuele interacties die zijn opgenomen in de Bundle.

AORTA FHIR $is-allowed

Feature

$is-allowed

Type

Service

Versie

1.0.1

Groep

GBZ

Gepubliceerd

Delta

Retourneren van AORTA-Version header optioneel gemaakt voor Resource Servers (GBZ-applicaties).

Feature

Versie

Dependency

Aanbieder

Afnemer

$is-allowed

1.0.1

core-FHIR-interactie

1.0

1.0

De resource server ondersteunt op haar endpoint een custom FHIR operation, waarmee een resource client kan achterhalen of een zorgaanbieder:

  • bepaalde gegevens, los van het feit of deze gegevens daadwerkelijk aanwezig zijn, beschikbaar stelt voor opvraag door een specifieke patiënt (middels een "verzamel-gegevensdienst"), danwel

  • ontvankelijk is voor bepaalde gegevens die een specifieke patiënt haar wenst te sturen (middels een "delen-gegevensdienst"). Hierbij dienen tenminste de ontvankelijkheidscriteria te worden getoetst die zijn gespecificeerd in het MedMij afsprakenstelsel.

Een resource server dient een beschikbaarheids- of ontvankelijkheidsvraag te kunnen beantwoorden voor alle MedMij Verzamelen en Delen gegevensdiensten waarvoor het een rol vervult.

Een resource client kan de beschikbaarheid- of ontvankelijkheidstatus als volgt ophalen:

GET [base]$is-allowed?scope=<scope aanduiding>

Het BSN van de betreffende patient is opgenomen in het access_token.

In Parameters:

Name

Cardinality

Type

Binding

Toelichting

scope

1..1

string

De scope, waarvoor de status dient te worden bepaald.

De parameter wordt gevuld met de string "http://fhir.nl/fhir/NamingSystem/medmij-scope|<scope>". Voor de MedMij use case is de waarde van <scope> gelijk aan de scope van het MedMij Authorization Request, zoals gespecificeerd in het MedMij afsprakenstelsel.

Out Parameters:

Name

Cardinality

Type

Binding

Toelichting

return

1..1

OperationOutcome

Indien de operation succesvol kan worden verwerkt, dan worden een HTTP statuscode 200 en een OperationOutcome geretourneerd. Wanneer het aangegeven gebruik van één van de aangegeven scope-onderdelen bij deze zorgaanbieder is toegestaan, dan wordt de OperationOutcome als volgt gevuld:

  • issue.severity = information

  • issue.code = informational

  • issue.diagnostics = <de feitelijk scope die is toegestaan, eveneens voorzien van het namingsystem "medmij-scope">

Het retourneren van de feitelijk toegestane scope is nodig, omdat een scope meerdere onderdelen kan bevatten en deze mogelijk niet allemaal worden toegestaan.

Wanneer géén van de aangegeven "verzamel-gegevensdiensten" bij deze zorgaanbieder is toegestaan, dan wordt de OperationOutcome als volgt gevuld:

  • issue.severity = information

  • issue.code = suppressed

Wanneer géén van de aangegeven "delen-gegevensdiensten" bij deze zorgaanbieder is toegestaan, dan wordt de OperationOutcome als volgt gevuld:

  • issue.severity = information

  • issue.code = forbidden

Indien de operation niet succesvol kan worden verwerkt, dan kan in sommige gevallen ook een OperationOutcome geretourneerd dienen te worden. De HTTP statuscode die wordt geretourneerd is dan echter niet gelijk aan 200.

Een verzoek waarbij de scope bestaat uit een combinatie van (een) verzamel-gegevensdienst(en) en (een) delen-gegevensdienst(en) dient te worden beschouwd als een ongeldig verzoek.

Voorbeeld $is-allowed

HTTP request:

GET [base]$is-allowed?scope=http://fhir.nl/fhir/NamingSystem/medmij-scope|eenofanderezorgaanbieder~53 HTTP/1.1

XML-based HTTP response wanneer gebruik gegevensdienst is toegestaan:

200 OK

[andere headers]

<?xml version="1.0" encoding="UTF-8"?>

<OperationOutcome xmlns="http://hl7.org/fhir">

<id value="0e855422-b8ef-4247-9443-f3747e78747e"/>

<issue>

<severity value="information"/>

<code value="informational"/>

<diagnostics value="http://fhir.nl/fhir/NamingSystem/medmij-scope|eenofanderezorgaanbieder~53"/>

</issue>

</OperationOutcome>

XML-based HTTP response wanneer gebruik van een delen-gegevensdienst niet is toegestaan:

200 OK

[andere headers]

<?xml version="1.0" encoding="UTF-8"?>

<OperationOutcome xmlns="http://hl7.org/fhir">

<id value="0e855422-b8ef-4247-9443-f3747e78747e"/>

<issue>

<severity value="information"/>

<code value="forbidden"/>

</issue>

</OperationOutcome>

JSON-based HTTP response wanneer gebruik van een verzamelen-gegevensdienst niet is toegestaan:

200 OK

[andere headers]

{

"resourceType": "OperationOutcome",

"id": "0e855422-b8ef-4247-9443-f3747e78747e",

"issue": [{

"severity": "information",

"code": "suppressed"

}]

}

AORTA FHIR pull-notification

Feature

pullNotification

Type

Service

Versie

1.0.0

Groep

GBZ

Gepubliceerd

Delta

Introductie van pullNotification in de vorm van een (infrastructureel) Feature, i.p.v. als een reguliere FHIR-interactie t.b.v. gegevensuitwisseling.

Initiële versie van feature.

Feature

Versie

Dependency

Aanbieder

Afnemer

pullNotification

1.0.0

core-FHIR-interactie

1.0

-

pullNotification

1.0.0

core-FHIR-interactie-broker

-

1.0

HTTP statuscodes

HTTP statuscodes die kunnen worden geretourneerd zijn:

AOF.UCe.VAL.100.v1 - Toetsing type content

Uitkomst

Stap

Omschrijving

i

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content niet ondersteund

statuscode 406 Not Acceptable

Gehanteerd type content niet ondersteund

statuscode 415 Unsupported Media Type

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

Stap

Omschrijving

Uitkomst

1

Het systeem controleert de geldigheid van het AORTA access_token, zoals omschreven in de toelichting Controle en gebruik van het access_token.

Ongeldig token

statuscode 401 Unauthorized

  • In deze situatie wordt, conform RFC 6750, ook een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_token" geretourneerd.

  • In deze situatie mag daarnaast ook een OperationOutcome met issue.code "security" worden geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

2

Het systeem toetst of het verzoek voldoet aan de interface specificatie.

Ongeldig FHIR-verzoek

statuscode 400 Bad Request

  • Wanneer een verplichte FHIR zoekparameter ontbreekt, dan wordt een OperationOutcome met issue.code "required" en de van toepassing zijnde issue.details geretourneerd.

  • Wanneer een verplichte FHIR zoekparameter een ongeldige waarde heeft, d.w.z. een waarde die niet is gespecificeerd binnen de gegevensdienst, dan wordt een OperationOutcome met issue.code "value" en de van toepassing zijnde issue.details geretourneerd;

  • Wanneer een ontvangen FHIR resource instance ongeldig is, dan wordt een OperationOutcome met issue.code "invalid" en de van toepassing zijnde issue.details geretourneerd.

  • In deze situatie wordt, indien van toepassing, conform RFC 6750, ook een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_request" geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

3

Afhankelijk van het type FHIR-interactie wordt nu de juiste generieke extension flow doorlopen, d.w.z.

4

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

  • Wanneer een geldige FHIR zoekparameter wordt ontvangen die niet wordt ondersteund, dan wordt een OperationOutcome met issue.code "not supported" opgenomen in het resultaat. 

  • Wanneer een ongeldige FHIR zoekparameter wordt ontvangen, dan wordt een OperationOutcome met issue.code "invalid" en de van toepassing zijnde issue.details geretourneerd opgenomen in het resultaat.

  • Wanneer een FHIR zoekparameter een geldige waarde bevat die niet wordt ondersteund, dan wordt een OperationOutcome met issue.code "not supported" en de van toepassing zijnde issue.details geretourneerd.

  • Wanneer een optionele FHIR zoekparameter een ongeldige waarde heeft, dan wordt een OperationOutcome met issue.code "value" en de van toepassing zijnde issue.details geretourneerd.

Voor bovenstaande criteria geldt dat ze

  • voor FHIR-interacties die worden vertaald van naar HL7v3: worden getoetst in de resource broker;

  • voor FHIR-interacties die niet worden vertaald: worden getoetst in de resource server.

Verwerking succesvol - resource instance gecreëerd

statuscode 201 Created

Omgang met id, fullUrl en reference

De MedMij informatiestandaard stelt:

  • When a client performs a search on a server, all instances in the returned searchset Bundle SHOULD have the id field populated.

    • Omitting ids is strongly discouraged as it breaks the assumptions about RESTful behavior. However, a server that omits ids is still considered conformant when the conditions below are met:

      • The server does not natively support logical ids

      • And the use case doesn't require read / update / delete / patch support for any of the returned of referenced resources, as stated by the CapabilityStatement for the information standard.

      • And the server includes all referenced resources in the searchset Bundle (regardless of whether the client asked to do so).

  • When a client reads, updates or otherwise addresses an existing resource on a server, the id element SHALL be populated in the request and response, and it SHALL match the id in the request URL.

AORTA eis m.b.t. vulling van resource.id

Een FHIR resource die door een bronsysteem wordt opgeleverd in een search kan zijn voorzien van een id attribuut, binnen FHIR ook wel aangeduid als een logical id. Dit is een technische sleutel die geacht wordt uniek te zijn en hetzelfde te blijven binnen een resource server, zodat duplicaten eenduidig kunnen worden herkend. Het id attribuut is verplicht wanneer de implementatie van een informatiestandaard voor een gegevensdienst één of meerdere interacties bevat (bijvoorbeeld een read- of een update-interactie) waarvoor het resource.id attribuut nodig is.

Wanneer een resource server resource.id vult, dan dient deze te voldoen aan de eisen die FHIR stelt aan logical id's

De informatiestandaard stelt verder dat:

  • If an instance can be accessed on the server using RESTful operations, the id of that instance in the Bundle will be populated. The corresponding fullUrl in this case SHALL be the absolute URL to the instance on the server.

  • Instances within the Bundle may use relative references to each other, like they are on the same server.

  • When id-less instances need to be referenced from within a Bundle, there are two alternatives:

    • UUIDs can be used as single-use ids that will change each time the Bundle is generated. The fullUrl for the instance will be the UUID prefixed with urn:uuid:

    • OIDs can be used if the instance has an OID-based business identifier (i.e. the identifier field), like the UZI number of a healthcare provider. The fullUrl will be the OID prefixed with urn:oid:

    • Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.

De FHIR core standaard stelt dat:

  • The fullUrl element SHALL have a value except that: * fullUrl can be empty on a POST (although it does not need to when specifying a temporary id for reference in the bundle) * Results from operations might involve resources that are not identified.

Iedere entry in een FHIR Bundle die wordt opgeleverd of verstuurd dient te voldoen aan bovenstaande eisen.

Vulling van bundle.entry.fullUrl en transformatie van URL's

Een absolute fullUrl, die wijst naar de instance op de server, is slechts vereist wanneer een resource instance in de Bundle middels een FHIR-read, FHIR-update, FHIR-patch of een FHIR-delete moet kunnen worden benaderd. Een fullUrl in de bundle entry wordt in andere situaties gevuld met een single-use UUID, of met een OID.

Wanneer een Resource Server een FHIR Bundle retourneert met een absolute URL (fullUrl of reference), dan dient deze URL het volgende formaat te hebben:

  • <base endpointadres van Reagerend xIS>/<type>/<id>

Resource Broker MedMij-in of Resource Broker ZA-in transformeert de URL in deze situaties naar volgende formaat:

  • <base endpointadres van Resource Broker XX-in>/<appID>/<type>/<id>

Waarbij het <type> het geretourneerde resource type bevat, bijvoorbeeld "Observation" en <appID> het applicatie-id (zonder root OID) bevat van het bronsysteem.

Bovenstaande aanpassing van absolute URL's is nodig, zodat een Resource Client, indien van toepassing binnen een gegevensdienst, in staat is om, o.b.v. de URL in het zoekresultaat, een FHIR-read, FHIR-update, FHIR-patch of een FHIR-delete uit te voeren via de Resource Broker.

Voorbeeld van een Bundle

Een voorbeeld van een Bundle die die het gebruik van id, fullUrl en reference illustreert is hieronder weergegeven.

<Bundle>

..

<Entry>

<fullUrl value="https://medmij-pgo.vzvz.nl/fhir/453782/Patient/4" />

<Patient>

<id value="4" />

..

</Patient>

</Entry>

<Entry>

<fullUrl value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e" />

<Patient>

<!--  Onderstaande id mag op deze wijze worden gevuld, maar mag in deze situatie ook worden weggelaten -->

<id value="0e855422-b8ef-4247-9443-f3747e78747e" />

..

</Patient>

</Entry>

<Entry>

<fullUrl value="https://medmij-pgo.vzvz.nl/fhir/453782/Observation/10 />

<Observation>

<id value="10" />

<subject>

<reference value="Patient/4" />

</subject>

..

</Observation>

</Entry>

<Entry>

<fullUrl value="https://medmij-pgo.vzvz.nl/fhir/453782/Observation/11 />

<Observation>

<id value="11" />

<subject>

<reference value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e" />

</subject>

..

</Observation>

</Entry>

<Entry>

<fullUrl value="https://medmij-pgo.vzvz.nl/fhir/453782/Observation/12 />

<Observation>

<id value="12" />

<subject>

<reference value="https://medmij-pgo.vzvz.nl/fhir/453782/Patient/5" />

</subject>

..

</Observation>

</Entry>

..

</Bundle>

HL7-v3 Resource Server

AORTA v3-interface

De interface specificaties zijn opgenomen in de HL7v3-Implementatiehandleidingen.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.