7kezo:V1.0 HL7v3-bouwstenen Ketenzorg

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

Inleiding

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.

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