Publish Box goes here

Use-casevoorbeelden

Use-casevoorbeelden

Zorgaanbiederauthenticatie is onafhankelijk van de klinische payload. BgZ en eOverdracht gebruiken in de referentie exact dezelfde discovery-, clientauthenticatie-, RAR-, token-, DPoP-, mTLS- en auditcode.

Alleen deze context verschilt:

• gekozen resource-URI;
• synthetische FHIR STU3 Bundle;
• zichtbare samenvatting van het resultaat.

De voorbeelden tonen daarmee dat een nieuwe zorguse-case niet automatisch een nieuw authenticatieprotocol vereist.

Basisgegevensset Zorg

Referentie-endpoint:

https://localhost:9445/fhir/bgz

De compacte synthetische STU3 Bundle bevat:

• Patient;
• actief probleem;
• allergie;
• vitale Observation;
• medicatiegebruik;
• Provenance.

De token-aud, RAR-location, DPoP-htu en werkelijke request-URI wijzen in dit scenario allemaal naar het BgZ-endpoint.

eOverdracht

Referentie-endpoint:

https://localhost:9445/fhir/eoverdracht

De compacte synthetische STU3 Bundle bevat:

• Patient;
• ontslag-Encounter;
• CareTeam;
• functionele Observation;
• risicoprobleem;
• allergie;
• medicatiegebruik;
• geplande wondzorg als ProcedureRequest.

Dezelfde securitycontroles worden uitgevoerd met het eOverdracht-endpoint als resourcebinding.

Afbakening

HAPI FHIR DSTU3 parseert beide fixtures tijdens startup en tests. De zorginhoud is alleen het zichtbare resultaat van een geslaagde beveiligingsflow.

De voorbeelden bewijzen niet:

• volledige landelijke BgZ- of eOverdracht-profielvalidatie;
• complete use-case- of terminologiedekking;
• transformatie tussen informatiestandaarden;
• patiëntmatching;
• toestemming, behandelrelatie of lokale mandatering;
• productiegeschiktheid van de synthetische data.

De R4-versie van de IG is uitsluitend de publicatieschil. De runtimefixtures blijven STU3 en worden daarom niet als R4-conformanceartefacten opgenomen.