Standaardisatie binnen de HL7 standaard

Transcriptie

1 Standaardisatie binnen de HL7 standaard We have a dream één representatie voor elk concept! Tom de Jong

2 Vergelijking met taal Neem een alfabet (abcd als bouwstenen) Neem een woordenboek (met betekenisvolle samenstellingen uit het alfabet) Neem een grammatica met spelregels voor het combineren van woorden in zinnen Heb je daarmee de garantie dat een bepaald concept (betekenis) nu maar in één zin (vorm) weergegeven kan worden: NEE!

3 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

4 Wat eraan vooraf ging binnen HL7! HL7 traditioneel opgesplitst in domeinen (prima, want daarmee bundel je expertise) Aparte groep Control/Query, voor generieke berichtmechanismen Control/query bemoeit zich niet met berichtpayloads (wel met bijv. wrappers) Op zeker moment ontstond Structured Documents (werkgroep), als ontwerper en beheerder van CDA als verpakkingsvorm

5 Wat is er misgegaan binnen HL7? Structured Documents ontwierp niet alleen een generieke documentstructuur, maar óók een generieke structuur voor entries. Ook al was het op generiek niveau, het XML Schema voor de entries lag daarmee vast! Dat bleek qua implementatie een schot in de roos (vast, stabiel Schema klinkt goed). Ze overlapten echter wel met het domein (en dus de modellen) van domeingroepen

6 Niveaus van gegevensdeling Conceptueel (semantiek = betekenis) HL7v3 RIM data types (abstract) Representatie (syntax = vorm) XML ITS (incl. XML formaat data types) Directe relatie met gekozen XML Schema! Verpakking (wrappers, documenten) HL7v3 message wrappers Clinical Documnt Architecture Transport (infrastructuur) Gedistribueerde of centrale opslag? Push (notificatie) of pull (query) model?

7 Verpakkingsniveau Betreft omlijsting van medische payload: header en body + sections bij CDA (documents) transmission/control act wrappers bij messages Bevat alleen meta-gegevens: patiënt (bij CDA in header, bij messages in payload) auteur (bij CDA in header, bij messages control act) zaken als aanmaakmoment, verwachte ontvanger(s) Document: alleen gegevensinhoud; message: ook transactie en transport workflow bij documenten extern afgehandeld Met XML transformatie goed uitwisselbaar verpakking eraf andere verpakking erom

8 Representatieniveau Hier ligt het knelpunt, op twee manieren: Redundantie/overlap binnen de berichtmodellen Inconsistentie tussen berichten en documenten Dit leidt ertoe dat dezelfde conceptuele bouwsteen (qua betekenis in RIM termen) kan voorkomen in meerdere verschillende representaties (qua vorm op XML niveau). Dit is niet alleen inefficiënt (qua softwareondersteuning), maar ook verwarrend (en dus foutgevoelig) bij implementatie

9 Clinical Statements Clinical Templates

10 Clinical Statements: Achtergrond Semantische interoperabiliteit voor medische informatie (door definièren van concepten) Consistente representatie van medische informatie (door standaardiseren van syntax) Beide wordt gestimuleerd als elk medisch informatiebrokje wordt afgeleid uit het Clinical Statement

11 Clinical Statement: Definitie An expression of a discrete item of clinical (or clinically related) information that is recorded because of its relevance to the care of a patient. Clinical information can be expressed with different levels of granularity and therefore the extent and detail conveyed in a single statement may vary

12 relationship Simplified Model ClinicalStatement ActChoice CS Type 1 participations Entry Point CS Type n Organizer component relationship CS Reference

13 Observation Normal Values Participations Clinical Statement (Oct. 2008) Substance Administration Supply Procedure Encounter Acts record target subject Organizer/Folder ext. References 15

14 Example of use A patient is given a medication because his blood pressure is found to be 180/120 mm[hg]. relationship ClinicalStatement ActChoice Observation participations Patient recordtarget Substance Administration author GP Entry Point Substance Administration Has reason Organizer component relationship Blood Pressure (Organizer) CS Reference component Diastolic Pressure 120 mmhg Systolic Pressure 180 mmhg

15 <Medication classcode="sbadm" moodcode="evn"> <templateid root=" " extension="repc_tm000378"/> <id root="457fbe67-33c9-4a96-b57f-1e7d80ec65a8"/> <code codesystem=" " code="xxxxxxxxxx" displayname="medication details"> <originaltext>medication to reduce BP</originalText> </code> <sourceof typecode="rson" inversionind="false" negationind="false"> <seperatableind value="true"/> <Organizer classcode="organizer" moodcode="evn"> <templateid root=" " extension="repc_tm000401"/> <id root="d3f6e3a8-19dd-4999-ac58-8b140a53db26"/> <code codesystem=" " code=" " displayname="blood pressure"> <originaltext>blood pressure</originaltext> </code> <effectivetime value=" "/> <component typecode="comp" inversionind="false" contextconductionind="true"> <Observation classcode="obs" moodcode="evn"> <id root="5edd370d ec-82a5-4d9545ba7c04"/> <code codesystem=" " code=" " displayname="systolic bp" <originaltext>systolic blood pressure</originaltext> </code> <effectivetime value=" "/> <value value="180" unit="mm[hg]"/> </Observation> </component> <component typecode="comp" inversionind="false" contextconductionind="true"> <Observation classcode="obs" moodcode="evn"> <id root=" b-9b af2f bcc19"/> <code codesystem=" " code=" " displayname="diastolic bp" <originaltext>diastolic blood pressure</originaltext> </code> <effectivetime value=" "/> <value value="120" unit="mm[hg]"/> Example of use - XML </Observation> </component> </Organizer> </sourceof> courtesy of ccclarion 19

16 Clinical Templates CDA, maar ook veel berichtmodellen gebruiken Clinical Statement als bouwsteen. Clinical Statements zijn heel generiek (dus heel flexibel) in de medische bouwstenen die ze kunnen weergeven. Bij een implementatie is het nodig om nadere regels te specificeren over de aard, de structuur en de inhoud van de gebruikte Clinical Statements

17 Background Story

18 Mouse Statement relationship Choice Mickey Mouse

19 Mouse Template Mouse Style#

20 Template Repository Precondition: ensure receiver is aware of Template definition, e.g. by means of registering any Templates that are used Determine explicit/implicit Templates used. Fetch template if unknown... but be able to process instance without any knowledge of Template details. Validation of Templates isn t mandatory. Sender Instance Receiver Template Repository

21 Wat zou de holy grail zijn? Maak een verzameling klinische bouwstenen (DCM s) op abstract niveau (doel van CIMI), die kennis vastleggen. Zorg ervoor dat de HL7 (XML?) representatie van die bouwstenen 1-op-1 is. Dat wil zeggen: elk concept maar één keer beschrijven (eventueel genest is hiërarchie). En van elk concept maar één representatie hebben (dus 1-op-1: semantiek syntax). Let op: dat komt overeen met één van de doelen van FHIR (resource is bouwsteen)

22 Hou zou je dat kunnen doen? Stop met berichtmodellen en maak van alle payloads CDA documenten (of zelfs CCD?). Enorme desinvestering. Verlies aan functionaliteit. Stop met CDA en maak op basis van alle templates specifieke berichtmodellen. Tegen de heersende trend in. Wacht op FHIR. Onzekerheid over kenmerken. Onzekerheid over termijnen

23 Accepteer dat ze vooralsnog beide bestaan, maar laat ze convergeren: Nu reeds mogelijk: Gebruik indien mogelijk XML transformaties Gebruik voor bestaande bouwstenen extensies op CDA om (bericht)modellen te kunnen hergebruiken Opties op termijn: Verander clinical statement in CDA zodanig dat het alle berichtmodellen kan afdekken (CDA R3) Baseer berichtmodellen niet meer op aparte XML Schema s, maar op datzelde clinical statement!

24 Wat te doen aan de CDA kant? Clinical statement vervangen door update die generiek blijft (en één vast Schema heeft), maar wel volledige RIM afdekt. Deze clinical statements zouden op XML niveau zoveel mogelijk (helemaal? ) compatible met CDA R2 moeten zijn. Vastleggen van specifieke structuur en eigenschappen gebeurt nog steeds met clinical template (geneste specificaties)

25 Wat te doen aan de berichtkant? Wens om in ieder geval te komen tot aanpak met één generiek XML Schema. Vervolgens toepassen van zelfde (full-rim) clinical statement als bedoeld bij CDA R3. Gevolg is dat onderscheid op payloadniveau wegvalt één representatie per concept. Toepassen clinical templates als bij CDA. Compatibiliteit is niet te garanderen, dus redesign bij ontwikkelaar onvermijdelijk

26 CDA release 3 Ontwikkeling die nu gaande is Eén uitgangspunt is bekend: CDA R3 moet (aan de medische kant) de volledige functionaliteit van het RIM kunnen ondersteunen en daarmee dus zonder verlies aan betekenis alle berichtpayloads kunnen opnemen in documenten Nog wel grote twijfel over huidige voorstel: Clinical Statement vervangen door reusachtige verzameling van alle modellen uit de domeinen. Dit wordt heel lastig te beheren en blijft niet lang compleet, dus ander voorstel heeft onze voorkeur