Skip to main content

Zorgtoepassingsprofiel huisartsinzage in het thuiszorgdossier v0.2

Dit

Scope

document heeft de status DRAFT. De Ontwikkeling van deze specificiaties worden op de Github Respository uitgewerkt.

Dit betreft v0.2 van het Zorgtoepassingsprofiel huisartsinzage in het thuiszorgdossier en bouwt voor op versie 0.1, maar maakt gebruik van de nieuwe inzichten van de hackathon en Nuts versie 6.

Dit artikel beschrijft achtereenvolgens

  • Doel, plan van aanpak en scope van de toepassing
  • de identifier van de zorgtoepassing;
  • de governance;
  • de informatiestandaarden;
  • de toegestane authenticatiemiddelen;
  • de toegestane grondslagen;
  • organisatiebeleid en
  • de access policy.

Voor een impressie van de functionele uitwerking aan de kant van de raadpleger kan op deze pagina gekeken worden: Functionele uitwerking.

Doel van de toepassing

Het doel van deze toepassing is tweeledig: het verbeteren van de informatievoorziening van de huisarts die behoefte heeft aan informatie over wat er in het VVT domein met de patient gebeurt en het optimaliseren van het werkproces van een verleegkundige die belast is met de taak om de huisarts waar nodig op de hoogte te houden.

In de huidige situatie wordt de huisarts daarover vaak geinformeerd doordat de VVT-medewerker een dubbele administratie bijhoudt in het eigen systeem (ECD) en dat de huisarts (HIS of samenwerkingsplatform). Deze toepassing beschrijft de techniek waarmee het mogelijkl wordt voor de huisarts om rechtstreeks de informatie uit het ECD te raadplegen vanuit het eigen systeem.

Plan van aanpak

UitgangspuntenScope:

HetInzage ontwerpdoor de huisarts is fase 1 van een toepassingveel kanbredere grofwegen opgedeeldrijkere integratie. Hierbij gaat het om informatie 'de andere kant op' en het uitzetten van taken. Deze functionaliteiten worden in tweelatere aspecten:versies van deze usecase toegevoegd.

Governance

De Governance en besluitvorming rondom deelname is belegd bij de techniekprojectgroep Huisarts inzage.

Functioneel Ontwerp

Deze usecase ondersteunt het ophalen van informatie zoals vastgelegd door de (wijk)verpleging in de VVT om deze informatie beschikbaar te stellen aan de huisarts. Het proces werkt als volgt:

De huisarts wil informatie inzien in het bronsysteem (VVT). In het huisartsensysteem start de gebruiker de zoekopdracht. Gezocht wordt op een individuele patiënt. Gebaseerd op de informatie die door de VVT instellingen in de discoveryservice is vastgelegd in combinatie met het BSN van de patiënt wordt in het opvragende systeem een lijst getoond van instellingen waar potentieel informatie op te halen is voor de betreffende patiënt. De huisarts selecteert de juiste instelling. Op basis daarvan vindt een FHIR-request ‘Patient’ plaats naar het bronsysteem. Het bronsysteem beoordeelt deze op een aantal parameters:

  • Ken ik deze patiënt?
  • Heeft deze patiënt een consent afgegeven?
  • Klopt het Verifiable Credential van de aanvrager (geldig en gelijk aan hetgeen is vastgelegd bij de informatiestandaard.patiënt)?
    • Om

Als middel wordt hiervoor wordt het URA nummer van de opvragende organisatie gebruikt. Deze informatie is door de (wijk)verpleging vastgelegd in het bronsysteem bij de patiënt. Indien er informatie beschikbaar is en deze vrijgegeven mag worden wordt het interne PatientID terugekoppeld aan het opvragende systeem. Hierin is ook de informatie opgenomen rondom de contactinformatie van de zorgverlener. Hiermee kan de vraag beantwoord worden ‘wie moet ik bellen voor deze patiënt'. Op basis van dit PatientID kan verdere (medisch inhoudelijke) informatie opgevraagd worden. Er is een lijst beschikbaar van informatie die opgevraagd kan worden indien het bronsysteem deze informatie beschikbaar heeft. Deze bestaat uit rapportages en meetwaarden volgens een afgesproken stramien (in aantal / tijd). Zie hiervoor de paragraaf ‘zorginhoudelijke informatie’.

De verdere medisch inhoudelijke informatie wordt opgehaald op basis van FHIR (ZIB’s waar mogelijk). De informatie wordt in het doelsysteem getoond. Het doelsysteem is er verantwoordelijk voor de informatie in de juiste context te voorkomentonen dat(denk weaan verschillen met eigen informatie). Logging vindt in de gehele keten plaats.

Uitgangspunten

  • De patiënt is reeds bekend/in zorg bij zowel de huisarts als bij de VVT instelling
  • De patiënt heeft consent afgegeven om data te langdelen met de huisarts
  • Informatie kan opgehaald worden bij het bronsysteem en getoond in het doelsysteem In de documentatie is vastgelegd welke informatie (ZIB's) er beschikbaar gemaakt kan worden via deze koppeling (Zie hoofdstuk ‘Lijst met ZIB’s’). Indien informatie opgehaald wordt, zal deze ook getoond worden in een ontwerpfasevorm die passend is in het doelsysteem. Dit geldt ook voor gegevens uit bijvoorbeeld de Patient ZIB. Passend kan zijn als er bijvoorbeeld discrepatenties zijn deze tonen. Er is een lijst beschikbaar van informatie die opgehaald kan worden.
  • De medewerkers blijven hangenin werkenhun weeigen kort-cyclischsysteem samenwerken. aan beide aspecten. Het plan is om met minstends 2 bronleveranciers en 2 raadpleegDe leveranciers samenzijn tezelf werkenverantwoordelijk aanhoe productenzij diede iteratiefmedewerker wordenhet verbeterd.

    beste

    Minimalwillen/kunnen Viableondersteunen.

    • Product

  • Er wordt een startgebruik gemaakt metvan eenbestaande Minimalzorginformatiebouwstenen Viabledie Productvoor (MVP).

    de

    leveranciers al bekend zijn. Hierbij wordt FHIR versie STU3 gebruikt.

  • Het doelafhandelen van de MVPconsent isvraag omvindt van de kant te komen en een goede samenwerking te starten tussen leveranciers en koepels die een basis vormt voor een verdere uitwerking in volgende fase. De MVP moet aantonen aan de markt dat deze toepassing resultaten kan leveren en dat deze aanpak het waard is om eventueel lopende trajecten naar toe te sturen. Leveranciers maken kennis met de onderliggende technieken implementeren en tonen aan dat deze bruikbaar zijn om deze toepassing op te kunnen doorontwikkelen.

    Dit betekent dat voor de MVP bewust en beperkte scope wordt gekozen:

    • De raadpleger haalt gegevens op bij één bronhouder.

    • We gebruiken enkel de ZIBs die bij beide bronhouders al beschikbaar en bruikbaar zijn. Deze komen overeen met de ZIBs van ANW.

    • Zodra er twijfel is over de invulling of bruikbaarheid van de ZIBs schuiven we deze door naar een volgende fase.

    • Voor het MVP geldt dat er geen specifieke lokalisatie functionaliteit in scope zit. In de praktijk weet de huisarts bij welke zorginstelling de patient in zorg is en wordt dit handmatig geregistreerdplaats in het huisartssysteem.

      bronsysteem. Het systeem bepaalt zelf hoe dit vastgelegd wordt en hoe het gecheckt wordt

    • Authenticatie vindt plaats op basis van een URAVerifiable Credential afgeleid vanCredential: het UZIURA Server Certificaat. Het aanmaken van dit credential is nog een handmatige stap.

    • Versiebeheernummer van de diverseorganisatie onderdelenwaar vande dezeopvrager specificatiewerkt wordten zoals vastgelegd in heteen ontwerpUZI zoveelServercertificaat.

      • mogelijk
    • Het meegenomen,bronsysteem maarmoet mogelijkvastleggen en checken welke organisatie bij de informatie mag. Er kan niet op medewerker niveau of rol worden gecontroleerd. Verdere uitwerking in hoofdstuk autorisatie. -Logging vindt in de gehele keten plaats

    Shortcuts en Toekomstige ontwikkelingen: Sommige zaken kunnen we op dit moment niet invullen zoals we willen omdat dit (om verschillende redenen) nog niet realistisch is. Deze zaken plaatsen we in techniekdeze usecase buiten scope en worden verwerkt.later eventueel toegevoegd. Het gaat om:

    • We sluiten niet aan op Mitz (maar gaan consent lokaal oplossen)
  • Er

    Volgendeis versies

    geen

    Voorgoed volgendeauthenticatiemiddel versiesvoor de gebruiker beschikbaar (DEZI) dus werken we met een VC waarbij de organisatie obv een UZI certificaat wordt geauthenticeerd

  • We implementeren niet alle mogelijke ZIB’s want die zijn niet beschikbaar in bronsystemen, maar hanteren een subset
  • dPOP wordt pas in een later stadium toegevoegd, voor nu maakt dit geen onderdeel uit van de specificatieusecase
    • staan
  • We verrijken / corrigeren de volgeneinformatie onderwerpen opuit de roadmap:

    UZI
      credentials niet (human readable namen), dit moet bij de bron opgelost worden
    • HetBij uitwisselengebrek vanaan een zorgteam.
      • generieke
    • Bloed glucose metingen
    • Pijnscore
    • Versiebeheer(?)

    Identifier van de zorgtoepassing

    De identifier van de zorgtoepassing huisartsinzage is een string die wordt gebruikt bij het discover, authenticatie en autorisatie proces. Op basis van deze identifierlokalisatiedienst wordt er een setworkaround aantoegepast credentialswaarbij handmatig wordt vastgelegd waar de patiënt in zorg is en waar dus informatie opgehaald kan worden

Architectuur beschrijving

Gebruik van Nuts

Voor deze usecase wordt gebruikt gemaakt van de raadplegerNuts gevraagdinfrastructuur. enSpecifiek eenwordt autorisatiegebruik policygemaakt toegepast. Gezien we incrementeel hier aanpassingen aan willen maken is het waarschijnlijk handig om een versienummer toe te voegen. Deze string is human-readable, maar het is nietvan de bedoeling om hem te parsen.

Het voorstel is de volgende identifier: zorginzage-ha-vvt-v2025.1

Toelichting

Deze toepassing is een profiel op zorginzage.

De toevoeging ha-vvt laat de bronhouder weten dat het om informatie uit het vvt domein gaat. Als een zorginstelling meerdere domeinen bedient is dit handig om te weten. De bronhouder weet nu ook dat het een huisarts ismogelijkheden die de raadplegingV6.1 doet.

versie

v2025.1van geeftNuts biedt en daarmee dus ook van did:web. Voor de versieinformatie aan.specifiek 2025 Isover de "major"Nuts-laag versie,wordt verwezen naar de 1officiele staatdocumentatie: https://nuts-node.readthedocs.io/en/stable/

Registreren voor de "minor"use-case

versie. Versiebeheer dient nog verder te worden uitgewerkt.

Governance

GovernanceX509CredentialTool: vanDe hetNuts zorgtoepassingsprofielcommunity wordt uitgevoerd door intiatiefnemende leveranciers, te weten: Nedap, HINQ, Ecare en Topicus. Leveranciers die op een later moment ook het zorgtoepassingsprofiel zullen ondersteunen maken daarmee per direct onderdeel uit van ‘governance groep’. Partijen zorgen zelfstandig voor het raadplegen van de achterban om te komen tot een goede beslisvoering.

Partijen streven naar het overdragen van deze governance aan zorgpartijen als InEen en Actiz.

Informatiestandaard

Er isbiedt op dit moment geen2 landelijketools informatiestandaardaan beschikbaarom rondomeen X509Credential te genereren:

Beide tools geven instructies om stappen 9-10 uit te kunnen voeren.

Data ophalen bij de inzageVVT

TODO: write out actions for each (group of) steps

Lokalisatie

Bij gebrek aan een generieke lokalisatiedienst wordt lokalisatie lokaal ingevuld. Dit houdt in dat er in de systemen zelf bijgehouden wordt waar data opgehaald kan worden. Bijvoorbeeld door de VVT instelling waar de patient bij in behandeling is expliciet vast te leggen.

Grondslag

Voor de behandelrelatie wordt ervan uitgegaan dat als de huisarts is vastgelegd bij de patient in het VVT dossier, er sprake is van een behandelrelatie.

Consent: de verantwoordelijkheid voor het thuiszorgdossier.vastleggen Zolangen dezechecken nogvan nietconsent beschikbaarwordt ingevuld door het bronsysteem zelf.

Adressering

Discovery Service

Discovery Definition

Algemene uitleg over wat is definiereneen weService Discovery is te vinden op de Nuts Wiki pagina Service Discovery

Input descriptors:

Qua benodigde credentials kennen wij 2 verschillende credentials, een X509Credential en een DiscoveryRegistrationCredential.

X509Cerdential

Dit betreft een X509Credential conform Nuts RFC023, ondertekend met een UZI-servercertificaat.

Aanmaken kan bijv. met de go-didx509-toolkit of de Java library. Als uitgever is besloten om hier eende eigenchain informatiestandaard.op te nemen het dichtst bij de leaf-certificaat.

DaarbijGezocht iskan hetworden belangrijk dat we een invulling geven aan hetop de eis van proportionaliteit bij data deling. Dit om zowel de privacynaam van de patientDID, teorganisatienaam, beschermenplaats alsmede& alleenURA.

relevante
DiscoveryRegistrationCredential
informatie

Dit betreft een DiscoveryRegistrationCredential conform de uitleg op de Nuts Wiki pagina over Service Discovery.

Hierbij is een veld toegevoegd aan de raadplegercredentialSubject genaamd fhirBaseURL. Deze kan gebruikt worden door gebruikers van de Discovery Service om te tonen.weten Het verdient aandacht om in kaart te brengen op basis van welke criteria er bijwaar de brondaadwerkelijke FHIR data opgehaald kan en moet worden gefilterd.worden.

Identiteit en authenticatie

Authenticatie

Om veilig gegevens te kunnen delen,delen tussen verschillende zorgaanbieders, is zorgaanbieder-overstijgende authenticatie van zorgorganisaties en zorgverleners essentieel. Vanuit de NEN wordt gewerkt aan een norm met betrekking tot identificatie en authenticatie. Op het moment dat deze norm gepubliceerd wordt zullen we de landelijke ontwikelingen mbt tot deze norm volgen. Om op korte termijn informatie uitwisseling mogelijk te maken, zal de authenticatie geborgd worden op de volgende manier:

Server & Client authenticatie

Voor server & client authenticatie is besloten om de volgende uitgangspunten te hanteren:

  • Testomgevingen maken gebruik van Test UZI-servercertificaten voor de X509Credentials & geldige certificaten voor TLS (publiekelijk vertrouwde & PKIOverheid) op de FHIR endpoints en als clientAuthenticatie
  • Acceptatieomgevingen maken gebruik van of test of productie UZI-servercertificaten voor de X509Credentials & PKIOverheid voor TLS op de FHIR endpoints en als clientAuthenticatie
  • Productieomgevingen maken enkel gebruik van productie UZI-servercertificaten voor de X509Credentials & PKIOverheid voor TLS op de FHIR endpoints en als clientAuthenticatie

OrganisatiesIdentificatie

Om de raadplegende organisatie te identificeren wordt gebruik gemaakt van het UZI abonnenumummer ook wel bekend als het URA nummer.nummer. Als middel voor de authenticatie van dit nummer gebruiken we een verifiable credenialcredential en de OpenID Foundation standaarden voor authenticatie.

Omdat het UZI register als authentieke bron zelf nog geen URA Credentials uitgeeft wordt dit credential afgeleid van een UZI Servercertificaat van de betreffende organisatie. We gebruiken hiervoor een nieuw credential NutsX509Credential waarvan de ontwikkeling hier te volgen is: https://github.com/nuts-foundation/nuts-node/issues/3582

Policy Definition

Input descriptors:

Qua benodigde credentials kennen wij 2 verschillende credentials, een X509Credential en een NutsEmployeeCredential.

X509Credential

Zie de X509Credential onder Discovery Definition, deze is exact het zelfde.

NutsEmployeeCredential

Zie de Nuts Wiki pagina over Requesting Access. voor context.

ZorgverlenersAutorisatie

DeVoor raadplegendefase zorgverlener zelf wordt niet geauthenticeerd, er wordt vertrouwd op het authenticeringsmechanisme1 van de gebruikteHuisartsinzage applicatie.gaan Welwij wordenuit ervan identificerendeautorisatie attributenop tbh5 logging-niveaus:

  • Aanwezig op Discovery service
  • Behandelrelatie
  • Consent
  • Zib
  • Fhir query parameters

Discovery service

Om data bij een bronhouder op te halen, wordt de discovery service gebruikt om het adres te vinden. Hoewel het technisch mogelijk is om data op te halen bij een partij die niet (meer) aangemeld is bij de discovery service, is dit functioneel en auditdoeleindenqua meegestuurdbeveiliging inniet wenselijk. Daarom moet de vormbronhouder ook controleren of de partij waarvoor de aanvraag ingedient wordt nog steeds aangemeld is voor de toepassing op de discovery service.

Behandelrelatie

Om toegang te krijgen tot gegevens van een NutsEmployeeCredential.

patient

Grondslagis enhet toestemming

vereist

Voordat er een behandelrelatie tussen de zorgtoepassing huisartsinzage in het thuiszorgdossier worden de volgende grondslagen ondersteund: expliciete toestemming vooraf.

In een later stadium kan onder de in de Nuts Bolt Zorginzage beschreven voorwaarden desgewenst de Wabvpz-toestemming vooraf worden toegevoegd.

Voor expliciete toestemming vooraf zijn de volgende bewijzen toegestaan:

  • registratie in het bronsysteem (bijvoorbeeld door middel van een 'vinkje')
  • ingescand, door de betrokkene ondertekend, toestemmingsformulier

Toestemming voor het delen van data gebeurt op organisatie niveau. Een toestemming moet dus naar een URA nummer terug te leiden zijn.

Organisatiebeleid

  • Iedere partij die de zorgtoepassing huisartsinzage in het thuiszorgdossier aanbiedt is zelf verantwoordelijk voor de beschikbaarheid van de eigen infrastructuur, het bron- en/of afnemersysteemhuisartspraktijk en de Nuts-node.
    • patient
  • De leveranciers van de actor voldoet aan de eisen zoals gesteld in de NEN7510, NEN7512 en NEN7513.
  • De leveranciers van de actor voldoet aan de eisen zoals gesteld in de Algemene verordening gegevensbescherming (AVG).
  • De leveranciers van de actor voldoet aan de eisen zoals gesteld in de Wet aanvullende bepalingen verwerking persoonsgegevens in de zorg (Wabvpz).

Access Policy

Niet-persoonsgebonden resources

Momenteel niet van toepassing.

Persoonsgebonden resources

Dit hoofdstuk beschrijft de afspraken die gelden voor persoonsgebonden resources.

Autorisatie-record

Nuts Authorization Credentials zijn deprecated.

TODO: Dit stuk moet worden omgeschreven naar een Policy Based Access Controll (ABAC). Tijdens de hackathonbekend is daar een OPA policy ontwikkeld die gebruik maakt vanbij het zorgnetwerkbronsysteem. enDeze de introspectie resultaten van het access token.

Het ophalen van huisartsinzage in het thuiszorgdossier vereist een geregistreerd autorisatie-record in de vorm van een Nuts Authorization Credential. Het credential moet voldoen aan de volgende eisen:

  • De issuer moet het DID bevatten van de bronhouder.
  • credentialSubject.id moet het DID van de afnemer bevatten
  • credentialSubject.purposeOfUse moet gelijk zijn aan zorginzage-thuiszorgdossier-door-huisarts.
  • credentialSubject.legalBase.consentType moet gelijk zijn aan implied bij veronderstelde toestemming of explicit bij expliciete toestemming
  • credentialSubject.subject moet het BSN bevatten als OID: urn:oid:2.16.840.1.113883.2.4.6.3:999999990.

Normatieve einddatum autorisatie

Bij het aanmaken van een autorisatie-record dient door middel van het veld 'expirationDate' een einddatum aan de autorisatie te worden gegeven. Ten eerste dient deze einddatum gebaseerd te zijn op de wensen van de cliënt in kwestie. De zorgverlener dient de cliënt te vragen naar de gewenste duur van een toestemming. Wanneer de wens van de cliënt ten aanzien van de duur van de toestemming niet is vastgelegd, gelden de volgende normen Bij een 'expliciete toestemming vooraf' is geen einddatum.

Intrekken autorisatie

Er zijn verschillende redenen denkbaar voor het intrekken van een autorisatie:

  1. Wanneer een autorisatie is gebaseerd op een expliciete toestemming dient deze te worden ingetrokken wanneer de expliciete toestemmingcontrole wordt ingetrokken. Het autorisatie-record moet in deze gevallen worden ingetrokken door de bronhouder.

Access token

Bij de aanvraag van het access token moet het autorisatie-record volgens bovenstaande eisen worden meegestuurd in het credentials-element. Daarnaast moet er gebruikersinformatie meegestuurd worden in het uzi-element. Het purposeOfUse-element moet de waarde ‘zorginzage-thuiszorgdossier-door-huisarts‘ bevatten.

Levensduur access token: 300 seconden (5 minuten)

Authenticatiecontract

Levensduur authenticatiecontract: 36.000 seconden (10 uur)

Authenticatie vindt plaatsgedaan op basis van inrichtinghet URA-nummer waarmee een resource wordt opgehaald. Dit nummer is terug te vinden in het organization_ura veld van heteen bevragendtoken systeem.introspect Bijop dezede bevragingNuts wordtnode. Zie ook stap 11 in "Request data at VVT" onder de architectuurbeschrijving.

Om een resource van een patient op te kunnen halen moet het UZI-nummerbronsysteem meegegeventoestemming alsvan identificatiede voorpatient geregistreerd hebben of op kunnen halen. Een algemene toestemming volstaat hier, waarbij de patient toestemming geeft om zijn of haar gegevens te delen met huisartsen.

Zib

Voor de Huisartsinzage is een beperkte set aan Zibs beschikbaar. Deze zijn uitgewerkt in de logging.lijst van ZIBs. Alleen deze Zibs kunnen opgehaald worden binnen de scope van de Huisartsinzage.

Autorisatie

Fhir policy

query parameters

WanneerOm eente bronhoudervoorkomen eendat binnenkomender requestteveel afhandeltinformatie moetopgehaald kan worden (bijvoorbeeld middels het gebruik van _include parameters) wordt er ook autorisatie uitgevoerd op basis van de BSN,gebruikte zoalsquery vermeldparameters. Hier wordt onderscheid gemaakt tussen verplichte parameters en toegestane parameters. Alle query parameters die gedefinieerd zijn in hetde autorisatie-record,set toegangaan wordengebruikte gegevenZibs tot(zie hieronder) zijn verplicht. Het gebruik van andere query parameters is niet toegestaan.

MedewerkerID

Uitgangspunt: Identificatie van de gerelateerde resources zoals benoemd in het hoofdstuk Resources.

Er wordt gewerkt met een eenvoudig autorisatiemodelmedewerker op basis van een (intern) MedewerkerID, gecombineerd met een VC gebaseerd op informatie binnen het UZI-servercertificaat.

Informatie

Lijst van ZIBs

Tabel met FHIR resources en queries

Hieronder staan de identiteitendpoints die beschikbaar gesteld moeten worden door de partijen die toegang tot het ophalen van de raadplegendeinformatie organsiatie.in Dehet gebruikersrolVVT wordtdomein nietverlenen. meegenomenTer verheldering zijn de kolommen Sort en Count toegevoegd om aan te tonen hoeveel resultaten er geretourneerd worden en op welke manier deze worden gesorteerd. Het is van belang dat bij een aanroep alle parameters gebruikt worden die in de autorisatietabel beslissing.

staan

Resources

en

Dezeook sectiegeen beschrijftextra. Dit heeft te maken met de ZIBS en bijbehorende FHIR profielencontrole die moetende wordensystemen ondersteund.doen Inop de specificatieverifiable iscredentials. Die controle wordt op die manier gedaan om te voorkomen dat met een setparameter van ZIBs opgenomen waarin de huisarts geïnteresseerd is. Die set iszoals een subsetinclude vanextra degegevens set die is gerealiseerd in de NUTS toepassing voor ANW. De beschikbaar stellende partijen in fase 1 (Nedap en eCare) hebben die gebreidere set al beschikbaar. Het ligt daarom voor de hand de ANW set te hanteren als startpunt en te bezien in hoeverre en onder welke voorwaarden die voor de huisarts relevant zijn.meekomen.

Logistiek

ConceptZIB ZIB(s)Method FHIR-resourceSortCountEndpointProfiel
Patient/ClientAlerts https:GET/fhir/Flag?patient={patientId}}&_profile=http://zibs.nictiz.nl/wiki/Patient-v3.1(2017NL) en https://zibs.nl/wiki/BurgerlijkeStaat-v3.0(2017NL)fhir/StructureDefinition/zib-Alert https://simplifier.net/nictizstu3-packages/nictiz.fhir.nl.stu3.zib2017/nl-core-patient2.2.10/files/1954733

Zorginhoudelijk

nogbeschikbaar* https:
ConceptAllergie ZIBGET FHIR-resource/fhir/AllergyIntolerance?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerancehttps://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.18/files/2317138
Tekst rapportagesBloeddruk *GET Date nietDESC 5 /fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure&_sort=-date&_count=5https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954744
LichaamsgewichtGETDate DESC5/fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight&_sort=-date&_count=5https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954750
LichaamslengteGETDate DESC5/fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight&_sort=-date&_count=5https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954746
LichaamstemperatuurGETDate DESC5/fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature&_sort=-date&_count=5https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954748
PatiëntPOSTZie onder de tabelhttps://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954638
RespirationGET/fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-Respiration&_sort=-date&_count=5https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954947
TekstRapportageGETDate DESC10/fhir/Observation?patient={patientId}&_profile=https://nuts.nl/fhir/StructureDefinition/nl-core-nursingreport&_sort=-date&_count=10 https://simplifier.net/anw/nl-core-nursingreport
Alertshttps://zibs.nl/wiki/Alert-v4.1(2020NL)https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954733
Wilsverklaring https:GET/fhir/Consent?patient={patientId}&_profile=http://zibs.nictiz.nl/wiki/Wilsverklaring-v3.1.1(2020NL)fhir/StructureDefinition/zib-AdvanceDirective https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954726
Woonsituatie GET /fhir/Observation?patient={patientId}&_profile=http://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954848nl/fhir/StructureDefinition/zib-LivingSituation https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954848
Bloeddrukhttps://zibs.nl/wiki/Bloeddruk-v3.2.1(2020NL))https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954744
Lichaamsgewichthttps://zibs.nl/wiki/Lichaamsgewicht-v3.2(2020NL)https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954750
Lichaamslengtehttps://zibs.nl/wiki/Lichaamslengte-v3.1.1(2020NL)https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954746
Pijnscorehttps://zibs.nl/wiki/Pijnscore-v4.1(2024NL)https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954746
Bloedglucosehttps://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_VitalSigns)https://simplifier.net/nictizstu3-zib2017/vitalsign-bloodglucose
Allergieenhttps://zibs.nl/wiki/AllergieIntolerantie-v3.3(2020NL)http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance

Voor het ophalen van de Patiënt geldt: POST /fhir/Patient/_search

  • Header: Content-Type = x-www-form-urlencoded (zie https://www.hl7.org/fhir/http.html#search-post)
  • Body: identifier=http://fhir.nl/fhir/NamingSystem/bsn|{bsn}

Foutafhandeling

In deze fase concentreren we ons op beveiliging – juist in de pilot zal bekeken moeten worden of dit ook leidt tot voldoende gebruiksgemak. In de basis wordt dus alleen getoond DAT er een fout is en geen specifiekere informatie zoals 'patient niet gevonden'. Informatie die publiekelijk beschikbaar is (bv inhoud van de usecase als zijnde 'deze resource valt buiten de usecase') zou toegevoegd mogen worden om nieuwe ontwikkelaars makkelijker te maken bij het testen

Versiebeheer

Wordt momenteel uitgewerkt in usecase ANW. Resultaat wordt hier opgenomen

Omgevingen

De volgende omgevingen zijn beschikbaar in de OTAP omgeving: -Ontwikkel: lokaal bij de ontwikkelaars zelf -Test: Testomgeving waar met UZI testcertificaten gewerkt wordt -Acceptatie: acceptatieomgeving waar met zowel test als productie UZI certificaten gewerkt kan worden (Dit omdat de leveranciers verschillend om gaan met acceptatie en staging). -Productie: productie omgeving waar met productie UZI servercertificaten gewerkt wordt.

Back to top