7kezo:V1.0 Bijlage A: CDA document: verschil tussen versies

Uit informatiestandaarden
Naar navigatie springen Naar zoeken springen
k (Tekst vervangen - "{{#customtitle:" door "{{DISPLAYTITLE:")
 
(9 tussenliggende versies door een andere gebruiker niet weergegeven)
Regel 1: Regel 1:
{{#customtitle: Bijlage A: CDA document (algemene specificatie) | Bijlage A: CDA document (algemene specificatie)}}
+
{{DISPLAYTITLE: Bijlage A: CDA document (algemene specificatie) | Bijlage A: CDA document (algemene specificatie)}}
 
<noinclude>{{DocumentPart|ns=7kezo|title=V1.0_HL7v3-uitwisseling_Ketenzorg}}</noinclude>
 
<noinclude>{{DocumentPart|ns=7kezo|title=V1.0_HL7v3-uitwisseling_Ketenzorg}}</noinclude>
 
=Bijlage A: CDA document (algemene specificatie)=
 
=Bijlage A: CDA document (algemene specificatie)=
Regel 12: Regel 12:
 
Tenslotte is het mogelijk om binnen de secties zogenaamde '''Entries''' op te nemen, die gestructureerde (en vaak gecodeerde) gegevens bevatten in de vorm van zogenaamde clinical statements. Een clinical statement is een instantiatie van een bouwsteen met een bepaalde gegevensinhoud, gebaseerd op het model dat daarvoor in CDA aanwezig is.  
 
Tenslotte is het mogelijk om binnen de secties zogenaamde '''Entries''' op te nemen, die gestructureerde (en vaak gecodeerde) gegevens bevatten in de vorm van zogenaamde clinical statements. Een clinical statement is een instantiatie van een bouwsteen met een bepaalde gegevensinhoud, gebaseerd op het model dat daarvoor in CDA aanwezig is.  
  
 +
[[Image:Cda_model_weergave.gif|600px]]
  
 
Voor nadere toelichting zie:  
 
Voor nadere toelichting zie:  
Regel 18: Regel 19:
 
{{NoteBox|Indien gebruik wordt gemaakt van gestructureerde bouwstenen als entries, wordt gesproken van een CDA level 3 document. Alle CDA documenten die in de zorgtoepassing Ketenzorg worden uitgewisseld, zijn level 3 documenten.}}
 
{{NoteBox|Indien gebruik wordt gemaakt van gestructureerde bouwstenen als entries, wordt gesproken van een CDA level 3 document. Alle CDA documenten die in de zorgtoepassing Ketenzorg worden uitgewisseld, zijn level 3 documenten.}}
  
Clinical statements in CDA Release 2 worden toegelicht in de Implementatiehandleiding Bouwstenen, waar ze in principe als basis dienen voor de bouwsteenimplementaties (tenzij gebruik wordt gemaakt van een bestaande implementatie binnen AORTA).  
+
Clinical statements in CDA Release 2 worden toegelicht in de Implementatiehandleiding Bouwstenen, waar ze in principe als basis dienen voor de bouwsteenimplementaties (tenzij gebruik wordt gemaakt van een bestaande implementatie binnen AORTA).
  
 
==Implementatierichtlijnen CDA Header==
 
==Implementatierichtlijnen CDA Header==
 +
De header bevat slechts een paar elementen die ingevuld moeten worden en zijn verplicht van de onderliggende standaard (CDA).
 +
===ClinicalDocument.id===
 +
Elk CDA document dient een identificatie te hebben die door het aanmakende systeem wordt uitgedeeld. Let wel dat dit niet dezelfde id is als die van het bericht waar een CDA document wordt getransporteerd.
 +
===ClinicalDocument.code===
 +
De typering van het document (code) is per use case voorgeschreven en dient zoals beschreven overgenomen te worden.
 +
===ClinicalDocument.title===
 +
Elk CDA document heeft een titel, hier bijvoorbeeld "Verwijzing" met de datum daarachter. De naam van de patiënt wordt hier niet opgenomen.
 +
===ClinicalDocument.effectiveTime===
 +
Het aanmaakdatum van het CDA document (komt hier meestal overeen met het aanmaakdatum van het bericht zelf), kan dus hetzelfde zijn, tot op de seconde nauwkeurig aan te geven.
 +
===ClinicalDocument.confidentialityCode===
 +
Deze code geeft de vertrouwelijkheidsgraad van het CDA document weer en vooralsnog dient hier de waard "N" uit de value set gekozen te worden.
 +
===ClinicalDocument.recordTarget===
 +
Deze structuur geeft de patiënt weer.
 +
 +
===ClinicalDocument.author===
 +
Deze structuur geeft de auteur (zorgverlener) van het document weer.
 +
 +
===ClinicalDocument.custodian===
 +
Deze structuur geeft de beheerder van het CDA document weer, dit komt overeen met de zorgverlenende organisatie (zorginstelling).
 +
 +
===Meer informatie===
 
Een overzicht van de Nederlandse implementatierichtlijnen voor de CDA Header staat op:
 
Een overzicht van de Nederlandse implementatierichtlijnen voor de CDA Header staat op:
  
Regel 26: Regel 48:
  
 
==Implementatierichtlijnen CDA Body==
 
==Implementatierichtlijnen CDA Body==
 +
Daar waar voor de CDA Header strikte richtlijnen bestaan voor de minimaal te vullen gegevenselementen, geldt voor de CDA Body in feite dat er veel minder regels bestaan.
 +
 +
Kort samengevat zijn de regels als volgt:
 +
 +
*Er is geen regel ten aanzien van het gebruik van Sections. Het is wel toegestaan om de tekst van het document in te delen in paragrafen met elk hun eigen titel, maar het is geen verplichting. Er mag ook één ‘loze’ Section zijn met alle Entries.
 +
*Hoewel het wenselijk is om Entries te plaatsen binnen de Section waarop deze betrekking hebben, is dat geen harde regel. Via een referentie is het mogelijk om een Entry te laten verwijzen naar tekst die in een andere Section is opgenomen.
 +
 +
Er is de nodige discussie geweest over de verplichting die CDA kent om in de vrije tekst minimaal dezelfde inhoud (qua betekenis) te hebben als in de gestructureerde Entries. Aangezien er in de scope van de zorgtoepassing Ketenzorg (nog) geen behoefte bestaat om informatie over te dragen buiten de Entries om, zou de tekstuele weergave in feite redundant zijn, terwijl de leverancier wel moeite moet doen om deze te genereren.
 +
 +
Enige voordeel kan zijn dat de toetredingsdrempel voor KIS leveranciers lager kan worden indien het mogelijk is om een patiëntverwijzing als vrije tekst te tonen, zonder de noodzaak om de Entries (bouwsteeninstantiaties) te verwerken en zelf weer te geven. Het volgende compromis is bereikt als afspraak binnen de zorgtoepassing Ketenzorg:
 +
 +
{{NoteBox|Een verzendend systeem mag in de vrije tekst (d.w.z. de som van de tekst van alle Sections) niet méér informatie (qua betekenis) doorgeven dan ook is opgenomen in de Entries (bouwsteeninstantiaties). Dit voorkomt dat de ontvanger verplicht is om náást de Entries ook de volledige documenttekst te bewaren, waarbij het lastig is om te bepalen waar de extra informatie staat.}}
 +
 +
{{NoteBox|Om te zorgen dat het genereren van de tekstuele weergave zo eenvoudig mogelijk is én bij voorkeur een gestandaardiseerd formaat aanhoudt, zal vanuit VZVZ een stylesheet worden ontwikkeld die kan worden ingezet om automatisch een tekstweergave te genereren vanuit de meegestuurde Entries. Deze stylesheet is beschikbaar vóór de start van de proof-of-concept.}}
 +
 
==Implementatierichtlijnen CDA Entries==
 
==Implementatierichtlijnen CDA Entries==
 
Voor de CDA Entries geldt slechts één algemene richtlijn, namelijk dat ze conform één van de gedefinieerde bouwsteendefinities (en het bijbehorende template) moeten zijn.
 
Voor de CDA Entries geldt slechts één algemene richtlijn, namelijk dat ze conform één van de gedefinieerde bouwsteendefinities (en het bijbehorende template) moeten zijn.

Huidige versie van 20 jul 2020 om 01:37


Dit materiaal is onderdeel van HL7v3-domein Ketenzorg V1.0_HL7v3-uitwisseling_Ketenzorg.
  • Compatible wijzigingen/nadere bewoordingen, tikfouten kunnen direct in de Wiki gewijzigd worden
  • Open issues die discussie vergen s.v.p. in de commentaarsectie opnemen.

Bijlage A: CDA document (algemene specificatie)

In deze bijlage wordt weergegeven hoe een CDA document dat via het LSP verzonden wordt (via een ‘push’ interactie) voor de zorgtoepassing Ketenzorg gevuld moet worden, in generieke zin. Eerst wordt de algemene structuur van een CDA document beschreven en vervolgens worden er implementatierichtlijnen gegeven voor de header en de algemene onderdelen van de body, inclusief de sections met tekst. Tenslotte wordt aangegeven welke algemene richtlijnen er gelden voor de gestructureerde entries.

Algemene structuur CDA document

Een CDA document bestaat ten ruwste weg uit een Header en een Body.

De Header is vergelijkbaar met het briefhoofd van een papieren brief en bevat meta-gegevens die op het hele document betrekking hebben. Voornamelijk zijn hierbij van belang de patiënt (als onderwerp van het document) en de zorgverlener (als inhoudsverantwoordelijke).

De Body van het document beslaat de feitelijke zorginhoudelijke informatie. Deze body kan bestaan uit niets anders dan vrije tekst. In dat geval wordt gezegd dat sprake is van een CDA level 1 document. Het is ook mogelijk om de vrije tekst in te delen in aparte Sections, die fungeren als paragraafkoppen binnen het document. Deze secties zijn dan ook te voorzien van een codering (bijv. SNOMED), die aangeeft wat de aard van de gegevens in de sectie is (bijv. anamnese, cumulatief laboverzicht of actuele medicatie). Als de tekst voorzien is van secties, wordt gesproken van een CDA level 2 document.

Tenslotte is het mogelijk om binnen de secties zogenaamde Entries op te nemen, die gestructureerde (en vaak gecodeerde) gegevens bevatten in de vorm van zogenaamde clinical statements. Een clinical statement is een instantiatie van een bouwsteen met een bepaalde gegevensinhoud, gebaseerd op het model dat daarvoor in CDA aanwezig is.

Cda model weergave.gif

Voor nadere toelichting zie: http://www.hl7.nl/wiki/index.php?title=CDA_Inleiding

Clinical statements in CDA Release 2 worden toegelicht in de Implementatiehandleiding Bouwstenen, waar ze in principe als basis dienen voor de bouwsteenimplementaties (tenzij gebruik wordt gemaakt van een bestaande implementatie binnen AORTA).

Implementatierichtlijnen CDA Header

De header bevat slechts een paar elementen die ingevuld moeten worden en zijn verplicht van de onderliggende standaard (CDA).

ClinicalDocument.id

Elk CDA document dient een identificatie te hebben die door het aanmakende systeem wordt uitgedeeld. Let wel dat dit niet dezelfde id is als die van het bericht waar een CDA document wordt getransporteerd.

ClinicalDocument.code

De typering van het document (code) is per use case voorgeschreven en dient zoals beschreven overgenomen te worden.

ClinicalDocument.title

Elk CDA document heeft een titel, hier bijvoorbeeld "Verwijzing" met de datum daarachter. De naam van de patiënt wordt hier niet opgenomen.

ClinicalDocument.effectiveTime

Het aanmaakdatum van het CDA document (komt hier meestal overeen met het aanmaakdatum van het bericht zelf), kan dus hetzelfde zijn, tot op de seconde nauwkeurig aan te geven.

ClinicalDocument.confidentialityCode

Deze code geeft de vertrouwelijkheidsgraad van het CDA document weer en vooralsnog dient hier de waard "N" uit de value set gekozen te worden.

ClinicalDocument.recordTarget

Deze structuur geeft de patiënt weer.

ClinicalDocument.author

Deze structuur geeft de auteur (zorgverlener) van het document weer.

ClinicalDocument.custodian

Deze structuur geeft de beheerder van het CDA document weer, dit komt overeen met de zorgverlenende organisatie (zorginstelling).

Meer informatie

Een overzicht van de Nederlandse implementatierichtlijnen voor de CDA Header staat op:

http://www.hl7.nl/wiki/index.php?title=CDA_Header

Implementatierichtlijnen CDA Body

Daar waar voor de CDA Header strikte richtlijnen bestaan voor de minimaal te vullen gegevenselementen, geldt voor de CDA Body in feite dat er veel minder regels bestaan.

Kort samengevat zijn de regels als volgt:

  • Er is geen regel ten aanzien van het gebruik van Sections. Het is wel toegestaan om de tekst van het document in te delen in paragrafen met elk hun eigen titel, maar het is geen verplichting. Er mag ook één ‘loze’ Section zijn met alle Entries.
  • Hoewel het wenselijk is om Entries te plaatsen binnen de Section waarop deze betrekking hebben, is dat geen harde regel. Via een referentie is het mogelijk om een Entry te laten verwijzen naar tekst die in een andere Section is opgenomen.

Er is de nodige discussie geweest over de verplichting die CDA kent om in de vrije tekst minimaal dezelfde inhoud (qua betekenis) te hebben als in de gestructureerde Entries. Aangezien er in de scope van de zorgtoepassing Ketenzorg (nog) geen behoefte bestaat om informatie over te dragen buiten de Entries om, zou de tekstuele weergave in feite redundant zijn, terwijl de leverancier wel moeite moet doen om deze te genereren.

Enige voordeel kan zijn dat de toetredingsdrempel voor KIS leveranciers lager kan worden indien het mogelijk is om een patiëntverwijzing als vrije tekst te tonen, zonder de noodzaak om de Entries (bouwsteeninstantiaties) te verwerken en zelf weer te geven. Het volgende compromis is bereikt als afspraak binnen de zorgtoepassing Ketenzorg:

Implementatierichtlijnen CDA Entries

Voor de CDA Entries geldt slechts één algemene richtlijn, namelijk dat ze conform één van de gedefinieerde bouwsteendefinities (en het bijbehorende template) moeten zijn.