Thuis
Contacten

    Hoofdpagina


Generieke implementatiehandleiding care provision d-mim

Dovnload 4.78 Mb.

Generieke implementatiehandleiding care provision d-mim



Pagina20/20
Datum25.10.2017
Grootte4.78 Mb.

Dovnload 4.78 Mb.
1   ...   12   13   14   15   16   17   18   19   20

CLINICAL STATEMENT


7.1 Inleiding

Dit hoofdstuk beschrijft de “Clinical Statement”. Voor deze tekst is de HL7 ballot van januari 2007 gebruikt als bronmateriaal.Het Engelse woord clinical kan voor het Nederlands het beste worden vertaald met zorginhoudelijk, dan wel primaire zorgproces. Er wordt dus uitdrukkelijk bedoeld om ook buiten het ziekenhuis in contacten met cliënten informatie vast te leggen en uit te wisselen, zoals in zorgketens. De “clinical statement” vormt de kern van het CDA bericht en van het “Care Provision D-MIM” en daarvan afgeleide “R-MIMs”.
Clinical Statement Pattern Domain
Het model dat in dit document beschreven wordt is een ”patroon” dat ontworpen is om gebruikt te worden binnen verschillende HL7 Versie 3 domeinmodellen. Dit patroon wordt bedoeld om het consistente ontwerp van communicatie te faciliteren die klinische informatie overbrengen om specifieke “use cases” te verwezenlijken. Het is niet de bedoeling dat het ”patroon” zelf ooit gebruikt wordt in een communicatie. Dienovereenkomstig is de informatie in dit document op een hoog abstractieniveau beschreven met een minimum aan beperkingen die toegepast worden. Het patroon representeert niet een “Record Architecture” of een fysieke structur voor het opslaan van data in een EPD database, hoewel het veel van de types van klinische informatie beslaat die deel zouden uit moeten maken van een Electronisch Pateinten Dossier. De “Clinical Statement” ballot zal ballot topics bevatten (met de tijd algemene patronen zoals Lab, Allergie etc) waarin deze topics zo worden geschreven dat ze zoveel mogelijk dezelfde structuur hebben als de domeinmodellen waarmee ze corresponderen.

De formele definitie van ”Clinical Statement” voor de zorg van een patiënt is:

“Een expressie van een discreet object van klinische (of klinisch gerelateerde, waarbij altijd wordt bedoel het primaire zorgproces) informatie die wordt vastgelegd vanwege de relevantie voor de zorg voor een patiënt / cliënt. Klinische informatie kan in verschillende mate van detail omschreven worden en daardoor kan de mate van detail in een enkele “Clinical Statement” variëren”.

Om beschouwd te worden als een ”Clinical Statement” moet een concept geassocieerd zijn met een patiënt op een manier die de volgende aspecten duidelijk maakt:



  • zijn tijdsgebonden context;

  • zijn relatie met de patiënt;

  • in het geval van een observatie: zijn ”mood” en de aanwezigheid, afwezigheid, of de waarde;

  • in het geval van een procedure: zijn ”mood” status is;

Deze duidelijkheid kan worden verkregen door:



  • expliciete representatie of;

  • impliciete applicatie van ‘defaults’ ALLEEN waar expliciet gemodelleerde regels de correcte ‘defaults’ definiëren.


achtergrond bronnen
Dit “Clinical Statement pattern” werd ontwikkeld door vele individuen uit vele landen, inclusief, maar niet gelimiteerd tot de vertegenwoordigers van het UK National Programme for Information Technology (NPfIT), het HL7 “Structured Documents Technical Committee”.

De “Clinical Statement Task Force” erkent al deze individuen en organisaties en wil hen bedanken voor hun waardevolle bijdrage. Deze standaard is echter niet bedoeld een afgeleide te zijn van één van deze bronnen en deze bronnen zouden niet gebruikt moeten worden om enige semantiek die in dit document gecommuniceerd wordt te interpreteren.


gebruik van het model
Het “Clinical Statement Domein Patroon” representeert een standaard structuur voor de inclusie van klinische informatie in communicatie met als doel specifieke bedrijfsfuncties te ondersteunen. Hoewel het niet mogelijk is het te implementeren zoals het is, kan het “Clinical Statement Domein Patroon” aangepast worden zodat aan de eisen van vele specifieke communicaties van klinische informatie voldaan wordt. Het proces van aanpassen zal of patroon beperking of uitbreiding (of soms beide) met zich meebrengen om aan de behoeften van een bepaald domein te voldoen.
Mogelijkheden voor patroon beperking bevatten:

  • de generieke 'Clinical Statement' klasse attributen kunnen beperkt zijn om de precieze aard van de data die overgebracht moeten worden weer te geven. Bijvoorbeeld:

    • optionele attributen kunnen verwijderd worden wanneer deze niet van toepassing zijn voor de business case;

    • attributen kunnen zelf beperkt zijn:

  • multipliciteiten kunnen beperkt worden naar meer beperkte sets; (0..*) kan bijvoorbeeld beperkt worden tot (1..*);

  • waardensets van attributen kunnen beperkt worden tot meer beperkte waardensets; de “mood code” kan bijvoorbeeld gelimiteerd worden tot ”Event”;

    • data typen voor een attribuut kunnen beperkt worden, bijvoorbeeld “ANY naar CD”;

  • associaties kunnen beperkt worden om de potentie voor complexiteit te verwijderen, bijvoorbeeld: het beperken van een implementatie naar 3 nesting levels; het verwijderen van “Episode Link” om een implementatie te definiëren naar de “lowest common denominator” met betrekking tot systeem vermogen;

  • klassen kunnen worden beperkt:

    • klassen kunnen worden verwijderd als ze niet vereist zijn;

    • klassen kunnen worden beperkt tot specifieke subklassen, bijvoorbeeld dat “Observation Class” wordt beperkt tot “Concern Class”;

  • klassen kunnen worden ”gekloond” om specifieke beperkingen voor attributen of associaties te documenteren.

    • klassen waarbij specifieke beperkingen van toepassing zijn, kunnen uitgerold worden van de “Clinical Statement Keuzebox” om hun gebruik te beperken tot een specifieke structuur (in dat geval kan niet langer worden aangenomen dat de beperkte versie van de klasse aanwezig is in de gegeneraliseerde Clinical Statement Keuzebox).


mogelijkheden voor patroon uitbreiding bevatten:

      • aanvullingen van klassen, attributen en associaties toegestaan in het RIM

      • vergroting van de waarden sets zoals ondersteund in door het RIM geaccepteerde vocabulaires.


filosofie over uitbreidingen

De intentie van het ”patroon” is dat het de potentie zou moeten hebben om de breedst mogelijke range van typen klinische informatie te bevatten in een ondubbelzinnige en samenhangende representatie. In dat licht is er een mogelijkheid dat als in de toekomst specifiekere eisen worden gesteld, enkele aanvullende klassen, attributen, associaties en vocabulaire waardensets nodig kunnen zijn. Aanvullingen zouden alleen gemaakt moeten worden wanneer het algemene model niet in staat is de vereiste informatie te representeren en dat soort aanvullingen zullen afgeleid moeten worden van het HL7 v3 RIM waarbij de juiste methodologie gevolgd wordt. Deze zouden ingediend moeten worden bij de “Clinical Statement Task Force” voor inclusie in het patroon. Dit kan gedaan worden door een verzoek tot verandering aan de “Clinical Statement List” in te dienen of aan de “Clinical Statement wiki”:

http://informatics.mayo.edu/wiki/index.php/Clinical_Statement_Change_Requests. Echter, er is geen eis dat uitbreidingen goedgekeurd moeten worden door het “Clinical Statement Committee” om in de ontwikkeling van domeinen gebruikt te worden. Als er, na het consulteren van het ”Modeling and Methodology Technical Committee”, een eis is waaraan niet voldaan kan worden door deze aanpak te volgen dan moet gezocht worden naar de juiste aanvulling op het HL7 v3 RIM of op de methodologie.
patroon gebruik

Een “Act” buiten het “Clinical Statement Domain-Pattern” model moet als referentie dienen voor dit patroon. Vaak levert deze externe “Act” het “Entry point” naar een communicatie specificatie en representeert het de context waarin de “clinical statement” informatie verzonden wordt. Bijvoorbeeld: de informatie met betrekking tot wie deze informatie zendt wordt gevonden in een “Act” extern van het “Clinical Statement Patroon”. De “Care Provision Act” in het “Care Provision Domein” is een voorbeeld van een “Act” extern van het Patroon.



    1. Clinical Statement Patroon  (COCS_DM000000)




Beschrijving
model overzicht

Het model kan verdeeld worden in 3 gerelateerde onderdelen:



  • Clinical Statement Act Keuzebox;

  • participaties om de Acts heen;

  • acts buiten de Keuzebox.

Elk van deze delen wordt hieronder beschreven.

clinical Statement Act Keuzebox

Dit deel van het model wordt gebruikt voor het overbrengen van de gedetailleerde klinische informatie die verzonden wordt ter ondersteuning van de specifieke zakelijke behoeften. Naast het leveren van een mechanisme voor het overbrengen van de componenten van deze informatie, ondersteunt dit het groeperen van deze componenten en levert het mechanismen om beweringen expliciet te verbinden daar waar een specifieke relatie is.

Daar waar een “Clinical Statement” voorheen overgedragen is en hierdoor bekend is binnen een informatiesysteem, kan de “Clinical Statement” toegevoegd worden door middel van referentie of door het herhalen van de volledige bewering. Wanneer de volledige bewering wordt herhaald moeten alle attributen en de context (hetzij expliciet of geërfd) identiek zijn.

De “Clinical Statement” heeft de structuur van de keuzebox om het mogelijk te maken elke klinisch relevante selectie, duplicatie, beperking en ordening van “Acts” in de communicatie op te nemen.

Alle items in de klinische data zullen gecodeerd kunnen worden via of een HL7 code, een extern geregistreerd code systeem, of een lokaal afgeleid/ontwikkeld code systeem. Via de OID structuur zal het juiste code systeem geïdentificeerd worden.
observatie

De klasse observatie bevat informatie over de observatie inclusief de aard en, wanneer van toepassing, en het resultaat of de bevinding van die observatie.

Dit omvat ook het verzoeken, aanbevelen, beloven, weigeren of het zetten van een doel dat bereikt moet worden of een risico dat vermeden moet worden van een observatie, evenals een specifieke instantiatie van een observatie met de resultaten.

Omvat elke soort Observatie subklasse.

De observatie in de “Clinical Statement” is een afgeleide (instantiatie) van de RIM Observatie klasse, en wordt gebruikt voor het representeren van gecodeerde en andere observaties.

De waardensets voor “Observation.moodCode (CNE)” zijn die volgens de definitie van het RIM.

Zoals bij de “Act Klasse” hierboven beschreven, wordt gebruikt gemaakt van de “Observation.negationInd”. Wanneer de “Observation.negationInd” “true” is, is dat een positief verklaring dat de beschrijvende attributen van de Observatie als geheel worden ontkend. Evenzo worden de inerte eigenschappen, zoals “Observation.id”, “Observation.moodCode” en participaties niet ontkend.

Vooralsnog wordt de “negation indicator” niet gebruikt voor Nederlandse implementatie­handleidingen en berichten, tenzij de “use case” helder is en niet tot foute interpretatie kan leiden.

Een Observatie kan nul tot vele “referenceRange” relaties hebben, welke een Observatie aan een “ObservationRange” klasse relateert, en waarin het verwachte bereik van waarden voor een bepaalde observatie kan worden gespecificeerd.
substanceAdministration

Een afgeleide van de RIM “SubstanceAdministration” klasse, gebruikt voor het representeren van medicatiegerelateerde gebeurtenissen, zoals medicatiegeschiedenis of geplande medicatietoe­diening opdrachten.

De “act” van het introduceren of op een andere manier toedienen van een substantie aan een subject.

Bevat het verzoeken, instrueren van de Patiënt, aanbevelen, beloven, verbieden of weigeren van het toedienen van een substantie, als ook de daadwerkelijke act van het persoonlijk toedienen van de medicatie.

Dit gedeelte van het patroon zal verder worden geharmoniseerd met de technische werkgroep farmacie.

De waardensets voor “SubstanceAdministration.moodCode (CNE)” zijn volgens het RIM.




SubstanceAdministration.priorityCode

Categorizes the priority of a substance administration
Categoriseert de prioriteit van een toediening van een substantie

SubstanceAdministration.doseQuantity

Indicates how much medication is given per dose
Geeft aan hoeveel medicatie per dosis gegeven wordt

SubstanceAdministration.rateQuantity

Can be used to indicate the rate at which the dose is to be administered (e.g. the flow rate for intravenous infusions)
Kan gebruikt worden om de frequentie aan te geven waarin de dosis wordt toegediend (bijv. de stroomsnelhid van intraveneuse infusen)

SubstanceAdministration.maxDoseQuantity

Is used to capture the maximum dose of the medication that can be given over a stated time interval (e.g. maximum daily dose of morphine, maximum lifetime dose of doxorubicin)
Wordt gebruikt om vast te kunnen leggen wat de maximale dosis is die over een gegeven tijdsinterval kan worden toegediend (bijv. maximale dagelijkse dosis van morfine, maximale dosis van doxorubicin op een leven)

SubstanceAdministration.effectiveTime

Is used to describe the timing of administration. It is modeled using the GTS data type to accommodate various dosing scenarios
Wordt gebruikt voor de timing van toedienen. Het wordt gemodelleerd door het GTS data type om verschillende doseringsscenario’s te accomoderen

Wanneer de “SubstanceAdministration.negationInd” “true” is, is dat een positief verklaring dat de beschrijvende attributen van de “SubstanceAdministration” als geheel worden ontkend.

Zoals hierboven bediscussieerd, worden de inerte eigenschappen, zoals “SubstanceAdministration.id”, “SubstanceAdministration.moodCode” en participaties niet ontkend. Deze inerte eigenschappen hebben altijd dezelfde betekenis, zo blijft de auteur bijvoorbeeld de auteur van een negatieve “SubstanceAdministration”. Een bewering van substantie toediening met “negationInd” is nog steeds een bewering over het specifieke feit beschreven door de “SubstanceAdministration”. Bijvoorbeeld: een ontkende "toediening van aspirine" betekent dat de auteur positief ontkent dat er aspirine wordt toegediend en dat hij dezelfde verantwoordelijkheid neemt voor zo’n bewering en dezelfde eis om bewijs te hebben voor zo’n bewering als wanneer hij de ontkenning niet gebruikt had.

Het vastleggen van aan medicatie gerelateerde informatie omvat ook de interrelatie van “SubstanceAdministration” met verscheidene andere klassen.


supply (levering)

Een afgeleide van de “RIM Supply klasse”, gebruikt voor het representeren van levering van materiaal door één entiteit aan een ander.

Omvat het aanvragen, aanbevelen, beloven, verbieden of weigeren van zo’n levering, als ook de daadwerkelijke gebeurtenis van levering.

Merk op dat een recept van een poliklinische patiënt over het algemeen een aanbeveling voor “SubstanceAdministration” en een verzoek tot Levering bevat.

Dit gedeelte van het patroon zal verder worden geharmoniseerd met Farmacie.

De waardenset voor “Supply.moodCode (CNE)” is volgens het RIM.

De Supply (Levering) klasse representeert het distribueren, terwijl de “SubstanceAdministration” klasse de toediening administreert. Prescripties zijn complexe activiteiten die zowel een toedieningsaanvraag aan de patiënt (bijvoorbeeld neem één maal per dag 0.125mg digoxin via de mond) als een leveringsverzoek aan de apotheek (bijvoorbeeld: lever 30 tabletten met 5 navullingen) inhouden. Dit zou in een CDA gepresenteerd moeten worden door een “SubstanceAdministration” registratie dat een “Supply component” registratie heeft. De geneste “Supply registratie” kan de “Supply.independentInd” op “false” hebben staan om aan te geven dat de “Supply” niet op zichzelf kan staan, zonder zijn omsluitende “SubstanceAdministration”.
procedure

Een afgeleide van de “RIM Procedure klasse”, gebruikt voor het representeren van procedures.

Een “act” waarvan de directe en voornaamste uitkomst (postconditie) de wijziging is van de fysieke conditie van het subject.

Omvat het aanvragen, aanbevelen, beloven, verbieden of weigeren van het uitvoeren van een procedure, als ook de daadwerkelijke act van het aanvaarden van de procedure.

De waardenset voor “Procedure.moodCode (CNE)” is volgens het RIM.

Wanneer de “Procedure.negationInd” “true” is, is dat een positief verklaring dat de beschrijvende attributen van de Procedure as geheel worden ontkend. De inerte eigenschappen, zoals “Procedure.id”, “Procedure.moodCode” en participaties worden niet ontkend. Deze inerte eigenschappen hebben altijd dezelfde betekenis, zo blijft de auteur bijvoorbeeld de auteur van een negatieve Procedure. Een procedure bewering met “negationInd” is nog steeds een bewering over het specifieke feit beschreven door de Procedure. Bijvoorbeeld: een ontkende "blindedarmoperatie uitgevoerd" betekent dat de auteur positief ontkent dat er ooit een blindedarmoperatie is uitgevoerd en dat hij dezelfde verantwoordelijkheid neemt voor zo’n statement en dezelfde eis om bewijs te hebben voor zo’n statement als wanneer hij de ontkenning niet gebruikt had.


encounter (afspraak)

Een interactie tussen een patiënt en zorgverlener(s) met tot doel het leveren van zorggerelateerde dienst(en). Zorgdiensten omvatten ook de zorg bepaling.

Merk op dat dit type bewering toelatingen, ontslagen en overdrachten van zorg omvat als ook het meer gebruikelijke begrip van een afzonderlijk, discreet bezoek, consult of visite.

Verder handelt het een plan af voor regelmatige bezoeken, zoals preventieve zorg tijdens zwangerschap of het monitoren van chronisch zieke patiënten.

Omvat het aanvragen, voorstellen, beloven, verbieden of weigeren van een encounter, als ook de daadwerkelijke encounter gebeurtenis.

Een afgeleide van de “RIM PatientEncounter klasse”, gebruikt voor het representeren van gerelateerde “encounters”, zoals follow-up bezoeken of vorige encounters waaraan gerefereerd wordt.

De waardenset voor “Encounter.moodCode (CNE)” is volgens het RIM.
organizer

Een afgeleide van de “RIM Act klasse”, welke gebruikt kan worden voor het creëren van arbitraire groepen van andere “clinical statements” die een gemeenschappelijke context delen. Een “Organizer” kan andere “Organizers” en/of ander klinische beweringen bevatten, door het doorkruisen van een component relatie. Een “Organizer” kan verwijzen naar “acts” via een referentie of via de component relatie. Een “Organizer” kan niet de bron zijn van de “sourceOf1”, “sourceOf2”, Definitie of conditie relaties.

“Organizer” van registraties. Dit is een “organizer” van registraties voor navigatie. Bevat geen semantische inhoud. Kennis van de actiecode is niet vereist voor het interpreteren van opgeslagen observaties. Representeert een titel in een hiërarchische structuur of “organizer boom”.

De dossier registraties die gerelateerd zijn aan een alleenstaande klinische sessie worden meestal gegroepeerd onder titels of rubrieken die fasen van de encounter representeren of assisteren met lay-out en navigatie. Klinische titels reflecteren meestal de klinische werkprocessen tijdens een zorgsessie en kunnen ook de redeneringsprocessen van de auteur weergeven. Veel onderzoek heeft uitgewezen dat titels verschillend worden gebruikt door verschillende groepen professionals en specialisaties en dat titels niet consequent genoeg gebruikt worden om veilige automatische verwerking van het Elektronisch Patiënten Dossier te ondersteunen.

Verscheidene specifieke typen van verzameling worden herkend (map, compositie, onderwerp, categorie, cluster en batterij), hoewel individuele communicatie de typen die gebruikt kunnen worden voor use cases van individuele communicatie zullen beperken.

Een “Organizer” kan over het algemeen een SNOMED CT “concept identifier” toegewezen worden die geschikt is voor zijn type (bijvoorbeeld: een categorie kan geïdentificeerd worden als 'investigations' en een batterij kan geïdentificeerd worden als ‘Full blood count’). Echter, alle soorten “concept identifiers” kunnen gebruikt worden.

De “Organizer” kan gebruikt worden om “Clinical Statements” te harmoniseren met de CEN/ISO 13606 standaard.

Merk op: “Clinical Statement ActChoice Acts” zoals “Organizers” kunnen ook andere “ActChoice Acts” bevatten door de “sourceOf2” klasse te gebruiken. Er is geen eis dat de registratie van de “Organizer” gebruikt moet worden om klinische beweringen te groeperen. De waardenset voor “Organizer.moodCode (CNE)” is volgens het RIM.


act klasse

Een afgeleide van de “RIM Act klasse”, te gebruiken wanneer andere meer specifiek klassen niet geschikt zijn.

Attributen van de “Act Klasse”:

“Act.negationInd”: wanneer deze ‘true’ is, is het een positieve bevestiging dat de beschrijvende attributen van de “Act” als geheel worden ontkend. De inerte eigenschappen zoals “Act.id”, “Act.moodCode” en de participaties worden niet ontkend. Deze inerte eigenschappen hebben altijd dezelfde betekenis, zo blijft de auteur bijvoorbeeld de auteur van een negatieve “Act”. Een “act statement” met “negationInd” is nog steeds een bewering over het specifieke feit beschreven door de “Act”. Bijvoorbeeld: een ontkende “bevinding van kortademigheid op 1 juli” betekent dat de auteur positief ontkent dat er kortademigheid was op 1 juli en dat hij/zij dezelfde verantwoordelijkheid voor zo’n bewering neemt en dezelfde eis om bewijs te hebben voor zo’n statement als wanneer hij/zij de ontkenning niet gebruikt had.


De waardensets voor “Act.moodCode (CNE)” zijn gedefinieerd in het RIM.

“Clinical statement pattern” gebruikt het “Act.negationInd”” attribuut. Wanneer deze ”true” is, is het een positieve bevestiging dat de beschrijvende attributen van de “Act” als geheel worden ontkend. De inerte eigenschappen zoals “Act.id”, “Act.moodCode” en de participaties worden niet ontkend. Deze inerte eigenschappen hebben altijd dezelfde betekenis, zo blijft de auteur bijvoorbeeld de auteur van een negatieve “Act”. Een “act statement” met “negationInd” is nog steeds een bewering over het specifieke feit beschreven door de “Act”. Bijvoorbeeld: een ontkende “bevinding van kortademigheid op 1 juli” betekent dat de auteur positief ontkent dat er kortademigheid was op 1 juli en dat hij/zij dezelfde verantwoordelijkheid voor zo’n statement neemt en dezelfde eis om bewijs te hebben voor zo’n statement als wanneer hij/zij de ontkenning niet gebruikt had.


attributen van Clinical Statements

Over het algemeen volgt het gebruik van attributen binnen klassen die de “Clinical Statements” representeren de standaard HL7 v3 regels.


moodCode

De HL7 v3 modelleeraanpak volgend kunnen de meeste klassen binnen het “ClinicalStatement” een “moodCode” toegewezen krijgen die aangeeft of er sprake is van een daadwerkelijke gebeurtenis of van het uiten van een verzoek, voorstel, belofte, afspraak of doel. De enige uitzondering is “Organizer.moodCode” welke altijd de waarde “EVN”heeft.

Het gebruik van “moodCode” overlapt met SNOMED CT context attributen. De SNOMED CT “concept identifiers” en “expressions” die gebruikt worden in het code attribuut moeten de “moodCode” niet tegenspreken. Het “Terminfo project” levert begeleiding bij de verbinding tussen “moodCode” en het SNOMED CT context model voor de verschillende klassen in het “Clinical Statement” patroon.
id

Elke instantiatie van een “Clinical Statement” zou geïdentificeerd moeten worden door middel van een id in de vorm van een “UUID (Universal Unique IDentifier)”. Dit identificeert de specifieke “Clinical Statement” op een unieke manier, zodat wanneer precies dezelfde informatie (statement en context) vereist wordt, gerefereerd aan of dezelfde communicatie of in andere communicatie, dat dan dezelfde identifier waarde gebruikt zal worden in een “ActReference” om aan de originele “Clinical Statement” te refereren.

Omgekeerd, als niet alle attributen en context van een “Clinical Statement” klasse identiek zijn, dan is er sprake van een andere “Clinical Statement” en dan zal een nieuwe “UUID” toegewezen worden. Dit betekent:


  • een subset van een “Clinical Statement” is een andere “Clinical Statement”, die een andere “UUID” vereist;

  • een “Organizer” waarvan één van de 'contained' statements wordt gemodificeerd is een nieuwe statement die een nieuwe “UUID” vereist.

Het “clinical statement” patroon staat toe dat “Clinical Statements” meerdere identifiers bevatten. Dit maakt het mogelijk dat “Clinical Statements” geïdentificeerd kunnen worden door een ”human readable identifier” in aanvulling op de “UUID” en zal altijd gerepresenteerd worden door een OID en code waarde. Het gebruik hiervan zou identifiers kunnen bevatten als bestelnummer van de afdeling, nummer van de episode, etc. wanneer dit vereist is door specifieke communicatie use cases.


code

Het code attribuut wordt gebruikt om de aard van de informatie, die overgedragen wordt door een instantiatie van een “Clinical Statement Act”, vast te stellen. Code kan in sommige specificaties optioneel zijn. De cardinaliteit en de conformatie van het code attribuut in de Observatie in act is 1..1 vereist. Terwijl het attribuut aanwezig moet zijn in alle instantiaties van de Observatie is het toegestaan om een null flavor te versturen als legale waarde. Het HL7 v3 data type van het code attribuut is CD (Concept Descriptor). Het CD data type staat de inclusie toe van:



  • de tekst die door het coderingsschema toegewezen wordt aan de code (displayText) en de tekst waarop de encodering gebaseerd was (originalText);

  • “qualifiers” en het type, gebruikt in SNOMED CT (inclusief context attributen) om de betekenis van een primaire code te verfijnen;

  • elke “qualifier” is een naam + waarde paar waarbij de naam is uitgedrukt in een code en de waarde als een andere instantiatie van het CD data type (met toestemming voor nested qualifiers, wanneer nodig);

  • vertalingen om de representatie van het concept toe te staan in het coderingsschema waarin het ontstaan is als ook zoals vertaald in andere geprefereerde terminologieën.

  • merk op dat de originele code wordt uitgedrukt op het buitenste niveau met daarbinnen de vereiste code (als deze anders is) uitgedrukt als een vertaling. De mogelijkheid de originele codes te herkennen is van belang om toekomstige vertalingen, gebaseerd op verbeterde mapping, mogelijk te maken. Dus, als de data van origine gecodeerd was in een ander coderingssysteem, moet de originele code toegevoegd zijn bij de vertaling die de SNOMED CT representatie bevat.

Het CD data type ondersteunt het gebruik van pre en postcoördinatie van vocabulaire uitdrukkingen en dit model stelt geen restricties aan hoe deze expressies worden gepresenteerd, anders dan de beperkingen opgelegd door de respectieve terminologieën.


value (waarde)

“Observation.value” is informatie die toegewezen of bepaald wordt door de observatie actie.

De vraag is nu hoe “Observation.code” en “Observation.value” moeten worden ingevuld. Terwijl dit kenmerkend rechtlijnig is voor laboratorium observaties, kan het vaag worden voor andere typen observaties, zoals bevindingen en stoornissen en familiegeschiedenis. Het HL7 Terminfo Project heeft principes gedefinieerd voor verschillende manieren om deze twee attributen te gebruiken. De klinische terminologie die wordt gebruikt als code attribuut is de SNOMED Clinical Terms (CT).

Het data type van het “Observation.value” attribuut varieert en waar de uitdrukking in een “Observation.code” een waarde vereist, wordt de subset van toegestane data typen beperkt door de code. Als de “PQ data type” wordt gebruikt, dan moeten de “UCUM codes” worden gebruikt om de meetunits te representeren.


priorityCode

Het “priorityCode” attribuut heeft een potentiële overlap met sommige vocabulaires. Het potentiële conflict kan als volgt opgelost worden:



  • “priorityCode” zou alleen gebruikt moeten worden om de urgentie, waarmee de ontvanger van het bericht zou moeten reageren op de informatie in de “Act”, aan te geven. Bijvoorbeeld: het verzoek voor een procedure zou als dringend beschouwd moeten worden. Daar uit voortvloeiend is het wenselijk dat het gebruik van “priorityCode” gelimiteerd zou moeten worden tot “acts” die in de “Intent mood” zijn;

  • “Act.code” vocabulaire expressies zouden gebruikt moeten worden om de klinische urgentie van de expressie die in het code attribuut staat aan te geven. Bijvoorbeeld: het concept ‘een nood blindendarmoperatie’ zou in z’n geheel binnen een “Act.code” weergegeven worden.


Act.code afhankelijke attributen in het Clinical Statement model

Sommige gecodeerde attributen die opgenomen zijn in het HL7 v3 RIM zijn met opzet optioneel gemaakt in “Act” klassen in dit model, omdat zij kwalificaties representeren die binnen het terminologie model beter afgehandeld worden (bijvoorbeeld het gebruiken van SNOMED CT beperkingen binnen het code attribuut, waar mogelijk). Deze omvatten:



  • “negationInd”;

  • “uncertaintyCode”;

  • “priorityCode”;

  • “statusCode”;

  • “observation.methodCode”;

  • “observation.targetSiteCode”;

  • “procedure.methodCode”

  • “procedure.targetSiteCode”;

  • “procedure.approachSiteCode”.

De basis voor het als optioneel beschouwen van deze attributen is dat flexibiliteit is vereist bij domeinen om de gekozen vocabulaire te implementeren zonder ambiguïteiten.


Zulke ambiguïteiten kunnen gerelateerd zijn aan het feit of een bepaald concept in een “Act.code” expressie of in een andere “Act” klasse attribuut waarde wordt opgenomen. Het terminfo project geeft aan hoe de attributen moeten worden gebruikt in de modellen en berichten als SNOMED CT het gebruikte codesysteem is.
het linken van Statements

Het model reikt drie mechanismen aan die het mogelijk maken “Clinical Statements” te linken door de “Act Relationship” Klasse:



  • inhoud (Containment);

  • directe relatie;

  • referentie.

Dit zijn allemaal verfijningen van dezelfde algemene structuur en delen de volgende faciliteiten:



  • “inversionInd”; wanneer “true” verandert het de richting van de relatie, ‘Oorzaak van’ wordt bijvoorbeeld ‘Veroorzaakt door’ (zie Context en Overerving (Inheritance) voor hoe dit werkt bij Context Overerving);

  • “negationInd”; wanneer “true”staat dit de zender toe om specifiek aan te geven dat de relatie niet van toepassing is. Bijvoorbeeld dat een observatie niet veroorzaakt werd door een medicijn.

Er is enige overlap in het potentiële gebruik van deze 3 relatie mechanismen wat op de volgende manier opgelost zal worden:


containment

Het groeperen van klassen van klinische/zorginhoudelijke data wordt bereikt door het gebruiken van verzamelklassen zoals de “Organizer klasse” (een specialisatie van de Observatie klasse code) geassocieerd met een “Component' Act Relatie” die terugkeer van de “Clinical Statement”structuur ondersteunt.

Het groeperen kan voor verschillende doeleinden gebruikt worden, inclusief:


  • beweringen met elkaar in verband brengen. Bijvoorbeeld: een zwangerschapscontrole kan individuele observaties bevatten van gewicht van de moeder, bloeddruk van de moeder, grootte van de foetus, hartslag van de foetus, etc.;

  • beweringen die gerelateerd zijn aan een specifiek probleem, in het geval van een “Concern”, met elkaar verbinden. (Zie hiervoor de specifieke uitwerking bij Care Provision).

“Organizer”: Het toegestane type van groeperen wordt beperkt door de vocabulaire die gebruikt wordt in het “Organizer.code attribuut”. Specifieke vocabulaire beperkingen zullen in individuele communicatie ontwerpen toegepast worden, gebaseerd op de communicatie eis die aangesproken wordt.


directe relatie

Dit verbinden wordt ondersteund door het terugkeren op het “Clinical Statement”, met “ActRelationship.typeCode” die de aard van de link tussen de beweringen ondersteunt. Het wordt gebruikt om een “Clinical Statement” toe te voegen aan een communicatie die relateert aan een andere toegevoegde “Clinical Statement”, maar niet direct relevant is voor de “Focal Act”, bron “Act” of doel van de communicatie.

Een voorbeeld is een vorige observatie die tijdens een contact (encounter) is gedaan en die een huidige observatie verklaart. In dat geval wordt de vorige conditie alleen toegevoegd aan de communicatie om de observatie te verklaren en niet omdat het werd geïdentificeerd tijdens het contact (encounter).

Daar waar de ondersteunde “Clinical Statement” al beschikbaar is van een vorige communicatie kan de link via referentie-aanpak gebruikt worden om dit type van linken over te brengen.


referentie

Het linken van “Clinical Statements” door referentie wordt ondersteund door de “sourceOf1” “Act Relatie” tussen de “Clinical Statement” en “ActReferentie”, weer met “typeCode” die de aard van de link specificeert. Er zijn drie gevallen voor het gebruik:



  • voor het handhaven van een link naar een “Clinical Statement” die al in een communicatie-instantiatie aanwezig is voor een ander doel, waardoor onnodige duplicatie voorkomen wordt;

  • voor het handhaven van een link naar een “Clinical Statement” die direct gerelateerd wordt aan het doel van de communicatie maar die gestuurd is als deel van een eerdere notificatie;

  • om een link naar een “Clinical Statement” die al beschikbaar is als een resultaat van een niet-gerelateerde communicatie.

De “ActReference.classCode” en “ActReference.moodCode” zullen de waarden aannemen van de doel “Act”, en “ActReference.id” is de “UUID” van het doel “Clinical Statement”.


context en Overerving (Inheritance)

Hoewel potentieel complex, context overerving biedt een essentiële faciliteit die:



  • de noodzaak elimineert om de volledige context van elke Clinical Statement expliciet te specificeren, zoals in het algemene geval kan dit geërfd worden van de bron statement;

  • een mechanisme aanreikt dat toestaat dat specifieke items van context opgeheven worden wanneer dit gepast is. Bijvoorbeeld: de 'auteur' van een resultaat van een reeks (battery) wordt geacht de auteur te zijn van alle componenten, maar elke test binnen de reeks zou door een andere persoon of apparaat uitgevoerd kunnen zijn.

Volgens de HL7 v3 afspraken specificeert de bron klasse (de klasse aan de botte kant van de SourceOf pijl) altijd de context waarin de “SourceOf” van kracht was. Dus deze bron klasse geeft de toekenning van de link aan (tijd, auteur, etc.). De semantische richting van het relatietype (zoals aangegeven door SourceOf.typeCode) kan omgekeerd worden door het gebruiken van de “inversionInd”. Omdat dit niet de bijbehorende context omkeert staat het toe dat de volledige omvang van richtingsrelaties uitgedrukt wordt van de context van één van de gerelateerde klassen.

De “seperatableInd” in een “Act Relatie” geeft aan of de auteur bereid is voor de inhoud van de bron “Act” in te staan als het wordt gescheiden van de doel “Act”. Een waarde ”false” geeft aan dat het de bedoeling is dat de twee “acts” niet gescheiden worden voor interpretatie. Dit kan duidelijk niet opgelegd worden, maar is bedoeld als een waarschuwing voor de ontvanger van de bedoeling van de auteur. De waarde van de “seperatableInd” wordt niet buiten de doel “Act” verspreid, ongeacht andere context overerving.

Alleen als een “Act Relatie” specifiek het tegenovergestelde aangeeft (een waarde “true” in de “contextConductionInd”), wordt de context niet overgeërfd van de bron naar het doel.

Als de “contextConductionInd” in een “Act Relatie” op “false” wordt gezet dan wordt niets van de context van de bron “Act” geërfd door de doel “Act”. Echter, als de waarde op ”true” wordt gezet wordt alles van de context geërfd, behalve de Participaties in de bron “Act”waar de “contextControlCode” op een ”non-propagating” waarde wordt gezet. Waar een specifieke Participatie wordt meegegeven aan een “Act”, overschrijft dit elke geërfde Participatie van hetzelfde type, behalve als de “contextControlCode” naar een “additive” waarde wordt gezet wanneer de specifieke Participatie als een toevoeging aan de geërfde waarde is (bijvoorbeeld: er zijn meerdere Participaties van hetzelfde type). Context die op deze manier geërfd is, wordt beperkt tot Participatie in een “Act”. Zie de RIM sectie van de HL7 v3 Standaard.

“Act Relaties” die een “ActReference” als hun doel hebben, voeren nooit de context aan, omdat de context van de “Clinical Statement” waar aan gerefereerd wordt, wordt gedefinieerd op basis zijn originele setting.


patiënten

De patiënt wordt gezien als het Subject van iedere “Clinical Statement” in de communicatie behalve wanneer het expliciet wordt aangegeven dat dit niet het geval is voor de gespecificeerde statement(s). Dit kan op één van de volgende manieren aangegeven worden:



  • de “Clinical Statement” heeft een subject participatie die details van de persoon aan wie de statement gerelateerd is geeft;

  • optioneel, in sommige domeinen, heeft het SNOMED CT concept in het code attribuut een context die refereert aan iemand anders dan de patiënt, bijvoorbeeld: Vader heeft een geschiedenis van Diabetes;


deelnemers (Participants)

“Clinical statements” kunnen verschillende deelnemers hebben. Deelnemers, verspreid door de “focal” of bron “Act”, kunnen te niet gedaan worden binnen de “clinical statement”. Deze participaties bevatten:



  • “recordTarget”;

  • subject;

  • “authors“

  • “performer”;

  • “informant”;

  • “dataEnterer”;

  • “verifier”;

  • “responsibleParty”;

  • “consumable”;

  • “product”;

  • “location”.

“Clinical Statements” kunnen verschillende deelnemers hebben. Deelnemers, verspreid door de “focal” of bron “Act”, kunnen te niet gedaan worden binnen de “clinical statement”. De waardensets voor “typeCodes (CNE)” en “contextControlCodes (CNE)” voor alle deelnemers zijn gedefinieerd in de RIM.


recordTarget

De record target is de entiteit waarvoor de “Clinical Statement” wordt vastgelegd. De target entiteit informatie wordt opgenomen in de “R_Patient CMET”.

De waardensets voor “recordTarget.typeCode (CNE)” en “recordTarget.contextControlCode (CNE)” zijn gedefinieerd in de RIM.
auteur

Representeert de mensen en/of machines die het document geautoriseerd hebben. Dat kan een toegewezen persoon/organisatie, zoals een zorgverlener of een familielid zijn (R_AssignedEntity) of de patient zelf (R_Patient). De auteur kan worden toegewezen aan een “clinical statement” die waarden vanuit de “focal or source act” overschrijft en gevolgen heeft voor geneste “Acts”.

De waardensets voor “author.typeCode (CNE)” and “author.contextControlCode (CNE)” zijn gedefinieerd in de RIM.

Een auteur is een persoon in de rol van een verzorger, patiënt of gerelateerde entiteit. De auteur-participant is gerelateerd aan een clinical statement waar het de waarde(n) vastlegt in een bron act.


consumable (het gebruikte)

De “consumable” participatie wordt gebruikt om de toegediende substantie te beschrijven. Dat kan zijn een “R_Medication CMET” of “AdministerableMaterial” entiteit. Het geproduceerde materiaal in de “R_Medication CMET” of de “Material klasse”, identificeert het medicijn dat volgens de substance administratie is genomen. De entiteit Materiaal wordt gebruikt voor het identificeren van toegediende substanties die geen medicatie zijn, zoals vaccines en bloedproducten.

De set waarden voor “consumable.typeCode (CNE)”, “ManufacturedProduct.classCode (CNE)”, “LabeledDrug.classCode (CNE)”, “Material.classCode (CNE)”, en “Material.determinerCode (CNE)” zijn gedefinieerd in de RIM.
informant

Een informant (of bron van informatie) is een persoon die relevante informatie levert, zoals de ouder van een comateuze patiënt die het gedrag van de patiënt van voor de coma beschrijft. Dit kan een aangewezen persoon of organisatie zijn (R_AssignedEntity) zoals een verzorger, gerelateerde partij zoals een familielid of raad, of de patiënt zelf (R_Patient). De “RelatedEntity” rol wordt gebruikt om een informant zonder “rol.id” te representeren (bijvoorbeeld een ouder of een man op straat). In dat geval heeft de informant enige formele of persoonlijke relatie met de patiënt. “RelatedEntity.code” kan gebruikt worden om de aard van de relatie te specificeren.


De “R_AssignedEntity” rol wordt gebruikt voor een geïdentificeerde informant en wordt bereikt (scoped) door een Organisatie.

De informant participant kan toegewezen worden aan een “clinical statement” waar het de waarde(n) onderdrukt van de “focal” of bron “Act” en verspreidt aan geneste “Acts”.

De waardensets voor de “informant.typeCode (CNE)”, “informant.contextControlCode (CNE)” en “RelatedEntity.classCode (CNE)” zijn gedefinieerd in de RIM.
uitvoerder (performer)

De performer is een persoon die een bepaalde “act”, of delen van een “act”, uitvoert of uit zal voeren. De “performer” hoeft niet de voornaamste verantwoordelijke deelnemer te zijn, bijvoorbeeld een arts-assistent die onder de verantwoordelijkheid van een aanwezige chirurg valt is een “performer”. De waardenset voor “performer.typeCode (CNE)” is gedefinieerd in de RIM.


product

Het uitgereikte product wordt geassocieerd met de “Supply act” via een product participant, die aan de “ManufacturedProduct rol” verbonden is. Dit kan een “LabeledDrug entity” of Materiaal zijn. De waardenset voor “product.typeCode (CNE)” is gedefinieerd in de RIM.


component

De component relatie heeft “Organizer” als bron (zie Organizer, en een doel dat een andere Clinical Statement is en wordt gebruikt om groepen clinical statements binnen een Organizer te maken). De waardenset voor “component.typeCode (CNE)” is gedefinieerd in de RIM.


condities

De preconditie klasse, afgeleid van de “ActRelatie klasse”, wordt gebruikt naast de

“Criterion klasse” om een conditie uit te drukken die waar moet zijn voordat enkele over-activiteit “Clinical Provision” ontstaat.
referenceRange

De “referenceRange relatie” (zie de beschijving bij Observatie), heeft een Observatie als bron en een doel dat een andere “CDA entry” is.


sourceOf2/targetOf

“Clinical Statement” heeft verschillende link scenario’s geïdentificeerd en gemodelleerd. Deze scenario’s maken het mogelijk dat “ActChoice Acts” semantisch gelinkt kunnen worden aan “Acts” die bestaan binnen hetzelfde document of bericht.

Merk op: Het “Clinical Statement” model staat toe dat elke “ActChoice Act” aan elke “ActChoice Act” gerelateerd kan worden door één van de volgende relatietypen te gebruiken. In veel gevallen zou dit resulteren in onzinnige relaties.

De “sourceOf2.inversionInd” kan op "true" gezet worden om aan te geven dat de relatie geïnterpreteerd zou moeten worden alsof de rollen van de bron en het doel entries omgekeerd waren. In het voorbeeld in de bovenstaande Tabel, "tredmolen test" RSON (has reason) "pijn op de borst". Omgekeerd, zou deze "pijn op de borst " als de bron en " tredmolen test " als het doel hebben: "pijn op de borst" RSON (inverted) "tredmolen test". Omkeren kan nuttig zijn wanneer de huidige context het doel van een act relatie beschrijft die teruggerelateerd moet zijn aan de bron.

De “actRelationship.contextConductionInd” verschilt van het anders zo algemene gebruik van dit attribuut waarbij in alle gevallen waarin dit attribuut wordt gebruikt de waarde vaststaat op "true", terwijl hier de default waarde op "true" staat en veranderd kan worden naar "false" wanneer gerefereerd wordt aan een “entry” in hetzelfde document. Het naar “false “zetten van de context wanneer gerefereerd wordt aan een entry in hetzelfde document houdt het feit duidelijk dat het object waar aan gerefereerd wordt zijn originele context behoudt.
sourceOf1

De “Clinical Statement” heeft diverse referentie scenario’s geïdentificeerd en gemodelleerd. Deze scenario’s maken het mogelijk dat “ActChoice Acts” semantisch kunnen worden verbonden aan “Acts by reference” die bestaan binnen hetzelfde document/bericht of horen bij “external Acts”.

Elk object heeft een “identifier”.
Act Buiten de Clinical Entry Keuzebox

NOTE: Dit gedeelte moeten worden uitgebreid met statements over wanneer de strategie wordt gebruikt, wat het betekent voor het Patroon, etc.


  1. Conclusie

In deze gids zijn de belangrijkste onderdelen voor Nederland opgenomen. De HL7 v3 Standaard Care Provision is uitgebreider dan hier is besproken. Voor Nederland zijn die aanvullende items mogelijk van belang en die kunnen in de toekomst worden opgepakt.



Naast deze generieke implementatiehandleiding is per project een nadere specificatie noodzakelijk. Die wordt in een domein specifieke aanvulling per project uitgewerkt. Concrete voorbeelden zijn voor PRN en de WMO.

1 Uitleg van het Care Provision Domein Message Informatie Model (D-MIM) volgt in hoofdstuk 2.

2 Prica D-MIM is het domein model voor het Waarneem Dossier Huisartsen

3 Care Provision Focal Class is de Care Provision: de centrale Act.

4 CWE staat voor Code with Extensions: er mogen zelf codes worden toegevoegd aan een standaard lijst

5 JCAHO staat voor Joint Commission on Accreditation of Healthcare Organizations. De Joint Commission, tot 2007 de Joint Commission on Accreditation of Healthcare Organizations (JCAHO,), is een non-profit organisatie, USA gebaseerd, opgericht in 1951, met de volgende missie: het behouden, en verhogen van de standaarden voor de zorgverlening door evaluatie en accreditatie van gezondheidszorgorganisaties. Bezocht 20 november 2007. (http://en.wikipedia.org/wiki/Joint_Commission_on_Accreditation_of_Healthcare_Organizations.

6 CMET’s: Common Message Elements Types

7 De Focal Class van dit R-MIM is de Care Provision klasse


1   ...   12   13   14   15   16   17   18   19   20

  • Clinical Statement Patroon (COCS_DM000000)
  • Conclusie

  • Dovnload 4.78 Mb.