Overdracht Concern
Inleiding
Doel en scope
Dit document beschrijft de HL7 implementatiehandleiding van de Ketenzorg-bouwstenen. De bouwstenen zijn hier functioneel beschreven. In de ART-DECOR omgeving staat de publicatie van de Ketenzorg-bouwstenen, zie project Ketenzorg.
Doelgroep voor dit document
De doelgroep voor dit document zijn de XIS-leveranciers die de Ketenzorg-bouwstenen moeten ondersteunen binnen hun applicaties.
Dit document is niet relevant voor infrastructuurleveranciers, omdat zij de berichten niet mogen bewerken of inhoudelijk mogen bekijken.
Relatie met overige documenten
In de Implementatiehandleiding HL7v3 Basiscomponenten is algemene achtergrondinformatie over de implementatie van HL7v3 te vinden.
Waarschuwing:Titelweergave "Documenthistorie" overschrijft eerdere titelweergave "HL7v3 Implementatiehandleiding Bouwstenen Ketenzorg".
Documenthistorie
De bewerking van de gidsen over de bouwstenen ketenzorg en de uitwisseling (interacties enz.) worden synchroon gehouden waardoor er maar één historie wordt bijgehouden.
| Versie | Datum | Omschrijving |
|---|---|---|
| 0.1.0.0 | 01-01-2014 | Eerste versie t.b.v. de werkgroep HL7 implementatie |
| 0.2.0.0 | 02-01-2014 | Update met nadere uitwerking diverse bouwstenen, plus aanpassing labbouwsteen aan bestaande spec’s. |
| 0.9.0.0 | 15-01-2014 | Verwerking reacties n.a.v. interne review plus aanvullen diverse specificaties. |
| 1.0.0.0 | 01-03-2014 | Verwerking reacties n.a.v. externe review plus verwerken nieuwe inzichten. |
| 1.0.1.0 | 01-06-2014 | Verwerking nieuwe inzichten mbt tot gebruik bouwsteen "Labbepaling" en "Medicatievoorschrift" |
| 2.0.0.0 | 21-06-2015 | Versie 2 van de gidsen, toevoegen van Contactverslag, Overdracht concern, Alert en Allergien en intoleranties en alle relevante informatie over structuur en uitwisselmechanismen. |
| 2.0.1.0 | 30-11-2015 | Nieuwe query parameter message type QUMT_RM020099NL03 |
| 2.0.1.0 | 30-12-2016 | Implementatiehandleiding aangepast conform huidige kennis en afspraken binnen Ketenzorg |
Legenda
|
|
Let op! Dit is een aandachtpunt. Een opmerking die de aandacht vestigt op een bepaald opvallend aspect |
|
|
Dit is een 'open issue' of 'known issue'. Een kwestie die nog open ligt voor discussie, maar onderkend is. |
|
|
Dit is een frequently asked question (FAQ) met antwoord. |
Algemene regels voor bouwsteenimplementatie
Bouwstenen als implementatievorm
In het architectuurontwerp voor de zorgtoepassing Ketenzorg is toegelicht waarom gekozen is voor het bouwsteenprincipe bij de uitwerking van deze zorgtoepassing (zodanig dat die later als basis kan dienen voor toekomstige zorgtoepassingen).
De definitie van een bouwsteen is:
- Een logisch afgebakende, herbruikbare informatie-eenheid, incl. een implementeerbare specificatie, die als geheel geautoriseerd kan worden.
Belangrijk om te benadrukken is dat het bouwsteenprincipe op verschillende niveaus kan worden beschouwd. De volgende termen typeren het onderscheid tussen deze niveaus:
- Bouwsteentype (aanduiding).
- Bouwsteenmodel (conceptueel).
Een visuele representatie van de gegevens¬elementen voor een bouwsteentype, in hun onderlinge samenhang. Dit model is implementatie-onafhankelijk omdat het alleen semantiek en geen syntax aanduidt.
- Bouwsteentemplate (implementeerbaar).
De ‘vertaling’ van het bouwsteenmodel in een implementeerbaar formaat (bijv. als restrictie op CDA R2 clinical statement). Een template beschrijft de syntax van het uitwisselformaat, plus de gekoppelde value sets.
- Bouwsteeninstantiatie (gevuld met echte data).
Een ‘invulling’ van het bouwsteentemplate voor specifieke gegevens. Hier wordt dus bijv. het concept medicatie weergegeven in de vorm die wordt beschreven door de template, maar nu met een specifiek medicijn.
Dit document benoemt enkele bouwsteentypen (een subset die momenteel in scope is), maar schetst daarbij geen conceptuele modellen. De nadruk ligt op het beschrijven van de HL7 templates die specificeren wat de implementeerbare vorm van deze bouwstenen is. Daarbij worden XML voorbeelden gegeven, die een indruk geven van de bouwsteeninstantiaties.
|
|
Het bouwsteenconcept wordt niet alleen op conceptueel niveau toegepast, maar ook op implementatieniveau. Het is juist bij het fysiek uitwisselen in XML formaat dat leveranciers nu vaak te maken hebben met verschillende implementatievormen van hetzelfde logische concept. Doel is om te zorgen dat leveranciers een softwaremodule kunnen schrijven die een bouwsteen-implementatie ondersteunt, zodanig dat deze software net zo herbruikbaar is als de bouwsteen zelf. Daarmee wordt het onderscheid tussen de uitwissel-mechanismen, met name berichten versus documenten, ook gereduceerd tot ‘verpakking’, omdat het XML formaat van de inhoud gestandaardiseerd is. Het werken met herbruikbare bouwstenen zal overigens ook de basis zijn voor de volgende generatie HL7 implementaties, want de resources van Fast Healthcare Interoperability Resources (FHIR) zijn ook gewoon bouwstenen. |
HL7v3 model voor implementatie
De belangrijkste vraag bij het maken van implementeerbare bouwsteenspecificaties is welk onderliggend HL7 versie model er gebruikt wordt. Bij de implementatie op basis van berichten die nu gangbaar is binnen AORTA, werd normaal gesproken voor elk type opgeleverde gegevens een specifiek berichtmodel ontwikkeld, waarbij ook een specifiek XML Schema hoort. Aan de andere kant kent HL7v3 het mechanisme van de Clinical Document Architecture (CDA), dat één vast model en bijbehorend XML Schema kent. Specifieke implementatierichtlijnen worden dan aangeduid door middel van een zogenaamd template, dat weergeeft welke regels er precies gelden voor de inhoud.
De trend is dat steeds meer HL7v3 interfaces wereldwijd gebaseerd zijn op CDA, specifiek op Release 2 van deze standaard. De implementatie van bouwstenen ligt echter niet op het niveau van gehele documenten (die een verzameling gegevens kunnen omvatten die bestaat uit meerdere instantiaties van verschillende bouwsteentypen), maar op het niveau van het zogenaamde Clinical Statement. Dit clinical statement is het onderdeel van het CDA model dat bedoeld is om specifieke medische gegevens weer te geven. Ook dit heeft een vast XML Schema, dat een subset is van het CDA R2 Schema.
|
|
Uitgangspunt is dat bouwsteenimplementaties in principe compatible zullen zijn met het clinical statement van CDA Release 2 (CDA R2), eventueel aangevuld met extensies voor het realiseren van functionaliteit die ontbreekt in het clinical statement model. Echter: de aanwezigheid van een bestaande, niet op CDA R2 gebaseerde implementatie (zoals die van bestaande zorgtoepassingen binnen AORTA), kan reden zijn om van dit principe af te wijken. Dit wordt per bouwsteentype apart afgewogen. |
De migratie richting het generieke model (en Schema) van het clinical statement is vooral een verschuiving van specificatie d.m.v. een specifiek XML Schema naar specificatie d.m.v. een specifiek template (en de bijbehorende Schematron regels). Daarbij blijft het nog steeds zo dat de gespecificeerde templates domeinspecifiek zijn.
Dat in eerste instantie een mix van op het clinical statement gebaseerde templates en bestaande AORTA-specificaties wordt gebruikt is een afweging tussen principe en praktijk. Voor de leveranciers heeft het hergebruik van bestaande AORTA-bouwstenen als voordeel dat ze ook bijbehorende softwaremodules kunnen hergebruiken. Op enig moment zal echter een migratie worden ingezet clinical statements conform CDA R2, hetgeen sowieso het uitgangspunt is voor ontwikkeling van nieuwe zorgtoepassingen.
In de volgende paragraaf wordt het generieke Clinical Statement model van CDA R2 beschreven. Per bouwsteentype wordt dan een subset van dit model aangeduid (het XML-implementatieformaat is altijd conform het Schema van het Clinical Statement).
Als sprake is van een reeds geïmplementeerd model binnen AORTA, dan wordt dit model weergegeven, zoveel mogelijk consistent met het gebruik binnen de bestaande zorg-toepassing (het XML-implementatieformaat is dan conform het bijbehorende Schema).
Clinical Statement Model – CDA R2
Het Clinical Statement model voor CDA R2 heeft de volgende grafische representatie:
Noot: bovenstaand model is iets overzichtelijker getekend dan in het totaalmodel voor CDA R2. De semantiek ervan is echter 100% compatible met die van standaard CDA R2.
Het (sub)model dat wordt gehanteerd voor bouwsteenimplementaties is een restrictie op bovenstaand model. Dat wil zeggen dat een keuze gemaakt wordt uit de choice box, dat optionele elementen kunnen worden weggelaten en dat de cardinaliteit van relaties en attributen kan worden aangescherpt. Deze bouwsteenimplementaties conformeren zich dus aan bovenstaand model. Het gevolg is dat de bijbehorende bouwsteeninstantiaties ook zullen valideren tegen het XML Schema van het Clinical Statement van CDA R2.
XML Schema
Het XML Schema dat hoort bij het Clinical Statement van CDA R2 is geen product dat op zichzelf staand door HL7 wordt opgeleverd. Er bestaat een overall Schema voor CDA R2, waar het Clinical Statement onderdeel van uitmaakt. Dit beschouwt het Clinical Statement zuiver in de context van een CDA document, waarbij elk van de ´statements´ fungeert als een ´entry´ binnen een sectie van het overkoepelende CDA document.
Voor toepassing bij de implementatie van bouwstenen is het echter wenselijk dat er een apart XML Schema is, specifiek voor het Clinical Statement, vanzelfsprekend zodanig dat dit 100% compatible is met het XML Schema van CDA R2. Dit XML Schema is gemaakt en wordt meegeleverd met deze implementatiehandleiding. Elke bouwsteeninstantiatie die conform het Clinical Statement is geïmplementeerd moet hier dus tegen valideren.
HL7 template
Van elke bouwsteenimplementatie zal in detail moeten worden uitgewerkt aan welke syntax (XML-structuur) en conformance statements (regels voor het vullen van de gegevenselementen) de bouwsteeninstantiaties (die over de lijn gaan) moeten voldoen.
Voorheen sloot dat binnen AORTA meestal 1-op-1 aan bij het XML Schema dat voor een bepaalde gegevensuitwisseling gehanteerd werd (één Schema per type berichtpayload), maar dat principe verandert nu elke bouwsteenimplementatie in principe gebaseerd is op het XML Schema van het clinical statement van CDA R2. De weergave van de exacte XML-structuur en de business rules gebeurt dus nu in een zogenaamd HL7 template.
Zo’n template kan worden uitgewerkt, onafhankelijk van het onderliggende XML Schema, en dient als basis voor het (zoveel mogelijk automatisch) genereren van Schematron scripts die kunnen dienen t.b.v. nadere validatie van de bouwsteeninstantiaties.
Relaties tussen bouwstenen
In het conceptueel model van een bouwsteen kunnen relaties worden gelegd naar andere bouwstenen (denk aan de relatie tussen een medicatieverstrekking en het bijbehorende voorschrift). De vraag is nu hoe een dergelijke relatie implementeerbaar wordt gemaakt. Daarbij zijn verschillende methodieken mogelijk, die hieronder kort worden opgesomd:
- By value, de ene bouwsteen is opgenomen in de andere, bijv. bij opnemen van de diagnose(code) als reden van voorschrijven in medicatievoorschrift.
- By reference, de ene bouwsteen verwijst naar de andere, door een unieke referentie (ID).
- By context, de relatie tussen bouwstenen wordt duidelijk uit de context waarin ze uitgewisseld worden. Hiervan kan bijv. gebruik worden gemaakt binnen een CDA document.
De keuze die in dit project is gemaakt is dat de relaties tussen bouwstenen worden aangeduid met unieke referenties (by reference). Dit kan op alle abstractieniveaus:
- Link naar relevante context in bouwsteenmodel.
- Subtemplates (o.b.v. template ID) in een template.
- Referenties (o.b.v. instance ID) in instantiaties.
Dit uitgangspunt zorgt ervoor dat bouwsteeninstantiaties los van elkaar kunnen worden verwerkt en opgeslagen, terwijl de samenhang ertussen toch te achterhalen blijft. Dit stelt wel de nodige eisen, zowel op conceptueel als op implementeerbaar niveau:
- het conceptueel model moet altijd alle referenties naar andere bouwstenen weergeven, waarbij het bouwsteentype verwijst naar het achterliggende model
- elke bouwsteeninstantiatie moet uniek en persistent identificeerbaar zijn, zodat de bijbehorende identifier gebrukt kan worden om eraan te refereren.
|
|
Relaties tussen bouwstenen kunnen ook impliciet zijn, als de context de relatie ertussen vastlegt. Een goed voorbeeld is de wijze waarop de patiënt wordt aangeduid binnen een CDA document. Deze ligt vast op het niveau van de header en is daardoor impliciet bekend in alle bouwsteeninstantiaties die als entry in het document zijn opgenomen. Hetzelfde effect kan worden bereikt in een bericht door een extra headerelement toe te voegen in het berichtmodel of door gebruik te maken van het element <attentionLine> in de tranmission wrapper van het bericht (waarin het BSN is opgenomen). |
|
|
Het kan gebeuren dat een referentie naar een bouwsteeninstantiatie ’doodloopt’ (een zogenaamde ‘dangling reference’), als de bouwsteen waarnaar verwezen wordt onbereikbaar is. Dit kan bijvoorbeeld gebeuren indien de vragende partij niet geautoriseerd is om het bouwsteentype waarna verwezen wordt in te zien. Software moet hier mee om kunnen gaan. |
Overzicht bouwstenen
Het volgende plaatje geeft een overzicht weer van de bouwstenen zoals nu gedefinieerd en de samenhang tussen de bouwstenen.
Figuur: Relaties tussen de bouwstenen
Waarschuwing:Titelweergave "Labbepaling" overschrijft eerdere titelweergave "Documenthistorie".
Labbepaling
Bouwsteentypering
Er is voor gekozen om een aparte bouwsteen te definiëren voor labbepalingen i.p.v. alleen één bouwsteen voor bepalingen. Het wordt dus onderscheid gemaakt tussen labbepalingen en algemene bepalingen.
|
|
Het niveau waarop deze bouwsteen wordt onderscheiden van andere zorggegevens is betwistbaar, omdat verschillend gedacht kan worden over het differentiatieniveau. Er zou gekozen kunnen worden voor een generieke bouwsteen voor alle bepalingen (observaties in HL7 terminologie). Er zijn echter bepaalde kenmerken die specifiek zijn voor laboratoriumbepalingen, zoals het afnemen van een monster waarop het onderzoek plaatsvindt. (bijv. bij bloed- of urineonderzoek) en het hanteren van zogenaamde normaalwaarden (hoewel die in principe ook voor kunnen komen bij andere bepalingen). Procesmatig is het van belang dat labbepalingen meestal worden uitgevoerd door een gespecialiseerde instelling of afdeling (het laboratorium). Dit is geen hard criterium, aangezien sommige labbepalingen ook op de huisarts- of specialistpraktijk, of door de patiënt zelf, kunnen worden uitgevoerd. Het onderscheid moet daarbij gemaakt worden op basis van het type bepaling en niet op basis van de locatie waar deze plaatsvindt. |
Subdataset Ketenzorg
|
|
Er moet worden nagegaan of met het gegevenselement Datum werkelijk de registratiedatum/tijd wordt bedoeld of eigenlijk de bepalingsdatum/tijd. Deze zullen normaal gesproken natuurlijk zeer dicht bij elkaar liggen, maar er is conceptueel wel een verschil (dat bepalend is voor de HL7v3 representatie). Overigens is het medisch-inhoudelijk belangrijker om de afnamedatum/tijd vast te leggen, als tenminste sprake is van een bepaling o.b.v. een monster. De uitslag van de bepaling heeft immers betrekking op de staat van het monster of het moment van afname (ervan uitgaande dat het vanaf dat moment biologisch stabiel blijft). Ook dit moment zal meestal dicht bij het bepalingsmoment liggen, dus vandaar dat het onderscheid niet essentieel is. |
HL7v3 model
Een labbepaling is een HL7 Observation met mogelijk aanduidingen van een Observation Range.
De template componenten zijn hier grafisch weergegeven.
HL7 template
De bouwsteen is gerepresenteerd door de template 2.16.840.1.113883.2.4.3.11.60.66.10.203 Labbepaling, in detail beschreven en met voorbeelden voorzien in ART-DECOR. Waarschuwing:Titelweergave "Algemene bepaling" overschrijft eerdere titelweergave "Labbepaling".
Algemene bepaling
Bouwsteentypering
Er is voor gekozen om een aparte bouwsteen te definiëren voor algemene bepalingen i.p.v. alleen één bouwsteen voor bepalingen. Het wordt dus onderscheid gemaakt tussen labbepalingen en algemene bepalingen.
HL7v3 model
Een algemene bepaling is een HL7 Observation.
De template componenten zijn hier grafisch weergegeven.
HL7 template
De bouwsteen is gerepresenteerd door de template 2.16.840.1.113883.2.4.3.11.60.66.10.202 Algemene bepaling, in detail beschreven en met voorbeelden voorzien in ART-DECOR. Waarschuwing:Titelweergave "Contactmoment" overschrijft eerdere titelweergave "Algemene bepaling".
Contactmoment
Bouwsteentypering
De bouwsteen Contactmoment geeft administratieve gegevens van het patiënten contact zoals begin- en eindtijdstip en de type van het contact weer.
HL7v3 model
De bouwsteen Contactmoment is een Encounter.
De template componenten zijn hier grafisch weergegeven.
HL7 template
De bouwsteen is gerepresenteerd door de template 2.16.840.1.113883.2.4.3.11.60.66.10.201 Contactmoment, in detail beschreven en met voorbeelden voorzien in ART-DECOR. Waarschuwing:Titelweergave "Medicatievoorschrift" overschrijft eerdere titelweergave "Contactmoment".
Medicatievoorschrift
Bouwsteentypering
Subdataset Ketenzorg
HL7v3 model
Een medicatievoorschrift is een HL7 Substance Administration met de mood code RQO (request order).
De template componenten zijn hier grafisch weergegeven.
HL7 template
De bouwsteen is gerepresenteerd door de template 2.16.840.1.113883.2.4.3.11.60.66.10.204 Voorschrift, in detail beschreven en met voorbeelden voorzien in ART-DECOR. Waarschuwing:Titelweergave "Contactverslag" overschrijft eerdere titelweergave "Medicatievoorschrift".
Contactverslag
Bouwsteentypering
De bouwsteen contactverslag geeft de SOEP regels weer (deelcontact). S- en E-regels mogen elk een probleemaanduiding (diagnose) met een ICPC code (probleem) bevatten.
HL7v3 model
De bouwsteen contactverslag is als “container” gedefinieerd met als componenten:
- Verantwoordelijke zorgverlener, al eerder in andere bouwstenen toegepast 2.16.840.1.113883.2.4.3.11.60.66.10.9030
- Referentie naar het contactmoment; let wel dat de eerder gedefinieerde bouwsteen contactmoment 2.16.840.1.113883.2.4.3.11.60.66.10.201 Contactmoment de administratieve gegevens bevat en het contactmoment in het contactverslag gewoon gekoppeld wordt (referentie)
- S-regel met een mogelijke probleemaanduiding (Probleem, problem observation) 2.16.840.1.113883.2.4.3.11.60.66.10.208 Subjective
- O-regel 2.16.840.1.113883.2.4.3.11.60.66.10.209 Objective
- E-regel met een mogelijke probleemaanduiding (Probleem, problem observation) 2.16.840.1.113883.2.4.3.11.60.66.10.210 Assessment
- P-regel 2.16.840.1.113883.2.4.3.11.60.66.10.211 Plan
S en E regels mogen probleemaanduidingen (Probleem, problem observation) 2.16.840.1.113883.2.4.3.11.60.66.10.213 Probleem bevatten.
De template componenten zijn hier grafisch weergegeven.
HL7 template
De bouwsteen is gerepresenteerd door de template 2.16.840.1.113883.2.4.3.11.60.66.10.207 Contactverslag, in detail beschreven en met voorbeelden voorzien in ART-DECOR. Waarschuwing:Titelweergave "Overdracht Concern" overschrijft eerdere titelweergave "Contactverslag".
Overdracht Concern
Bouwsteentypering
De bouwsteen overdracht concern bevat informatie over de concern (episode) met een concern label, als componenten zijn er afzonderlijke probleem observatie (diagnosen) met ICPC codes aanwezig.
HL7v3 model
De bouwsteen Overdracht Concern is als “container” gedefinieerd met als componenten:
- Auteur zorgverlener, al eerder in andere bouwstenen toegepast 2.16.840.1.113883.2.4.3.11.60.66.10.9025
- Probleemaanduidingen 2.16.840.1.113883.2.4.3.11.60.66.10.213 Probleem (Problem Observation)
De template componenten zijn hier grafisch weergegeven.
De statusCode van de Problem Concern Act is de definitieve aanduiding van de status van de concern, waartegen de effectiveTime van de geneste Problem Observation (2.16.840.1.113883.2.4.3.11.60.66.10.213) de definitieve aanduiding daarvan is of de conditie is opgelost of niet.
De effectiveTime/low van de Problem Concern Act geeft aan wanneer de concern actief werd. Dit komt overeen met de tijd dat de concern in het patiëntendossier terecht is gekomen. De effectiveTime/high geeft aan wanneer de concern is afgesloten, dus wanneer de zorgverlener aanneemt dat er geen noodzaak is om de concern nog verder te volgen.
Een Problem Concern Act kan meedere Problem Observations (2.16.840.1.113883.2.4.3.11.60.66.10.213) bevatten. Elke Problem Observation is een discrete observatie van de concern en heeft dus altijd de statusCode “completed”. Het aantal Problem Observations genest onder een Problem Concern Act spiegelen de veranderingen van klinische kennis in de tijd weer.
HL7 template
De bouwsteen is gerepresenteerd door de template 2.16.840.1.113883.2.4.3.11.60.66.10.212 Overdracht Concern, in detail beschreven en met voorbeelden voorzien in ART-DECOR.
Alert
Bouwsteentypering
De bouwsteen Alert bevat alerts (waarschuwingen) of comorbiditeiten.
HL7v3 model
Voor comorbiditeiten wordt de code voor ‘Conditie’ toegepast. Indien waarschuwingen doorgegeven moeten worden die geen aandoening zijn, wordt de code voor ‘Alert’ gebruikt.
De template componenten zijn hier grafisch weergegeven.
HL7 template
De bouwsteen is gerepresenteerd door de template 2.16.840.1.113883.2.4.3.11.60.66.10.214 Alert, in detail beschreven en met voorbeelden voorzien in ART-DECOR.
Allergie Intolerantie
Bouwsteentypering
De bouwsteen Allergie Intolerantie wordt gebruikt om allergieën en intoleranties ((NHG: medicatie-overgevoeligheid/ overige overgevoeligheid) door te geven.
HL7v3 model
De template componenten zijn hier grafisch weergegeven.
HL7 template
De bouwsteen is gerepresenteerd door de template 2.16.840.1.113883.2.4.3.11.60.66.10.215 Allergie Intolerantie, in detail beschreven en met voorbeelden voorzien in ART-DECOR.