Ga naar inhoud
HexaTransfer
Terug naar blog
Brancheoplossingen

Elektronische patientendossiers delen: interoperabiliteitsgids

Deel elektronische patientendossiers tussen systemen en zorgverleners. Navigeer interoperabiliteitsuitdagingen met praktische oplossingen en standaarden.

Het delen van elektronische patiëntendossiers over systemen heen betekent het verzoenen van minimaal vier standaarden: HL7 FHIR R4 voor API-gebaseerde uitwisseling, C-CDA R2.1 voor documentgebaseerde overdracht, HL7 v2.x voor verouderde berichten en DICOM voor beeldvorming. De Autoriteit Persoonsgegevens (AP) stelde in haar handhavingsprioriteiten voor 2025 dat de uitwisseling van elektronische patiëntendossiers zonder adequate grondslag en beveiliging het meest gesignaleerde nalevingsprobleem in de zorgsector vormt. USCDI v3 definieert de minimale dataset die US-zorgverleners deelbaar moeten maken, en TEFCA stelt de governancelaag via Qualified Health Information Networks in. Wanneer een dossier verplaatst wordt tussen Epic en Cerner/Oracle Health, verloopt dit doorgaans via het Carequality-kader dat C-CDA-documenten omhult over IHE XCA-profielen. Wanneer het naar de telefoon-app van een patiënt gaat, verloopt dit via SMART op FHIR met OAuth 2.0.

De standaardenstack waarmee u werkelijk werkt

Interoperabiliteit van gezondheidsgegevens ziet eruit als een standaarden-salade, want dat is het ook. Hier is wat elke laag doet:

  • HL7 v2.x — pijpgescheiden berichten uit de jaren negentig, nog steeds het werkpaard voor laboratoriumorders, ADT-feeds (opname/ontslag/overdracht) en orderbeheer binnen een ziekenhuis; niet geschikt voor uitwisseling tussen organisaties
  • C-CDA R2.1 — gestructureerde XML-documenten die een patiëntensamenvatting, ontslagbrief of verwijsbrief vertegenwoordigen; de ruggengraat van Direct Messaging en de meeste HIE-uitwisseling
  • HL7 FHIR R4 — RESTful resources (Patiënt, Observatie, Conditie, MedicatieVerzoek) uitgewisseld via HTTPS met JSON of XML; de moderne laag, vereist door ONC Cures Act-regels voor gecertificeerde EPD's
  • DICOM — beeldvormingstandaard, beweegt via eigen pijpen (DIMSE, DICOMweb)
  • USCDI v3 — de vereiste dataklassen en -elementen die elk gecertificeerd EPD moet blootstellen, inclusief klinische notities en sociale determinanten van gezondheid

Wanneer u een EPD "deelt", deelt u werkelijk fragmenten van elke laag, samengesteld in het juiste formaat voor de ontvanger.

FHIR-API's en de informatieblokkeringsregel

De ONC's 21st Century Cures Act Final Rule (45 CFR Part 171) maakt informatieblokkeringen een verboden praktijk, met civiele geldboetes tot $1 miljoen per overtreding voor bepaalde actoren. De technische vereiste: gecertificeerde EPD-technologie moet een FHIR R4-API blootstellen die de USCDI-dataset ondersteunt.

Voor een ontwikkelaar die integreert met Epic, Cerner, athenahealth of eClinicalWorks betekent dat:

  1. Een app registreren in het ontwikkelaarsportaal van de leverancier (Epic op FHIR, Cerner Code, athenahealth Developer Portal)
  2. SMART op FHIR-startsequentie gebruiken met OAuth 2.0 en PKCE
  3. Scopes aanvragen zoals patient/*.read of specifieke resources
  4. JSON-bundels ontvangen via HTTPS

De praktische valkuil: API-scopes, snelheidslimieten en productiestoegang variëren sterk per leverancier. De productiestoegang van Epic vereist een ondertekende overeenkomst voor payers/providers of specialiteitsapps.

C-CDA: nog steeds de standaard voor samenvattingen tussen organisaties

Ondanks de opkomst van FHIR verloopt de meeste uitwisseling van dossiers tussen organisaties nog steeds via C-CDA-documenten. Een Continuity of Care Document (CCD) onder C-CDA R2.1 beslaat doorgaans 200 KB-2 MB aan XML met ingebedde HTML voor menselijke leesbaarheid. Belangrijke sjablonen:

  • CCD (Continuity of Care Document)
  • Ontslagbrief
  • Verwijsbrief
  • Consultatiebrief
  • Voortgangsnotitie

Deze stromen via Direct Messaging (S/MIME via SMTP) of querywisseling via HIE. Het ontvangende EPD parseert de XML en neemt gestructureerde elementen op in het lokale dossier. Parserkwaliteit varieert — sommige EPD's nemen probleemlijsten correct op maar laten sociale anamnese vallen. Gegevensverzoening blijft bij de meeste klinieken een handmatige stap.

TEFCA, QHIN's en de nationale networkstrategie

Het Trusted Exchange Framework and Common Agreement (TEFCA), gefinaliseerd door de ONC in januari 2022 en operationeel sinds 2023, creëert een netwerk-van-netwerken. Qualified Health Information Networks (QHIN's) zoals eHealth Exchange, Epic's Carequality-brug en Health Gorilla verbinden via de Common Agreement.

Vanuit het perspectief van de verzendende clinicus betekent TEFCA: éénmaal opvragen, deelnemers over QHIN's heen bereiken, voor behandeling, betaling, zorgactiviteiten, volksgezondheid, overheidsuitkeringen, individuele toegangsdiensten en dekkingsgebruikscases.

Vanuit het perspectief van de IT-directeur betekent TEFCA een governancelaag bovenop bestaande IHE-profielen, geen nieuw protocol om te implementeren.

Wanneer API's mislukken en u een bestandsoverdracht nodig hebt

Ondanks alle standaarden moeten clinici regelmatig een bestand verplaatsen dat in geen enkele API past. Voorbeelden:

  • Een 300 MB PDF-bundel van gescande papieren dossiers van vóór de digitalisering van de kliniek
  • Een onderzoeksdataset in SAS- of Stata-formaat voor een retrospectief onderzoek
  • Een reeks wondfoto's van thuiszorg die de beeldserver niet hoeven op te schepen
  • Juridische bewaringsdossiers voor een hangende aansprakelijkheidsschaak

Hiervoor valt u terug op versleutelde bestandsoverdracht. De vereisten: HIPAA-conform (BAA ondertekend), AES-256-GCM versleuteling in rust, TLS 1.3 in transit, auditlogging en linkverlooptijd. Of dat tool een ingebouwde Epic-functie is, een door het ziekenhuis goedgekeurde enterprise-service of een ad-hoc browsergebaseerde overdracht hangt af van uw governance.

HexaTransfer biedt het ad-hoc pad met client-side versleuteling vóór het uploaden. Probeer het via https://hexatransfer.com — gratis, geen account, maximaal 10 GB. Log de overdracht in uw standaard auditrecord zodat u er later verantwoording over kunt afleggen.

Patiëntmatching en het identiteitsprobleem

Het delen van een dossier vereist weten dat het de juiste patiënt is. De VS heeft geen nationaal patiëntidentificatienummer, waardoor identiteitsresolutie berust op probabilistisch matchen op naam, geboortedatum, geslacht, adres en telefoon. Het Sequoia Project's Patient Matching Framework beveelt minimaal 7 demografische attributen aan voor cross-organisatiematching.

In de praktijk lopen matchpercentages in productienetwerken van 70 tot 95%, afhankelijk van de gegevenskwaliteit. Mispercentages vertalen zich in ontbrekende dossiers op het punt van zorg en dubbele dossiers die de downstream-dossier vervuilen.

Voor overdrachten op bestandsniveau: neem altijd patiëntidentificatoren op in de bestandsnaam of een begeleidend blad — patiënt-ID, geboortedatum en minstens één aanvullende identificator.

Toestemming, segmentatie en bijzondere gegevenscategorieën

Niet alle dossiers worden gelijkelijk gedeeld. In Nederland verbiedt de AVG (artikel 9) de verwerking van bijzondere categorieën persoonsgegevens (gezondheidsgegevens, genetische gegevens) tenzij een specifieke uitzondering van toepassing is. 42 CFR Part 2 beperkt in de VS het delen van dossiers over middelengebruiksstoornissen met strengere toestemmingsvereisten dan HIPAA.

Gedragsgezondheidsdossiers, HIV-status, genetische en voortplantingsgezondheidsgegevens hebben vaak jurisdictiespecifieke regels. Als uw overdrachtstool segmentatie niet kan respecteren — niet kan markeren welke delen van een document extra toestemming vereisen — gebruik het dan niet voor geestelijke gezondheidsdossiers. Gebruik het voor het orthopedisch follow-uppakket.

Audit en verantwoording van openbaarmakingen

HIPAA's Accounting of Disclosures (45 CFR 164.528) geeft patiënten het recht op een lijst van openbaarmakingen die in de afgelopen 6 jaar zijn gedaan. De AVG geeft patiënten vergelijkbare rechten (artikel 15). Het auditlogboek van uw overdrachtsysteem voedt deze verantwoording. Leg vast:

  • Tijdstempel in UTC
  • Verzendings- en ontvangstorganisaties
  • Doelcode (BEHANDELING, BETALING, ACTIVITEITEN, AUTORISATIE, etc.)
  • Overgedragen datacategorieën
  • Patiënt-ID

Als u vertrouwt op een generieke tool voor bestandsdeling die alleen logt "gebruiker X heeft bestand Y geüpload", zult u zich vastlopen wanneer een patiënt een verantwoording vraagt.

Kleine praktijken en de resource-kloof

Een praktijk met 3 zorgverleners heeft geen CIO. Ze hebben een praktijkmanager die IT naast facturering afhandelt. Ze moeten toch USCDI-conforme dossiers op aanvraag produceren, BAA's ondertekenen met elke leverancier en informatieblokkeringsklachten afhandelen. De praktische aanpak:

  • Gebruik een EPD (athenahealth, Elation, DrChrono) dat Direct, FHIR en patiënt-API kant-en-klaar afhandelt
  • Kies één ad-hoc versleutelde overdrachtstool met een BAA voor alles wat het EPD niet kan verzenden
  • Documenteer de workflow in een SOP van één pagina
  • Train elk personeelslid op de twee tools die ze wekelijks zullen gebruiken

Het delen van elektronische patiëntendossiers is geen probleem dat één leverancier oplost. Het is een gelaagde workflow om te onderhouden. Zet de standaarden goed neer waar dat kan, en houd een schone versleutelde terugvaloptie voor de gevallen die standaarden niet dekken.

Verstuur grote bestanden veilig met end-to-end-versleuteling

Draag bestanden tot 10 GB gratis over met end-to-end-versleuteling. Geen account nodig. Uw bestanden worden in uw browser versleuteld voordat ze worden geüpload — niemand anders kan ze lezen.

Een bestand verzenden