HL7 v3 in een notendop

HL7 v3 in een notendop

Relatie Contactpersoon Auteur Collegiale toetsing Versie Datum Kenmerk Bruggebouw Bos en Lommerplein 280 Postbus 9204 1006 AE Amsterdam Telefoon (020) 346 71 71 Fax (020) 346 71 77 [email protected]

: : : : : : :

Furore Christiaan Knaap 1.0 8 augustus 2007 Fur_HL7v3notendop_1-0

© 2007 Furore. Alle in dit document opgenomen informatie is vertrouwelijk en moet als zodanig worden behandeld. Dit document mag alleen door de opdrachtgever worden gebruikt voor het doel waarmee het is geschreven en mag niet zonder uitdrukkelijke toestemming van de auteur aan derden ter inzage worden gegeven.

INHOUDSOPGAVE

1.

Inleiding..................................................................................................................... 2

2.

Belangrijkste elementen ........................................................................................... 3 2.1. 2.2. 2.3. 2.4.

3.

Use Case Model .............................................................................................. 3 Information Model ......................................................................................... 3 Interaction Model........................................................................................... 4 Message Design .............................................................................................. 4

Informatiemodellen en hun samenhang ..................................................................5 3.1. 3.2. 3.3. 3.4. 3.5.

RIM ..................................................................................................................5 Klonen ..............................................................................................................5 Beperken ..........................................................................................................5 D-MIM en R-MIM...........................................................................................5 Efficiënt hergebruik – CMETs ....................................................................... 6

4.

Versie 3, dat is toch XML? .........................................................................................7

5.

Voorbeeld................................................................................................................... 8

6.

Verdere informatie ................................................................................................... 11

Furore, HL7 v3 in een notendop © 2009 Furore

8 augustus 2007 pagina 1

1.

INLEIDING

HL7 v3 is de meest recente en moderne versie van de HL7 communicatiestandaard voor de gezondheidszorg. Met versie 3 tracht HL7 de goede ervaringen van de eerdere versies te combineren met het aanpakken van hun tekortkomingen. De belangrijkste verbeteringen in HL7 v3 richten zich op het verhogen van de consistentie van het gehele model. Dankzij deze verbeteringen ten opzichte van versie 2 is HL7 versie 3 beter geschikt voor communicatie tussen verschillende organisaties. Deze introductie is bedoeld om uit te leggen hoe de versie 3 standaard is opgebouwd, en hoe daarmee de gewenste consistentie wordt afgedwongen. Daarbij ligt de nadruk op informatiemodellen (RIM, D-MIM, R-MIM), use cases, interacties en messages. De begrippen worden ook in hun context geplaatst in een voorbeeld uit de HL7 v3 documentatie. Dit document behandelt niet de HL7 organisatie, de onderdelen (commissies) daarvan of de balloting procedures waarmee de standaard tot stand komt. Aan het HL7 Development Framework (HDF) wordt slechts kort aandacht besteed. Er zijn naast HL7 ook vele andere standaarden op het gebied van informatieuitwisseling in de gezondheidszorg. Velen daarvan houden zich voornamelijk bezig met de indeling en codering van bijvoorbeeld ziekten, onderzoeken, behandelingen etc. Deze worden waar zinvol in HL7 toegepast. De meest opvallende tegenhanger met vergelijkbaar doel is de Europese standaard EN-13606. Men moet zich bewust zijn van het bestaan van alternatieven, maar dit document gaat geen vergelijk aan tussen de verschillende standaarden.



2.

BELANGRIJKSTE ELEMENTEN

Een informatiemodel en berichten voor HL7 v3 worden per domein ontwikkeld. Bestaande domeinen zijn bijvoorbeeld Patient Administration en Claims & Reimbursement. Hoofdzakelijk in Nederland is het Pharmacy domein ontwikkeld. Dit is echter nog niet in de internationale standaard opgenomen. Bij het specificeren van een domein spelen globaal gezien vier elementen samen, zoals hieronder weergegeven. Deze elementen zullen nog gekoppeld worden aan de terminologie binnen HL7.

2.1.

Use Case Model

HL7 gaat over uitwisseling van informatie. De start bij de ontwikkeling van een nieuw domein is dus om te bepalen in welke context uitwisseling gewenst is. Wat is de scope van het domein? Welke gebruikers en systemen spelen daarbij een rol? Dit wordt verhalend toegelicht in een zogeheten Storyboard. 2.2. Information Model HL7 gaat over uitwisseling van informatie. Het Information Model gaat logischerwijs over het onderdeel ‘informatie’ in deze zin. Welke entiteiten spelen een rol? Hoe hangen deze samen? Welke beperkingen gelden er? Deze zaken worden – mede – bepaald uit het Use Case Model. Waarschijnlijk het belangrijkste onderwerp uit HL7 v3 om de consistentie te bewaren is het RIM: Reference Information Model. Het RIM is feitelijk een UML class diagram. Het bevat de klassen die de basis vormen voor alle klassen die in een Information Model van een domein gebruikt kunnen worden. Bij de ontwikkeling van een domein worden de relevante klassen uit de RIM gekozen. Vervolgens worden deze klassen – anders dan in reguliere object-oriëntatie – gekopieerd en ingeperkt om tot passende klassen voor het domein te komen. Dit afgeleide model heet een D-MIM: Domain Message Information Model.



2.3. Interaction Model HL7 gaat over uitwisseling van informatie. Het Interaction Model gaat over het onderdeel ‘uitwisseling’ in deze zin. Op welk moment is een bericht gewenst? Welke rollen zijn er in de berichtuitwisseling? Welke verantwoordelijkheden hebben beide kanten? Deze zaken worden afgeleid uit het Use Case Model. In de uitwisseling is sprake van Application Roles. Dit zijn de rollen die een systeem kan spelen in een interactie. Deze zijn van een vrij gedetailleerd niveau. Voorbeelden uit de Patient Administration zijn Person Registry Query Placer en Person Registry Query Fulfiller. Ofwel een systeem dat vragen kan stellen aan de personenadministratie, en een systeem dat antwoord kan geven. Denk bij het eerste aan een ordercommunicatiesysteem, en bij het tweede aan de patiëntenregistratie (doorgaans onderdeel van het ZIS). Een Interaction in HL7 v3 bestaat uit: - een trigger event: de aanleiding voor communicatie; - een message type: wat er gecommuniceerd moet worden; - receiver responsibilities: de reactie die van de ontvanger verwacht wordt (dat is weer een interactie op zich); - sending and receiving roles: de rollen die het zendende en ontvangende systeem spelen in deze interactie. 2.4. Message Design HL7 gaat over uitwisseling van informatie. Bij het Message Design komen de uitwisselingsaspecten en het informatiemodel bij elkaar. In een message wordt altijd een precies gespecificeerd stuk van de informatie uit het domein gecommuniceerd, in het kader van een interactie. Ten behoeve van een message wordt wederom een specialisatieslag uitgevoerd, uitgaande van het D-MIM. Het model wordt beperkt tot de klassen die nodig zijn voor dit bericht, en eventueel kunnen ook de klassen zelf verder beperkt worden. Dit leidt tot het R-MIM: Refined Message Information Model. Het R-MIM beschrijft dus precies wat er in een bericht of familie van sterk gerelateerde berichten gecommuniceerd wordt.



3.

INFORMATIEMODELLEN EN HUN SAMENHANG

In bovenstaand verhaal zijn informatiemodellen op drie niveaus besproken. Van algemeen (RIM) via domein-specifiek (D-MIM) naar message-specifiek (R-MIM). Iets meer achtergrond bij het RIM en de verfijningsmethoden kan het begrip van de informatiemodellen vergroten. 3.1.

RIM

Het RIM is in de basis opgebouwd uit vier soorten klassen: Entity, Role, Participation, Act Elk van de klassen in het RIM is een Entity, Role, Participation of Act. In de klassediagrammen worden voor deze vier en hun afgeleiden consequent dezelfde kleuren gebruikt. Dit vergemakkelijkt het lezen van de diagrammen. De andere klassen worden gemaakt door deze vier te: - klonen; - beperken. De uitzonderingen die de regel bevestigen zijn de klassen RoleLink, om twee Roles aan elkaar te relateren, en ActRelationship, om twee Acts aan elkaar te relateren. 3.2. Klonen Klonen gebeurt als eenzelfde klasse in het model in meerdere samenstellingen nodig is. Zo kan de klasse Person zowel in de rol van Patient als die van Arts nodig zijn. De klasse Person kan dan gekloond worden (en dus twee keer in het model staan), maar deze is dan wel met verschillende rollen (de Role afgeleiden Patient en Arts) verbonden met de relevante Act klasse (bijvoorbeeld een operatie). 3.3. Beperken Een gekloonde klasse kan beperkt worden ten opzichte van zijn origineel. Beperken kan op meerdere manieren gebeuren. Ten eerste is er de classcode, een attribuut van Entity, Role en Act. In termen van OO zou je dit kunnen lezen als de ‘naam van de subklasse’. Het geeft in een keer aan om wat voor soort Entity, Role of Act het gaat. Vervolgens zijn er de verplichtingen in de attributen en cardinaliteit van de relaties. In een afgeleide klasse kan bepaald worden dat een attribuut verplicht wordt, terwijl deze dat in de superklasse niet is. Ook kan de cardinaliteit van een relatie beperkt worden. Bijvoorbeeld van 0-n naar 1-1. Andersom kan echter niet. Ten slotte kan er beperkt worden in de toegestane waarden van attributen. Zo kan er voorgeschreven worden dat een attribuut altijd een waarde uit een specifiek codestelsel moet hebben. Of een beperking in de range van numerieke waarden bijvoorbeeld. 3.4. D-MIM en R-MIM Beperken en klonen worden zowel gebruikt om van het RIM naar een D-MIM te komen, als om van een D-MIM naar een R-MIM te komen. Merk op dat een verfijnder model doorgaans ook slechts een deel van het grovere model bestrijkt. Een D-MIM hoeft tenslotte slechts informatie over één domein te bevatten. Een R-MIM zelfs slechts over één berichttype.



3.5. Efficiënt hergebruik – CMETs In D-MIMs en R-MIMs komen regelmatig dezelfde combinatie van klassen voor om een bepaald concept uit te drukken. Een voorbeeld is het concept van een patiënt. Dit ziet er zo uit:

Figuur 1: CMET R_Patient Een patiënt is een rol (te herkennen aan de gele kleur voor Role klassen). Eraan gekoppeld zijn een organisatie (de zorgorganisatie) en een ‘Living subject’. Jawel, HL7 kán ook over dieren gaan. Om dit concept gemakkelijk in een diagram te kunnen gebruiken, wordt het samengevat met het – hier – witte blokje ‘R_Patient’. Zo’n blokje heet een CMET: Common Message Element Type. In het schema is te zien dat ook voor de organisatie en Living Subject weer CMETs gebruikt zijn. Ze kunnen dus genest worden.Verder is aan de eerste letter (voor de underscore) te zien van welk type de hoofdklasse van de CMET is. Bij R_Patient is dat een Role, bij E_Organization een Entity, en zo is A_EncounterUniversal in de basis een Act.



4.

VERSIE 3, DAT IS TOCH XML?

Ja, normaal gesproken worden de berichten in versie 3 uitgedrukt in XML. Maar de achtergrond is iets uitgebreider. Onderdeel van de HL7 standaard is namelijk de ITS: Implementation Technology Specification. Zoals de naam zegt: een specificatie van de techniek waarmee je de standaard kunt implementeren. In principe zijn alle modellen onafhankelijk van techniek. Vervolgens kan er een ITS gekozen worden om de modellen (en in het bijzonder de berichten) in uit te drukken. Je kunt een ITS zien als een serialisatie-techniek. Bij wijze van spreken zou het ook in rooksignalen kunnen. De default ITS voor versie 3 is echter een XML schema.



5.

VOORBEELD

De figuur hieronder toont een deel van de documentatie-index van de HL7 v3 standaard. Bij de rode 1 is het domein ‘Patient Administration’ te zien. Het domein is verder onderverdeeld in topics. Dit is de gebruikelijke indeling. In het ‘Person Topic’ bij de rode 2 zijn de hierboven besproken elementen te herkennen.

Figuur 2: HL7 v3 documentatie-index, Person topic Storyboards bevat de use cases die bepalen waar het topic zich toe beperkt. Eén van de storyboard is ‘Add New Person’, met als doel “This storyboard demonstrates adding a new person to a person registry.”



Application Roles zijn de rollen die in het Person Topic van toepassing zijn. Eén ervan is de ‘Person Comprehensive Informer’, met als doel “A Person Comprehensive Informer sends all notification messages for person registries.” Denk bijvoorbeeld aan het ZIS dat een nieuwe patiënt doorgeeft aan het laboratoriumsysteem. De laatste vervult dan overigens de ‘Person Revision Tracker’-rol. Trigger Events bepalen wanneer een bericht verstuurd zal worden. Een voorbeeld is ‘Get Person Demographics Query’, met als omschrijving “The Person Registry Get Demographics Query requests demographic information for a specific person identifier.” Een verloskundesysteem dat bij het eerste bezoek de persoonsinfo van de moeder wil weten, kan dit Trigger Event doen ontstaan. Het bovengenoemd Trigger Event resulteert in een query, waarschijnlijk aan het ZIS. Deze zal antwoorden. Voor dat antwoord bestaat vervolgens weer een R-MIM, de “Person Event Get Person Demographics Response R-MIM”. Om een idee te krijgen hoe dat eruit ziet, zie Figuur 3. Dit model bepaalt dus de gegevens die het ZIS moet antwoorden. Het kopje ‘Refined Message Information Models’ bevat alle R-MIM’s voor de interactions die in dit topic gedefinieerd worden. Onder Hierarchical Message Descriptions zijn de uiteindelijke berichtbeschrijvingen te vinden. Deze zijn in feite ‘platgeslagen’ R-MIM’s, in tabelvorm. Deze vorm is geschikt om de informatie te serialiseren, bijvoorbeeld in XML. Overigens kunnen ook meerdere sterk gerelateerde HMD’s uit één R-MIM zijn afgeleid. Onder Interactions ten slotte worden alle interacties opgesomd. Een voorbeeld is de ‘Get Person Demographics Query’. Deze interaction heeft: - een trigger event dat dezelfde naam heeft (en een andere identifier overigens), - een message type ‘Person Event Query By Id’, - een zender- en ontvangerrol (‘Person Registry Query Placer’, resp. ‘Person Registry Query Fulfiller’), - receiver responsibilities, hetgeen een andere interactie is, met de naam ‘Get Person Demographics Response’. Daarmee is dus duidelijk: - wanneer het bericht gestuurd wordt (als de Query Placer, bijv. het verloskundesysteem naar de persoongegevens vraagt), - welk bericht er dan gestuurd wordt (het message type, met daaraan gekoppeld het R-MIM), - naar wie het bericht gaat (de Query Fulfiller, waarschijnlijk het ZIS) - en met welke interactie het ZIS moet reageren (de receiver responsibilities), in dit geval met ‘Get Person Demographics Response’, ofwel met het leveren van de gevraagde persooninformatie.



Figuur 3: Person Event Get Person Demographics Response R-MIM



6.

VERDERE INFORMATIE

Als u meer van HL7 v3 wilt weten is het ten zeerste aan te raden om een cursus te volgen. HL7 University organiseert deze regelmatig. Daarnaast is het verstandig lid te worden van HL7 Nederland. Voor een bescheiden bedrag krijgt u volledige toegang tot alle documentatie en modellen. Informatie over zowel de cursussen als lidmaatschap kunt u vinden op www.hl7.nl. Boeken zijn er helaas vrijwel niet over HL7 v3. Er is één introductieboekje uitgegeven: Understanding Version 3 – A Primer on the HL7 Version 3 Communication Standard, Andrew Hinchley (83 pagina’s, ca. €20,-). ISBN 3-933819-18-0 Naar beste weten van de auteur is dit boek op het moment echter niet verkrijgbaar.



HL7 v3 in een notendop

Recommend Documents