MedMij:FO:V1/FunctioneelOntwerp: verschil tussen versies

Uit informatiestandaarden
Naar navigatie springen Naar zoeken springen
(MM-3790: Verhuis release notes voor MedMij Functioneel Ontwerp 1 naar centrale pagina)
(geen verschil)

Versie van 25 okt 2022 09:37


1 Inleiding

1.1 Algemeen

MedMij is dé Nederlandse standaard voor het veilig uitwisselen van gezondheidsgegevens tussen zorggebruikers en zorgaanbieders. Deze uitwisseling vindt plaats via een PGO, een persoonlijke gezondheidsomgeving. Hiermee kan je als persoon je gezondheidsgegevens van verschillende zorgverleners op één plek verzamelen, beheren en delen. Een gedetailleerde omschrijving is te vinden via de MedMij website.

Deze pagina beschrijft het functioneel basisontwerp dat voor alle MedMij uitwisselingsscenario's (usecases) van toepassing is. In de individuele informatiestandaarden zijn de aanvullende specificaties voor de usecases opgenomen. De communicatiestandaard die voor MedMij usecases wordt toegepast is HL7 FHIR, waarvan de technische ontwerpen via de MedMij-landingspagina bereikt kunnen worden.

1.2 Doelgroep

De doelgroep voor deze pagina bestaat uit:

  • Productmanagers, architecten, ontwerpers, bouwers en testers van XIS- en PGO-leveranciers, regio-organisaties en Nictiz;
  • Vertegenwoordigers van patiënten, laboratoria en zorgverleners.

1.3 Kaders & Uitgangspunten

1.3.1 Richtlijn

Daar waar een richtlijn van toepassing is op de gegevensuitwisseling, wordt dit op het functioneel ontwerp van de betreffende informatiestandaard vermeld.

1.3.2 Geografische reikwijdte

De geografische scope van alle ontwerpen van MedMij is Nederland.

1.3.3 Infrastructuur

De berichten beschreven voor MedMij kunnen over elke willekeurige infrastructuur worden getransporteerd. De specificatie van de infrastructuur en het berichttransport is buiten scope van de MedMij usescases in de informatiestandaarden. MedMij kent echter wel een een afsprakenstelsel met spelregels die zorgen dat de gegevensuitwisseling veilig is, privacy geborgd is en dat systemen aan juridische eisen voldoen.

1.4 Kwalificatie

Op deze informatiestandaard is een Nictiz kwalificatie van toepassing. Kwalificatie vindt plaats per systeemrol. Meer informatie over de kwalificeren is te vinden op de kwalificatiepagina.

2 Basisprincipes MedMij usecases

2.1 Doel en Proces

Het doel van de verschillende MedMij usecases is: het voor personen mogelijk maken regie op hun eigen gezondheid te nemen door met de zorg(verlener) gegevens uit te wisselen. De publicaties met daarin de verschillende usecases zijn te vinden via de MedMij-landingspagina.

De systemen die in de usecases worden onderscheiden zijn:

  • PGO, persoonlijke gezondheidsomgeving
  • XIS, zorginformatiesysteem

Vanuit het MedMij afsprakenstelsel worden in aanvulling hierop ook rollen onderscheiden voor de dienstverlenende partijen die de gegevensuitwisseling ondersteunen. Dit wordt nader toegelicht in deze begrippenlijst.

De wijze waarop gegevens worden uitgewisseld, is in de naamgeving van de usecase aangegeven met de transactie. De usecases maken gebruik van twee transactietypes:

Transactienaam Uitwisseling Activiteit PGO Activiteit XIS
Raadplegen Gegevens PGO <- XIS (PULL) Raadplegen gegevens Beschikbaarstellen gegevens
Sturen Gegevens PGO -> XIS (PUSH) Sturen gegevens Ontvangen gegevens

Het MedMij afsprakenstelsel spreekt ook vanuit het perspectief van een PGO, maar heeft het over respectievelijk "Verzamelen" en "Delen".

2.1.1 Patient journeys

2.2 Dataset en Zorginformatiebouwstenen

Het programma 'Registratie aan de bron' heeft zorginformatiebouwstenen voor Nederland gedefinieerd. Een zorginformatiebouwsteen (zib) beschrijft nauwkeurig wat er over een bepaald onderwerp van het zorgproces van de patiënt moet worden vastgelegd. Zorginformatiebouwstenen zijn opgesteld vanuit de gedachte dat dezelfde informatie relevant is voor artsen, verpleegkundigen, paramedici en patiënten, ieder met hun eigen invalshoek. MedMij heeft gekozen om de datasets zoveel mogelijk samen te stellen uit zibs. Daarbij is altijd de volledige zib gedefinieerd zodat contextonafhankelijke implementatie mogelijk wordt. Dit zorgt er ook voor dat interoperabiliteit met zorginformatiesystemen mogelijk wordt. Soms gebruikt een informatiestandaard (bijv. de Basisgegevensset Zorg, BgZ) slechts een deel van een bepaalde zib. Daar waar geen zib voorhanden is of er in de bestaande zib informatie ontbreekt, zijn extra gegevenselementen opgenomen in de dataset. Deze extra elementen zijn waar mogelijk afgestemd met andere standaarden zoals HL7 FHIR resources.

De functionele specificaties (datasets en transacties) worden gepubliceerd in ART-DECOR. Vanuit alle functionele ontwerpen is er de mogelijkheid om via een link de publicatie te openen, soms aangevuld met een view (iframe).

2.3 Terminologie en vertalingen

Richtinggevend voor de applicaties die MedMij-standaarden implementeren is dat ze Nederlandse termen gebruiken. Dit wordt op de volgende wijze functioneel en technisch ondersteund.

Functioneel

De functionele definities van de MedMij-informatiestandaarden zijn zoveel mogelijk samengesteld uit bestaande zibs. De zibs bevatten veel (eigen) waardelijsten. Bij deze waardelijsten wordt een Nederlandse vertaling gegeven.

Voor het verwerken en tonen van waarden uit bestaande terminologie- en codestelsels (zoals SNOMED CT en LOINC) in een PGO, kan het volgende uitgangspunt gehanteerd worden:

  • Indien er een Nederlandse patiëntvertaling beschikbaar is, toon deze aan de PGO-gebruiker.
  • Indien een Nederlandse patiëntvertaling ontbreekt, maar er wel een Nederlandse zorgverlenervertaling beschikbaar is, toon deze aan de PGO-gebruiker.
  • Indien zowel een Nederlandse patiëntvertaling als een zorgverlenervertaling ontbreken in het terminologie- of codestelsel, volg de dataset, waarin voor uitgewerkte waardelijsten ook Nederlandse termen beschikbaar zijn.
  • Indien Nederlandse vertaling geheel ontbreekt, kan de Engelse term getoond worden.

Meer informatie over eventueel benodigde licentie en implementatie van terminologie- en codestelsels is te vinden in het standaardenoverzicht van Nictiz

Ook wat betreft de omschrijving van informatie geniet het de voorkeur om ze veel mogelijk gebruik te maken van Nederlandse termen. De (omschrijvingen van de) conceptnamen die in zibs gehanteerd worden, kunnen gebruikt worden, evenals correcte Nederlandse synoniemen daarvan die mogelijk beter aansluiten op het persoonsdomein.

Technisch

Voor de waardelijsten in de zibs zijn FHIR ValueSet-resources gemaakt. Deze bevatten gestructureerd de Nederlandse vertalingen van de zib-concepten en worden dus bij de standaard aangeboden. Leveranciers kunnen bij het weergeven van concepten uit deze ValueSets dan ook kiezen voor de Nederlandse vertaling.

De ValueSets zijn óf direct gekoppeld in de FHIR-profielen, of kunnen, indien dit niet mogelijk is, via een FHIR ConceptMap gerelateerd worden aan de waarden die binnen een profiel gebruikt worden. Zie hiervoor de specificaties in de FHIR-implementatiegids.

2.4 Zib referenties

MedMij informatiestandaarden gebruiken zoveel mogelijk bestaande zibs. Deze zibs verwijzen naar elkaar middels referenties. FHIR kent ook het concept van referenties. Via zo'n referentie kan bijvoorbeeld ook het specialisme van een zorgverlener bij een verrichting opgehaald worden. Het uitgangspunt is dat alle references 'resolvable' (opvraagbaar) moeten zijn, niet dat ze resolved worden. Een PGO zou er ook voor kunnen kiezen om een klikbare link te tonen, waarmee een gebruiker (de persoon) desgewenst zelf kan opvragen. Omdat de verbinding met een XIS (sessie) maar beperkte tijd in stand blijft, kan er indien nodig een nieuwe sessie worden gestart voor deze opvraging. Meer informatie over het gebruik van FHIR-references binnen MedMij is te vinden in de informatiestandaardoverstijgende principes in de FHIR-implementatiegids.

2.5 Herleidbaarheid

Voor gegevensuitwisseling tussen patiënt en zorgverlener is het belangrijk dat inzage wordt gegeven in de informatie over de totstandkoming van gegevens in het systeem van de gebruiker (PGO of XIS). Het doel hiervan is aan zowel patiënt als zorgverlener de mogelijkheid te bieden om zelf de gegevens op waarde te kunnen schatten en/of in context te kunnen plaatsen. Het principe van deze informatie over de uitwisseling zelf wordt in de informatiestandaarden aangeduid als herleidbaarheid. Voor de informatiestandaarden houdt dit in, dat zowel patiënt als zorgverlener informatie kunnen inzien over op welk moment (datum/tijd) en met welke partij (“bron”) de inhoudelijke gegevens zijn uitgewisseld.

Met herleidbaarheid wordt hier dus niet bedoeld dat alle references (verwijzingen) naar andere FHIR-resources resolvable (opvraagbaar) moeten zijn. Dat is weliswaar ook een uitgangspunt in het ontwerp maar staat los van hoe het herleidbaarheidsprincipe bedoeld is.

De scope van herleidbaarheid in de context van MedMij:

  • Raadplegen door de PGO – geef informatie over wie de inhoudelijke gegevens beschikbaar stelt en wanneer ze zijn verzameld door de PGO-gebruiker.
  • Ontvangen door XIS – geef informatie over wie de inzender is en wanneer de gegevens zijn ontvangen in het systeem. Zorg bij overname (reconciliatie) van deze gegevens in het dossier dat in ieder geval duidelijk wordt dat de patiënt deze heeft gedeeld.

Tips voor implementatie en kwalificatie zijn verderop in deze tekst te vinden bij Aanwijzingen voor de functionaliteit van systemen

Voorbeelden gebruik (patient journeys)

  1. Een patiënt is door de huisarts verwezen naar het ziekenhuis. De verwijsbrief van de huisarts is via digitale gegevensuitwisseling in de zorg toegevoegd aan het ziekenhuisdossier. De patiënt wil graag weten welke informatie beide zorgaanbieders hebben en raadpleegt met zijn PGO alle documenten (PDF/A) die aanwezig zijn bij de huisarts en bij het ziekenhuis. Dezelfde verwijsbrief verschijnt twee keer in de PGO. Doordat de patiënt kan zien van welke zorgaanbieder de gegevens afkomstig zijn, is impliciet duidelijk dat de brief van de huisarts ook in het ziekenhuis is verwerkt.
  2. Een aantal bloedwaarden van een patiënt worden in opdracht van de arts maandelijks gemeten door een laboratorium. De patiënt heeft zich niet geabonneerd op labresultaten en ontvangt daardoor geen notificatie dat er nieuwe gegevens beschikbaar zijn. Na een paar maanden vraagt de patiënt zich af of de metingen in de PGO nog wel actueel zijn. Hij kijkt naar de datum waarop voor het laatst metingen in het PGO zijn verzameld. Dit blijkt twee maanden eerder te zijn, de patiënt weet daardoor dat hij de labresultaten beter nog eens opnieuw kan raadplegen.

2.6 Systeemrollen

De informatiestandaard kent altijd een formele beschrijving met ten minste de volgende metagegevens: De informatiestandaard (met een informatiestandaardnaam) bestaat uit een of meer transacties (met per transactie een transactienaam), met voor elk van de transacties een aanduiding van de bijbehorende systeemrollen en de bijbehorende bedrijfsrol (Patiëntbedrijfsrol of Zorgaanbiedersbedrijfsrol). Op basis van de systeemrol wordt door de MedMij autorisatieraad, het bestuur van Stichting MedMij, een systeemrolcode toegekend. Deze identificeert 1 versie van 1 systeemrol. Een versie van een systeemrol wordt geïdentificeerd door 1 Systeemrol-code. Deze metagegevens zijn van belang voor de definitie van de gegevensdiensten binnen het MedMij afsprakenstelsel. Nadere informatie over gegevensdiensten, zoals de geldigheidsperiode, vindt u in de Catalogus van het MedMij Afsprakenstelsel.

3 Aanvullende informatie

3.1 Eisen aan de functionaliteit van systemen

Vanuit het MedMij afsprakenstelsel gelden verdere eisen met betrekking tot de architectuur en informatiebeveiliging.

Tevens kunnen er voor bepaalde usecases aanvullende afspraken en eisen zijn gesteld vanuit o.a. versnellingsprogramma's (VIPP). Dit wordt vanuit de programma's gepubliceerd en is niet opgenomen in de specificaties van de informatiestandaard.

3.2 Aanwijzingen voor functionaliteit van systemen

3.2.1 What's new

Een PGO kan na een eerste raadpleging nieuwe of gewijzigde gegevens raadplegen middels een "what's new" uitvraag. Voordeel van deze functionaliteit is dat niet onnodig reeds bekende gegevens opnieuw beschikbaar gesteld hoeven te worden. Denk hierbij aan wederom raadplegen van een volledige gegevensset zoals de BgZ. PGO dient hiervoor de datum van eerdere raadpleging te bewaren, om te gebruiken in een nieuwe raadpleging. XIS dient deze datum te kunnen verwerken. Technische uitwerking staat in de paragraaf "The _lastUpdated search parameter" van het technisch ontwerp.

3.2.2 Herleidbaarheid

Onderstaande betreft een implementatieadvies, hoe het hierboven beschreven basisprincipe herleidbaarheid geïnterpreteerd en toegepast kan worden in de praktijk.

PGO
De informatie over herleidbaarheid kan het beste worden gehaald uit de connectie die over het MedMij-netwerk wordt gelegd. De partij die de gegevens beschikbaar stelt: de zorgaanbieder. Informatie over de zorgaanbieder kan uit het zorgadresboek (ZORG-AB) of de ZorgAanbiedersLijst (ZAL) worden gehaald. Kanttekening ZorgAanbiedersLijst (ZAL): de naam op deze lijst kan afwijken van de naam die de patiënt/cliënt kent uit contact met zijn zorgaanbieder.

XIS
Zorg dat duidelijk is dat de gegevens door de patiënt (of gemachtigde) zijn gestuurd. Na overname van de gegevens in het dossier kan ook uit de context blijken dat de informatie afkomstig is van de patiënt. Bijvoorbeeld door een label voor “patiënt als auteur” of “ontvangen uit PGO”. Het moment van ontvangen gaat om de datum en tijd van de technische ontvangst/verwerking in het systeem, dus niet om wanneer de zorgverlener de gegevens opent. Er kan immers vertraging tussen ontvangst en bekijken zitten. Voor de gebruiker kan het waardevol zijn om te weten wanneer de gegevens zijn ontvangen.

Verwachting kwalificaties
Bij kwalificatie worden de requests naar de simulator (Touchstone) los van het MedMij-netwerk uitgevoerd. Daardoor is er geen DigiD-authenticatie waarmee het XIS de persoon kan herleiden. Voor de PGO is er in de connectie met Touchstone geen ZAL of ZORG-AB beschikbaar om de naam van de zorgaanbieder uit op te halen.

  • We adviseren het XIS om gebruik te maken van de persoonsgegevens en het fictieve-BSN (fBSN) die in de kwalificatiematerialen zijn opgenomen van de systeemrol waarvoor wordt gekwalificeerd.
  • We adviseren de PGO om in de kwalificatie (test/acceptatie) omgeving van het systeem een alternatief in te bouwen om de Zorgaanbiederslijst (ZAL) te simuleren, wanneer er een connectie met Touchstone wordt gelegd. Gebruik daarbij bij voorkeur de organisatienaam die in het kwalificatiescript staat voor deze alternatieve lijst. Het is ook mogelijk om een algemene kwalificatienaam toe te passen, bijvoorbeeld kwalificatie@medmij.nl.

Een hulpmiddel bij de kwalificatie kan bijvoorbeeld zijn om gegevens uit de HTTP-header (de base URI endpoint en datum) in te zetten:
HTTP message header

3.3 Afschermen van gegevens

3.3.1 Burgerservicenummer

Hoewel de volledige definitie van enkele zibs het BSN bevat, mag dit niet worden gebruikt in de gegevensuitwisseling met de patiënt. Dit aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Het nummer is in de definities opgenomen omdat dit geregistreerd kan worden in het zorgaanbiedersdomein. De afspraak om het BSN niet uit te wisselen is opgenomen in het MedMij afsprakenstelsel.


4 Referenties

5 Release notes

Release Versie BITS-ticket Omschrijving
6 1.0.0 MM-3408 Versie 1.0.0 van het MedMij functioneel ontwerp.

6 Ondersteuning

Voor vragen en wijzigingsverzoeken over dit ontwerp, maak een ticket aan in BITS.