Medische bouwstenen en hun implementatie in HL7

Medische bouwstenen en hun implementatie in HL7

Vereniging van Zorgaanbieders voor Zorgcommunicatie

Wouter Tesink en Tom de Jong Architect Infra en Product Mgr 14 juni 2013

Onderwerpen Hoe zit HL7v3 ook al weer in elkaar? Wat zijn de kenmerken van CDA? Gevaar van inconsistente weergave.

Medische bouwstenen Standaardisatieniveaus. Garanderen van consistente weergave. Migratie naar CDA release 3? 2

Definitie

van Health Level Seven

Health Level Seven (HL7) is een applicatieprotocol voor elektronische gegevensuitwisseling in de gezondheidszorg.

De aanduiding ‘Seven’ slaat op het feit dat het protocol betrekking heeft op laag 7 van OSI netwerkmodel (de applicatielaag).

HL7 Standaarden Versie 2.x Messaging methodiek (1987+)

Versie 3 Messaging methodiek (1995+) Document methodiek (1999+) CDA: Clinical Document Architecture CCD: Continuity of Care Document

(= HL7v3!) (= CDA!)

Services methodiek (parallel)

In ontwikkeling: FHIR 4

(Fast Healthcare Interoperability Resources)

HL7 v3: Fragment

juli ’13

© Stichting HL7 Nederland

5

Enkele misvattingen wegnemen: “Wij hebben geen HL7 versie 3 nodig, want we gebruiken al XML koppelingen.” Vergelijk: “Ik hoef geen Engels te leren, want ik ken het Latijnse alfabet toch al.” XML is een implementatiekeuze (op representatieniveau) bij gebruik van HL7 (op applicatieniveau).

“Wij hebben geen HL7 versie 3 nodig, want we gaan met CCD overdracht doen.” Vergelijk: “Ik hoef geen Engels te leren, want ik vul een standaardformulier in”. CCD *is* (een implementatievorm van) HL7 v3!

Wat is essentieel aan HL7 v3? Niet berichten, documenten of services. Niet XML of SOAP of rooksignalen. Niet AORTA/LSP of CCR/CCD. Wel: Wel: Wel: Wel: Wel:

referentie informatie model (RIM) conceptuele modelleermethode (HDF) scheiding tussen data- en procesmodel datatypes (elementaire bouwstenen) regels voor identificatie & classificatie

RIM

Reference Information Model (RIM) Persoon A classCode

Arts classCode

Uitvoerder typeCode

Persoon B classCode

Patiënt classCode

‘Onderwerp’ typeCode

Entity

Role

Participation

Anamnese classCode

Act

Zelfde data set kan op meerdere manier worden weergegeven  risico op inconsistentie binnen de standaard.

HL7 v3 Basic Data types ANY BL ST INT REAL QTY PQ II ED

Boolean Character String Integer Number Real Number Quantity Physical Quantity Instance Identifier Encapsulated Data

CV CE CD

Code Value Coded Equivalent Concept Descriptor EN Entity Name PN Person Name ON Organization Name TEL Telecom Address AD Postal Address TS Point in Time 9

Gegevensmodel (bijv. medicatievoorschrift)

Message payload Transmission Wrapper Transport: van waar naar waar?

ControlAct Wrapper Transactie: door wie en waarom? Payload

Interacties in het ‘berichtmodel’ A

Order of Query

B

Initial Trigger

Execute reciever responsibilities

Accept Acknowledgement

Application Response - OK

OR Application Response - Reject

Notificatie

Notification

Initial Trigger

NO reciever responsibilities

Accept Acknowledgement

12

Zelfde payload, maar nu in CDA document Header Clinical Document

Patient Provider

Body Body Structures (Sections)

Body Entries (Clinical Statements) Observation

Procedure

Encounter

Medication ...

Reden voor ontstaan CDA Migratiepad nodig van vrije tekst naar gestructureerde gegevensuitwisseling

14

CDA Model

Sections

Header 15

Entries (‘Clinical Statement’) Ext’l Ref’s

Zelfde betekenis, andere verpakking (m.a.w. ander uitwisselmechanisme)

Document header en sections vervullen vergelijkbare rol als wrappers in berichten. Zijn alleen niet gericht op transport en transactie, maar op documentkenmerken, tekstuele weergave en sectie-indeling.

Omzetting naar HTML Kan zowel bij CDA document als bij message payload (XSLT)

17

Verschil in XML Schema (representatie ‘over de lijn’): Bij messaging: elke payload eigen Schema (gebaseerd op R-MIM van bijbehorend model).

Bij CDA document: maar één XML Schema. Elke invulling ervan gebeurt d.m.v. ‘templates’. XML Schema van huidige CDA Release (R2) bevat slechts een deel van RIM elementen. Gevolg van bovenstaande zaken is: Niet alle concepten zijn (zuiver) weer te geven in CDA. Representatie van dezelfde (model)concepten zal (meestal) tot een verschillende representatie leiden.

Inconsistente weergave bouwstenen

Wanneer welk mechanisme? De theorie… Officieel zijn er formele richtlijnen, in ieder geval voor keuze berichten vs. documenten Criteria daarbij zijn: Vluchtig vs. persistent Veel vrije tekst vs. veel gestructureerde data Dynamische set gegevens (query response) vs. ‘bevoreren’ set gegevens (samenhangende data) Workflow management vs. Dossieroverdracht

Zie http://www.ringholm.de/docs/04200_en.htm voor een whitepaper over dit keuzeaspect.

Wanneer welk mechanisme? De praktijk… De realiteit is dat veel bepalender zijn: Beschikbare infrastructuur (bijv. AORTA vs. XDS) Smaak m.b.t. interpretatie van gegevens (“is een recept een bericht of een document?”) Populariteit van standaardrichtlijnen (bijv. CCD)

Gevolg is dat de criteria waziger worden: Payloads van berichten worden persistent gemaakt Documenten kunnen een workflow ondersteunen (sinds introductie van XDW als workflow document)

 Mechanisme wordt per project bepaald

Communicatieuitdagingen Ambiguïteit (één vorm, twee betekenissen) “De jongen die Marc geslagen heeft.” Soms kan dezelfde vorm op twee manieren worden uitgelegd. Dat is een kwestie van strak definiëren.

Synoniemen (één betekenis, twee vormen) “De jongen die door Marc geslagen is.” “De jongen die van Marc een klap gekregen heeft.” Niet meer ambigue, maar wel twee synoniemen. Voor een menselijke gebruiker niet zo erg, maar voor een computer (die moet parsen) erg lastig.

HL7v3 is goed in het voorkomen van ambiguïteit, maar dreigde ‘veelvormig’ in weergave te worden.

Medische bouwstenen om consistentie af te dwingen Wouter

Probleem Visie achter ontwerp van zorgtoepassingen ontbrak Iedere zorgtoepassing staat daarmee op zichzelf Data-elementen over zorgtoepassingen heen niet consistent Compatibiliteit matig Hergebruik is beperkt Generieke medische bouwblokken

Oplossing ‘Bouwblokken’ van medische informatie Zorgtoepassingsbreed gedefinieerd Hergebruik van bouwblokken in verschillende zorgtoepassingen Consistentie van medische informatie over zorgtoepassingen heen

Generieke medische bouwblokken

Medicatie

Allergieën

Problemen

}

Medicatie Allergieën Problemen Episodes Journaalregels Labuitslagen Verwijzingen ….

Episodes

Journaalregels

Labuitslagen

Verwijzingen Generieke medische bouwblokken

Mogelijkheden om gegevens op te vragen Granulair Bouwblokken apart opvraagbaar Query(parameter) per bouwblok Versionering per bouwblok Authenticatie/autorisatie per bouwblok Zelf gegevenssets samenstellen

Samengesteld (templates) Voorgedefinieerde gegevenssets Query(parameter) per template Versionering per bouwblok Authenticatie/autorisatie per template Samenvoegen gegevens uit verschillende bronnen is lastiger?

Generieke medische bouwblokken

Hoe in te richten? Services Bronsysteem Samengesteld Granulair

Services Opvragend

Granulair

Samengesteld

1

Bronsysteem biedt granulair aan, opvragend systeem gebruikt datasets LSP

Authenticatie/autorisatie op de opgevraagde dataset Query wordt door het LSP uitgezet in granulaire query(‘s)(parameters) Bronsysteem is zeer flexibel in het ondersteunen van nieuwe datasets Bronsysteem moet bij nieuwe (versies) van bouwblokken gaan ontwikkelen Opvragend systeem moet alleen bij nieuwe (versies) van datasets gaan ontwikkelen LSP treedt op als broker

2

Bronsysteem biedt templates aan, opvragend systeem gebruikt templates LSP

‘Huidige situatie PS’ Authenticatie/autorisatie op het opgevraagde dataset Query wordt door het LSP onveranderd doorgezet Bronsysteem is enigszins flexibel in het ondersteunen van nieuwe datasets Bronsysteem moet bij nieuwe (versies) van datasets gaan ontwikkelen Opvragend systeem moet bij nieuwe (versies) van datasets gaan ontwikkelen Bronsysteem en opvragend systeem moeten nieuwe ontwikkelingen (bijna) synchroon uitrollen

3

Bronsysteem biedt granulair aan, opvragend systeem ook granulair LSP

‘Huidige situatie medicatie’ Authenticatie/autorisatie op het opgevraagde bouwblok Query wordt door het LSP onveranderd doorgezet Opvragende systemen kunnen eigen datassets on the fly samenstellen Bronsysteem en opvragend systeem moeten bij nieuwe (versies) van bouwblokken gaan ontwikkelen

Goed gedefinieerde bouwblokken zijn essentieel voor lange termijn Eenheid van taal Minder afhankelijk ontwikkeling bronsystemen Flexibeler in keuze infrastructuur Versionering per bouwblok

Toepassings specifieke query HL7 koppeling Op basis van bestaande interacties LSP als messagebroker en FILTER Niet toekomstvast – wel snel te regelen XIS Raadplegen informatie

Specifieke toepassings Query Diab

Spoed

etes

GERI ATRIE

CVA

COPD

HWG

LSP Autorisatie / Authenticatie Logging / Patiëntrechten Query per bestaand bericht PS

ICA

Voorschrif ten

Huisarts Generieke medische bouwblokken

….

…

Query per bouwblok

XIS Raadplegen informatie

Query per onderdeel dossier

LSP Autorisatie / Authenticatie Logging / Patiëntrechten

medicatie voorschriften

episodes

journaal regels

Huisarts Generieke medische bouwblokken

allergieën

…

Generieke query HL7 koppeling Op basis van bouwblokken LSP als messagebroker XIS Raadplegen informatie

Specifieke ketenzorg Query

Generieke opvraag interface

LSP Autorisatie / Authenticatie Logging / Patiëntrechten Query per onderdeel dossier medicatie voorschriften

episodes

journaal regels

Huisarts Generieke medische bouwblokken

allergieën

…

Generieke query HL7 koppeling Op basis van bouwblokken LSP als messagebroker XIS Raadplegen informatie

Specifieke ketenzorg Query

Generieke opvraag interface

LSP Autorisatie / Authenticatie Logging / Patiëntrechten Query per onderdeel dossier journaal Generieke opvraag interface … episodes allergieën

medicatie voorschriften

regels

Huisarts Generieke medische bouwblokken

CDA en/of messaging? Afhankelijk van eisen toepassing, keuze tussen CDA Messaging

De verpakking verschilt, maar de bouwstenen zijn identiek

Generieke medische bouwblokken

Realisatie bouwstenen in HL7 Tom

Voeg titel in via Invoegen -> Koptekst en voettekst -> Overal toepassen

39

Hoe bouwen we een virtueel EPD op? Verzameling gedistribueerd opgeslagen gegevenselementen, die onderling samenhangen, en waarvan je langs verschillende invalshoeken dwarsdoorsnedes kunt maken.

Virtueel EPD

= bepaalde bloeddrukmeting 40

Standaardisatieniveau’s H O W ?

W H A T ?

Infra A (XDS)

Infrastructure B (national)

Document-based (CDA) exchange

Infrastructure C (vendor-specific)

Message-based exchange

Infra D (…)

Service-based (REST) exchange

Syntax: standardized (XML) building blocks Semantics: standardized meaning of concepts

Als de syntax-laag goed gestandaardiseerd is, kan keuze in lagen erboven irrelevant worden. Voeg titel in via Invoegen -> Koptekst en voettekst -> Overal toepassen

41

Realisatie in HL7:

standaardisatie binnen de standaard

Interne standaardisatiemechanismes: Gebruik van CMETs in berichten. Gebruik van templates in documenten.

De ‘holy grail’ is om te komen tot universeel herbruikbare bouwstenen:

‘One concept – One representation’

Voeg titel in via Invoegen -> Koptekst en voettekst -> Overal toepassen

42

CMETs in berichten Interacties

Medicatie voorschrift

Antwoord op voorschriftquery

Antwoord op opvragen PS

Message Types

CMET Reference Information Model

Entity

Role

Participation

Act

43

Templates in documenten CDA kent maar één model voor entries: clinical statement (met subset RIM) Daar bovenop kun je spelregels maken voor de precieze gegevensinhoud Deze beschrijving heet een ‘template’ Kan bestaan uit vrije tekst (regels) Trend is om formeel te specificeren: Schematron expressies

Templates en consistentie Ondanks vast XML Schema, kun je ook binnen CDA meerdere manieren hebben om hetzelfde weer te geven (templates) Over de jaren was wildgroei ontstaan aan (deels inconsistente) templates Inmiddels een slag gemaakt om deze te consolideren in C-CDA (basis voor MU2)  verzameling consistente templates 45

Wat was ook al weer het probleem?

Mogelijke oplossingen Alles met CDA R2 documenten doen? Transformaties tussen berichten en documenten (XSLT stylesheets) Gebruik extension-mechanisme in CDA R2 om bouwstenen op te nemen Toepassen van CDA Release 3

Alles met CDA R2 documenten doen? Onpraktisch door verlies aan semantiek en desinvestering message interfaces Onnodig, want bij herbruikbare bouwstenen kunnen CDA en berichten prima naast elkaar bestaan De kunst is het ontkoppelen van weergave en drager/infrastructuur

Transformaties tussen berichten en documenten XSLT kan op korte termijn zeker een oplossing zijn om verschillende weergaven toch snel te verwerken Zelfde mechanisme als gebruikt kan worden tussen versies van bouwstenen Op langere termijn niet voldoende: Onderhoudsinspanning Foutgevoeligheid Performance

Gebruik extension-mechanisme in CDA R2

CDA kent mechanisme om vaste XML Schema uit te breiden met ‘plug-in’ Deze extension heeft eigen name space Breekt dus niet validatie tegen CDA R2 Staat toe om bouwstenen buiten CDA om te gebruiken in volgende gevallen: Meer RIM semantiek nodig (o.a. in epSOS) Install-base bestaande weergave (AORTA?)

Project GenOGeg gaat dit toepassen

Toepassen van CDA Release 3

Entries (‘Act Statement’)

Act Statement

Herbruikbare bouwstenen in HL7v3

Voeg titel in via Invoegen -> Koptekst en voettekst -> Overal toepassen

53

Query van virtueel EPD Bronnen

Batch met elementen (payloads) conform templates

Vragend systeem

batch

Combinatie naar behoefte van zorgaanbieder / XIS applicatie 54

Hartelijk dank voor uw aandacht Heeft u nog vragen?

55