7kezo:V1.0 HL7v3-bouwstenen Ketenzorg

{{#customtitle:HL7v3 Implementatiehandleiding Bouwstenen Ketenzorg|HL7v3 Implementatiehandleiding Bouwstenen Ketenzorg}}

Inleiding

Doel en scope

Dit document beschrijft de HL7 implementatie van de bouwstenen die relevant zijn voor de zorgtoepassing Ketenzorg. In eerste instantie is dit beperkt tot een set bouwstenen die wordt gebruikt voor het uitvoeren van een ‘proof of concept’, maar in volgende versies zal dit worden uitgebreid naar alle bouwstenen die nodig zijn om de zorgtoepassing Ketenzorg in productie te laten draaien. Uiteindelijk kan dit document uitgroeien tot een overzicht van alle bouwstenen die gebruikt worden in de context van de landelijke basisinfrastructuur AORTA, naarmate andere zorgtoepassingen dezelfde systematiek gebruiken.

De volgende bouwsteentypen worden in het kader van de proof of concept uitgewerkt:

• Labbepaling
• Algemene bepaling
• Contactmoment
• Medicatievoorschrift

De reden voor deze selectie ligt in feit dat deze subset de volgende kenmerken heeft:

• Deze bouwstenen zijn relatief eenvoudig en conceptueel niet controversieel
• De set is volledig genoeg om een realistische gegevensuitwisseling te toetsen
• Het administratieve contactmoment heeft relaties naar de andere bouwstenen
• Van medicatievoorschriften bestaat al een actieve implementatie binnen AORTA

Overigens is later besloten om ook voor labbepalingen vooralsnog aan te sluiten bij de bestaande specificatie binnen AORTA v6.12 (die als scope de medicatiebewaking door apotheken heeft, maar op bouwsteenniveau conceptueel niet verschilt). Bijkomend argument is dat bovenstaande bouwstenen overeen komen met concepten die ook voor het project Generieke Overdrachtsgegevens (GOG) uitgewerkt zijn, zodat ervaring kan worden opgedaan met de raakvlakken met dit project (zie toelichting in par. 1.3.1XXXXXXXXX).

Noot: de publicatievorm van de bouwsteenimplementaties zal uiteindelijk liggen in de ART-DECOR omgeving, maar voorlopig wordt gebruik gemaakt van dit Word document voor een snelle afstemming met de werkgroep HL7 implementatie van het project Referentiearchitectuur Ketenzorg. Parallel wordt gewerkt aan het opzetten van een weergave in ART-DECOR, inclusief het uitwerken van de bijbehorende XML-materialen.

Doelgroep voor dit document

De doelgroep voor dit document bestaat uit de XIS-leveranciers die de hierin genoemde bouwsteenimplementaties moeten ondersteunen binnen hun software. De handleiding is in principe niet relevant voor de LSP-leverancier, aangezien bouwstenen per definitie als ‘blobs’ behandeld worden door het LSP. Dat wil zeggen dat ze onveranderd worden doorgegeven, mogelijk in een andere verpakking (document/wrappers), maar inhoudelijk niet bewerkt of zelfs bekeken worden. Theoretisch moeten bouwsteeninstantiaties versleuteld kunnen zijn, zonder dat de werking van het LSP daardoor beïnvloed wordt.

Relatie met overige documenten

Dit document is bewust zoveel mogelijk opgezet als een zelfstandige bron van informatie. De HL7 versie 3 standaard is nuttig als achtergrondinformatie, maar niet per se noodzakelijk om de bouwstenen te implementeren. De details voor het implementeren van de data types (elementaire bouwstenen) en de bouwstenen voor patiënten en artsen zijn uitgewerkt in de Implementatie¬handleiding HL7v3 Basiscomponenten, waarin ook meer algemene achtergrondinformatie over de implementatie van HL7v3 te vinden is.

Er wordt in dit document nadrukkelijk niets vermeld over de samenhang met het uitwisselmechanisme voor de bouwstenen, inclusief de verpakking waarin ze uitgewisseld worden (berichtwrappers en/of CDA documenten). Deze implementatiehandleiding beschrijft alleen de implementatie van de bouwstenen zelf (als gegevensdragers) en die is per definitie onafhankelijk van het gebruikte uitwisselmechanisme. De enige wisselwerking die kan bestaan is dat sommige gegevenselementen in de instantiaties optioneel kunnen zijn, omdat ze impliciet bekend zijn vanuit de omliggende gegevensdrager (dit geldt met name voor de patiënt in geval van CDA documenten).

Relatie met bestaande specificaties binnen AORTA

Bij het specificeren van de implementatievorm voor bouwstenen is er steeds een afweging nodig tussen het principe van standaardisatie volgens internationale standaarden en de praktische behoefte om aan te sluiten bij bestaande specificaties. Vanzelfsprekend zal altijd gestreefd worden naar het aansluiten bij standaarden, maar vooralsnog wordt interne consistentie binnen AORTA iets zwaarder gewogen dan internationale standaardisatie. Dat wil zeggen dat de volgende hiërarchie bestaat bij het maken van de keuze voor de implementatievorm van een bepaalde bouwsteen:

• Indien er al een specificatie bestaat voor implementatie binnen AORTA (zoals bij labbepalingen en medicatievoorschriften) dan wordt daar 1-op-1 bij aangesloten.
• Zo nee, dan wordt gebruik gemaakt van het universele model voor het clinical statement uit CDA Release 2 als basis voor implementatie (zie paragraaf 2.2XXXXXXXXXXX).

Het voordeel van de eerste optie is dat softwareleveranciers de softwaremodule voor het verwerken van dit bouwsteentype onveranderd moet kunnen toepassen (al kan dat zijn op basis van een nieuwe interactie of zelfs een nieuw type gegevensdrager, zoals CDA). Het voordeel van de tweede optie is dat een generieke module gebruikt kan worden voor het verwerken van clinical statements, ook al zullen er altijd specifieke implementatie-richtlijnen zijn (in de vorm van een zogenaamde template) voor elk bouwsteentype.

Relatie met project Generieke Overdrachtsgegevens

Er is een belangrijke relatie tussen het project Referentiearchitectuur Ketenzorg, in het bijzonder deze bouwsteenimplementaties, en het project Generieke Overdrachtsgegevens van de NFU (onder regie van Nictiz). Het nobel streven is om er voor te zorgen dat de bouwsteenimplementaties in beide projecten volledig consistent met elkaar zijn. Dat wil zeggen dat daar waar sprake is van dezelfde uitwisselbare concepten (d.w.z. bouwsteen-types), ernaar gestreefd zal worden hiervoor ook dezelfde implementatie te hebben.

Documenthistorie

Versie	Datum	Omschrijving
0.1.0.0	01-12-2013	Eerste versie t.b.v. de werkgroep HL7 implementatie
0.2.0.0	01-01-2014	Update met nadere uitwerking diverse bouwstenen, plus aanpassing labbouwsteen aan bestaande spec’s.
0.9.0.0	15-01-2014	Verwerking reacties n.a.v. interne review plus aanvullen diverse specificaties.
1.0.0.0	01-03-2014	Verwerking reacties n.a.v. externe review plus verwerken nieuwe inzichten.

Legenda

Let op! Dit is een aandachtpunt. Een opmerking die de aandacht vestigt op een bepaald opvallend aspect

Dit is een 'open issue' of 'known issue'. Een kwestie die nog open ligt voor discussie, maar onderkend is.

Dit is een frequently asked question (FAQ) met antwoord.

Algemene regels voor bouwsteenimplementatie

Bouwstenen als implementatievorm

In het architectuurontwerp voor de zorgtoepassing Ketenzorg is toegelicht waarom gekozen is voor het bouwsteenprincipe bij de uitwerking van deze zorgtoepassing (zodanig dat die later als basis kan dienen voor toekomstige zorgtoepassingen).

De definitie van een bouwsteen is:

• Een logisch afgebakende, herbruikbare informatie-eenheid, incl. een implementeerbare specificatie, die als geheel geautoriseerd kan worden.

Belangrijk om te benadrukken is dat het bouwsteenprincipe op verschillende niveaus kan worden beschouwd. De volgende termen typeren het onderscheid tussen deze niveaus:

• Bouwsteentype (aanduiding).
• Bouwsteenmodel (conceptueel).

Een visuele representatie van de gegevens¬elementen voor een bouwsteentype, in hun onderlinge samenhang. Dit model is implementatie-onafhankelijk omdat het alleen semantiek en geen syntax aanduidt.

• Bouwsteentemplate (implementeerbaar).

De ‘vertaling’ van het bouwsteenmodel in een implementeerbaar formaat (bijv. als restrictie op CDA R2 clinical statement). Een template beschrijft de syntax van het uitwisselformaat, plus de gekoppelde value sets.

• Bouwsteeninstantiatie (gevuld met echte data).

Een ‘invulling’ van het bouwsteentemplate voor specifieke gegevens. Hier wordt dus bijv. het concept medicatie weergegeven in de vorm die wordt beschreven door de template, maar nu met een specifiek medicijn.

Dit document benoemt enkele bouwsteentypen (een subset die momenteel in scope is), maar schetst daarbij geen conceptuele modellen. Wel wordt een link gelegd naar modellen voor vergelijkbare concepten, die in het project Generieke Overdrachts-gegevens zijn uitgewerkt. De nadruk ligt op het beschrijven van de HL7 templates die specificeren wat de implementeerbare vorm van deze bouwstenen is. Daarbij worden XML voorbeelden gegeven, die een indruk geven van de bouwsteeninstantiaties.

Het bouwsteenconcept wordt niet alleen op conceptueel niveau toegepast, maar ook op implementatieniveau. Het is juist bij het fysiek uitwisselen in XML formaat dat leveranciers nu vaak te maken hebben met verschillende implementatievormen van hetzelfde logische concept. Doel is om te zorgen dat leveranciers een softwaremodule kunnen schrijven die een bouwsteen-implementatie ondersteunt, zodanig dat deze software net zo herbruikbaar is als de bouwsteen zelf. Daarmee wordt het onderscheid tussen de uitwissel-mechanismen, met name berichten versus documenten, ook gereduceerd tot ‘verpakking’, omdat het XML formaat van de inhoud gestandaardiseerd is. Het werken met herbruikbare bouwstenen zal overigens ook de basis zijn voor de volgende generatie HL7 implementaties, want de resources van Fast Healthcare Interoperability Resources (FHIR) zijn ook gewoon bouwstenen.

HL7v3 model voor implementatie

De belangrijkste vraag bij het maken van implementeerbare bouwsteenspecificaties is welk onderliggend HL7 versie model er gebruikt wordt. Bij de implementatie op basis van berichten die nu gangbaar is binnen AORTA, werd normaal gesproken voor elk type opgeleverde gegevens een specifiek berichtmodel ontwikkeld, waarbij ook een specifiek XML Schema hoort. Aan de andere kant kent HL7v3 het mechanisme van de Clinical Document Architecture (CDA), dat één vast model en bijbehorend XML Schema kent. Specifieke implementatierichtlijnen worden dan aangeduid door middel van een zogenaamd template, dat weergeeft welke regels er precies gelden voor de inhoud.

De trend is dat steeds meer HL7v3 interfaces wereldwijd gebaseerd zijn op CDA, specifiek op Release 2 van deze standaard. De implementatie van bouwstenen ligt echter niet op het niveau van gehele documenten (die een verzameling gegevens kunnen omvatten die bestaat uit meerdere instantiaties van verschillende bouwsteentypen), maar op het niveau van het zogenaamde Clinical Statement. Dit clinical statement is het onderdeel van het CDA model dat bedoeld is om specifieke medische gegevens weer te geven. Ook dit heeft een vast XML Schema, dat een subset is van het CDA R2 Schema.

Uitgangspunt is dat bouwsteenimplementaties in principe compatible zullen zijn met het clinical statement van CDA Release 2 (CDA R2), eventueel aangevuld met extensies voor het realiseren van functionaliteit die ontbreekt in het clinical statement model. Echter: de aanwezigheid van een bestaande, niet op CDA R2 gebaseerde implementatie (zoals die van bestaande zorgtoepassingen binnen AORTA), kan reden zijn om van dit principe af te wijken. Dit wordt per bouwsteentype apart afgewogen.

De migratie richting het generieke model (en Schema) van het clinical statement is vooral een verschuiving van specificatie d.m.v. een specifiek XML Schema naar specificatie d.m.v. een specifiek template (en de bijbehorende Schematron regels). Daarbij blijft het nog steeds zo dat de gespecificeerde templates domeinspecifiek zijn.

Dat in eerste instantie een mix van op het clinical statement gebaseerde templates en bestaande AORTA-specificaties wordt gebruikt is een afweging tussen principe en praktijk. Voor de leveranciers heeft het hergebruik van bestaande AORTA-bouwstenen als voordeel dat ze ook bijbehorende softwaremodules kunnen hergebruiken. Op enig moment zal echter een migratie worden ingezet clinical statements conform CDA R2, hetgeen sowieso het uitgangspunt is voor ontwikkeling van nieuwe zorgtoepassingen.

In de volgende paragraaf wordt het generieke Clinical Statement model van CDA R2 beschreven. Per bouwsteentype wordt dan een subset van dit model aangeduid (het XML-implementatieformaat is altijd conform het Schema van het Clinical Statement).

Als sprake is van een reeds geïmplementeerd model binnen AORTA, dan wordt dit model weergegeven, zoveel mogelijk consistent met het gebruik binnen de bestaande zorg-toepassing (het XML-implementatieformaat is dan conform het bijbehorende Schema).

Clinical Statement Model – CDA R2

Het Clinical Statement model voor CDA R2 heeft de volgende grafische representatie:

Noot: bovenstaand model is iets overzichtelijker getekend dan in het totaalmodel voor CDA R2. De semantiek ervan is echter 100% compatible met die van standaard CDA R2.

Het (sub)model dat wordt gehanteerd voor bouwsteenimplementaties is een restrictie op bovenstaand model. Dat wil zeggen dat een keuze gemaakt wordt uit de choice box, dat optionele elementen kunnen worden weggelaten en dat de cardinaliteit van relaties en attributen kan worden aangescherpt. Deze bouwsteenimplementaties conformeren zich dus aan bovenstaand model. Het gevolg is dat de bijbehorende bouwsteeninstantiaties ook zullen valideren tegen het XML Schema van het Clinical Statement van CDA R2.

Labbepaling

3.1 Bouwsteentypering 14 3.2 Subdataset Ketenzorg 14 3.3 Conceptueel model GOG 15 3.4 HL7v3 model 16 3.5 HL7 template 18 3.6 XML voorbeeld 19

Algemene bepaling

4.1 Bouwsteentypering 20 4.2 Subdataset Ketenzorg 20 4.3 Conceptueel model GOG 21 4.4 HL7v3 model 22 4.5 HL7 template 22 4.6 XML voorbeeld 23

Contactmoment

5.1 Bouwsteentypering 24 5.2 Subdataset Ketenzorg 24 5.3 Conceptueel model GOG 25 5.4 HL7v3 model 26 5.5 HL7 template 26 5.6 XML voorbeeld 27

Medicatievoorschrift

6.1 Bouwsteentypering 28 6.2 Subdataset Ketenzorg 28 6.3 Conceptueel model GOG 29 6.4 HL7v3 model 29 6.5 HL7 template 30 6.6 XML voorbeeld 32