1 Implementatiehandleiding HL7v3 Pathologie postadres: Postbus 19121, 2500 CC Den Haag bezoekadres: Oude Middenweg 55, 2491 AC Den Haag telefoon: (070...
p o s t a dr e s : P os t b u s 1 9 1 2 1 , 2 5 0 0 C C D e n H a a g b e z o e ka d r e s : O u d e M i dd e n w e g 5 5 , 2 4 9 1 A C D e n H a a g telefoon: (0 70) 31 7 34 50; f ax: (070) 3 20 7 4 37; e-mail: s er v ic ed esk @ in fo EP D. nl w ww. nict iz.nl
Versie Datum
: 6.1.0.0 : 30 september 2009
Disclaimer Hoewel deze publicatie met de uiterste zorg is samengesteld, kan Nictiz geen aansprakelijkheid aanvaarden voor directe of indirecte schade ontstaan door de inhoud van de – al dan niet door derden aangeboden – informatie.
Inhoud Eerste opzet handleiding Eerste publicatie van het concept, voorgelegd aan Stichting PALGA Aanpassingen volgens de commentaren Stichting PALGA Storyboards toegevoegd, tabellen aangepast en sommige beschrijvingen toegevoegd Diverse tekstuele aanpassingen Interacties aangepast Laatste inhoudelijk check en toevoeging referenties, loinc code voor klinische gegevens gewijzigd, voorbeeld van gegenereerde versie van obductieverslag toegevoegd. OID’s PALGA toegevoegd Hoofdstuk 7 “document management” gewijzigd, generiek aanmelden LSP, specifiek vragen via MR berichten, EncompassingEncounter vervangen door ServiceEvent Gewijzigde procedure voor aanmelden LSP (categoraal); toevoegen storyboards hoofdstuk 3 Commentaren PALGA alsnog verwerkt, oorspronkelijk door YPH overgenomen Aangepassingen i.v.m. veranderingen in het Architectuurontwerp formele publicatie
Patient (recordTarget) Auteur Beherende organisatie (Custodian) Beoogde ontvanger (IntendedRecipient) Ondertekenaar (legalAuthenticator) Personen bij data invoer (dataEnterer) Overige betrokkenen Relatie met voorgaande documenten (ParentDocument) Informatie over type en tijdstip onderzoek (ServiceEvent)
28 31 34 35 36 38 38 38 39
CDA R2 body
6.1 6.2
41
Algemene opbouw body Levels 6.2.1 6.2.2 6.2.3
6.3 6.4 6.5
41 42
Level 1 Level 2 Level 3
42 43 43
Classificeren secties met LOINC codes Structuren binnen level 3 Tekststructuren 6.5.1 6.5.2 6.5.3 6.5.4 6.5.5
6.6
44 45 45
Lijsten Tabellen Inhoudreferenties (content) Paragrafen Nieuwe regels
45 45 46 46 46
Mapping medisch inhoud naar CDA body 6.6.1 6.6.2 6.6.3 6.6.4 6.6.5 6.6.6 6.6.7
Gebruikte HL7 Datatype Documenten-Id Type document Aanvullende beschrijving DocumentType Autorisatie datum documenten Vertrouwelijkheid van de documenten Taal van document Versie van documenten
Deze implementatiehandleiding is opgebouwd uit drie delen. Allereerst zal de motivatie en opzet van het document beschreven worden. Vervolgens zullen de modellen die ten grondslag liggen aan de communicatie uitvoerig aan bod komen. Uit deze modellen zijn de opbouw en de semantiek van de berichten en/of documenten af te leiden. Daarnaast kunnen de modellen aanwijzingen leveren voor het bouwen van databases of de applicaties die in deze communicatiescenario’s als zender of ontvanger fungeren. Tot slot zal deze handleiding ondersteuning bieden bij het implementeren. Door de beschreven voorbeelden en detaillering moet de handleiding voldoende kennis bieden aan de programmeurs om de interfaces op te bouwen. Op deze manier wordt uiterst nauwkeurig de informatie-inhoud beschreven en de relatie tussen de overeenstemmende klassen en attributen in het model getoond.
1.2
HL7 en het Referentie model
Alle modellen in HL7 versie 3 zijn gebaseerd op het Referentie-Informatie-Model (RIM). Dit model wordt gebruikt om op een generieke manier processen te beschrijven. Het model bestaat uit zes basisklassen, zoals weergegeven in Figuur 1 .
Figuur 1 RIM basisklassen
Het uitgangspunt in het model is een Activiteit (Act) waaraan Entiteiten (bijv. personen) in een bepaalde Rollen (bijv. arts, patiënt) deelnemen (Participation). Activiteiten kunnen een onderling verband hebben (ActRelationship), zoals een laboratoriumonderzoekaanvraag en het daaruit volgend resultaat. In het totale RIM komen uiteraard nog specialisaties van de basisklassen voor. Zo is een diagnose een bijzonder geval van een observatie die op haar beurt weer een activiteit is.
Pathologie laboratoria wisselen gegevens uit over individuele patiënten. Het betreft hier historische overzichten van de patiënt in de vorm van een overzicht van eerder uitgevoerde pathologie onderzoeken. Deze uitwisseling moet via de landelijke basisinfrastructuur plaats gaan vinden. Het doel van deze handleiding is een beschrijving te geven van de elektronische uitwisseling van pathologieverslagen. Deze beschrijving bevat vaststelling van, inperkingen op en eisen aan HL7 CDA-elementen.
2.2
Doelgroep
Deze handleiding is geschreven voor software ontwikkelaars en adviseurs die betrokken zijn bij implementaties en integraties rondom pathologie. Deze specificatie definieert aanvullende bepalingen, beperkingen en eisen voor de CDA-elementen in de pathologie historie verslagen, die via het landelijk schakelpunt door laboratoria kunnen worden opgevraagd. De handleiding bevat geen specificatie van de infrastructuur, noch workflows, processen of protocollen voor de uitwisseling van patiënt historieverslagen tussen de laboratoria.
2.3
Uitgangspunt
Uitwisseling via het landelijk schakelpunt (LSP) vindt plaats op basis van HL7. Deze oorspronkelijk uit Amerika komende opzet is in de loop der tijd tot een internationale standaard uitgegroeid, die nog continu doorontwikkeld wordt. HL7 biedt: •
Een conceptuele basis in een gemeenschappelijk, omvangrijk Referentie Informatie Model (RIM) voor alle delen van HL7 versie 3; Dit RIM is een ANSIen ISO standaard;
•
Een solide semantisch fundament in expliciet gedefinieerde conceptdomeinen;
•
Geselecteerde en gestandaardiseerde terminologieën, die binnen de domeinen semantische interoperabiliteit garanderen;
•
Scheiding van inhoud en syntax;
•
Een technologie onafhankelijke ontwerpmethodiek.
HL7 is gebaseerd op XML en wordt gebruikt voor het overbrengen van berichten. Daarnaast stelt HL7 een standaard ter beschikking voor de structurering, inhoud en voor het uitwisselen van medische documenten, de zogenoemde Clinical Document Architecture (CDA). Hierbij ligt de focus op de informatie-uitwisseling in de gezondheidszorg. HL7 versie 3 CDA release 2 wordt als basis gebruikt voor deze documenten.
Deze specificatie is tot stand gekomen in samenwerking met de Nederlandse vereniging voor Pathologie (NVVP), stichting PALGA en Nictiz. De informatie uit de gehouden workshops zijn gecompleteerd door inperking en concretisering van bestaande standaarden. •
Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das Deutsche Gesundheitswesen. Implementierungsleitfaden, Versie 1.50, 12.05.2006, Dokumenten-OID: 1.2.276.0.76.3.1.13.7.5
•
E_pathologisch dossier. Impactanalyse op hoofdlijnen, versie 0.7, 2006-0515, Nictiz
Aan het eind van het traject zijn ook de HL7-tools nodig, waarmee automatisch de constraints van het CDA Refined Message Information Model (R-MIM) afgeleid kunnen worden. Tevens vindt er validatie plaats om er zeker van te zijn dat het voorbeelddocument een afgeleide CDA document is conform de CDA constraints die zijn vastgelegd in de pathologie eisen. Daarnaast vindt er nog een tweede validatie plaats. Bij deze validatie wordt gecheckt of het voorbeeld document in overeenstemming is met de toegevoegde business rules en beperkingen, zoals vastgelegd in deze implementatiegids, zonder te botsen met het HL7 CDA Compliant Schema.
3 Storyboards en voorbeelden Pathologie In dit hoofdstuk zijn een vijftal voorbeelden opgenomen van teksten uit pathologieonderzoeken, die onderdeel zijn van de gegevensuitwisseling tussen de pathologen.
3.1
Histologie [T] – groot (POCD_SN970001NL)
Klinische gegevens: Rectosigmoid resectie. Rectumcarcinoom bij status na lage dosering en radiotherapie. Nu anterior resectie. Vraagstelling: histologie, radicaliteit, lymfkliermetastasen? Macroscopie: Aantal inzendingen: 1. Diepte preparaat: low anterior resectie. Lengte preparaat: 14 cm. Kwaliteit TME: resectie op de mesorectale fascie. Proximale omslagplooi: op 11 cm van het distale sneevlak. Tumor: Lokalisatie: op 4 cm van het distale sneevlak. Maximale lengte tumor: 4 cm. Percentage van de circumferentie innemend: 90%. Diepte van invasie: Macroscopisch beperkt tot de muscularis. Afstand tot het beeld is circumferentiele sneevlak: 20 mm. Cassettes: 1 tot met 3: tumor 4 colonslijmvlies elders. 5 t/m 20. Lymfklieren. Microscopie: Tumor type (WHO) : Adenocarcinoom Differentiatiegraad : Goed Diepste doorgroei tumor reikend tot in : peri-rectale vet Angioinvasie : Nee Darm resectievlak : Vrij Overige mucosa : Geen afwijking LYMFKLIEREN Aantal lymfklieren : 16 Aantal positief : 1 (coupe 8) Conclusie: Low anterior resectie na korte voorbestraling: hoog in het rectum gelokaliseerd, goed gedifferentieerd adenocarcinoom; oppervlakkige doorgroei in het perirectale vet; sneevlak vrij (Afstand tot CRM 20 mm); Totaal 16 lymfklieren waarvan 1 met een metastase. 10 van 73
Klinische gegevens: Gepigmenteerd plekje rechter slaap. Macroscopie: 1 inzending. Een ellipsvormige huidexcisie met subcutis van 12 x 7 x 3 mm. Op de epidermis een matig verheven, korrelige, lichtbruine laesie van 5 mm in diameter. T.i. Microscopie: Doorsneden door een verruca seborrhoica van het acanthotische type. De laesie werd in toto verwijderd. Conclusie: Excisie verruca seborrhoica rechter slaap. Diagnosen: Diagtekst1: huid*gelaat*excisie*verruca seborrhoica Palga-codes1: T01000*TY02000*P11200*M27250
3.3
Cytologie [C] (POCD_SN970003NL)
Klinische gegevens: Hoofdcarina punctie long op glaasjes --> maligniteit? 18 uitstrijken (G) ontvangen. Microscopie: Celrijk materiaal waarin losliggende en groepen dissocierende wanordelijk gelegen sterk atypische cellen met vergrote, polymorfe en hyperchromatische kernen, forse anisonucleose, prominente nucleoli, grof chromatinepatroon en zeer onregelmatig en soms verhoornend cytoplasma. Daarnaast veel granulocyten, lymfocyten, cylinderepitheelcellen en veel bloed. Conclusie: long punctie hoofdcarina: planocellulair carcinoom. Diagnosen: Diagtekst1 : long*punctie*carina*verhoornend planocellulair carcinoom Palga-codes1: T28000*P31430*T25200*M80713 Implementatiehandleiding HL7v3 Pathologie, v6.1.0.0
11 van 73
3.4
Cervix cytologie [B] (POCD_SN970004NL)
Klinische gegevens: Datum strijk: 27-09-07 Aanleiding: vervolgonderzoek Uitstrijk door: huisarts Instrument: cervexbrush Klachten: geen Datum LM: ZZ-ZZ-ZZ Toestand preparaat: normaal Aantal glaasjes: 1 Menstruatiepatroon: menopauze Anticonceptie: geen Hormoongebruik: geen Opmerking: geen Ingrepen: conisatie, lisexcisie, biopt Aspect cervix: normaal Zwangerschap: geen Prioriteit: routine Microscopie: K 4: Endocerv. cyl. en squameus metapl. cellen aangetroffen O 6: Geen teken van ontsteking P 1: Geen afwijkende plaveiselepitheelcellen A 2: Epitheelatrofie C 1: Geen afwijkingen van endocerv. cyl.cellen aangetroffen B 1: Goed beoordeelbaar Conclusie: Pap 1. Epitheelatrofie. Diagnosen: Diagtekst1: Cervix*uitstrijk*systeem*ec+sqm*g.ont*g.a.*ep.atr*g.a.*pap1 Palga-codes1: T83000*P31100*E99999*T83300M73220*M09380*M58001*M00100*M69152
Klinische gegevens: Op 27 september mitraalklep plastiek middels annuloplastiek en aorta klep vervanging door bioprothese. Op 03 oktober terugplaatsing uit Zwolle na bovengenoemde ingreep. Op 04 oktober ritmestoornissen waarvoor digoxine. Later die dag hoge koorts, tachycardie en beeld van pneumonie links waarvoor opname intensieve care en beademing. Ondanks vulling en inotropica geen verbetering van de bloeddruk. Echografie hart: pericardvocht maar niet voldoende voor punctie. Patiënte is overleden. Macroscopie: Voornaamste pathologische diagnosen: 1. Status na recente sternotomie met aortaklepvervanging (bioklep) en mitralis kleppen plastiek middels annuloplastiek. Geen loco regionale veranderingen; geen paravalvulaire lekkage; geen thrombi of vegetaties. 2. Mediastinitis met puspockets direct retrosternaal. (Kweek wondvocht: stafylokokken aureus) 3. Gegeneraliseerde stuwing met circa 2,5 liter ascitesvocht; ernstige pericentrale levercel necrose en tubulus necrose passend bij multi orgaanfalen bij sepsis.. 4. Ernstige circulaire linker ventrikelhypertrofie (hartgewicht 740 g) met geringe rechter ventrikel hypertrofie 5. Tekenen van een oud myocardinfarct in de onderachterwand bij normale coronair arterien. 6. Matig ernstige atherosclerose van de aorta abdominalis met artherosclerose van de nieren; links schrompelnier. 7. Milde diabetische nefropathie( diffuse mesangiale sclerose en hyalinose van de arteriolen) 8. Galstenen. Geen aanknopingspunten voor cholecystitis. 9. Obesitas. Epicrise: Obductie werd verricht op een 71 jarige patiente die circa een week voor overlijden een cardiochirurgische ingreep onderging met mitraalklep plastiek en aortaklepvervanging. Enkele dagen postoperatief ontstonden er ritmestoornissen, koorts en het beeld van sepsis waarna patient overleed. Bij obductie werd een mediastinitis aangetroffen met pus pockets gelokaliseerd retrosternaal vermoedelijk samenhangend met de recente cardiochirurgische ingreep. Uit het wondvocht werd stafylokokken aureus gekweekt. Deze infectie heeft geleid tot een sepsis met hypotensie en het beeld van multi-orgaan falen als uiting waarvan massale levercelnecrose is opgetreden. Een ander focus voor een infectie werd niet aangetroffen. De afwijkingen verklaren het overlijden. De mitralisplastiek en aortaklep bioprothese toonden verder geen afwijkingen. Met name waren er geen aanknopingspunten voor paravalvulaire lekkage, thrombi en of vegetaties. Als toevalsbevinding werd een milde diabetische nefropathie aangetroffen. Was paImplementatiehandleiding HL7v3 Pathologie, v6.1.0.0
13 van 73
tiente bekend met diabetes mellitus? Conclusie: Obductie werd verricht op een 71-jarige patiente welke overleed na een cardiochirurgische ingreep. Bij obductie werd een mediastinitis aangetroffen op basis van stafylokokken aureus infectie vermoedelijk ontstaan als wond infectie postoperatief. Deze heeft geleid tot sepsis en het overlijden. Diagnosen: Diagtekst1: lichaam*obductie*sepsis Diagtekst 2: hart*obductie*status na operatie*litteken*aortastenose* myocardhypertrofie Diagtekst 3: mediastinum*obductie*abces*ontsteking Diagtekst 4: lever*obductie*necrose*sepsis Diagtekst 5: nier*obductie*diabetische glomerulosclerose Palga-codes1: TYY000*P30110*D00800 Palga-codes2: T32000*P30110*F01502*M49060*T39000M34100*T33010M71000 Palga-codes3: TY2300*P30110*M41740*M40000 Palga-codes4: T56000*P30110*M54000*D00800 Palga-codes5: T71000*P30110*T71200M53300D23810
3.6
Aanmelden en opvragen
Aanmeld en opvraag scenario’s zijn gedetailleerd beschreven in hoofdstuk 7 “Document Management”.
De Clinical Document Architecture is een standaard voor het uitwisselen en opslaan van klinische documenten. Hierbij wordt gebruik gemaakt van Extensible Markup Language XML. CDA is ontwikkeld door Health Level Seven (HL7), een van de belangrijkste internationale standaardontwikkelaar voor de gezondheidszorg. CDA stelt een XML gebaseerde Documenten-Markup standaard ter beschikking. CDA release 2, gebaseerd op het HL7 Referentie-Informatiemodel, bestaat grofweg uit Tags, die semantiek opstellen voor personen en documenteigenschappen (bijv. <patiënt>, <arts>) en die gebruikt kunnen worden voor het weergeven van de structuur en de hiërarchie van het document (bijv. <sectie>, <paragraaf>, ).
4.2
Eigenschappen CDA documenten
In de standaard worden zes essentiële eigenschappen beschreven die kenmerkend zijn voor een CDA document. Deze zullen hieronder beschreven worden. 4.2.1 Persistent CDA documenten zijn volkomen persistent, dat wil zeggen gekenmerkt als duurzaam bestaan in het zendende of ontvangende systeem. 4.2.2 Verantwoordelijkheid voor documentbeheer Een organisatie tekent verantwoordelijk te zijn voor het beheer van een CDA document. 4.2.3 Onderteken mogelijkheid Een CDA document is gekenmerkt door informatie die mogelijk ondertekend kan worden, bijvoorbeeld een voor de wet geldige handtekening. 4.2.4 Context Alle informatie binnen een document heeft een bepaalde context. Bij een labuitslag staan bijvoorbeeld ook alle samenhangende labonderzoeken samengevat in de context van de labuitslag. Dit behoud van context geldt voor het gehele document. 4.2.5 Totaliteit van documenten De inhoud van een klinisch document heeft altijd betrekking op het gehele document, deelinformatie uit het document mag niet zonder link met het document gebruikt worden. 4.2.6 Leesbaarheid In elk CDA document moet de klinische informatie op een leesbare manier zijn opgebouwd. De leesbaarheid van de klinische inhoud voor de menselijke communicatieImplementatiehandleiding HL7v3 Pathologie, v6.1.0.0
15 van 73
partners wordt daardoor gewaarborgd, zodat men dit aandeel in het XML document met eenvoudige middelen (bijvoorbeeld stylesheets) zichtbaar kan maken. Hiervoor geldt het volgende: •
Het moet een deterministische manier zijn voor de ontvanger om de geverifieerde inhoud zichtbaar te maken;
•
De leesbaarheid moet niet inhouden dat een bepaalde stylesheet met het CDA document meegestuurd moet worden. Het moet mogelijk zijn om de inhoud met een unieke stylesheet en op de markt gebruikelijke browsers weer te geven;
•
De leesbaarheid heeft betrekking op de geverifieerde inhoud. Daarnaast kan meer informatie in het document voor handen zijn, die beoogd is voor verwerkbaarheid door de applicatie, maar die niet geverifieerd of leesbaar moeten zijn;
•
Wanneer gestructureerde inhoud afgeleid is van verhalende tekst moet het mechanisme hoe dit bewerkstelligd is, beschreven zijn. Is het een persoon die codes ingevoerd heeft of is het tot stand gekomen door geautomatiseerde bewerking van de natuurlijke spraak door bepaalde software.
•
Wanneer verhalende tekst afgeleid is van gestructureerde informatie moet het mechanisme beschreven zijn hoe dit tot stand is gekomen.
4.3
CDA modelbeschrijving
Net als alle berichtspecificaties is ook de Clinical Document Architecture gebaseerd op het Referentie Informatiemodel en wordt het ook als HL7 versie 3 model gepresenteerd. Grofweg gesproken bestaat een CDA document uit een header en een body. Deze laatste is weer opgebouwd uit body structuren en body entries. Aan deze body entries kunnen externe referenties (External References) geknoopt worden. In Figuur 2 wordt een overzicht van de hoofdcomponenten van CDA release 2 modellen getoond. In Figuur 3 is een gehele XML weergave van de opbouw van een CDA document weergegeven.
Figuur 2 vereenvoudigde weergave van een CDA model
4.4
CDA header
In de header is informatie over de patiënt en over het document zelf vastgelegd, sterk gestructureerd en ook de semantiek is er in vastgelegd. Daarnaast bevat de header informatie over betrokken personen en organisaties en episodes waarover gedocumenteerd wordt. De informatie in de header ondersteunt de uitwisseling van klinische documenten over instituutgrenzen heen. De informatie in de header helpt de documentmanagementsystemen doordat het passende mechanismen ter beschikking stelt.
4.5
CDA body
De echte klinische documentatie wordt in de CDA body vastgelegd. Op de voorgrond staat hier leesbare (verhalende) tekst, hetgeen het verplichtende deel van CDA release 2 documenten is en dat de interoperabiliteit tussen twee menselijke communicatiepartners garandeert. Er wordt hier de mogelijkheid geboden de tekst grof te structureren, zoals men gewend is bij tekstverwerking. Hierbij stelt de standaardspecificatie een rij XML elementen ter beschikking, de body structures.
De body bevat een of meerder secties, die in elkaar geschakeld kunnen zijn, zoals bijvoorbeeld een hoofdstuk en een subhoofdstuk in een boek. Bovendien is structurering in de zin van tabellen of lijsten mogelijk. •
Sectie <section>
•
Paragrafen <paragraph>
•
inhoud
•
Koppen
•
Tabellen
•
Lijsten <list>
Secties bevatten altijd een verhalend blok en vervullen daarmee een van de hierboven genoemde voordelen van CDA: de mens-mens interoperabiliteit, dus de leesbaarheid van informatie voor de mensen. In het verhalende blok, gerepresenteerd door het tekstattribuut in de sectie-klasse, wordt ingebedde tekst binnen een sectie aangeduid. Met de beschreven body structuren, kunnen body entries verbonden worden, deze vertegenwoordigen het computerleesbare deel binnen een documentsectie. Body entries zijn in principe een selectie van klassen samen met attributen uit het HL7 Referentie Informatiemodel. In Figuur 4 is een fragment hiervan weergegeven.
Deze keuzemogelijkheden van activiteiten, ook wel Clinical Statements genoemd, vindt men ook terug in HL7 versie 3 berichten. De keuze bestaat uit de volgende klassen: •
Observation: een (gecodeerde) waarneming, bijvoorbeeld een uitslag of diagnose
•
Procedure: een procedure, bijvoorbeeld een operatie, behandeling of een therapeutische of diagnostische ingreep
•
Encounter: gegevens van eerdere, huidige of geplande patiëntcontacten
•
SubstanceAdministration: informatie over ontvangen geneesmiddelen in de zin van plaatsgevonden of geplande geneesmiddelentoediening.
•
Supply: het verstrekken van geneesmiddelen of ter beschikking stelling van materiaal
•
Organizer: ter groepering van andere CDA entries
•
ObservationMedia: multimedia inhoud als onderdeel van het document
•
RegionOfInterest: kenmerken van geaccentueerde delen van een afbeelding/foto
Al deze entries kunnen lineair of recursief hiërarchisch met elkaar verbonden zijn. Figuur 5 geeft het totale CDA release 2 model weer.
De XML-namespace voor CDA Release 2 documenten is urn:hl7-org:v3. Deze moet op gepaste wijze in iedere XML instance genoemd worden. In deze handleiding wordt geen gebruik gemaakt van namespace voorvoegsels. Voor de pathologie patiënthistorie XML documenten op basis van CDA release 2 is tekenset UTF-8 voorgeschreven (vgl. Implementatiehandleiding HL7v3 Basiscomponenten, v2.0, 31-05-2007, Nictiz). De patiënthistorie XML documenten beginnen met het root element Clinical Document. Hieronder volgt een grove opbouw: …zie beschrijving CDA R2 header <structuredBody> …zie beschrijving CDA R2 Body
De centrale klasse van Clinical Document Architecture modellen is de ClinicalDocument klasse, zie Figuur 6. De bijbehorende attributen worden verderop in deze implementatiegids beschreven. Hiervoor worden XML fragmenten als voorbeelden gebruikt.
Figuur 6 Clinical Document Klasse In de hier onderstaande Tabel 1 wordt een overzicht gegeven van de CDA header elementen die in deze implementatiegids besproken worden. Van deze elementen worden ook hun datatype en cardinaliteiten in de tabel aangegeven. 22 van 73
Persoon wiens medische rapporten in de document zijn opgenomen Auteur
1..* 1..*
dataEnterer
Invoerder van de gegevens
0..1
custodian
Beheerder van het document
1..1
informationRecipient
Ontvanger document
0..*
legalAuthenticator
Wettelijke authenticator
0..1
participant
Betrokkene
0..*
relatedDocument
Relatie met voorgaande documenten
0..*
component
CDA Body Service die wordt gedocumenteerd in het document (Service Event)
1..1
ActRelationship
documentationOf
0..1
Tabel 1 overzicht CDA header elementen gebruikt in deze implementatiegids
5.2
Algemene eisen aan Header
Voor de pathologie patiënthistorie overzichten op basis van CDA Release 2 gelden de volgende algemene eisen: •
De header mag alleen uit de in Tabel 1 genoemde elementen bestaan. Andere elementen zijn niet toegestaan
•
Iedere patiënt moet op basis van het Burger Service Nummer (BSN) geïdentificeerd zijn. Daarnaast moeten naam en geboortedatum van ieder persoon bekend zijn.
•
Elke medewerker moet geïdentificeerd worden op basis van het UZI-nummer.
•
Elke organisatie wordt op basis van het URA-nummer geïdentificeerd.
ClinicalDocument.code (onderdeel van PA nummer) ServiceEvent.code
Pathologie/Anatomie (PA)-nummer
ClinicalDocument.id
Datum autorisatie document
ClinicalDocument.effectiveTime
Start document
ServiceEvent.effectiveTime.low
5.4
Beschrijving Header elementen
5.4.1 Gebruikte HL7 Datatype Nadere informatie over de datatypen en hun gebruik staat geschreven in de Implementatiehandleiding HL7v3 Basiscomponenten, v2.0, 31-05-2007, Nictiz [1]. 5.4.2 Documenten-Id id ................................................................................. documenten identificatie II [1..1] De documenten-id in de pathologie patiënthistorie is een eenduidige identificatie, die het document wereldwijd en voor altijd uniek identificeert. Een CDA document heeft precies één id. Bij deze implementatie wordt als id gebruik gemaakt van het rapportnummer. Dit nummer is opgebouwd uit het type onderzoek gevolgd door het jaartal van ontvangst van de aanvraag met daarachter het PA-nummer en tot slot gevolgd door een versieaanduiding. Opbouw van het rapportnummer:
ojj99999v
24 van 73
beschrijving
o
type onderzoek (B, C, S, T of M)
jj
jaartal (laatste twee cijfers) van ontvangst materiaal
Identificaties zijn van het type Instance Identifier (zie [1]). Het XML-element id levert de XML attributen @extension en @root. Het is verplicht bij identificaties het attribuut @root in te vullen. Met het @root attribuut wordt de makende applicatie van het document geïdentificeerd. Voor de communicatie naar buiten toe moet een OID gekozen worden die uniek is voor de instantie van de applicatie. Voor deze implementatie is het de Stichting PALGA OID 2.16.840.1.113883.2.4.3.23, met als achtervoegsel .3 (voor organisaties) en .nnn voor het pathologie laboratorium nummer. Het @extension attribuut geeft het documentnummer=rapportnummer binnen de applicatie weer. In het volgende voorbeeld heeft de document makende applicatie de OID 2.16.840.1.113883.2.4.3.23.3.20. De applicatie heeft het interne rapportnummer B0700466A aan het document toegewezen. Deze twee nummers tezamen zorgen voor een wereldwijde unieke identificatie.
5.4.3 Type document code ........................................................................................... documenttype CE CWE [1..1] Het attribuut code uit de ClinicalDocument klasse wordt gebruikt om het type document aan te geven. Om te zorgen dat er een eenduidige typering is, wordt hier gebruik gemaakt van het codesysteem LOINC (Logical Observation Identifiers Names and Codes [LOINC]). Gekozen kan worden uit de codes in Tabel 2. Voor de typering van de pathologie documenten worden alleen de codes op level 2 uit onderstaande tabel gebruikt, bijvoorbeeld een “cervix cytologie verslag” wordt als LOINC document code 47527-7 getypeerd. De algemene code voor onderzoeksverslag pathologie (11526-1) wordt niet voor een documenttype zelf gebruikt maar is de enige code die – ondanks het type document op level 2 – bij het LSP wordt aangemeld. Afgesproken is dat bij het opvragen van documenten via het LSP voorlopig alle typen onderzoeksverslagen kunnen worden opgevraagd. Level
LOINC code
Document Type
1
11526-1
Onderzoeksverslag pathologie (wordt niet gebruikt voor ClinicalDocument.code, alleen voor het aanmelden bij het LSP)
Ter typering van het onderzoeksverslag worden dus alleen de LOINC codes uit bovenstaande tabel gebruikt die op level 2 staan. In het XML @code attribuut staat de eigenlijke code, in het @codeSystem attribuut staat de OID van het LOINC systeem (2.16.840.1.113883.6.1). Het optionele @displayName attribuut kan gebruikt worden om de typering in duidelijke bewoording (niet gecodeerde tekst) te beschrijven, maar mag niet door een applicatie worden verwerkt. Het is verplicht om zowel het attribuut @code als @codeSystem te geven.
5.4.4 Aanvullende beschrijving DocumentType title …………………………………………………………………Aanvullende beschrijving documenttype ST [0..1] Dit attribuut is optioneel te gebruiken om het document type te verduidelijken. Hierbij is het mogelijk om bijvoorbeeld de auteur en datum van het verslag te vermelden. Pathologie verslag van dr. Pietersen van 12-09-2007
5.4.5 Autorisatie datum documenten effectiveTime ............................................................. Autorisatie datum document TS [1..1] De verplichte afsluitdatum van het document wordt als tijdstip weergegeven in effectiveTime. De afsluitdatum is de datum waarop het document compleet is en voorzien wordt van een handtekening (de papieren versie), dus de autorisatie datum. Het document kan vanaf dit moment niet meer gewijzigd worden. De afsluitdatum betekent voor de pathologie de datum van autorisatie van het verslag door een patholoog en dat het document is vrijgegeven voor opname in het pathologiedossier. De afsluitdatum effectiveTime moet minimaal op de dag precies zijn. Dit betekent dat er ten minste een jaar, maand en dag zijn aangegeven. Wanneer men ook het exacte tijdstip wil weergeven, kunnen de uren en minuten hier ook worden weergegeven. Bijvoorbeeld: het document wordt op 30 augustus 2007 om 16.30 uur afgerond en voorzien van een handtekening <effectiveTime value="200708301630"/>
5.4.6 Vertrouwelijkheid van de documenten confidentialityCode .......................................................... Vertrouwelijkheidsgraad CE CWE [1..1] 26 van 73
Hier wordt de vertrouwelijkheidgraad van de documenten vastgelegd. De volgende codes zijn toegestaan: Code
Display Name
Nederlands omschrijving
N
Normal
Normale vertrouwelijkheidregels zijn van kracht, d.w.z. alleen geautoriseerde personen hebben toegang tot de gegevens
R
Restricted
Beperkte toegang tot de gegevens, d.w.z. alleen personen met een medische aanstelling hebben toegang tot de gegevens
V
Very restricted
Zeer beperkte toegang, d.w.z. toegang tot de gegevens wordt geregeld door een “privacy officer”
Tabel 3 Vocabulaire domein voor ClinicalDocument.confidentialityCode (OID: 2.16.840.1.113883.5.25) Een normale vertrouwelijkheid wordt zo weergegeven:
5.4.7 Taal van document languageCode ......................................................................... taal van document CS CNE [0..1] Het formaat om de taal aan te duiden is als volgt: ss-CC. ss staat voor de spraakcode, conform ISO-639-1 en CC voor landencode, conform ISO-3166.
Met languageCode in de CDA-header wordt de taal van het totale document aangegeven. 5.4.8 Versie van documenten setId ........................................................................................... set kenmerken II [0..1]
versionNumber ............................................................................. versienummer INT [0..1] Met behulp van setId en versionNumber kan een versiekenmerk worden weergegeven. Ofwel beide attributen komen voor, ofwel beide zijn afwezig. Het element setId kenmerkt de set van documenten, die uit verschillende versies kan bestaan. Dit attribuut blijft voor alle versies van het document hetzelfde, namelijk het rapportnummer (zie boven) zonder vermelding van de versie. Het versienummer versionNumber is een natuurlijk getal voor de doorlopende versietelling. Bij een nieuwe versie wordt dit getal opgehoogd, het setId blijft gelijk. Implementatiehandleiding HL7v3 Pathologie, v6.1.0.0
Een aantal deelnemers wordt ook in de CDA-header beschreven. In deze implementatiegids gaat het om: •
Patiënt (recordTarget)
•
Auteur van het document (author)
•
Beheerder van het document (custodian)
•
Beoogde ontvanger (informationRecipient)
•
Wettelijke verantwoordelijke (legalAuthenticator)
Dit zijn relaties die uitgaan van de ClinicalDocument klasse.
5.5.1 Patient (recordTarget) PatientRole In de CDA-header moet minimaal een patiëntrol beschreven zijn, die door precies één persoon gespeeld wordt. De recordTarget relatie wijst naar de patientklasse en geeft aan welke patiënt het document toebehoort.
Figuur 7 Klasse rondom de patiënt
De PatientRole klasse bevat de volgende attributen: 28 van 73
id .............................................................................. patiënt identificatienummer SET [1..*] Met het XML attribuut @extension wordt de id van de patiënten zelf aangegeven, terwijl het @root attribuut verwijst naar het identificatie uitgevende systeem dat door middel van OID beschreven wordt. In deze implementatiegids wordt het Burger Service Nummer (BSN) als identificatie van de patiënt gebruikt. De OID voor het burger service nummer is: 2.16.840.1.113883.2.4.6.3. Deze id is verplicht. Daarnaast mag een ander identificatie van de patiënt gebruikt worden.
addr ......................................................................................................... adres SET [0..*] Het adres van een patiënt kan hier optioneel worden weergegeven. Adres wordt voor het pathologiedossier voorlopig niet geïmplementeerd. telecom .................................................................................... telecommunicatie SET [0..*] Het telecom attribuut behelst alle telecommunicatiemogelijkheden om in contact te treden met de patiënt. Ook dit attribuut is optioneel. Telecom wordt voor het pathologiedossier voorlopig niet geïmplementeerd.
Patient (entiteit) De rol van patiënt wordt door een persoon gespeeld. De volgende attributen in de entiteit-klasse zijn mogelijk: name ....................................................................................... naam van patiënt SET [0..*] In dit attribuut kan de naam van de patiënt vermeld worden. Verdere toelichting over namen zie [1]. administrativeGenderCode ...................................................................... geslacht CE CWE [0..1]<= AdministrativeGender Het geslacht van de patiënt wordt gecodeerd weergegeven. Hierbij worden de codes van HL7 vocabulaire gebruikt. In het code attribuut wordt de code vermeld, in het codesysteem attribuut wordt met behulp van OID naar het systeem waaruit de code gekozen is, verwezen. Deze is constant 2.16.840.1.113883.5.1.
Tabel 4 vocabulaire domein voor geslacht (OID 2.16.840.1.113883.5.1) birthTime .................................................................................... geboortedatum TS [0..1] De geboortedatum is aan te geven in het value attribuut van het birthTime element. Hierbij wordt het datumformaat van HL7 gebruikt (yyyymmdd). Het XML voor de record target ziet er als volgt uit: <patientRole> <patient> Emma <prefix qualifier="VV">van Oranje
Geboorteplaats patiënt Het kan in sommige gevallen zinvol zijn om de geboorteplaats van de patiënt te vermelden. Dit kan in de klasse BirthPlace en de klasse Place.
Figuur 8 klassen om geboorteplaats weer te geven birthPlace [0..1 ................................................... informatie geboorteplaats patiënt Hierbij moet precies één locatie beschreven zijn in de Place klasse, waarbij de volgende attributen mogelijk zijn: name .................................................................................. naam geboorteplaats EN [0..1] addr ................................................................................... adres geboorteplaats AD [0..1] Adres wordt voor het pathologiedossier voorlopig niet geïmplementeerd.
Spreekvaardigheid patiënt In de klasse LanguageCommunication kan de spreekvaardigheid van de patiënt worden aangegeven. LanguageCommunication wordt voor het pathologiedossier voorlopig niet geïmplementeerd. Voogdij (Guardian) In de klasse Guardian kan melding gedaan worden over de voogdij. Guardian wordt voor het pathologiedossier voorlopig niet geïmplementeerd.
5.5.2 Auteur De auteur relatie geeft de maker van het document en het tijdstip waarop weer. Implementatiehandleiding HL7v3 Pathologie, v6.1.0.0
31 van 73
Figuur 9 klassen rondom de auteur functionCode .......................................................................functie van de auteur CE CWE [0..1]<=ParticipationType In de auteur-participatie wordt met behulp van de functionCode de functie van de auteur aangegeven. Hierbij wordt gebruik gemaakt van het vocabulaire domein ParticipationType. time ........................................................................... tijdstip van documenteren TS [1..1] In dit verplichte attribuut time wordt het tijdstip van documenteren vastgelegd. Informatie over de auteur wordt in de klasse AssignedAuthor weergegeven. Hier vindt men de gebruikelijke weergaven van identificatie, adres en telecom gegevens. id .................................................................................... identificatie van auteur SET [1..*] Het is verplicht een id van de auteur aan te geven. In deze implementatiegids wordt hiervoor het UZI- nummer van de persoon gebruikt. OID is 2.16.528.1.1007.3.1.
addr ......................................................................................................... adres SET [0..*] Optioneel te gebruiken voor het adres van de auteur. telecom .................................................................................... telecommunicatie SET [0..*] Optioneel te gebruiken voor telecomgegevens van de auteur. 32 van 73
Aan de Author klasse zitten twee associaties verbonden: representedOrganization en assigendPerson. Hier wordt de auteur zelf en het laboratorium van de auteur weergegeven. assignedPerson [0..1] ............................................. associatie auteur met persoon representedOrganization [0..1 ........................ associatie met organisatie van auteur
Persoon als auteur De auteur van een document kan zowel een persoon zijn als een apparaat. De rol auteur wordt gespeeld door AssignedPerson wanneer het om een persoon gaat. Deze klasse biedt de mogelijkheid om de auteur verder te specificeren door het weergeven van de naam. name ............................................................................................. Naam auteur SET [0..*] Apparaat als auteur Wanneer de auteur een apparaat is die de informatie geleverd heeft, dan wordt de auteur rol gespeeld door AssignedDevice. Bij deze implementatie komt deze situatie niet voor en is de auteur altijd een persoon. De door de auteur vertegenwoordigde organisatie In de representedOrganization klasse kan de organisatie die door de auteur vertegenwoordigd wordt nader gespecificeerd worden. Bij deze implementatie is dat altijd een pathologie laboratorium. Het attribuut id is verplicht aan te geven, het URAnummer. id ............................................................................. identificatie van organisatie II [1..*] name ....................................................................................... Naam organisatie ON [0..*] telecom .................................................................................... telecommunicatie TEL [0..*] addr ........................................................................................ adres organisatie AD [0..*]
5.5.3 Beherende organisatie (Custodian) De organisatie die verantwoordelijk is voor het beheer van de documenten moet verplicht in de overeenkomstige klasse weergegeven worden. Bij deze implementatie is dit altijd een pathologie laboratorium.
Figuur 10 klassen rondom de beherende organisatie id ............................................................................. identificatie van organisatie SET [1..*] De organisatie moet minimaal gekenmerkt worden door één id, het URA-nummer. Andere attributen als naam, telecom en adres zijn optioneel. name ....................................................................................... Naam organisatie 34 van 73
ON [0..*] telecom .................................................................................... telecommunicatie TEL [0..*] addr ........................................................................................ adres organisatie AD [0..*] <custodian> Academisch Medisch Centrum, Amsterdam <streetName>Meibergdreef 9 <postalCode>1100 DD Amsterdam
5.5.4 Beoogde ontvanger (IntendedRecipient) De beoogde ontvanger van de documenten kan in de klasse IntendedRecipient nader aangegeven worden. Hierbij moet men in acht nemen dat het om de direct bij het opstellen van het document beoogde ontvanger gaat. Het gaat hier niet om mogelijke ontvangers van een kopie van het document, tenzij deze al bij het opstellen van het document bekend zijn. Voorbeelden van ontvangers zijn de patiënt zelf of de organisatie die het laboratorium onderzoek heeft aangevraagd.
Figuur 11 klassen rondom beoogde ontvanger
typeCode ................................................ Type ontvanger <= InformationRecipient In het attribuut @typeCode van de participatie kan worden aangegeven om het om een primaire ontvanger gaat of om een secundaire (cc) ontvanger gaat.
Een ontvanger die tevens het document ontvangt (cc, kopie)
Tabel 5 Vocabulaire domein voor InformationRecipient Wanneer de beoogde ontvanger een persoon is dan wordt dit duidelijk gemaakt door de aanwezigheid van de Person klasse met eventueel de betrokken organisatie erbij gespecificeerd. Wanneer de beoogde ontvanger een organisatie is dan wordt slechts de organisatie vermeld. KarelOogappel <streetName>Ziekenhuisweg 23 <postalCode>6734 WR Assen
5.5.5 Ondertekenaar (legalAuthenticator) Documenten kunnen een ondertekenaar bevatten. Het gaat hierbij om een ondertekenaar die voor de wet verantwoordelijk is (legalAuthenticator). Deze is hier verplicht. Daarnaast kunnen er andere ondertekenaars zijn (authenticator). Deze worden bij deze implementatie niet gebruikt. Beide betrokken klassen hebben de volgende attributen: time ............................................................................. tijdstip van ondertekenen TS [1..1] Het is verplicht om het tijdstip van ondertekenen weer te geven. signatureCode .............................typering ondertekening <= ParticipationSignature 36 van 73
CS CNE [1..1] Hiermee wordt aangeduid welk type handtekening wordt of is geplaatst. Dit is niet de handtekening of een digital signature zelf. De toegestane waarden voor typering handtekening zijn: Code
Display Name
Nederlands omschrijving
I
Intended
Er is beoogd dat er een handtekening wordt geplaatst
S
Signed
Handtekening is beschikbaar, ofwel op papier gezet ofwel digitaal
R
Required
Handtekening is vereist
Tabel 6 Vocabulaire domein voor ParticipationSignature
Figuur 12 klassen rondom authenticator/legalAutenticator
De klasse AssignedEntity bevat informatie over de ondertekenaar en heeft de volgende attributen: id………………………………………………………………………………………………id van de ondertekenaar SET [1..*] Het is verplicht om de id van de ondertekenaar te vermelden. Als id wordt het UZInummer gebruikt. Optioneel kan men het adres en telecommunicatiegegevens van de ondertekenaar vermelden. addr………………………………………………………………………………………………adres ondertekenaars SET [0..*]
telecom…………………………………………………………………………………………………telecommunicatie SET [0..*]
Persoon als ondertekenaar De rol van ondertekenaars wordt gespeeld door de verplicht aan te geven AssignedPerson. Deze kan verder gespecificeerd worden door namen van de personen te vermelden. Bij deze implementatie betreft het de patholoog die het document ondertekent als het compleet is. name ……………………………………………………………………………………na(a)m(en) ondertekenaar SET [0..*] 5.5.6 Personen bij data invoer (dataEnterer) In de associatie dataEnterer kunnen de personen die betrokken zijn bij het invoeren van de gegevens gespecificeerd worden. In de klasse AssignedEntity kan de id, adres en telecommunciatiegegevens weergegeven worden. Deze personen worden in de huidige situatie niet vastgelegd. 5.5.7 Overige betrokkenen Met deze associatie en de overeenstemmende klassen kunnen overige bij de documentatie betrokken personen of organisaties beschreven worden. Bij deze implementatie wordt hier verder geen aandacht aan besteed. 5.5.8 Relatie met voorgaande documenten (ParentDocument) De relatie met voorgaande documenten met dezelfde documentklasse wordt door middel van de relatedDocument relatie en de ParentDocument klasse, tezamen met setId en versionNumber uit de ClinicalDocument klasse gespecificeerd.
Figuur 13 ClinicalDocument en ParentDocument klasse Is een document verstuurd (geregistreerd) en moet het door een ander document vervangen worden, dan wordt uitsluitend het vervangingsdocument van het oorspronkelijke document gebruikt en gecommuniceerd. Het bevat een nieuwe ClinicalDocument.id, evenwel bevat het nieuwe document hetzelfde setId als het oorspronkelijke document en het versienummer wordt met 1 opgehoogd.
Het oorspronkelijke document is in het kader van documentmanagement belangrijk en hierdoor blijft ook een begrijpelijke documenthistorie in het systeem voor handen. In dit geval wordt de relatie tussen het ParentDocument en ClinicalDoument vastgelegd door in @typeCode van relatedDocument “RPLC” te vermelden. Mogelijke waarden voor @typeCode staan in de onderstaande tabel.
Code
Display Name
Nederlands omschrijving
APND
Appends
Een toevoeging aan een bestaand bericht, die de totale informatie bevat. Status van het oorspronkelijke document blijft ongewijzigd. Dit wordt vooralsnog niet gebruikt.
RPLC
Replaces
Een vervangingsbericht vervangt het oorspronkelijke bericht. De status van het te vervangen bericht wordt op achterhaald gezet. Het oorspronkelijke bericht blijft als historisch referentie beschikbaar.
XFRM
Transformed
Het document is een resultaat van een transformatieproces, d.w.z. het is uit een ander origineel document voortgekomen. Dit wordt vooralsnog niet gebruikt.
Tabel 7 Vocabulaire domein voor relatedDocument.typeCode
5.5.9 Informatie over type en tijdstip onderzoek (ServiceEvent) In de klasse ServiceEvent wordt het type onderzoek en de tijdstip van onderzoek gespecificeerd.
Figuur 14 ServiceEvent klasse We gebruiken hiervoor de codering die het type onderzoek aangeeft (PALGA service types, OID 2.16.840.1.113883.2.4.3.23.5.1). code ......................................................................................... type onderzoek CE CWE [1..1]
Tabel 8 Vocabulaire domein voor ServiceEvent.code (OID: 2.16.840.1.113883.2.4.3.23.5.1) De datum waarop het document gestart wordt en komt overeen met het begin van het onderzoek. De datum wordt weergegeven in het attribuut effectiveTime van de klasse ServiceEvent en is verplicht.
effectiveTime ..................................................................... periode van onderzoek IVL [1..1] Het element low geeft het moment aan waarop het onderzoek gestart wordt en er met het verslagdocument begonnen is, high geeft het moment aan waarop het onderzoek eindigt en het document klaar is en voorzien wordt van een handtekening. Hierna kunnen er geen wijzigingen meer worden aangebracht. <documentationOf> <serviceEvent> <effectiveTime>
6 CDA R2 body Terwijl er in de CDA header de auteur en andere meer administratieve dingen beschreven worden, worden in de CDA body de daadwerkelijke klinische documenten beschreven. De body bestaat uit een structuredBody element, die weer section elementen laat zien, waarmee de informatie gestructureerd kan worden. Grofweg ziet de structuur er als volgt uit: ……zie beschrijving CDA R2 header <structuredBody> …CDA R2 Body
6.1
Algemene opbouw body
De structuredBody van een CDA release 2 document is opgebouwd uit een of meerdere componenten, waarbij iedere component wederom uit een of meerdere secties bestaat en indien nodig uit een of meerdere entry elementen (level 1 t/m 3). Elk Clinical Document moet minimaal één section element bevatten. Elke sectie moet precies één text element bevatten dat niet leeg mag zijn. text ......................................................................................... verhalende tekst ED [0..1]
Figuur 15 sectie-klasse met bijbehorende attributen. Secties kunnen ook subsecties (componenten) bevatten wanneer ze aaneengeschakeld worden.
In de regel zijn de secties voorzien van codes. Bij deze implementatie hebben we te maken met 3 typen secties: •
Tekst in de sectie, die niet met behulp van codes geïdentificeerd worden, binnen een sectie met optionele ondersecties (zie level 1 hieronder).
•
Tekst in secties, die met codes geïdentificeerd zijn, binnen een sectie met optionele ondersecties (zie level 2 hieronder).
•
Tekst in secties en ondersecties, aangevuld met gecodeerde notities volgens de RIM klassen (zie level 3 hieronder).
6.2
Levels
Het CDA level representeert de onderscheidende fijnheid van het weergeven van klinische informatie en de machine bruikbare Markups. 6.2.1 Level 1 Met level 1 wordt een XML document gekenmerkt dat voor alle menselijke interoperabiliteit bedoeld is, dus die makkelijk toegankelijk voor menselijk gebruik gemaakt kunnen worden, bijvoorbeeld door Stylesheets. Het geeft geen beperkingen in het gebruik of nut van de documenten en heeft geen invloed op de inhoud. De technische eisen om level 1 documenten te maken of te verwerken zijn verhoudingsgewijs gering. Uit het oogpunt van dataverwerking is level 1 een niveau van informatie, waarbij de mens-mens interoperabilteit gewaarborgd wordt. Section.title ....................................................................................... sectie titel ST [0..1] Het sectie element bevat daardoor slechts een optionele titel, alsook een verplicht aan te geven tekst die de verhalende uitvoering van klinische documenten beschrijft. 42 van 73
<section> Klinische gegevens Rectosigmoid resectie. Rectumcarcinoom bij status na lage dosering en radiotherapie. Nu anterior resectie. Vraagstelling: histologie, radicaliteit, lymfkliermetastasen?
6.2.2 Level 2 Level 2 documenten zijn, net als level 1 documenten waarbij aanvullend de sectie geclassificeerd wordt. De identificatie van de sectie is ook voor de applicaties toegankelijk, d.w.z. machine uitwisselbaar. Dit wordt bereikt door de associaties van de secties van een code te voorzien. Bij deze implementatie worden uitsluitend LOINC codes gebruikt voor het classificeren van de documentsecties. Section.code ................................................................................ sectie typering CE CWE [0..1] Het sectie element bevat een code element waarin de inhoud van de sectie geclassificeerd wordt. <section> Klinische gegevens Rectosigmoid resectie. Rectumcarcinoom bij status na lage dosering en radiotherapie. Nu anterior resectie. Vraagstelling: histologie, radicaliteit, lymfkliermetastasen?
6.2.3 Level 3 CDA documenten die ook level 3 conform zijn, bevatten machine uitwisselbare componenten op het niveau van afzonderlijke informatie, bijvoorbeeld een diagnose, die overeenkomen met de RIM klassen. Een applicatie kan hierdoor afzonderlijke observaties, procedures, etc identificeren en verwerken.
<section> Klinische gegevens Rectosigmoid resectie. Rectumcarcinoom bij status na lage dosering en radiotherapie. Nu anterior resectie. Vraagstelling: histologie, radicaliteit, lymfkliermetastasen? <entry> HL7 versie 3 RIM klassen (observation,...) met codes
6.3
Classificeren secties met LOINC codes
Door de aparte secties worden de algemene categorieën van een pathologie rapport gestructureerd. Op level 2 krijgen de secties een LOINC code. Tabel 9 toont de LOINC van secties. Pathologie item
Als CDA entry kan gekozen worden uit de volgende RIM klassen: CDA Entry
Betekenis
Pathologie
Observation
Algemene of specifieke waarneming
Onderzoeken, diagnosen
ObservationMedia
Media-informatie ter observatie
n.v.t.
Procedure
Procedure, ingrepen die de patiënten veranderen
n.v.t.
RegionOfInterest
Focus informatie
n.v.t.
SubstanceAdministration
Voorschrijven van geneesmiddelen, hulpmiddelen
n.v.t.
Supply
Toedienen, ter beschikking stellen van geneesmiddelen, hulpmiddelen
n.v.t.
Encounter
Contact met de patiënt
n.v.t.
Act
Generieke activiteit
n.v.t.
Organizer
Groepering van CDA entries
Groepering en rangschikmogelijkheid diagnosen
Tabel 10 CDA Entry klassen (n.v.t. betekent dat de klasse vooralsnog niet gebruikt wordt in deze handleiding).
6.5
Tekststructuren
De tekst zelf kan structuurelementen bevatten. Deze kunnen gebruikt worden om tabellen of lijsten te definiëren. Tekststructuren worden voorlopig niet geïmplementeerd, met als uitzondering paragrafen, inhoudreferenties en aanduidingen voor nieuwe regels. 6.5.1 Lijsten Lijsten worden gebruikt voor een eenvoudige opsomming van medische inhoud. Deze vorm wordt bij deze implementatie niet gebruikt en zal niet verder worden toegelicht.
6.5.2 Tabellen Er bestaat de mogelijkheid om de medische inhoud in tabelvorm te presenteren. Deze vorm wordt bij deze implementatie niet gebruikt en zal niet verder worden toegelicht.
6.5.3 Inhoudreferenties (content) Het CDA content element wordt gebruikt om tekst uitdrukkelijk met tags te “omlijsten” zo dat de inhoud gereferenceerd kan worden. Dit element wordt in deze handleiding alleen gebruikt om de diagnosecodering en teksten te omlijsten. Het content element bevat een identificatie attribuut dat als doel voor een XML referentie kan dienen. Al deze XML referenties worden als XML IDs gedefinieerd en dienen binnen het document uniek te zijn. Het originalText component van een RIM klasse (in de CDA entries) kan op die manier eenduidig naar een stuk omsloten tekst wijzen. ... Palga-codes1: T01000* TY02000* P11200* M27250 ...
Meer voorbeelden zijn bij de diagnose te vinden. 6.5.4 Paragrafen Ter structurering van langere teksten (alinea’s) wordt de paragraph tag gebruikt. <paragraph> Celrijk materiaal waarin losliggende en groepen dissocierende wanordelijk gelegen sterk atypische cellen met vergrote, polymorfe en hyperchromatische kernen, forse anisonucleose, prominente nucleoli, grof chromatinepatroon en zeer onregelmatig en soms verhoornend cytoplasma. <paragraph> Daarnaast veel granulocyten, lymfocyten, cylinderepitheelcellen en veel bloed.
6.5.5 Nieuwe regels Het br element kann worden gebruikt om een lijn “hard” af te breken (zonder een nieuwe paragraaf te beginnen). Het verschil met een paragraaf (zie boven) is dat een nieuwe regel geen inhoud heeft. Ontvanger dient dit als een nieuwe regel te vertonen.
Rectosigmoid resectie. Rectumcarcinoom bij status na lage dosering en radiotherapie. Nu anterior resectie. Vraagstelling: histologie, radicaliteit, lymfkliermetastasen?
6.6
Mapping medisch inhoud naar CDA body
Voor de verschillende onderzoekstypen (terug te vinden in het type document, gecodeerd in LOINC) worden er bepaalde CDA sections, ook gecodeerd met LOINC gebruikt. De volgende tabel geeft een overzicht over het type document, de aanwezigheid van bepaalde secties met hun cardinaliteiten. De secties worden vervolgens beschreven. Document type
Klinische Gegevens
Macroscopie
Microscopie
Epikrise
Protocol
Conclusie
Diagnosen
22636-5
22634-0
22635-7
33746-9
34122-2
22034-4
22637-3
Cervix cytologie verslag
0..1
0..1
0..1
0..0
0..1
1..1
1..1
Non gyn. cytologie verslag (overige cytologie)
0..1
0..1
0..1
0..0
0..1
1..1
1..1
Obductie verslag
0..1
0..1
0..1
0..1
0..1
1..1
1..1
Histologie verslag
0..1
0..1
0..1
0..0
0..1
1..1
1..1
Moleculair onderzoeksverslag
0..1
0..1
0..1
0..0
0..1
1..1
1..1
Tabel 11 Samenhang tussen secties en documenttypen (onderzoekstypen).
6.6.1 Klinische gegevens (inclusief vraagstelling) Deze sectie (LOINC code voor sectie: 22636-5) bevat de klinische gegevens die onderdeel uitmaken van de patiënthistorie. De klinische gegevens bestaat uit de tekst van de aanvraag van het onderzoek en is vrije tekst. In XML ziet het er als volgt uit:
<section> Klinische gegevens Rectosigmoid resectie. Rectumcarcinoom bij status na lage dosering en radiotherapie. Nu anterior resectie. Vraagstelling: histologie, radicaliteit, lymfkliermetastasen?
6.6.2 Macroscopie In deze sectie (LOINC code voor sectie: 22634-0) staat het resultaat van het macroscopisch onderzoek beschreven in vrije tekst. In XML ziet het er als volgt uit: <section> Macroscopie Aantal inzendingen: 1. Diepte preparaat: low anterior resectie. Lengte preparaat: 14 cm. Kwaliteit TME: resectie op de mesorectale fascie. Proximale omslagplooi: op 11 cm van het distale sneevlak.
6.6.3 Microscopie Hier wordt het resultaat van het microscopisch onderzoek beschreven (LOINC code voor sectie: 22635-7). Dit vindt plaats met vrije tekst. In XML ziet het er als volgt uit:
<section> Microscopie Tumor type (WHO) : Adenocarcinoom Differentiatiegraad : Goed Diepste doorgroei tumor reikend tot in : peri-rectale vet Angioinvasie : Nee Darm resectievlak : Vrij Overige mucosa : Geen afwijking
6.6.4 Conclusie De conclusie (LOINC code voor sectie: 22034-3) van het uitgevoerde onderzoek wordt hier in vrije tekst beschreven en ziet er in XML als volgt uit: <section> conclusie Low anterior resectie na korte voorbestraling: hoog in het rectum gelokaliseerd, goed gedifferentieerd adenocarcinoom; oppervlakkige doorgroei in het perirectale vet; sneevlak vrij (Afstand tot CRM 20 mm); Totaal 16 lymfklieren waarvan 1 met een metastase. Geen angio-invasieve groei.
6.6.5 Diagnose De diagnose wordt naast in level 1 en 2 ook gecodeerd in level 3 weergegeven. Indien de verhalende tekst van de diagnose (tekst element in level 2, LOINC code voor sectie: 22637-3) ook met behulp van codes kan worden weergegeven, wordt dit gedaan met het attribuut @typeCode in het entry element te voorzien van DRIV (derived from).
De diagnose wordt door de pathologen als volgt weergegeven: Diagtekst1: gevolgd door diagnosetekst-a*diagnosetekst-b*diagnosetekst-c Implementatiehandleiding HL7v3 Pathologie, v6.1.0.0
49 van 73
Palga-Codes1: gevolgd door PALGAcode-a* PALGAcode-b* PALGAcode-c Dit gedeelte vindt men precies zo terug in level 2. Een voorbeeld: <section> Conclusie: <paragraph>Excisie verruca seborrhoica rechter slaap. <paragraph> Diagtekst1: huid*gelaat*excisie*verruca seborrhoica Palga-codes1: T01000* TY02000* P11200* M27250
De weergave kan er als volgt uitzien:
Daarnaast worden de PALGA codes ook in level 3 weergegeven in het value attribuut van de Observation klasse. Pathologie item
CDA
Cardinaliteit
Diagnoseregelnummer
Level 2: Section.text
[1..*]
Level 3: Organizer.component.sequenceNumber
[1..*]
Diagnosetekst
Level 2: Section.text
[1..*]
PALGA-codes
Level 3: Observation.value
[1..*]
Voor de codering wordt gebruik gemaakt van de PALGA-codes, gedefinieerd in de thesaurus van PALGA [PALGC]. Diagnose is een speciale vorm van een observatie en die RIM klasse uit het CDA model wordt dan ook in level 3 gebruikt.
Figuur 16 Observatie klasse CDA model voor het aangeven van een gestructureerde diagnose
classCode .............................................................................. class code <= OBS De class code van de gespecificeerde diagnose is OBS (observation). moodCode ............................................................................ mood code <= EVN De mood code van de gespecificeerde diagnose is EVN, aangezien de observatie reeds heeft plaatsgevonden. id ................................................................... uniek diagnose identificatieummer SET [0..*] Het is mogelijk om elke op zichzelf staande diagnose binnen een systeem een identificatienummer te geven. Op dit moment wordt geen gebruik gemaakt van deze mogelijkheid. code ........................................................................................typering diagnose CD CWE [1..1] <= DX Hier wordt door middel van de vaste waarde (DX) aangegeven dat het om een diagnose gaat. negationInd ....................................................................... aanduiding ontkenning BL [0..1] Wanneer deze waarde op true gezet wordt, betekent dit dat een bepaalde diagnose expliciet wordt uitgesloten. text ........................................................................................... uitleg diagnose ED [0..1] Hier kan een toelichting op de diagnose gegeven worden. Let op: gebruik dit niet om de diagnose in vrije tekst weer te geven.
De statuscode heeft hier altijd de waarde completed, aangezien het om een afgeronde observatie gaat. effectiveTime ................................................................. tijdsaanduiding diagnose IVL [0..1] Tijdsaanduiding van wanneer de diagnose gesteld is. In de regel is dit een interval, maar in de praktijk wordt vaak alleen de ondergrens met het element low gebruikt, tijdstip van diagnose stelling, tijdsmoment vanaf waar de diagnose geldig is. <effectiveTime>
Voor de pathologie is dit de datum autorisatie door patholoog. value ............................................................................................diagnose code CD [0..1] <= PALGACode Hier wordt de eigenlijke diagnose gecodeerd aangegeven. Hiervoor wordt de PALGAcodering (OID: 2.16.840.1.113883.2.4.3.23.5.2) gebruikt. Wanneer er meerdere PALGA codes gebruikt worden, dan moet de hele observatie klasse herhaald worden. Daarnaast wordt er gebruik gemaakt van de klasse Organizer ter groepering van de diagnosen. De diagnosen zijn componenten waarbij het sequenceNumber element de volgorde van de codes weergeeft. De Organizer wordt altijd gebruikt, dus ook als er maar één diagnose code is.
Figuur 17 Organizer klasse CDA model voor het groeperen van de gestructureerde diagnosen
classCode ....................................................................... class code <= CLUSTER De class code van de groepering is CLUSTER (cluster). moodCode ............................................................................ mood code <= EVN De mood code van de gespecificeerde groepering is EVN. statusCode ..................................................................status code <= completed De statuscode heeft hier altijd de waarde completed.
In de relatie met de component klasse (@typeCode = COMP) wordt de verbinding gelegd naar de diagnosen. Daarbij wordt in component.sequenceNumber de volgorde van de diagnosen aangegeven. component typeCode ................................... typering van de component <= COMP De @typeCode is hier altijd COMP. component.sequenceNumber .................................. volgorde van de diagnose code INT [1..1] Met het element sequenceNumber wordt de volgorde aangeduid. Het volgende voorbeeld toont vier diagnosen die door een Organizer gegroepeerd zijn. <entry typeCode="DRIV"> <statusCode code="completed"/> <sequenceNumber value="1"/> … <sequenceNumber value="2"/> … <sequenceNumber value="3"/> … <sequenceNumber value="4"/> …
Hieronder volgt een XML voorbeeld, waaruit de samenhang tussen level 2 en 3 naar voren komt:
6.6.6 Epicrise (Obductie) Wanneer er een obductie heeft plaatsgevonden kan er een epicrise zijn. Dit is een beschrijving van alles wat men tegenkomt bij de obductie en is vrije tekst in level 2 (LOINC code voor sectie: 33746-9). Binnen de pathologie worden vier typen obductie onderscheiden.
Tabel 12 Vier typen obductie PALGA types obductie (OID 2.16.840.1.113883.2.4.3.23.5.3). Op level 2 wordt in de sectie code aangegeven dat het om een obductie gaat. Op level 3 niveau wordt het type obductie in code van de Act klasse op een gecodeerde manier aangeduid. classCode .............................................................................. class code <= ACT De class code van is ACT. moodCode ............................................................................ mood code <= EVN De mood code van is EVN. code ........................................................................................ typering obductie CD CWE [1..1] <= PALGA types obductie De code als aanduiding van het type obductie (tabel zie boven). statusCode ..................................................................status code <= completed De statuscode heeft hier altijd de waarde completed.
Figuur 18 Act klasse CDA model om het type obductie aan te duiden
... Epicrise Obductie werd verricht op een 71 jarige patiente die circa een week voor overlijden een cardiochirurgische ingreep onderging met mitraalklep plastiek en aortaklepvervanging. Enkele dagen postoperatief ontstonden er ritmestoornissen, koorts en het beeld van sepsis waarna patient overleed. ... <entry typeCode="DRIV"> <statusCode code="completed"/> ...
6.6.7 Protocol Het merendeel van de onderzoeken wordt uitgevoerd op basis van een set richtlijnen en protocollen. Ook de registratie en verslaglegging van het onderzoek kan voorgeschreven zijn en separaat zijn vastgelegd en bruikbaar voor gegevensuitwisseling: protocolnaam, protocoldata en protocollaire verslaglegging. De protocollen worden in level 2 beschreven (LOINC code voor sectie: 34122-2). In XML ziet het er als volgt uit: <section> protocol Protocolnaam: ........... Protocoldata: ........... Protocollaire beschrijving: ...........
7 Document management De pathologen stellen reeds jarenlang eerdere onderzoeksgegevens van een patiënt aan elkaar ter beschikking bij aanvang van een nieuw onderzoek voor die patiënt. Nu gaat het gerealiseerd worden door gebruik te maken van een gedeelde Clinical Document Directory, het Landelijk Schakelpunt (LSP). De pathologen melden aan het LSP dat een onderzoeksverslag (“uitslag”) beschikbaar is. Daarbij wordt de inhoud van de uitslag niet meegestuurd.
7.1
Dynamisch model
Het dynamisch model beschrijft het werkproces van de pathologen en de momenten waarop er iets met het document moet gebeuren. 7.1.1 Storyboards Pathologen van een pathologie laboratorium doen onderzoek en leggen de bevindingen, diagnosen en conclusie vast in een onderzoeksrapport. Wanneer het onderzoek met een conclusie is afgesloten, wordt het onderzoeksrapport geautoriseerd door de patholoog (“zet handtekening”). Hierna kan de inhoud van het onderzoeksrapport niet meer gewijzigd worden. Is wijziging/aanvulling noodzakelijk dan wordt een nieuwe versie van het onderzoeksrapport aangemaakt. De oude versie blijft ongewijzigd. Na het autoriseren van de uitslag door de patholoog wordt de uitslag aangemeld bij het Landelijke Schakelpunt voor de betreffende patiënt. De inhoud van de uitslag blijft in het laboratorium. Als het vigerende onderzoek wordt afgerond en de uitslag geautoriseerd wordt ook deze uitslag bij het Landelijke Schakelpunt aangemeld en is dan beschikbaar t.z.t. voor opvragen van pathologiehistorie. Voorbeeld: Pathologie lab X heeft voor patiënt A een pathologie verslag als Clinical Document met als type “Histologie groot” (ClinicalDocument.code LOINC 22036-8) en de identificatie T0760123A aangemaakt. Bij het Landelijk Schakelpunt (LSP) wordt vervolgens de categorie “pathologie gegevens” (LOINC code 11526-1) aangemeld. Daardoor wordt publiek gemaakt dat pathologie lab X over pathologie gegevens voor patiënt A beschikt (categorale aanmelding). Voor deze aanmelding wordt een registratie act geconstateerd die een aparte id heeft om de registratie altijd te kunnen wijzigen of in te trekken.
Figuur 19 Samenhang tussen Clinical Document (pathologie verslag) en aanmelden bij het LSP. Aangemeld wordt alleen het feit dat pathologie lab X over pathologie gegevens beschikt. Op basis van de informatie in het LSP kunnen vragen naar documenten worden doorgestuurd naar de bron die de query afhandelt. De vertoonde gegevens van het LSP zijn een uittreksel van de daadwerkelijk opgeslagen items.
Vervolgens kunnen pathologie verslagen als documenten worden opgevraagd door een “find document metadata and content” query naar het LSP te sturen. In de pathologie staat deze procedure van opvragen momenteel bekend onder de aanduiding “PatiëntenZoekVraag”. Uit het oogpunt van document management is dit meer generiek geformuleerd een “find document metadata [and content]” (zie hieronder). Als parameter wordt het BSN van de patiënt aangegeven. Voor aanvullende parameter zie later in dit hoofdstuk. Het LSP stuurt de vraag op basis van de categorale aanmelding door naar alle pathologie laboratoria die over pathologie verslagen beschikken en deze hebben aangemeld. De ontvanger van de query kunnen op basis van de query parameters filteren. Als antwoord worden alle documenten teruggestuurd die aan de filter criteria voldoen. Bij aanvang van een ieder pathologieonderzoek wordt door degene, die het onderzoek initieel registreert binnen het laboratorium een vraag gesteld aan het Landelijk Schakelpunt, of voor de betreffende patiënt in andere pathologielaboratoria uitslagen beschikbaar zijn. De initiële registratie geschiedt door secretaresse of analist in opdracht van het hoofd van het pathologielaboratorium. De complete pathologiehistorie (“uitslagen”) van de betreffende patiënt wordt vanuit de andere laboratoria via het LSP ter beschikking gesteld van het aanvragend laboratorium en voor gebruik tijdens het onderzoek tijdelijk opgenomen bij het onderzoeksrapport. Wanneer een aanvulling op het onderzoek is uitgevoerd en een nieuwe versie van de uitslag beschikbaar komt, wordt deze nieuwe versie van de uitslag bij het LSP aangemeld (replacement).
In uitzonderlijke gevallen kan de patholoog de beschikbaarheid van een uitslag bij het LSP intrekken (cancel). Bijvoorbeeld als een uitslag aan een verkeerde patiënt is gekoppeld binnen het laboratorium. Samengevat zijn er dus de volgende interacties tussen pathologie labs en het LSP nodig: • Registreren van een pathologie verslag (Directory Original Document Registration Request) • De vraag naar een pathologie verslag (Find Document Metadata and Content Query) • Het antwoord op de vraag naar een pathologie verslag (Find Document Metadata and Content Response) • Vervangen van een pathologie verslag (Directory Replacement Registration Request) • Intrekken van een pathologie verslag (Document Cancel Notification).
7.1.2 Interactieschema In de domein “Medical Record” zijn een aantal interacties gedefinieerd die de bovenstaande functies vervullen. In Nederland wordt in verband met het Landelijk schakelpunt het registreren, vervangen en intrekken van een pathologie verslag niet met de in de Medical Record domein gedefinieerde interacties doorgevoerd maar met generieke Act Registry interacties zoals in de “Implementatiegids Generieke Berichten” [5] beschreven: • MFMT_IN002101 Activate Act Reference • MFMT_IN002102 Revise Act Reference • MFMT_IN002103 Nullify Act Reference Voor vraag naar pathologie verslagen en het antwoord daarop worden de betreffende Medical Record interacties (Nederlands versie) gebruikt: • RCMR_IN000031NL Find Document Metadata and Content Query • RCMR_IN000032NL Find Document Metadata and Content Response Hieronder staan de interacties weergegeven die er tussen de pathologielaboratoria en het LSP plaatsvinden.
Figuur 20 Interactieschema 7.1.3 Applicatierollen Er zijn in feite drie applicatie rollen: •
Clinical Document Directory (RCMR_AR 000005NL) Deze applicatie rol, ingevuld door het LSP, beheert een directory van complete klinische documenten die opgeslagen zijn in de document management systemen van de aangesloten organisaties (de pathologie laboratoria in dit geval).
•
Document Originator (RCMR_AR000001NL) Deze applicatie rol ondersteunt het tot stand komen van het document en brengt de documenten en wijzigingen in de status van documenten over naar andere applicaties. De rol wordt ingevuld door de document management systemen van de pathologie laboratoria
•
Document Recipient (RMCR_AR000004NL) Deze applicatie rol ontvangt status wijzigingen en documenten van een document management systeem. Deze documentontvangers kunnen (en in dit geval zijn) op hun beurt ook document management systemen, namelijk die van de pathologie laboratoria.
7.2
Aanmelden, vervangen en intrekken
Zoals gezegd wordt aanmelden, vervangen en intrekken van pathologie verslagen door gebruik van generieke Act Registry berichten gedaan. In [5] is een modelbe60 van 73
schrijving in het geval van categorale aanmelding gegeven. In het geval van pathologie verslagen zijn de volgende attributen van de klasse ActReference gebruikt. classCode ........................................................................................... class code Het verplichte classCode attribuut is altijd de CATEGORY (categorale aanmelding). moodCode ......................................................................................... mood code Het moodCode attribuut is in dit geval altijd EVN (event). Voorbeeld
id ...............................................................................................identificatie (II) De identificatie van de registratie Act. De categorale aanmelding is een aparte act waar een id (aanmeldnummer) verplicht is. Dit dus niet de ClinicalDocument.id. Voorbeeld
code ............................................................................... typering document (CE) Het code attribuut is gelijk de typering van het soort gegevens. Dit is hier altijd de LOINC code voor (generieke) pathologie verslagen. Nota bene: er worden geen subtypes zoals cervix cytologie aangemeld maar alleen generieke pathologie verslagen (LOINC code 11526-1). Voorbeeld
statusCode ................................................................. status code document (CS) Dit is bij het aanmelden en vervangen van pathologie documenten “completed”, in het geval van intrekken wordt dit “nullified”. Voorbeeld <statusCode code="completed"/>
effectiveTime .................................................................. aanmelddatum (IVL_TS) Het begin en/of eindtijdstip van de aanmelding. Bij het aanmelden van een registratie Act bij de ZIM is het te gebruiken datatype IVL. Voorbeeld <effectiveTime xsi:type="IVL_TS">
7.2.1 Activate Act Reference (MFMT_IN002101) Voor het registreren van een pathologie verslag (in het Medical Record domein “Directory Original Document Registration Request”) wordt interactie MFMT_IN002101 gebruikt. Voorbeeld ... <statusCode code="completed"/> <effectiveTime xsi:type="IVL_TS"> <patient> ... ... ... ...
7.2.2 Revise Act Reference (MFMT_IN002102) Voor het vervangen van een pathologie verslag (in het Medical Record domein “Directory Replacement Registration Request”) wordt Interactie MFMT_IN002102 gebruikt. 7.2.3 Nullify Act Reference (MFMT_IN002103) Voor het intrekken van een pathologie verslag (in het Medical Record domein “Document Cancel Notification”) wordt Interactie MFMT_IN002103 gebruikt.
7.3
Statisch model voor vraag en antwoord bericht
Het message model voor klinische documenten is een subset van het domein model Medical Records (RCMR_RM00005UV01), zie Figuur 21. De interactie 3 in het kader van de pathologie (het antwoord bericht op query) maakt gebruik van dit message model.
7.5.1 R-MIM (RCMR_RM000050UV01) Dit R-MIM is basis voor message type RCMR_MT000001 en wordt gebruikt om metadata van documenten te zenden, zonder de documenten zelf. De klasse die in het geval van de pathologie in dit R-MIM zitten zijn een kopie van de informatie die in Clinical Documents zit. Omdat hier metadata van Clinical Documents verzonden worden, komen deze klasse toevalligerwijs overeen met de klasse uit het Clinical Documents model. Vandaar dat deze klasse niet opnieuw beschreven worden, maar dat verwezen wordt naar de paragraaf waarin deze klasse reeds beschreven zijn. Het gaat hier om de volgende klassen: •
ClinicalDocument (zie 5.4.2)
•
legalAuthenticator (zie 5.5.5 )
•
author (zie 5.5.2)
•
recordTarget (zie 5.5.1)
•
custodian (zie 5.5.3)
•
ParentDocument (zie 5.5.8)
•
ServiceEvent (zie 5.5.9)
R-MIM RCMR_RM000050UV01 wordt gebruikt om de message type RCMR_MT000002 af te leiden (net als RCMR_MT000001). Daarmee worden zowel metadata van documenten als het document zelf verzonden. Hieronder volgt een overzicht van de klasse die in het geval van de pathologie in deze message zitten. Ook hier gaat het om een kopie van informatie van de ClinicalDocuments en wordt er verwezen naar de paragrafen waar de klasse beschreven zijn. •
ClinicalDocument (zie 5.4.2) LET OP: het daadwerkelijke document zit in het text attribuut van deze klasse. Dit is een zogenaamd container document dat omgezet is naar HL7 data type ED (encapsulated data) base 64 in plaats van XML.
7.5.2 R_MIM Medical Records Parameter Query Message (RCMR_RM000920UV) De pathologen vragen documenten op bij het LSP op basis van het burger service nummer (BSN) van de patiënt en op basis van het type document. Hierbij wordt gebruik gemaakt van query message type RCMR_MT000003UV die is afgeleidt uit het R-MIM RCMR_RM000920UV). Deze query bestaat hier uit een subset van klassen uit het Medical Records Parameter Query Domain. Patient.id In Patient.id (ParameterId) komt in de value het BSN van de patiënt waarvan je een document wil opvragen. value .................................................................................................. patient id II [1..1]
ClinicalDocument.code In ClinicalDocument.code (ParameterItem) komt in de value de code die staat voor onderzoeksverslag pathologie (LOINC code). value ...........................................................................................document type CE [1..*] <= LOINC (PALGA document type)
In ClinicalDocument.effectiveTime (ParameterId) kan in de value een tijdsinterval opgegeven worden waarin het document gemaakt is. value ................................................ tijdsinterval waarin document is aangemaakt IVL [1..*]
ServiceEvent.code In ServiceEvent.code (ParameterId) kan in de value een type onderzoek (bijvoorbeeld “B”) als filter opgegeven worden. value .......................................................................................... type onderzoek CE [1..*]
ServiceEvent.effectiveTime In ServiceEvent.effectiveTime (ParameterId) kan in de value een tijdsinterval opgegeven worden waarin het onderzoek is gemaakt is. value ............................................... tijdsinterval waarin het onderzoek is gemaakt IVL [1..*]
HL7 v3 Clinical Document Architecture, Release 2.0 (ANSI Standard CDA Release 2, July 2005)
[3]
Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das Deutsche Gesundheitswesen. Implementierungsleitfaden, Versie 1.50, 12.05.2006, Document OID: 1.2.276.0.76.3.1.13.7.5
Naast deze implementatiehandleiding is een elektronische versie van een aantal ondersteunende documenten beschikbaar. De structuur van de mappen is als volgt: • •
CDA bevat het hoofdschema CDA, voorbeelddocumenten en een stylesheet MR bevat de interactieschema voor het medical record domein, beschreven in
•
hoofdstuk 7 en medical record voorbeeldberichten coreschemas bevat algemene schema’s voor HL7 datatypen, vocabulaire en definities voor het gedeelte voor verhalende tekst
10.1 Schema’s CDA CDA Release 2 bevat een set van XML schema’s (map CDA), die ter validatie van CDA documenten kunnen worden gebruikt. Het “instap” schema is
• •
CDA.xsd, dat een aantal verdere schema’s aanroept, onder meer: POCD_MT000040.xsd, bevat definities voor header en body CDA R2
Bovendien zijn alle voorbeeld documenten en PALGA-stylesheet.xsl, een voorbeeld stylesheet om CDA documenten te vertonen, aanwezig.
10.2 Schema’s ActReference Voor de interacties aanmelden, wijzigen en intrekken van generieke Act References zijn schema’s beschikbaar (map MR), voor elke interactie één schema. •
MFMT_IN002101 Activate Act Reference (Directory Original Document Regis-
datatypes.xsd met de definities van de HL7 datatypen, gebruikt datatypes-base.xsd voc.xsd met definities voor HL7 vocabulaires NarrativeBlock.xsd met definities voor de verhalende tekst.
10.5 Voorbeeld documenten en berichten In deze handleiding zijn een aantal storyboards met voorbeelden te vinden. Voor deze storyboards zijn CDA voorbeeld documenten beschikbaar. Verder is voor elke interactie uit het medical record domein een voorbeeldbericht beschikbaar.
PALGA-POCD_EX97000*.xml als voorbeeld document voor elke storyboard: Storyboard
Omschrijving
Voorbeeld document(en)
POCD_SN970001NL
Histologie [T] - groot
PALGA-POCD_EX970001NL
POCD_SN970002NL
Histologie [T] - klein
PALGA-POCD_EX970002NL
POCD_SN970003NL
Cytologie [C]
PALGA-POCD_EX970003NL
POCD_SN970004NL
Cervix cytologie [B]
PALGA-POCD_EX970004NL
POCD_SN970005NL
Obductie [S]
PALGA-POCD_EX970005NL
PALGA-MFMT_EX00210*.xml als voorbeeld document voor elke interactie uit hoofdstuk 7 (document management): Interactie
Omschrijving
Voorbeeld bericht(en)
MFMT_IN002101
Activate Act Reference (Directory Original Document Registration Request)
10.6 Schematron Er zijn schematroon regels beschikbaar voor de volgende interacties: Interactie
Omschrijving
schematron set
RCMR_IN000031NL
Find Document Metadata and Content Query
RCMR_IN000031NL.sch
RCMR_IN000032NL
Find Document Metadata and Content Response
RCMR_IN000032NL.sch
Deze schematron’s zijn aanvullend op de regels voor generiek aanmelden enz.
10.7 Stylesheet Er is een stylesheet beschikbaar dat kan worden gebruikt om de inhoud van een CDA document te vertonen. •
PALGA-stylesheet.xsl als voorbeeld van een stylesheet
Hieronder staat een voorbeeld van een met de PALGA stylesheet gegenereerde versie van het obductieverslagvoorbeeld (zie 3.5). Het bijgevoegde stylesheet vertoont één manier van visuele weergave van de inhoud van een CDA document.
