Thuis
Contacten

    Hoofdpagina


Generieke implementatiehandleiding care provision d-mim

Dovnload 4.78 Mb.

Generieke implementatiehandleiding care provision d-mim



Pagina5/20
Datum25.10.2017
Grootte4.78 Mb.

Dovnload 4.78 Mb.
1   2   3   4   5   6   7   8   9   ...   20

Care Statement Structuur Overzicht (januari 2007)




      1. Bereik van de Care Statement Structuur Domein

Het “Care Structures topic” definieert de vele UML klasse diagrammen, de zgn. “Care Structures”, die de informatie pertinent aan de voortdurende zorgverlening modelleren. Deze worden beschreven als lokale “CMET’s” die lokaal zijn voor het “Care Provision” Domein. Deze lokale “CMET’s” zullen worden opgenomen in de groep van gedeelde HL7 “CMET’s” als deze lokale “CMET’s” de ballot passeren op domein niveau. Deze “CMET’s” of bouwstenen binnen het “Care Provision” Domein representeren herbruikbare objecten in grote modeldiagrammen.


In vele gevallen, handhaven deze structuren de basis van de verantwoordelijkheid voor zorg door het aangeven van de “concerns” en zorgplannen als componenten van de verantwoordelijkheden gekoppeld aan de scope (als bereik of aandachtsgebied). De Care Structures vertegenwoordigen de variabele delen van een communicatie met betrekking tot de verantwoordelijkheid voor de “Care Provision”. Zoals beschreven in de scope van het “Care Provision” Domein, wordt deze zorg geleverd aan individuen, populaties en andere doelen van zorg en communicatie. Deze informatie is ontworpen om de samenwerking tussen zorgverleners te ondersteunen. Dit “Care Structures” topic bestaat onder het “Care Provision” Domein. Voor een volledige beschrijving van het domein en een discussie van de verantwoordelijkheid van zorg wordt verwezen naar het “Care Provision Domein” Overzicht.
Type informatie die gemodelleerd wordt in de Care Structures:

  • “basic Care Statements”, i.e. ruwe data met minimale samenvatting of interpretatie (bijv. gewicht, lengte, bloeddruk);

  • informatie in een samenvating gecreëerd in lijsten (bijv. lijsten van medicatie, operaties);

  • “judgment-related Care Statements” (bijv. lijsten van problemen, allergieën, diagnostische schalen zoals depressieschaal, Barthel index voor activiteiten voor het dagelijks leven of valrisico voor patiënten);

  • zorgplannen en hun gerelateerde richlijndefinities (wat is gedaan, wat moet nog, wie is verantwoordelijk );

  • beweringen over toestand van verzorgers van de patiënt (bijv. familieleden).

Natuurlijk zal de pertinente informatie die wordt bijgesloten in een individuele communicatie variëren afhankelijk van de behoefte van de patiënt en de behoeften van de samenwerkende zorgverleners. Door “Care Structures” toe te voegen aan run-time berichten kunnen de berichten worden uitgebreid als dat nodig is.


Het “Care Structures topic” refereert aan het domein “Clinical Statement” Patroon (waarvan de beschrijving is opgenomen in een apart document) en begeleidt lezers hoe specifieke Clinical Statement kwesties te ballotten. Alleen “Care Provision” aanpassingen van het “Clinical Statement” Patroon zullen worden geballot in de “Care Structure topic”. Specifieke “Care Structures” bevatten de “Concern Tracking” Structuur, de “Care Plans/Guidelines” Structuur, en “Assessment" structuren, alsmede de meest belangrijke zorgstructuur, de “Care Provision” Domein versie van de “Clinical Statement” keuzebox waar naar verwezen wordt in dit topic als de “Care Statement Structure”.

2.5.2 Grenzen van het bereik

“Care Structuren” zijn niet bedoeld om alle informatie te representeren die gecommuniceerd wordt door systemen die gedetailleerde pertinente informatie voortbrengen, zoals observatiegegevens of persoonsregistratiegegevens. Domeinen die de communicatie ondersteunen van deze data genererende systemen, voorzien vaak in veel meer details, gezien de complexe data context waarin de data worden gegenereerd. De bedoeling van “Care Structuren” is de ”instance identifiers” te communiceren en de meta data voor deze kleine instantiaties, zodanig dat het ontvangende systeem genoeg informatie heeft om queries te verzenden voor meer details over bepaalde items van pertinente informatie. Daarbij wordt aangenomen dat de verzendende systemen queries en instance identifiers ondersteunen. Echter, andere implementatie specificaties kunnen deze scope op “Information Content” uitbreiden om meer detail te vereisen in de originele communicatie en minder afhankelijk te zijn van queries en respons methodologie.


Deze “Care Structures” kunnen verder beperkt worden voor gebruik in andere “Care Provision” Domein topics en/of implementatiehandleidingen van verschillende commissies en organisaties buiten HL7. Het is NIET de bedoeling dat dit “Care Provision” topic alle mogelijke beperkingen op deze meer algemene “Care Structures” beschrijft. Binnen de templates werkgroep wordt gezocht naar eenduidige structuren die wel de details en beperkingen specificeren en binnen de ”Care Statement” structuur passen en kunnen leiden tot nadere detaillering in berichten.

2.5.3 Plaatsing van Care Structuren in het Care Provision Domein Model:

De structuren rechts van de “Care Proivision Act” worden hieronder beschreven:


samenvatting van de “Care Structuren of Care Structures”

De “Care Structures topic” is bedoeld als een bibliotheek van herbruikbare en te vervangen “care structures” of Detailed Clinical Models uit de “Care Provision D-MIM” die opnieuw te gebruiken zijn. Op dit moment levert de topic alleen de kern structuren waarvan specifieke “care structures ”, zoals bloeddruk en allergieen, kunnen worden afgeleid. Sommige van deze specifieke “care structures” worden geleverd als informatieve voorbeelden:

Normatieve Care Structuren:


  • “Care Statement”;

  • “Composition Content”;

  • “Statement Collector”;

  • “Concern Tracking Structure”;

  • “Care Provider”;

  • “Care Target”;

  • “Involved Person”;

Informatieve “Care Structures” zijn vooralsnog opgenomen als zorginformatiemodellen:



  • Blood Pressure (Bloeddruk);

  • Heart Rate (Hartslag);

  • Weight (Gewicht);

  • Height (Lengte);

  • Allergy (Allergie);

  • Barthel Index.


local CMET's

De “Care Structuren” in deze sectie zijn locale “CMET’s” (lokaal voor het Care Provision Domein). Een “Care Structuur CMET” gebruikt de “Common Message Element Type” benadering om herbruikbare structuren weer te geven en te gebruiken in het “Care Provision” Domein, welke afgeleid zijn van zijn “D-MIM”. De “CMET” wordt gebruikt om deze complexe “care structuren” te representeren die worden gebruikt in meerdere “RMIM’s”. Dit vereenvoudigt de “R-MIM” dramatisch wat toestaat dat de focus nu op de focale klasse en de associatie ligt, terwijl de vervanging van de beperkte “CMET” ondersteund wordt voor een universele “CMET”, of bij het ontwerp van het bericht , implementatie of ontwikkeltijd.

Het “Care Plan” (zorgplan), de “Involved Person” (betrokken persoon), de “Care Taker” (zorgverlener) en “Care Target” (doel van zorg) structuren hebben op dit moment geen verder beperkte modellen maar worden nu geleverd als een “Care Structuur” die steeds opnieuw gebruikt kan worden.
Een belangrijk concept in dit topic is de hiërarchie van “Constraints”van de abstracte structuren in het “Care Provision D-MIM”. De “Care Statement” structuur is beperkt tot het definiëren van de “Concern Tracking” Structuur. De “Composition Content” structuur is ook een beperking op de “Care Statement” . Elke van deze beperkingen kan vervangen worden door de “Care Statement” die wordt geassocieerd met het “Care Plan” en de “Statement Collector” structuren, en de “Care Provision Act”.
clinical Statement Pattern

Zoals hierboven vermeld, focust de ballot voor dit document op de uitbreidingen en beperkingen die het “Care Provision Domein” heeft opgelegd aan het “Clinical Statement Patroon”. Deze uitbreidingen of beperkingen zullen duidelijk geïdentificeerd worden in de bespreking van elke “care structure”. Ballot kwesties gerelateerd aan het “Clinical Statement Patroon” zelf zouden verwezen moeten worden naar de “Clinical Statement Pattern” ballot. Ter vergelijking wordt de “Clinical Statement Definitie” vergeleken met de “Care Statement Definitie”.


definitie Clinical Statement

De formele definitie van een “clinical statement” voor patiëntenzorg is:



An expression of a discrete item of clinical (or clinically related) information that is recorded because of its relevance to the care of a patient."
Een uitdrukking van een afzonderlijk item van klinische (of klinisch gerelateerde) informatie dat wordt vastgelegd, omdat het relevant is voor de zorg van een patiënt”.
Klinische informatie bestaat altijd uit stukjes informatie en daarom kan de informatie per bewering qua hoeveelheid en betekenis van informatie erg variëren.

Klinische informatie vereist dat de informatie wordt geassocieerd met een patiënt waarbij duidelijk wordt:



  • zijn tijdelijke context;

  • zijn relatie met de patiënt;

  • in geval van een observatie: zijn moodcode en de aanwezigheid of afwezigheid ervan of een waarde,

  • in geval van een procedure: zijn moodcode en de status.

Deze duidelijkheid kan worden verkregen door:



  • expliciete representatie of;

  • impliciet gebruik van defaults ALLEEN als expliciet regels zijn gemodelleerd die de geschikte defaultwaarde vaststellen.

Het “Clinical Statement Patroon” is een veralgemeniseerd HL7 abstractie patroon dat gebruikt wordt in meer HL7 domein “message information models” die basisdata leveren over het doel van zorg. Dit HL7 patroon kan worden beperkt, uitgebreid, of ongewijzigd gelaten worden door HL7 Technische commissies die dit patroon gebruiken om een domein te definiëren.


care Statement Structure (REPC RM00100)

Als men kijkt naar het “Clinical Statement Patroon” dan ziet men dat er geen grote verschillen zijn tussen dat patroon en de “Care Statement Structure” die in hoofdstuk 7 is uitgewerkt. hieronder.


uitbreidingen op het Clinical Statement Patroon Domein

Het “Clinical Statement Patroon” is hernoemd en heet nu “Care Statement Structuur” in dit “Care Structure topic” om te benadrukken dat zorg zowel betrekking heeft op medische hulpmiddelen, diensten en omgeving/plaatsen als ook op patiënten/ cliënten. In die zin is het vocabulair dat wordt gebruikt om de “Care Statements” te ondersteunen meer uitgebreid dan het vocabulair dat slechts gebruikt wordt om de zorg aan patiënten te ondersteunen. Deze uitbreidingen zullen gedocumenteerd worden door een geleidelijke toename in het aantal en de variëteit van HL7 vocabulair waardensets.


De intentie is dat een instantiatie van een “care statement” door zichzelf kan worden toegevoegd aan de “Care Provision Act” bij het maken van een “R-MIM” of bij “run-time” uitvoering van een applicatie om de variabilitiet van mate en detail te kunnen ondersteunen welke beschreven wordt in de bovenstaande “clinical statement definitie”. Natuurlijk kan de “care statement”toegevoegd worden aan de “Care Provision Act” samen met het toevoegen van andere structuren van het “Care Provision” Domein.

De uitbreiding van de “Clinical Statement” naar “Care Statement” verbreedt de definitie van “Care Statement” naar:

Een uitdrukking van een afzonderlijk item van zorggerelateerde informatie welke wordt vastgelegd, omdat het relevant is voor de zorg van een patiënt / cliënt. Zorginformatie bestaat altijd uit stukjes informatie en daarom kan de informatie per “statement” qua hoeveelheid en betekenis van informatie variëren”.
Om als “Care Statement” te worden beschouwd, moet een concept worden geassocieerd met een “target of care” waaruit blijkt:


  • zijn tijdelijke context;

  • zijn relatie met “ target of care” ;

  • in geval van een observatie: zijn moodcode en aanwezigheid, afwezigheid of waarde;

  • in geval van een procedure: zijn mood en de status.

Duidelijkheid kan worden verkregen door:



  • expliciete representatie of;

  • impliciet gebruik van defaults ALLEEN daar waar expliciet gemodelleerde regels de geschikte defaultwaarden vaststellen.


beperkingen van het Clinical Statement Pattern Domein

  • de veelheid van “ Clinical Statement ActChoice Act identifiers” wordt aangegeven in the “ Pattern” als (0..*), terwijl deze veelheid in de “ Care Statement Act identifiers” is beperkt tot (1..*). De reden voor deze belangrijke beperking is dat het uitgebreide gebruik van “ ActReference” en queries in het “ Care Provision” Domein afhankelijk is van het bestaan van “instance identifiers”. Deze “ instance identifiers” zijn normaal gesproken gegenereerd door het systeem dat de instance (instantiatie) authoriseert. Echter, er bestaan veel strategieën voor “ instance identifiers” en de enige aanname in deze beperking is dat een “ instance identifier” op een unieke wijze de “ instance” identificeert in systemen die bevraagd worden. “ Instances” kunnen afgeschermd gecommuniceerd worden van een zendend systeem naar een ontvangend systeem of interface engine die unieke systeem identifiers toevoegt en dan de “ instances” opnieuw stuurt naar de andere systemen. In dit geval kan het originele systeem niet bevraagd worden. Alleen de systemen die unieke “ instance identifiers” gegenereerd of ontvangen hebben, kunnen bevraagd worden.

  • twee beperkingen zijn toegevoegd aan specifieke “ Care Structure” klassen van de “Infrastructure Root Class” : de “ InfrastructureRoot.realmCode” en de “InfrastructureRoot.templateID” . Deze twee beperkingen zijn bedoeld om gebruikt te worden in “Care Structures” op dezelfde manier als ze gebruikt worden in “ CDA Release 2” documenten. Dat wil zeggen, totdat er overeenstemming is over meer specifieke HL7 methoden voor “templates” , refereert de “ template ID” aan een unieke specificatie handleiding binnen de “ Care Provision topic” . De “ realmCode” wordt dan gebruikt om een “ templateID” verder in te perken, waardoor verschillende “ realms” de mogelijkheid gegeven wordt een specifieke “template” op een unieke manier te gebruiken (vooral door additionele berperkingen op vocabulair gebruik). Alle klassen in de “Care Statement” bevatten de “templateId and realmCode attributen”.

  • “Care Structure Constraints”. Het “Clinical Statement Pattern” is erg algemeen en staat toe dat alle “Clinical Statements” (of in het geval van dit topic, de “Care Statements”) gerepresenteerd worden van recursies op de “ Clinical Statement” keuze. Echter, in de “ Care Structures topic” wordt de “Care Statement” beperkt in het representeren van dezelfde structuur in hetzelfde “RMIM” wanneer een “Care Structure” , afgeleid van het “Care Statement Patroon”, wordt uitgerold en gedefinieerd. Met andere woorden, in één en dezelfde “RMIM” mogen “Concern events” niet dubbel gerepresenteerd worden in zowel de “Concern Tracking Structure” als vanuit “Concern Acts” geconstrueerd uit de “Care Statement”. Daarom handelen de volgende “Care Structures” elk als een beperking op de “Care Statement” wanneer de afgeleide “Care Structure” en de “Care Statement” in hetzelfde “R-MIM” gebruikt worden.

In de toekomst zullen additionele “Care Structures” opgenomen worden in de “Care Structures topic”. Deze nieuwe structuren zullen gebruikt worden door specifieke “realms” voor specifieke doeleinden met specifieke beperkingen op vocabulaire door gebruik te maken van HL7 attributen, “InfrastructureRoot.templateId” en “InfrastructureRoot.realmCode”. Zo zullen beperkingen specifiek worden gedefinieerd in zowel de niet uitgerolde delen van de structuur als in het overgebleven beperkte “Care Statement” gedeelte van de structuur. Als gevolg hiervan kunnen veel “Care Structures” die gedefinieerd zijn in dit document opnieuw geclassificeerd worden en als “templates” gepubliseerd worden.

In de volgende sectie worden de “R-MIM’s” voor de specifieke “Care Structures” beschreven. Ze worden eerst op een ‘klinisch relevante manier’ beschreven in een algemene beschrijving. Na de algemene klinische beschrijving zal er een formele “walk-thru” zijn zoals men ook tegenkomt in typische engineering specificaties. Niet alles van de formele “walk-thru’s” is afgerond voor deze ballot.
Care Statement Structure Overview:
De “Care Statement Structure” helpt bij het verzamelen van klinische informatie, die gedocumenteerd kan worden tijdens de zorgverlening. De keuzebox staat het uitdrukken van elke verzameling van beweringen toe over zorg in elke volgorde of in elk aantal en in elke combinatie, afhankelijk van het doel en de aard van het bericht.
De “Care Statement Structure” is het model waarvan alle andere “Care Structures” zijn afgeleid. Deze afleiding gebeurt door beperking. Gebaseerd op het “Clinical Statement Patroon” wordt het hernoemd in de “Care Provision Structure” in dit “Domain Message Information Model” voor “Care Provision” om te benadrukken dat zorg van toepassing kan zijn op medische apparatuur, faciliteiten en omgevingen, als mede op patiënten. Op die manier wordt de vocabulair, gebruikt om de “Care Statements” te ondertsteunen, meer uitgebreid dan het vocabulair dat gebruikt wordt om simpelweg de zorg voor de patiënten te ondersteunen. Deze uitbreidingen zullen gedocumenteerd worden door een geleidelijke toename in het aantal en de variëteit van de HL7 vocabulair waardensets. Deze beschrijving geeft niet de volledige details van het “Clinical Statement Patroon” weer, maar documenteert die aspecten die significant verschillen van het basispatroon.
De intentie is dat een “care statement instantiatie” door zichzelf toegevoegd kan worden aan de “Care Provision Act” bij de relatie van de “R-MIM” of toegevoegd kan worden tijdens uitvoering door een applicatie om de variabiliteit van mate en detail, beschreven in de “care statement” definitie hierboven, te ondersteunen. Natuurlijk kan de “care statement toegevoegd” worden aan de “Care Provision Act” samen met het toevoegen van ook andere strucutren van het “Care Provision” Domein.


Gebruik van het Care Statement Model:

Het “Care Statement Model” presenteert een standaard structuur op hoog niveau voor het opnemen van klinische informatie in “Care Provision” communicatie bedoeld ter ondersteuning van specifieke zakelijke functionaliteiten. Hoewel niet bedoeld om geïmplementeerd te worden ”as is”, kan het “Care Statement model” beperkt worden om aan de eisen tegemoet te komen van vele specifieke communicatie met betrekking tot klinische informatie.

Opties voor patroonbeperkingen omvatten:


  • De generieke “Care Statement” klasse attributen kunnen worden beperkt om de exacte aard van de data die gecommuniceerd moeten worden duidelijk over te dragen;

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

  • attributen kunnen zelf beperkt zijn:

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

  • waarde sets 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 mogelijkheid tot complexiteit te verwijderen, bijvoorbeeld: het beperken van een implementatie naar 3 niveaus van nesten; het verwijderen van 'Episode Link' om een implementatie te definiëren naar de laagst mogelijke gemeenschappelijke noemer met betrekking tot het systeem vermogen;

  • klassen kunnen worden beperkt:

  • klassen kunnen worden verwijderd als ze niet vereist zijn;

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

  • klassen kunnen worden ‘gekloond’ om specifieke beperkingen voor attributen of associaties te documenteren;

  • klassen waarop specifieke beperkingen op toegepast zijn, kunnen worden ‘uitgerold’ van de “Clinical Statement Choice box” om hun gebruik te beperken tot een specifieke structuur (in dat geval kan niet langer aangenomen worden dat de beperkte versie van de klasse aanwezig is in de algemene “Care Statement Choice Box”).

  • klassen kunnen worden gecombineerd tot specifieke klinische groepen (artefacten) zoals gecombineerde observaties in het geval van bloeddruk, of klinische schalen zoals de Apgar score en Barthel Index.

Aan dit model wordt gerefereerd via een externe “Act” naar de “Care Statements”. Vaak levert deze externe “Act” de “Entry Point” naar een specificatie voor communicatie en representeert de context waarin de “care statement” informatie wordt verzonden. Bijvoorbeeld: informatie over degene die de informatie verzendt zit in een externe “Act” naar de “Care Statements”. De “Care Provision Act” in het “Care Provision” Domein is een voorbeeld van een externe “Act” naar de “Care Statement”.


het Care Statement Model (REPC_RM000100)

Het model kan verdeeld worden in 3 gerelateerde onderdelen:



  • “Care Entry” Keuzebox;

  • participaties om de “Acts” heen;

  • ”Acts” buiten de “CareEntry” Keuzebox.


de Care Entry keuzebox

Dit deel van het model wordt gebruikt voor het overbrengen van de gedetailleerde “care statements” die verzonden worden ter ondersteuning van de specifieke zakelijke behoeften. Evenals het leveren van een mechanisme voor het overbrengen van de componenten van deze informatie ondersteunt het het groeperen van deze componenten en levert het mechanismen om expliciet beweringen te linken waar er een specifieke relatie is.

De gekloonde klassen in de “CareEntry” keuze zijn hetzelfde als die beschikbaar zijn in de “Clinical statement Pattern ActChoice”. Namen van gekloonde klassen en alle aspecten van de attributen zijn identiek.
linken van Care Statements
The modeling of the linking of Care Statements has been modified from that in the Clinical Statement Pattern as follows:
Het modelleren van het linken van “Care Statements” is als volgt gemodificeerd van hetgeen staat in het Care Statement Pattern:


  • de “sourceOf/targetOf” relatie is uit elkaar gehaald in twee aparte relaties: “sourceOf” en “targetOf”;

  • doel van de “sourceOf” relatie is de buitenste “Care Statement” keuze;

  • “SourceOf” is weggehaald;

  • een beperking is toegevoegd aan de nieuwe “sourceOf” relatie: de waarde van “contextConductionInd” is ”false” als het doel een “ActReference” is (context kan niet worden herleid tot ActReference).

Deze nieuwe modelleerbenadering bevat nu dezelfde semantiek als die in de “Clinical Statement Pattern”, maar wordt gezien als een minder gecompliceerde benadering.


record Target en Subject

Naast het toepassen op patiënten kan een “Care Statement” ook van toepassing zijn op variëtiet van andere typen Entiteiten (o.a. hulpmiddelen). Om dit te ondersteunen is het doel van de “RecordTarget” participatie een keuze tussen “R_CarePatient” en “R_CaredEntity CMET’s”.

Evenzo kan het subject van een “Care Statement” één van diverse typen entiteiten omvatten: de patiënt, een ander persoon, een soort, een apparaat, een dienst, een plaats. Om dit te ondersteunen is in de “SubjetChoice” keuzebox, “target” van subject participatie, een uitgebreide set van rollen opgenomen.
consumable

De “consumable” participatie wordt gebruikt om de “Consumble Choice” in te brengen. Dit kan een “Manufactures Product” rol zijn (gespeeld door een “Labeled Drug” of een “Material”) of een “Instance of Kind” rol (gespeeld door een “Material Kind” dat zelf gespecificeerd kan zijn als deel van een groter geheel).


1   2   3   4   5   6   7   8   9   ...   20

  • 2.5.2 Grenzen van het bereik
  • 2.5.3 Plaatsing van Care Structuren in het Care Provision Domein Model
  • Gebruik van het Care Statement Model

  • Dovnload 4.78 Mb.