GENERIEKE IMPLEMENTATIEHANDLEIDING CARE PROVISION D-MIM, STORYBOARDS CARE PROVISION, CLINICAL STATEMENT PATTERN EN VERWIJS EN OVERDRACHTBERICHTEN -concept-
November 2006 – Maart 2007
[email protected]
Datum: Versie: Status:
20 maart 2007 0.85 Concept op basis van ballot januari 2007
Vertalers:
dr. Kai Heitmann, dr. Ineke Jonkersz, drs. Judith van der Kooij, drs. Lisanne van Beek en dr. William Goossen.
The contents of this document have been placed in the public domain. Note that parts of this document are based on ballot package 7 of HL7 version 3, which is © HL7 Inc. Disclaimer Hoewel deze publicatie met de uiterste zorg is samengesteld, kunnen de verantwoordelijke organisaties Acquest, HL7 Nederland, Results 4 Care en NICTIZ geen aansprakelijkheid aanvaarden voor directe of indirecte schade ontstaan door de inhoud van de – al dan niet door derden aangeboden – informatie.
2
INHOUDSOPGAVE VOORWOORD
2
SAMENVATTING
3
1.
INLEIDING........................................................5 1.1 De generieke toepasbaarheid van het Domein model Care Provision 1.2 Relevante implementatiegidsen 1.3 Leeswijzer
5 6 6
2. HET CARE PROVISON DOMAIN MESSAGE INFORMATION MODEL (D-MIM) .............................8 2.1 Care Provision Domain Message Information Model (REPC_DM000000) 8 2.2 De algemene Organisatie van het Care Provision D-MIM 8 2.3 Care Provision Act in Patient Care 9 2.4 Care Provision D-MIM Walk-through 12 2.4.1 CareProvision Focal Class .................................................................................. 12 2.4.2 Care Provision Focal Class: Attributen ............................................................... 12 2.4.3 CareProvision Associations................................................................................. 18 2.4.4 Domain topics ..................................................................................................... 27 2.5 Care Statement Structuur Overzicht (januari 2007) 29 2.5.1 Bereik van de Care Statement Structuur Domein................................................ 29 2.5.2 Grenzen van het bereik............................................................................................... 30 2.5.3 Plaatsing van Care Structuren in het Care Provision Domein Model: ....................... 31 Gebruik van het Care Statement Model:............................................................................. 34
3.
STORYBOARDS ..............................................37 3.1 3.2 3.3 3.4 3.5 3.5
4.
Doel Patiënt Vult Persoonlijk Medisch Dossier (DOPC_ST000033) Pediatrische Immunisatie (Vaccinatie) (DOPC_ST000030) Huisarts Verwijst naar Specialist (DOPC_ST000034) Multidisciplinaire Zorg (DOPC_ST000032) Ouderenzorg (Aged Care) Overplaatsing - Domein (DOPC_ST000035)
37 38 38 39 40 41
Verwijsbericht...............................................44 4.1 Inleiding op verwijsbericht en overdracht 4.2 Care Transfer Topic 4.3 Care Transfer Definitie 4.4 Storyboards 4.5 Applicatie Rollen 4.6 Trigger Events 4.7 Refined Message Information Modellen 4.8 Care Transfer Request (REPC_RM002000UV) 4.9 Care Transfer Promise (REPC_RM003000UV) 4.10 Hierarchical Message Descriptions 4.11 Interacties
3
44 44 45 46 59 60 62 62 65 67 69
5.
CARE RECORD QUERY TOPIC ......................75 5.1 5.2 5.3 5.4 5.5 5.6 5.7
Inleiding Storyboards Application Roles Trigger Events Refined Message Information Models Hierarchical Message Descriptions Interacties
75 75 78 78 80 85 86
6. overdracht/ ontslagsamenvatting: Care Record Topic .........................................................90 6.1 6.2 6.3 6.4 6.5 6.6 6.7
7.
Inleiding Storyboards Applicatierollen Trigger Events Refined Message Information Models Hierarchical Message Descriptions Interacties
90 91 97 98 100 103 104
CLINICAL STATEMENT .................................109 7.1 Clinical Statement Patroon (COCS_DM000000)
4
111
1.
INLEIDING
1.1
De generieke toepasbaarheid van het Domein model Care Provision
NICTIZ ondersteunt de realisatie van elektronische dossiers in de gezondheidszorg. Het doel van elektronische dossiers is zowel de zorgverlener als de beleidsmaker een beter inzicht geven in de actuele gezondheidstoestand en zorgbehoefte van cliënten. Een adequate informatievoorziening draagt bij aan de kwaliteit van de gezondheidszorg in Nederland. De huidige integrale papieren dossiers bij zorgaanbieders gaan daarom plaatsmaken voor elektronische dossiers. Hiertoe zijn bijvoorbeeld Basis Datasets ontwikkeld en vastgesteld door de betrokken koepelorganisaties. De berichten die nodig zijn voor de realisatie van het elektronisch gezondheidsdossier zijn afgeleid van HL7 versie 3. Met name het Care Provision D-MIM is tot stand gekomen mede dankzij input van diverse projecten van NICTIZ, zoals perinatologie en CVA-Ketenzorg. Inmiddels blijkt dat dit berichtenmodel dermate generiek toepasbaar is dat diverse andere projecten er gebruik van maken. Dit betreft onder andere: ∗ het project Digitaal Begrepen van het Samenwerkingsverband Regio Eindhoven (SRE), waarin is gebleken dat deze berichten toepasbaar zijn op de domeinen zorg, wonen en welzijn; ∗ het project Integraal Elektronisch Kind Dossier in de jeugdgezondheidszorg (EKD JGZ) zijn dat de Landelijke Vereniging voor Thuiszorg (LVT, thans Z-org), GGD Nederland en de Vereniging van Nederlandse Gemeenten (VNG), samen met het ministerie van Volksgezondheid, Welzijn en Sport (VWS) en NICTIZ is gestart en waarin dit bericht een belangrijke rol speelt. In dit project zijn overigens aanpassingen nodig gebleken op het Care Provision model van HL7, die in een later stadium als voorstel kunnen worden ingebracht; ∗ het project Elektronisch Cliënt Dossier en het project Eenheid van Taal van Actiz; ∗ het elektronisch Diabetesdossier dat de Nederlandse Diabetes Federatie (NDF), samen met het ministerie van Volksgezondheid, Welzijn en Sport (VWS) en NICTIZ onlangs zijn gestart; ∗ het Elektronisch Verpleegkundig Dossier (EVD) dat op dit moment in voorbereiding is. Er zijn in de loop van deze projecten telkens nieuwe uitwerkingen in de implementatiehandleidingen gemaakt, die daardoor niet meer geheel consistent zijn. Bovendien zijn er in de loop der tijd door de HL7 ballots wijzigingen aangebracht in het model. Doordat dit domein model zo generiek is, zijn er bovendien legio gebruikstoepassingen mogelijk in andere domeinen. Dit is de reden dat Acquest het initiatief heeft genomen de beschrijving van het D-MIM los te koppelen van de diverse implementatiehandleidingen per project en er een ‘HL7 Nederland versie’ van te maken die ook geballot kan worden door de leden. Dit is dan te zien als een vervolg op de implementatiehandleiding datatypen en CMETs van HL7 Nederland. Het betekent dat meer domeinen en projecten van dit materiaal gebruik kunnen maken zonder telkens deze uitvoerige beschrijving te hoeven bewerken. Het accent verschuift dan meer naar het in het domein zelf vaststellen van de basis data set voor dat domein en de mapping naar vocabulaire en naar de Care Provision berichten. De onderdelen waarin de use cases, storyboards, de dynamische modellen en de specifieke berichten worden gedefinieerd blijven alsnog gewoon noodzakelijk in de domein specifieke implementatiehandleidingen. Er zijn op basis van Health Level 7 versie 3 (HL7 v3) Care Provision D-MIM diverse gestandaardiseerde berichten gedefinieerd om gegevens elektronisch uit te wisselen.
5
Deze specifieke berichten en detailleringen zijn in de afzonderlijke implementatiegidsen te vinden. 1.2
Relevante implementatiegidsen
Als basis voor de berichten is het HL7 v3 Care Provision Domein Message Informatie Model (D-MIM) gebruikt. Deze versie is consistent gemaakt met de januari 2007 ballot. Dit omdat die de DSTU status (waarschijnlijk) krijgt. DSTU staat voor Draft Standard for Trial Use en deze status richt zich op het gedurende 2 tot 3 jaar stabiel houden van de Care Provision materialen en via drafts werken aan nieuwe topics. Daarnaast is gebruik gemaakt van de volgende implementatiehandleidingen: ∗ implementatiehandleidingen perinatologie, CVA-ketenzorg, Geboortebericht JGZ, en concept implementatiehandleiding Digitaal Begrepen; ∗ implementatiehandleiding HL7v3 Data types en CMETs versie 1. Leidschendam, NICTIZ. Dit specifiek voor de CMET patient NL, person NL, provider NL en organization NL; ∗ HL7. Care Provision standard HL7 v3 September ballot version (2006) Ann Arbor, Health Level Seven. ∗ HL7. Care Provision standard HL7 v3 January ballot version (2007) Ann Arbor, Health Level Seven. ∗ Nictiz implementatiegids Prica-GGZ voor de verwijzing 1e lijns geestelijke gezondheidszorg. Nictiz heeft naast Care Provision ook het Primary Care D-MIM ontwikkeld voor het project waarneemdossier huisartsen (WDH). Dit is gebaseerd op de NHG standaarden voor de elektronische dossiers van de huisartsen en de MIE-EUR Edifact berichten. Het toenmalige model Care Provision bood niet wat nodig is. In de afgelopen twee jaar zijn grote harmonisatieslagen gemaakt. Beide modellen zijn in de tijd verder ontwikkeld en naar elkaar toe gegroeid. Zo zijn de diverse typen diagnostiek die voor de huisartsen belangrijk zijn inmiddels opgenomen in de condition tracker R-MIM: een uitwerking die diagnostiek en klachten kan volgen. De harmonisatie heeft geleid tot een 99% overeenkomst tussen beide modellen. Nictiz heeft het voornemen op termijn het Prica D-MIM volledig te harmoniseren met Care Provision. De verzamelde ervaringen uit de WDH implementatie zijn voorwaardelijk om tot een geslaagde harmonisatie te komen. Met andere woorden: gefaseerd in de tijd dient eerst de implementatie van WDH plaats te vinden, vervolgens evaluatie van de Prica berichten en dan de volledige harmonisatie. 1.3
Leeswijzer
Deze implementatiehandleiding is uit diverse onderdelen opgebouwd. Hoofdstuk 2 omvat een algemene beschrijving van het Care Provision Domain Model. Dit is een vertaling van de volledige walk-through uit de ballot van September 2006, waarbij niet relevante voorbeelden zijn verwijderd. Dit is vooral te zien als achtergrondmateriaal waarin echter wel alle onderdelen die in een HL7 bericht aan de orde komen worden uitgelegd. Hoofdstuk 3 bevat de uitleg over de mapping tabel. De mapping tabel is een bijlage bij de implementatiehandleiding: een spreadsheet waarin alle gegevens uit het domein, die in de berichten worden opgenomen, zijn uitgewerkt. Elk gegeven wordt voorzien van datatypen, waar nodig het waardedomein, unieke code voor elk gegeven en OIDs voor code en waardedomein,
6
en een aanduiding van de precieze plaats in het D-MIM en ervan afgeleide berichten. Waar nodig worden nadere specificaties aangegeven.
7
2.
HET CARE PROVISON DOMAIN MESSAGE INFORMATION MODEL (DMIM)
2.1
Care Provision Domain Message Information Model (REPC_DM000000)
Een bericht is gebaseerd op het HL7 v3 domein model voor patiëntenzorg: Care Provision ballot mei 2006 (www.hl7.org). Hierin zijn diverse mogelijkheden opgenomen voor de uitwisseling van patiënteninformatie en het overdragen van verantwoordelijkheden. 2.2
De algemene Organisatie van het Care Provision D-MIM
Dit hoofdstuk beschrijft op domein niveau de opbouw en inhoud van het Care Provision DMIM van HL7 v3 ballot versie september 2006. Deze Care Provision D-MIM vormt een belangrijke bron van berichten in het domein van de zorg en is tevens gebruikt voor de ontwikkeling van elektronische patiënten dossiers. In figuur 1 is een overzicht gegeven van dit model.
1
3
Care Provision
2
EntryPoint
Care Statement Choice 4 Observation
5 Person Procedure Target Participation Medication
Provider Participation
Patient orRelated orProvider
Person
Encounter
Person
Figuur 1. samenvatting Care Provision Model (toelichting nummers zie tekst) In figuur 1 vormt Care Provision de hoofdact (1). Later in dit document wordt een beschrijving van de Care Provision Act gegeven met een gedetailleerde beschrijving van alle associaties verbonden aan de focal Act. De associaties in figuur 1 omvatten de participaties naar Providers en Targets of Care (2), relaties naar de keuzebox (3), de Care statement (4) waarin relevante informatie (pertinent information) is opgenomen, waaronder de reden voor zorg. Aan de keuzebox is een related party gerelateerd om hierover gegevens vast te leggen, bijvoorbeeld over de foetus in het dossier van de zwangere. In de Care Provision DMIM worden de meeste variabele elementen uitgedrukt door de care structures. Care Structures zijn patronen van gedetailleerde klinische informatie, die een specifieke detaillering kunnen geven voor het betreffende onderwerp. Ze sluiten altijd aan op dit D-MIM. In deze gids voor het D-MIM worden ze (nog) niet besproken. De uitwerkingen van die delen zullen in de concrete implementatiegidsen worden toegelicht.
8
Wanneer deze structuren opgenomen worden in de ballot van het Care Provision Domein, kunnen ze voorgelegd worden als gedeelde CMET’s voor het gebruik in meerdere domeinen. De CMET’s die beschreven worden in de Care Structures omvatten veel structuren, zoals onder andere: Care Statement (bewering over de zorg), Condition Tracking (volgen van conditie), Worklist (werklijst), Care Plan (zorgplan) en Guidelines (richtlijnen). Deze CMET’s kunnen worden gebruikt in de onderwerpen van de berichtenspecificaties, zoals de Care Transfer (zorgoverdracht) en Care Record (zorgdossier). Echter, in dit gedeelte zal de focus liggen op de betekenis van de Care Provision Act en op de associaties die om de Care Provision Act heen zitten.
2.3
Care Provision Act in Patient Care
Begrip van deze Act is van belang voor het concept van patiëntenzorg door professionals en vooral het aan elkaar overdragen van verantwoordelijkheden voor de zorg. Normaal is een patiënt zelf verantwoordelijk voor zijn of haar zorg. Maar zodra iemand ziek is, is het moeilijk om zelf volledig verantwoordelijk te zijn. Een deel van het proces van gezondheidszorg is dan ook dat patiënten aan zorgverleners verzoeken hen te helpen met de zorg. Dit verzoek voor hulp is een centraal item in het contract tussen patiënten en zorgverleners. In Nederland wordt dit via de WGBO geregeld (Wet geneeskundige behandelingsovereenkomst). In een aantal gevallen zullen ook andere wetten de afspraken tussen patiënten en zorgverleners reguleren. Het is verder algemeen gebruik dat de ene zorgprofessional de hulp inroept van een andere professional, steeds binnen de context van het contract met de patiënt. De Care Provision Act representeert een uitspraak over de scope van de verantwoordelijkheid die gedeeld wordt tussen de patiënt, soms familieleden, en een of meer zorgverleners. De hier volgende discussie is bedoeld om het concept van ‘gedeelde verantwoordelijkheid’ verder toe te lichten en het begrip patiënt gerelateerde zorg te verbreden naar Care Provision in het algemeen. Het is met name deze brede invulling van samenwerking tussen professionals van diverse disciplines die het generieke gebruik van het model mogelijk maakt. Care Provision Act: De betekenis van de Care Provision Act begint met een verkenning van de betekenis van "Care" (Zorg) en de betekenis van "Provision" (verlenen) in de context van dit domein. definities Care (5) CHARGE, SUPERVISION, MANAGEMENT: responsibility for or attention to safety and well-being (under a doctor's...), (the ... of all the churches) CUSTODY: temporary charge. Provision (2a) The act or process of providing (the ... of a play area for the children). Provide (3) To supply what is needed for sustenance or support (the Lord will...), (we'll have to ... for him) Merriam- Webster's Third New International Dictionary Unabridged, copyright 1961-2002. In het HL7 Reference Information Model (RIM) vertegenwoordigt de term ‘Act’ altijd het vastleggen van het doen, bijvoorbeeld een zorgproces. ‘Care Provision’ is een beperking op de definitie van ‘Act’ dat de vorm aanneemt van de ‘Act Care Provision’ waarbij ‘Care Provision’
9
het zelfstandig naamwoord is van de onbepaalde wijs ‘to povid care (zorgvelenen)’.Daarom is de ‘Act Care Provision’ het vastelggen van een proces dat de verantwoordelijkheid van het leveren van zorg. Het is een statement van supervisie , management en zorg. In de zorgverlening worden veel medewerkers aangewezen voor de uivoering van zorg, voor de faciliteiten en apparaten en voor de levende wezens (Care provision richt zich uiteraard op mensen die zorg vragen, maar kan ook voor dieren en materialen worden gebruikt, zie de HL7 v3 entiteitenklassen). Deze Act van Zorgverlening moet gebruikt worden wanneer de expliciete aansprakelijkheid voor de zorg van een levend of niet-levend wezen een component is van de semantiek die wordt uitgewisseld. Met andere woorden, het onderwerp van zorg wordt gedefinieerd in de subject participatie die de semantiek van zorgverlening beperkt, bijvoorbeeld: het subject heeft de rol van patiënt, het subject heeft de rol van een apparaat. In zorgverlening kan de zorg zich richten op een medische apparaat, het huis van de patiënt of andere niet-levende wezens. Uiteraard kan ook de conditie van het lichaam van de patiënt, of de patient zelf de reden voor zorg zijn. Daarom wordt ‘Care Provision’ vaak gecombineerd met het HL7 concept ‘Condition Tracking’ en met ‘Care Plan’, structuren die opgenomen zijn in de Care Structures. De volgende voorbeelden illustreren de mogelijkheden van het Care PRovision DMIM: zorg voor materiaal, zorg voor de patiënt, zorg voor faciliteiten, verantwoordelijkheid voor populatie-monitoring, verantwoordelijkheid voor een omgeving. Daarbij spelen de volgende begrippen ook nog een rol in Care Provision: de preferred principal van de care provision is de arts die primair de uitvoering van zorg voor zijn rekening neemt als participatie, terwijl de patiënt de author is; een verwijzing van de huisarts naar de specialist bevindt zich de Care Provision activiteit in request mood, waarbij de participerende author de huisarts is en de principal performer de specialist; bij case management is de case manager de performer voor een patiënt of een groep van patiënten als subject deelnemers; coverage assignment (toewijzen van opdrachten), bijvoorbeeld van verpleegkundigen aan patiënten in de diverse diensten, zoals dag, avond of nachtdienst; bij zorg voor de leefomgeving is de leefomgeving de subject participant en een bedrijf is de performer participant; in het kader van het monitoren van populatie stelt de populatie de subject participant en een overheid de performer participant voor.
10
2.4
Care Provision D-MIM Walk-through
2.4.1 CareProvision Focal Class De Care Provision Act wordt gebruikt om alle aspecten van zorgverlening aan te duiden, zoals de naam van een zorgprofessional en de details van de patiënten/cliënten. Deze centrale Act heeft relaties met zichzelf en met vele andere acts. De meeste van deze relaties zijn direct verbonden aan acts van de Care Statement, bijvoorbeeld observaties, activiteiten en afspraken. Het heeft ook Participaties die rollen en entiteiten definiëren, bijvoorbeeld de rol van patiënt of zorgverlener. De details van het domein Care Provision worden hierna beschreven, te beginnen met de attributen van de focale klasse Care Provision. 2.4.2
Care Provision Focal Class: Attributen
classCode Het vocabulaire domein dat is gespecificeerd voor Act.classCode bevat Patient Care Provision (PCPR) als een specialisatie van de Act klasse. moodCode Zoals alle Acts in het RIM, kan ook de Care Provision Act in verschillende mood codes worden aangeduid. Deze moods onderscheiden de verschillende aspecten van de business lifecycle van een Care Provision Act. Deze moods, die de centrale concepten voor het DMIM zijn, zijn als volgt gedefinieerd: ∗ request RQO (verzoek); ∗ promise PRMS (belofte); ∗ event EVN (gebeurtenis); ∗ definition DEF (definitie) ; ∗ intention INT (intentie); ∗ goal (GOL) (doel); ∗ proposal PRP (voorstel). request Een "Care Transfer Request" is een vraag aan een andere zorgverlener met betrekking tot hun mogelijkheid om de verantwoordelijkheid voor zorg aan een subject over te nemen. Een dergelijk verzoek of dergelijke verwijzing wordt gedaan door een zorgverlener, gedocumenteerd in een computersysteem gecommuniceerd met een ander computer systeem en door de ontvangende zorgverlener geanalyseerd en beantwoord. Maar, deze mood code wordt ook gebruikt voor zelfverwijzing door patiënten. Een verwijzende verantwoordelijke partij, zoals een regering of rechtbank, kan ook een Care Transfer Request doen. In een Care Transfer Request wordt de ontvangende zorgverlener getypeerd als de performer (uitvoerder). De scope van de verantwoordelijkheid, inclusief CareProvision.code, reden voor zorgverlening, en de zorgplannen die de specifieke verwachtingen voor zorg uitdrukken vallen hier onder voor de ontvanger van de verwijzing. promise Een "Care Provision Promise" is de bewering of afspraak om de verantwoordelijkheid voor Care Provision te accepteren zoals die in de promise wordt gespecificeerd. De aanname is dat de ontvangst van een verwijzing of verwijsbericht de promise triggert via een berichtenuitwisseling met de verwijzende partij. Vanwege de implicaties voor de patiëntveiligheid wordt geen gebruik
gemaakt van de "Implicit Promise" zoals in het Laboratorium Domein van HL7. De acceptatie van de verantwoordelijkheid moet worden gecommuniceerd als een expliciete ‘Promise’. In dit geval is de performer de zender van de promise. Ook hier zijn de scope van de verantwoordelijkheid, inclusief de CareProvision.code, de reden voor zorg en zorgplannen die de verwachtingen voor zorg bevatten onderdeel van de verantwoordelijkheid van de zender van de promise. event Volgens het RIM is een Event een service die daadwerkelijk plaatsvindt, het kan vooortdurende service zijn of een documentatie van een service in het verleden. Voor Care Provision, een “Care Provision Event” is een record die de gebeurtenissen samenvat die tijdens de zorg plaatsvonden, inclusief wie verantwoordelijk is voor de gelverde zorg. Een auteur van de “Care Provision Event” documenteert en vat de gebeurtenissen (events) samen. De uitvoerder is verantwoordelijk voor het uitvoeren van de zorg-events. De auteur en de uitvoerder kunnen dezelfde persoon zijn. Care Provision Event berichten kunnen gedurende de zorg worden verzonden om de voortgang van de zorg te rapporteren of om het einde van de zorg aan te geven om alle activiteiten te beschrijven die gedurende het verlening van zorg hebben plaatsgevonden. In dit geval is de uitvoerder de zendende leverancier. definition mood Definition mood kan gebruikt worden om een richtlijn of protocol uit te drukken. Goal mood De goal mood wordt in de Care Planning gebruikt om bijvoorbeeld een doelwaarde van een observatie te definiëren die op een later tijdstip leidt tot observatie en kan leiden tot vergelijking van de dan actuele situatie met het doel. Dit wordt in de Care Plan topic uitgelegd en vormt geen deel van deze algemene beschrijving van Care Provision. intention mood Wordt gebruikt om voorgenomen activiteiten in een zorgplan op te nemen. Het gaat specifiek om de toepasselijke selectie van observaties en activiteiten die vanuit een richtlijn in een zorgplan worden opgenomen voor een specifieke patiënt. Met andere woorden de intented acts worden geïndividualiseerd vanuit de richtlijn. proposal Wordt gebruikt om een ander een suggestie te doen, maar zonder de formele status van een request (verwijzing). Het wordt verder gebruikt als een plaatshouder voor het gebruik in het Care Plan R-MIM. Het kan bijvoorbeeld worden gebruikt door een consultant om een bepaalde aanpak voor te stellen. Care Provision Acts in verschillende moods worden aaneengeschakeld door het feit dat promises (beloften) gecreëerd worden om een verzoek te vervullen en events (gebeurtenissen) worden gecreerd ol promises (beloften) en/of requests (verzoeken) te vevullen.
careProvision.id Dit attribuut identificeert een bepaalde Care Provision. Identifier kan gebruikt worden om een instantiatie van een klasse te indentificeren. Soms is meer dan één attribuut nodig om een instantiatie van een klasse te identificeren. Het identifier attribuut heeft altijd een waarde. De waarden van identifier attributen zijn uniek onder alle instantiaties van de klasse. Omdat identiteit statisch is veranderen waarden van identifier attributen niet. Identifier attributen wordt een set van instantiatie indenfiers (SET
) data type toegewezen en hebben over het algemeen
13
de naam “id” die het toestaat dat meerdere indentifiers gespecificeerd worden. Het identifier attribuut is een set van instantiatie identifiers. Dit geeft aan dat er meerdere, unieke identifiers kunnen zijn voor een Act. In de CareProvision Act wordt de “id” gebruikt om een unieke id te geven aan alle informatie die bij elkaar hoort. Het wordt gebruikt om de huidige zorgverlening voor een patiënt met een bepaalde conditie en de verantwoordelijke verleners te identificeren. Het wordt verder gebruikt in queries en om informatie van eerdere zorgverleningen terug te vinden voor bijvoorbeeld voorgaande condities of gerelateerde condities en dergelijke. careProvision.Code Dit attribuut beschrijft een soort van Care Provision Act, in overeenstemming met de definitie van Act.code in het RIM. Op dit moment is het attribuut CWE en is er geen waardenset gedefinieerd. CareProvision.code representeert de soort zorgverlening en de persoon die er verantwoordelijk voor is. Deze begeleiding geldt: Care Provision is een statement van verantwoordelijkheid. De code voor dit statement zou van toepassing moeten zijn op een algemeen geaccepteerde legale/regulerende/accrediterende standaard scope voor verantwoordelijkheid. Het is bekend dat deze kunnen variëren per jurisdictie. In de Verenigde Staten omvatten de voorbeelden het volgende: JCAHO; staatsvergunningen geven aan ziekenhuizen, verpleeghuizen en thuiszorgorganisaties; medisch en verpleegkundige specialismen commissies; etc. Bijvoorbeeld: een samenvatting van een ziekenhuisontslag in een ziekenhuis met een vergunning van Wisconsin zou een code voor “Wisconsin ziekenhuiszorg” gebruiken of misschien een JCAHO gecertificeerde toewijzing voor acute zorg. Deze code moet niet geïnterpreteerd worden als een code voor een context of een code voor een afspraak, maar moet consistent zijn met andere gerelateerde concepten, bijvoorbeeld documenttype, afspraaktype en organisaties voor het geven van vergunningen of accreditatie van een deelnemende (zorg)verlener. Lokale behoeften kunnen uitbreidingen vereisen van elke gegeven waardenset, afhankelijk van lokale voorschriften en accreditaties. Een algemene waardenset voor deze concepten (waarvan verwacht kan worden dat ze uitgebreid worden door lokale overeenkomsten) zullen gedefinieerd worden door HL7, omdat externe vocabulaires dit concept op dit moment niet ondersteunen. De intentie voor het gebruik van CareProvision.code is het definiëren van een traditionele scope van domeinexpertise, bijvoorbeeld orthopedische zorg; oncologische zorg; acute zorg; zorg voor lange termijn, etc. Deze scope, beschreven door zijn algemeen domein van expertise, zou dan verder beperkt worden door de lijst van Condities genoteerd als Redenen voor zorg en de Zorgplannen geïdentificeerd als componenten van de Care Provision Act. Deze gehele scope van zorg wordt dan geïncludeerd in het bepaalde verzoek, belofte of levering van zorg vertegenwoordigd door de mood codes die gebruikt worden in de Care Provsion Act. Voorlopig kan elke act.code van elke codestelsel hier geïncludeerd worden. Bijvoorbeeld de codes van SNOMED CT: Preventive care:169443000: preventive procedure Surgery: 257556004: surgery Delivery: 386216000: human parturition, function Elke codestelsel wordt geïdentificeerd door de Object Identifier (OID), bijvoorbeeld voor SNOMED CT is dit: 2.16.840.1.113883.6.5 Voor Nederland wordt hierbij aangesloten bij de Aorta infrastructuur en wordt naar de implementatiegidsen daarvoor verwezen. Zo zijn er unieke coderingen voor specialismen vastgesteld.
14
careProvision.derivationExpr. Het derivation expression attribuut staat een string expressie over afleiding en wordt gesteund in een observatie instantiatie. De derivationExpr zal in de nabije toekomst worden vervangen door een datatype. Voor het gebruik door Decision support (beslissingsondersteuning) worden Use cases in een later stadium toegevoegd. Ook in het Care Plan wordt dit gebruikt. De DSS werkgroep van HL7 zal binnenkort use cases verstrekken en bepalen hoe beslissingen over dit attribuut het gebruik ervan beïnvloeden. Binnen Care Provision wordt het in de care statements gebruikt om relaties tussen observaties aan te geven (zoals somscores, formule voor Body Mass index en dergelijke). careProvision.negationInd Er zijn twee antwoordmogelijkheden voor de negation indicator: true, false. True betekent zorg is geleverd, false betekent er is geen zorg geleverd. Echter, het gebruik van de negation indicator in Care Provision Act wordt niet aangemoedigd. Als het gebruikt wordt, moet voorzien worden in een duidelijke use case en expliciete interpretatierichtlijnen om medische fouten te voorkomen. Zie terminfo project voor toekomstige richtlijnen voor toepassing van negation.indicator.
careProvision.title Care Provision kan één titel krijgen in vrije tekst. careProvision.text Dit attribuut kan worden gebruikt om een kort label te geven aan de care provision of een korte bewering over het type van Care Provision. Het is niet bedoeld voor een vrije tekst toelichting van alles dat is uitgevoerd of de reden ervoor of het verzoek. Zulke zaken worden uitgewerkt via de expliciete relaties naar de care statement. careProvision.statusCode Het statusCode attribuut wordt gebruikt om de huidige status van de Care Provision klasse aan te geven. Het statusCode attribuut correspondeert met de status machine van de Act en heeft voor de Care Provision Act de volgende valide waarden: Code
Definitie
active
De care provision kan uitgevoerd worden of wordt uitgevoerd
Een care provision die geactiveerd is (acties kunnen uitgevoerd worden of suspended zijn uitgevoerd), maar is tijdelijk uitgeschakeld. Er moet hier geen verdere actie ondernomen worden totdat het wordt voortgezet. completed
Een care provision die normaal geëindigd is nadat al zijn bestanddelen uitgevoerd zijn.
aborted
De care provision is geëindigd voordat de van origine bedoelde voltooiing plaats heeft gevonden.
obsolete
Deze care provision record is vervangen door een nieuwe instantiatie.
nullify
Deze care provision record werd foutief gecreeerd en is ‘verwijderd’ en wordt behandeld alsof het nooit bestaan heft. Een record wordt enkel
15
bewaard voor doeleinden m.b.t. de account. De afhandeling van status zelf wordt in implementatiehandleidingen op R-MIM niveau expliciet gemaakt. Dan is het gekoppeld aan de feitelijke toepassing van een specifiek bericht.
careProvision.effectiveTime Het effectiveTime attribuut vertegenwoordigd het tijdsinterval waarvoor de zorgverlening wordt geleverd. Voor ‘intent’ zorgverleningen zal, waar van toepassing, de tijd de voorgestelde start en eind tijd/datum zijn, terwijl voor zorgverlening ‘events’ de tijd de daadwerkelijke start en eind datum/tijd zal zijn ( voor een meer algemene beschrijving van effective wordt u verwezen naar het RIM). priorityCode Het priorityCode attribuut heeft een potentiele overlap met enkele vocabulaires. Deze potentiele conflicten worden als volgt opgelost: De priorityCode zou alleen gebruikt moeten worden om de urgentie waarmee de cummuncatieontvanger zou moeten reageren op de informatie in de Act aan te duiden. Bijvoorbeeld : het verzoek voor een proceduren zou behandeld moeten worden als ‘urgent’. Derhalve is het wenselijk dat het gebruik van de priorityCode gelimiteerd zou moeten zijn aan acts die in de ‘intent’ mood verkeren. Act.code vocabulair expressies zouden gebruikt moeten worden om de klinische urgentie te kwalificeren van de expressie die in het code attribuut staat. Bijvoorbeeld: het concept ‘een spoed verwijdering van de blinde darm’ zou in z’n geheel uitgedrukt moeten worden binnen een Act.code.
Code
Definitie
A (ASAP)
As soon as possible (zo spoedig mogelijk), op één na hoogste prioriteit na stat.
R (routine)
Routine service, doen in normale werktijd.
S (stat)
With highest priority (met de hoogst prioriteit) (bijvoorbeeld spoed).
confidentiality.Code Het ConfidentialityCode attribuut Code
Definitie
Een waardenset die toegang tot informatie door een subject / rol en op relatie gebaseerde reachten toestaat. ConfidentialityByAccessKind (Deze concepten sluiten elkaar uit, één en slechts één is vereist voor een valide vertrouwelijkheid codering). ConfidentialityModifiers
Modificeerders van op een rol gebaseerde toegangsrechten (veelvoud toegestaan).
16
careProvision.reasonCode Het reasonCode attribuut specificeert de motivatie, de oorzaak of de reden van een Care Provision, wanneer zo’n reden niet redelijkerwijs gerepresenteerd wordt als een ‘has reason’ (heeft reden) ActRelationship type gelinkt aan een Condition Observation.
Code
Definitie
PAT (patient request)
De patiënt heeft de zorgverlening aangevraagd.
MEDNEC (Medical Necessity)
Vereist vanwege medische reden(en). Een abstract vocabulaire domein gelinkt aan een externe codeset die de reden voor een Klinische Service die uitgevoerd wordt vertegenwoordigt.
ActBillableClinicalServiceReason Dit domein sluit redenen die gespecificeerd zijn door gediagnosticeerde condities uit. Voorbeelden van waarden uit dit domein omvatten dubbele therapie en frauduleuze recepten. De CareProvision focal Act heeft zes verschillende Entry points: Elk Entry Point kan fungeren als de ingang voor een concreet bericht, afgestemd op de moodcodes hierboven of op een specifieke invulling of toepassing. Elk van deze Entry Points leidt tot een of meer Refined Message Information Models (R-MIMs), die het generieke DMIM naar de concrete praktijk van gegevensuitwisseling in een bepaald domein vertalen. ∗ ∗ ∗ ∗ ∗ ∗
Care Provision: D-MIM voor Care Provision berichten; CareRecord: voor overdragen van een Care Record; Care Transfer Request: verzoek tot zorgoverdracht; Care Transfer Promise: acceptatie van zorgoverdracht (Care Transfer); Care Plan: Care Plan Structuur; A_PrincipalCareProvision: dit definieert de hoofduitvoerder van een gespecificeerde zorgverlening. De uitvoerder van zorgverlening kan over het algemeen de hoofdbehandelaar zijn, soms alleen binnen een specifieke zorgfaciliteit. De relatie is meestal solide gedurende de tijd en wordt alleen voor administratieve doeleinden vastgelegd; de daadwerkelijke zorg die door deze zorgverlener geleverd wordt, wordt apart vastgelegd.
Deze Entry points zullen gedetailleerder beschreven worden om uit te leggen welke doel elke van deze Entry points heeft en hoe ze refereren aan het R-MIM dat voor elk Entry Point gecreëerd wordt. In de toekomst kunnen aanvullende Entry points verwacht worden. De attributen van CareProvision, en zijn codering, waarden, cardinaliteiten en korte beschrijving zijn in onderstaande tabel samengevat. attribuut
waarde
beschrijving
17
Class code Mood code
PCPR X_ActClinicalStatementActMood
Id Code NegationInd
SET [0..*] CD CWE [0..1] <= ActCode BL [0..1]
derivationExpr Title
ST [0..1] ST [0..1]
Text
ED [0..1]
Status Code
CS CNE [0..1] <= ActStatus
Effective Time Priority Code Confidentiality Code Reason Code
IVL [0..1] CE CWE [0..1] <= ActPriority SET CWE [0..*] <= Confidentiality SET CWE [0..*] <= ActReason
2.4.3
Patient Care Provision Mogelijke moods: DEF (definition), EVN (event), INT (intention), PRMS (promise), RQO (request) en PRP (proposal)
Er zijn 2 antwoordmogelijkheden: true, false. True betekent in deze context dat geen zorg is of wordt geleverd (afhankelijk van de moodcode), false betekent dat zorg is of wordt geleverd (afhankelijk van de moodcode). Er kan maximaal één titel gegeven worden in vrije tekst. Korte toelichting op de care provision actief, uitgesteld, geannuleerd, afgerond en afgebroken. Tijdsaanduiding
CareProvision Associations
In de Care Provision D-MIM is de Care Provision Act omgeven door associaties. De associaties die noodzakelijk zijn voor verantwoorde communicatie bij Care Provision zijn: ∗ participaties naar "Provider" keuzebox (author, performer, primaryInformationRecipient); ∗ participaties naar "Target" keuzebox (subject, recordTarget); ∗ Participations naar "R_AssignedPerson" CMET (verifier, dataEnterer); ∗ terugkeer via ActRelatie voor "SequelTo", waarin een eerdere of latere zorgverleningsrelatie vastgesteld kan worden. (sequel to); ∗ terugkeer via “Has Component” ActRelationship (component 3); ∗ terugkeer via “Has Pertinent Information” ActRelationship (pertinentInformation3); ∗ de "Refers To" ActRelationship naar huidige Encounter (reference); ∗ de Care Provision "Has Reason" ActRelationship naar Conditions (reason) ∗ de "Has Component" ActRelationship naar Care Statements (component1) ∗ de "Has Component" ActRelationship naar StatementCollector (component2) ∗ de "Has Pertinent Information" ActRelationship naar StatementCollector (pertinentInformation1) ∗ de "Has Subject Of" ActRelationship naar Care Statements (subjectOf) ∗ de "Has Final Objective" ActRelationship naar Care Statements (final goal) Deze associaties samen met de Care Provision Act zelf leveren alle relaties die nodig zijn voor het communiceren van: ∗ wie is de verzorger met verantwoordelijkheid?
18
∗ voor wat of wie is de verzorger verantwoordelijk?; ∗ welke eerdere levenscyclus Act van Care Provision wordt vervuld door deze Care Provision
instantiatie, als dit van toepassing is?; ∗ welke eerdere instantiatie van dezelfde Care Provision Act wordt vervangen door deze
instantiatie, als dit van toepassing is?; ∗ in wat voor encounter wordt deze Care Provision Act gecreëerd, als dit van toepassing is?; ∗ welke Conditie(s), bijvoorbeeld Reasons for Care (Redenen voor zorg), worden (via de
condition tracking structuur) toegevoegd aan de provider's scope van verantwoordelijkheid?; ∗ wat voor Care Plan activiteiten worden toegevoegd aan de provider's scope van
verantwoordelijkheid?; ∗ wat voor Observaties en Acts zijn uitgevoerd in deze zorgverlening of in eerdere
zorgverleningen? De associaties zullen hieronder opvolgend worden besproken. Algemene Associatie Attributen contextControlCode Levert een mechanisme om te specificeren hoe participanten bijdragen aan de context van een Act en of de context geleid kan worden naar geassocieerde ‘child ‘ (kind) acts. Het attribuut is een code met twee letters die in elke combinatie kan worden gebruikt en het leidende gedrag specificeert: 'AN'– associatie bij context en niet gerelateerd aan een kind Act 'AP' - associatie bij context en mogelijk gerelateerd aan een kind Act(s) ‘ON'- elke associatie(s) van hetzelfde of meer specifieke type die geleid wordt van de parent (ouder) wordt vervangen door deze associatie die niet gerelateerd is aan een kind Act 'OP'- elke associatie(s) van hetzelfde of meer specifieke type die geleid wordt door de ouder wordt vervangen door deze associatie die mogelijk gerelateerd is aan een kind Act. recordTarget De record target is de entiteit waarvoor de Care Provision wordt vastgelegd, zoals de details van de baby in het dossier van de moeder gaan. Er kan maar één doel van vastlegging zijn voor een Care PRovision. De target (doel) entiteit informatie wordt vastgelegd binnen de R_Pateint CMET of een Maintained Entity provided in the Target choice. De Maintained Entity kan of een Apparaat of Plaats zijn welke verder worden beschreven in het R_CaredEntity gedeelte van de Care Structures. Attributen typeCode: De type code is RCT (record target). contextControlCode: Zie bovenstaande beschrijving in Common Participation attributen. De default waarde is "OP" (overriding, propagating). subject De subject of subjecten is het hoofddoel(en) van de zorgverlening wanneer de subject niet de record target is, bijvoorbeeld de patiënt in het lichamelijk onderzoek, een monster in een labobservatie. Het kan ook een familieid van de patiënt zijn (lesgeven) of een apparaat of kamer
19
(schoonmaken, desinfecteren, huishouden). De subject informatie wordt vastgelegd binnen de R_Pateint CMET of een Maintained Entity provided in the Target choice. De Maintained Entity kan of een Apparaat of Plaats zijn welke verder worden beschreven in het R_CaredEntity gedeelte van de Care Structures. Attributen typeCode: de type code is SBJ (subject). contextControlCode: “OP”. Zie beschrijving hierboven onder ‘Algemene participatie Attributen’. De default waarde is “OP” (overriding, propagating). Author De partij die Care Provision vraagt, toezegt of invoert. Dit kan zijn een toegewezen persoon/zorgverlener of organisatie (R_AssignedParty), een gerelateerde partij in de zin van familie/jurist (R_RelatedParty), of de patiënt zelf (R_Patient). Attributen typeCode: de type code is AUT (author (originator)). contextControlCode: “OP”. Zie beschrijving hierboven onder ‘Algemene participatie Attributen’. noteText: commentaar inzake auteur participatie. tijd: moment waarop de author de documentatie tekent of compleet maakt die betrekking heeft op de care provision act.. modeCode: specificeert hoe informatie is verkregen, bijvoorbeeld verbaal, elektronisch of handgeschreven (waarden komen uit ParticipatieMode domein). signatureCode: code die author specificeert. signatureText: een code die specificeert of the auteur heeft, vereist is of de intentie heeft om in te staan voor de care provision act door gebruik te maken van een handtekening. code I (intended) S (signed)
X (required)
beschrijving The author intends to provide a signature. De auteur heeft de intentie een handtekening te plaatsen. Signature has been affixed, either written on file, or electronic (incl. digital) signature in signatureText. De handtekening van de auteur is toegevoegd, hetzij op papier in een dossier of een elektronische (inclusief digitale) handtekening. A signature for the care provision act is required of this author. Een handtekening van de auteur is noodzakelijk voor het verlenen van zorg.
DataEnterer De transcriptionist die de informatie van de Care Provision invoert. De data enterer informatie wordt opgeslagen binnen de R_AssignedPerson CMET. Attributen typeCode: the type code is ENT (data entry person). contextControlCode: Zie de beschrijving die hierboven gegeven is in de Algemene Participatie attributen. De default waarde is “OP”. time: Het tijdstip waarop de dataEnterer de documentatie in relatie tot de care provision act getekend of gecomplementeerd heeft.
20
modeCode: Specificeert hoe de persoon die de data invoert de informatie heeft geleverd. De default waarde is ELECTRONIC (elektronische data). Alternatieve waarden kunnen komen uit het ParticipatieModeWritten domein. signatureCode: De code die specificeert of de ‘data entry persoon’ de care provision act officieel goedgekeurd heeft of dat goedkeuring hiervoor vereist is. code S (signed)
X (required)
beschrijving Signature has been affixed, either written on file, or electronic (incl. digital) signature in signatureText. De handtekening van de auteur is toegevoegd, hetzij op papier in een dossier of een elektronische (inclusief digitale) handtekening. A signature for the care provision act is required of this author. Een handtekening van de auteur is noodzakelijk voor het verlenen van zorg.
signatureText: een digitale ondertekening of multimedia representatie van de handtekening geleverd door de data entry persoon, de care provision act goedkeurend.
Verifier De supervisor die de aanvraag voor care provision (zorgverlening) verifieert, de toezegging voor zorgverlening doet of informatie over verleende zorg vastlegt. Attributen typeCode: waarde uit ParticipationVerifier domein. code VRF (verifier)
AUTHEN (authenticator)
LA (legal authenticator)
beschrijving A person who verifies the correctness and appropriateness of the care provision act (plan, request, event, etc.) and hence takes on accountability. Iemand die de correctheid en toepasselijkheid van de care provision act verifieert (plan, verzoek, gebeurtenis, etc.) en de verantwoordelijkheid op zich neemt. A verifier who attests to the accuracy of an care provision act, but who does not have privileges to legally authenticate the act. An example would be a resident physician who sees a patient and dictates a note, then later signs it. Their signature constitutes an authentication. Iemand die de accuraatheid van een zorgverlening beoordeelt, maar die geen privileges heeft voor het wettelijk authentiseren van de act. A verifier who legally authenticates the accuracy of a care provision act. An example would be a staff physician who sees a patient and dictates a note, then later signs it. Their signature constitutes a legal authentication. Iemand die wettelijk de accuraatheid van een zorgverlening authentiseert.
contextControlCode: Zie de beschrijving die hierboven gegeven is in de Algemene Participatie attributen. De default waarde is “OP”. noteText: commentaar inzake Verifier participatie time: tijdstip waarop verifier de Care Provision Act getekend of geaccepteerd heeft. modeCode: specificeert hoe de verifier heeft geaccepteerd, bijvoorbeeld mondeling, elektronisch of schriftelijk. Gebruik elke waarde van de ParticipationModeWritten, ParticipationModeVerbal or ParticipationModeElectronicData. signatureCode: Code die specificeert of de verifier de care provision act officieel offcieel goedgekeurd heeft of dat goedkeuring hiervoor vereist is. code S (signed)
beschrijving Signature has been affixed, either written on file, or electronic (incl. digital) signature in signatureText.
21
X (required)
De handtekening van de auteur is toegevoegd, hetzij op papier in een dossier of een elektronische (inclusief digitale) handtekening. A signature for the care provision act is required of this author. Een handtekening van de auteur is noodzakelijk voor het verlenen van zorg.
signatureText: een digitale ondertekening of multimedia representatie van de handtekening geleverd door de verifier, de care provision act goedkeurend. Performer De partij of partijen die verantwoordelijk zijn voor de scope van de zorg geïdentificeerd door de Care Provision Act en zijn gerelateerde condities en zorgplannen. Echter, deze persoon of organisatie kan ‘supervisors’ of ‘monitors’ hebben die gerelateerd management of regulerende verantwoordelijkheden voor de zorg dragen. Zorg kan worden geleverd door een brede range aan providers. In een patiëntenzorgvoorbeeld kan zorg gelverd worden door de patiënt zelf (R_Patient), familie of mantelzorg (R_RelatedParty), ontelbare individuele professionele zorgverleners/-organisaties (R_AssignedParty). Medische apparaten kunnen deelnemen aan de zorg, maar kunnen duidelijk geen verantwoordelijkheid nemen voor zorg. In een niet-patiënt zorg scenario kan zorg gelverd worden aan geografische plaatsen door omgevingsingenieurs (R_AssignedParty). Vaak zijn de ‘author’ en de ‘performer’ dezelfde partij. Echter, in een verzoek tot zorg is de auteur degene die vrezoekt en de ‘performer’ degene die de verantwoordelijkheid voor zorg zal nemen. Attributen typeCode: waarde uit onderstaande lijst uit ParticipationPhysicalPerfomrer domein. code PRF (performer)
PPRF (primary performer) SPRF (secondary performer)
beschrijving A person who actually and principally carries out the care provision. Need not be the principal responsible actor, e.g. a surgery resident operating under supervision of attending surgeon, and may be the patient in self-care. Degene die feitelijk de zorg verleent. Dit hoeft niet de hoofdbehandelaar te zijn. The principal or primary performer of the care provision. De hoofdbehandelaar van de care provision act. A person assisting in care provision through his substantial presence and involvement. Degene die helpt bij het uitvoeren van de care provision act.
functionCode: een optionele codeaanvullende details over de functie die de performer heeft in de zorgverlening specificeert, bijvoorbeeld de priamire arts, eerste chirurg, tweede chirurg anesthesist, verpleegkundige, waarnemende arts. contextControlCode: zie beschrijving hierboven onder ‘Algemene participatie Attributen’. time: Begin- en eindtijd van verantwoordelijkheid van performer voor de zorg aan een subject. modeCode: specificeert hoe de performer de zorg heeft verleend, wat mere dna alleen de communicatie betreft. De defaultwaarde is "PHYSICAL" (physical presence). Andere toegestane waarden zijn: code PHYSICAL (physical presence) REMOTE (remote presence)
beschrijving Participation by direct action where subject and actor are in the same location. Een participatie van directe actie waarbij subject en actor in elkaars fysieke aanwezigheid zijn. Participation by direct action where subject and actor are in separate locations, and the actions of the actor are transmitted by electronic or mechanical means. Een participatie van directe actie waarbij subject en actor in verschillende locaties
22
aanwezig zinj en waarbij de acties van de actor via electronische of mechanische wijze verstuurd worden.
PrimaryInformationRecipient De partij die is voorbestemd het verzoek voor zorgoverdrachten of bevestigingen te ontvangen. In het geval van een verzoek tot zorgoverdracht is de ontvanger niet de verzochte performer van de zorgverlening, maar ontvangt het verzoek voor de informatie van de ontvanger en zij hoeven niet te handelen naar aanleiding van dit verzoek. Een andere mogelijkheid is dat de bedoelde ontvanger van een bevestiging van zorgoverdracht (promise) meestal de auteur van een corresponderend verzoek is maar ook een ‘copy to’ ontvanger kan zijn. De bedoelde ontvanger kan een toegewezen persoon of organisatie zijn (R_AssignedParty), zoals een zorgverlener, een gerelateerde partij (R_RelatedParty), bijvoorbeelde een familielid of raad, of de patiënt zelf (R_Patient). Attributen typeCode: De type code is PRCP (primary information recipient). contextControlCode: Zie de beschrijving die hierboven gegeven is in de Algemene Participatie attributen. De default waarde is “OP”. In dit domein gaat de gestuurde pertinente informatie ten aanzien van patiënten variëren afhankelijk van de behoeften van de patiënt en de behoeften van de zorgverleners. Evenzo is dit domein georganiseerd in Care Structures die het toestaan dat Partial Information Models gebruikt worden als bouwstenen in het construeren van het grotere informatiemodel voor een specifieker communicatie.
Algemene ActRelationship Attributen De volgende ActRelationship attributen worden meestal gebruikt in Act Relationships die geassocieerd zijn met de focale CareProvision Act en andere geassocieerde Acts. De attributen zullen hier in algemene zin worden beschreven en beschreven in de context met de specifieke Act Relationship waar meer specifieke details nodig zijn. contextConductionInd: Wanneer het context conduction indicator attribuut op ‘true’ gezet wordt wordt alle context van de parent act die gemakeerd is als ‘propagating’ naar de geassocieerde child act geleid. Het alternatief is dat wanneer deze op ‘false’ gezet er geen context geleid wordt naar de geassocieerde child act. contextControlCode: Specificeert hoe een child act bijdraagt aan de context van de parent act. Als sontext wordt geleid naar andere child acts dan specificeert dit attribuut ook of de context die door de child geleverd wordt, leidt naar ander children. Dit attribuut is een code van twee karakters die in elke combinatie gebruikt kan worden en het leidende gedrag specificeren: 'AN': de associatie wort alleen toegevoegd aan de context van deze act en word niet geleid door een childAct 'AP' : de associatie wordt toegevoegd aan context van deze act en kan geleid worden door een child Act ‘ON': elke associatie(s) van hetzelfde of meer specifieke type die geleid worden van de parent worden vervangen door deze associatie en deze associatie wordt niet geleid door elke child act.
23
'OP':
elke associatie van hetzelfde of meer specifieke type geleid worden van de parent worden vervangen door deze associatie en deze associatie kan geleid worden door elke child act.
sequenceNumber:Het SequenceNumber attribuut kan gebruikt wroden om de volgorde van elk component aan te geven. Recursive Care Provision Act Relationships De focale Care Provision Act heeft drie relaties die terugverwijzen naar de centrale Act zelf: dit zijn de zognaamde recursieve relaties. Sequel to Deze relatie geeft een chronologische volgorde of levenscyclus van zorgverlening acts aan. Bijvoorbeeld: voor preventieve zorg tijdens een derde zwangerschap zou het relevant kunnen zijn om tergu te verwijzen naar de eerste en tweede zwangerschap die voltooid zijn en naar de kinderen die hiervan het resultaat zijn. Ook kan een Care Provision Event gerelateerd zijn aan de Care provision Request voor welke de Event de vervulling is; of een vervangende Care Provision Event die een voorgaande account van het Event corrigeert. Attributen typeCode: de type code is een subset van de waarden uit het ActRelationshipSequel domein (zie box hieronder). code SEQL (is sequel)
FLFS (fulfills)
OCCR (occurrence)
RPLC (replaces)
INST (instantiates (master))
beschrijving An act relationship indicating that the source care provision act follows the target care provision act. Een act relatie die aangeeft dat de bron care provision act de doel care provision act volgt. The source care provision act fulfills (in whole or in part) the target care provision act. Source must be in a mood equal or more actual than the target. De bron care provision act vervult (geheel of gedeeltelijk) de doel care provision act. The source care provision act is a single occurrence of a repeatable target care provision act. Source must be in a mood equal or more actual than the target. De bron care provision act is een eenmalige gebeurtenis van een te herhalen doel care provision act. Bron moet in een mood gelijk zijn aan het doel of in een meer actuele mood. A replacement source care provision act replaces an existing target care provision act. The state of the care provision act being replaced becomes obsolete, but the care provision act is typically still retained in the system for historical reference. Een bron care provision act vervangt een bestaande doel care provision act. De status van de care provision act die vervangen wordt, wordt obsoleet, maar de care provison act wordt behouden in het systeem voor historische referentie. Used to capture the link between a potential care provision ("master" or plan) and an actual care provision, where the actual care provision instantiates the potential care provision. The instantiation may override the master's defaults. Wordt gebruikt om de link tussen mogelijke care provision en de feitelijke care provision vast te leggen, waarbij de feitelijke care provision de potentiele care provision instantieert.
ContextControlCode: Zie beschrijving in Common ActRelationship attributen. ContextConductionInd: Zie beschrijving in Common ActRelationship attributen.
24
Component 3 De component3 relatie heeft CareProvision als zijn bron en heeft een andere Care Provision (zorgverlening) als doel en wordt gebruikt om groeperingen van Care Provisions te maken in een min of meer hiërarchische volgorde. Bijvoorbeeld voor Care Provision dat is gegeven aan een patiënt om een complicatie te behandelen, zoals behandling voor een allergie voor antibiotica, deel van een overall zorgverlening voor een infectie. Attributen typeCode: De type code is COMP (has component). ContextConductionInd : Zie beschrijving in Common ActRelationship attributen. ContextControlCode: Zie beschrijving in Common ActRelationship attributen. Sequence number: Zie beschrijving in Common ActRelationship attributen. Pertinent information 3 De pertinentInformation3 relatie bevestigt een erg onspecifieke relatie van één item van klinische informatie naar een andere.Het geeft geen oordeel over de rol van de pertinente informatie. Het wordt gebruikt om gedetailleerde, bestaande informatie aan de huidige Care Provision Act te verbinden. Voorbeelden omvatten: operatiegeschiedenis uit het verleden, een familie geschiedenis profiel, historische lijst van vrijgestelde medicatie. Attributen typeCode: De type code is waarde van de volgende subset afgeleid van het ActRelationshipPertains domein (zie box hieronder). code PERT (has pertinent information) SAS (starts after start of) PREV (has previous instance)
SUMM (summarized by)
beschrijving A very unspecific relationship from the source care provision act to another care provision act. Een ongespecificeerde relatie tussen de bron care provision act naar een andere care provision act. The source Care Provision Act starts after the start of the target Care Provision Act. De bron care provision act start na de start van de doel care provision act. A relationship in which the target Care Provision act is a predecessor instance to the source Care Provision act. Generally each of these instances is similar, but not identical. Een relatie waarin de doel care provision act een voorloper is van de bron care provision act. Over het algemeen is elke van deze instantiaties gelijk maar niet identiek. A Care Provision act that contains a summary of a list or set of subordinate Care Provision acts. Een Care Provision act die een samenvatting van een lijst of set van van ondergeschikte care provision acts bevat.
ContextConductionInd: Zie beschrijving in Common ActRelationship attributen. ContextControlCode: Zie beschrijving in Common ActRelationship attributen. Sequence number: Zie beschrijving in Common ActRelationship attributen.
Information related to Care Provision De overgebleven associaties van de Act voor Care Provision zijn gericht op het leveren van andere pertinente informatie over het doel van zorg om de samenwerking tussen zorgverleners
25
te ondersteunen. De typen informatie, die verder beschreven worden in de ‘Care Structures topic’, omvatten: ∗ basis care statements, bijvoorbeeld ruwe data met minimale samenvatting of interpretatie. ∗ samenvattende informatie gecreëerd in lijsten en andere structuren, bijvoorbeeld medicatielijsten, operatielijsten , SOAP aantekeningen; ∗ aan beoordeling gerelateerde care statements, bijvoorbeeld probleemlijsten, allergielijsten. ∗ zorgplannen en hun geassocieerde richtlijn definities; wat is voorgesteld, wat is besteld of gepland, wat was afgerond en wat moet nog afgerond worden. ∗ statements over de conditie die effect hebben op de verzorgers van de patiënt, zoals familieleden, bijvoorbeeld vermoeidheid van de zorgverlener. Reason Deze ActRelationship specificeert de klinische reden voor de Care Provision gerepresenteerd als een Conditie Observatie. Dit onderwerp wordt verder uitgewerkt in het stuk over Conditions in de CareStructures topic document. Attributen typeCode: De type code is RSON (has reason). contextConductionInd: Zie beschrijving in Common ActRelationship attributen. Default waarde “true”. contextControlCode: Zie beschrijving in Common ActRelationship attributen. Default waarde “AN” (Additive, non-propagating). Reference Deze ActRelationship levert informatie over de Encounter die de Care Provision Act heeft gegenereerd. Attributen typeCode: De type code is REFR (refers to). contextConductionInd: : Zie beschrijving in Common ActRelationship attributen. Default waarde “false”. contextControlCode: : Zie beschrijving in Common ActRelationship attributen. Default waarde “OP” (overriding, propagating). Pertinent information2 De pertinentInformation2 relatie staat care statements pertinent toe maar geen delen van de geassocieerde Care Povision act, zoals relevante pathologie en observaties in de vorm van beeld, klinische bevindingen, familiegeschiedenis en meetschalen. Het doel van de act relatie is de CareStatement keuze welke in detail besproken wordt in het Care Structures topic. Attributen typeCode: de type code is PERT (has pertinent information). ContextConductionInd: Zie beschrijving in Common ActRelationship attributen. ContextControlCode: Zie beschrijving in Common ActRelationship attributen. Component1 De component1 act relatie staat care statements toe pertinent die expliciet splitsen van de geassocieerde Care Provision act, zoals pathologie en beeld observaties, klinische bevindingen, familiegeschiedenis en meetschalen uitgevoerd tijdens the scope van de bron care provision act. Het doel van de act relatie is de CareStatement keuze welke in detail beschreven wordt in het Care Structures topic.
26
. Attributen typeCode: de type code is COMP,(component). ContextConductionInd: Zie beschrijving in Common ActRelationship attributen. De default: true ContextControlCode:Zie beschrijving in Common ActRelationship attributen. De default waarde “AN”. Sequence number: Zie beschrijving in Common ActRelationship attributen. Pertinent information 1 De pertinentInformation1 act relatie staat een gemengde collectie toe van care statements pretinent maar niet direct gerlateerd aan geassocieerde Care Provision act. Het doel van de act relatie is de StatementCollector keuze welke in detail wordt besproken in de Care Structures topic. Attributen typeCode: de type code is PERT (has pertinent information). ContextConductionInd: Zie beschrijving in Common ActRelationship attributen. ContextControlCode: Zie beschrijving in Common ActRelationship attributen. Sequence number: Zie beschrijving in Common ActRelationship attributen. SubjectOf De subjectOf act relatie heeft als target van de ‘has subject’ relatie de Care Provision act met als bron de Care Statement. Dit maakt het maken van statements mogelijk die additionele informatie over de Care Provision Act kwalificeren of leveren, zoals aantekeningen en geplande herzieningen van een zorgplan. Attributen typeCode: de type code is SUBJ (has subject). contextConductionInd: Zie beschrijving in Common ActRelationship attributen. De default waarde is “true”. contextControlCode: Zie beschrijving in Common ActRelationship attributen. De default waarde is “AN” (additive, non-propagating). FinalGoal
De finalGoal act relatie staat een clinical statement toe die het einddoel weergeeft van de Care Provision dat geassocieerd moet worden met de bron act. Attributen typeCode: OBJF. contextConductionInd: Zie beschrijving in Common ActRelationship attributen. De default waarde is “true”. contextControlCode: Zie beschrijving in Common ActRelationship attributen. De default waarde is “AN” (additive, non-propagating). 2.4.4
Domain topics
Het Care pRovision domein is verdeeld in een aantal onderwerpen en focust op het deel van het informatiemodel dat de focale klasse van de Care Provision omringt. Andere pertinente klinische informatie zal gevonden worden in het Clinical Structures topic dat hieronder
27
genoemd wordt. Een lijst van onderwerpen die bedoeld zijn voor het Care Provision Domein omvat: ∗ Care Structures topic. Dit onderwerp omvat CMETS voor het Care Provision Domein. Specifieke Care Provision Structuren omvatten de Condition Tracking structuur, de Care Plans/Guidelines structuur en andere specifieke structuren. De Care Statement Structuur, welke een beperkte en uitgebreide versie is van het Clinical Statement Patroon, is onderdeel van deze sectie; ∗ Care Record topic. Dit onderwerp bevat de samenvatting en dossier uittreksel notificaties die gebruikt worden om de daadwerkelijk gegeven zorg te communiceren terwijl een subject onder de zorg stond van een verantwoordelijke partij; ∗ Care Record Query topic. Dit topic omvat de queries en query antwoorden die gerelateerd zijn aan de feitelijk verstrekte zorg waarin de zorg aan een subject onder de verantwoordelijkheid viel van een zorgverlener; ∗ Care Transfer topic. Dit onderwerp bevat de onderhandelingsberichten in de zakelijke cyclus van verzoeken en beloften die plaatsvinden wanneer een overdracht van verantwoordelijkheid voor zorg geregeld wordt; ∗ Care Transfer Query topic. Dit onderwerp bevat de queries en query antwoorden die gerelateerd zijn aan de status van onderhandelingen over zorgoverdracht. ∗ International Affiliate topic. Deze onderwerpen worden alleen geintroduceerd voor het geven van opmerkingen. Zij kunnen ooit ingediend worden als voorstellen voor de ballot.
28
2.5 2.5.1
Care Statement Structuur Overzicht (januari 2007) Bereik van de Care Statement Structuur Domein
Het Care Structures topic definieert de vele UML klasse diagrammen, de zgn. Care Structures, welke de informatie pertinent aan de voortdurende zorgverlening modelleren. Deze worden beschreven als lokale CMET’s welke 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. Deze structuren handhaven de basis van de verantwoordelijkheid voor zorg. Daarnaast wordt in de scope aangegeven welke verantwoordelijkheden er zijn voor bijvoorbeeld de conditie tracker en zorgplannen. De Care Structures vertegenwoordigen de variabele delen van een communicatie met
29
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 communicaties met deze informatie zijn 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); ∗ samenvatingsinformatie gecreerd 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 geassocieerde richlijndefinities (wat is gedaan, wat moet nog, wie is verantwoordelijk ); ∗ statements over toestand van verzorgers van de patiënt (bijv. familieleden). Natuurlijk zal de pertinente informatie die wordt bijgesloten in een individuele communicatie varieren 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 bercihten worden uitgebreid als dat nodig is. Dit topic refereert aan het domein Clinical Statement Patroon (waarvan de beschrijving is opgenomen in een apart document) en begeleidt lezers in 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 Condition 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 document 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 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
30
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 De Care Structuren topic is bedoeld als een bibliotheek van herbruikbare en te vervangen care structuren 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, van afgeleid kunnen worden. Sommige van deze speciefe care structures worden geleverd als informatieve voorbeelden: Normatieve Care Structuren: ∗ Care Statement; ∗ Composition Content; ∗ Statement Collector; ∗ Condition Tracking Structuur; ∗ 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 om te gebruiken in het Care Provision Domein, welke afgeleid zijn van zijn DMIM. De CMET wordt gebruikt om deze complexe care structuren te representeren die worden gebruikt in meerdere R-MIM’s. Dit vereenvoudigt de RMIM 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 creatietijd. 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 zijn 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 DMIM. De Care Statement structuur is beperkt tot het definiëren van de Condition 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
31
Zoals hierboven vermeld focust de ballot pool 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 pool. Voor het contrast 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: Een uitdrukking van een afzonderlijk item klinische (of klinisch gerelateerde) informatie dat moet worden 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 statement qua hoeveelheid en betekenis van informatie erg variëren. Klinische informatie vereist dat de informatie wordt geassocieerd met een patiënt waarbij duidelijk wordt: ∗ context in tijd; ∗ relatie met de patiënt; ∗ in geval van een observatie: de moodcode en de aanwezigheid of afwezigheid ervan of een waarde, ∗ in geval van een procedure: de 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 Pattern is een veralgemeniseerd HL7 abstractie patroon dat gebruikt wordt in meer HL7 domein message information models die basisdata leveren over het target van zorg. Dit HL7 patroon kan worden beperkt, uitgebreid, of ongewijzigd gelaten worden door HL7 Technical Committees welke 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 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 Care 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 om de Care Statements te ondersteunen meer uitgebreid dan het vocabulair dat slechts gebruikt wordt om de zorg van patiënten te ondersteunen. Deze uitbreidingen zullen gedocumenteerd worden door een graduele 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 RMIM of bij run-time uitvoering van een applicaite om de variabilitiet van mate en detail te kunnen ondersteunen dat beschreven wordt in de bovenstaande clinical statment 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.
32
De uitbreiding van de Clinical Statement naar Care Statement verbreedt de definitie van Care Statement naar: Een uitdrukking van een afzonderlijk item van zorggeralteerde informatie dat wordt vastgelegd omdat het relevant is voor de zorg van een patiënt / cliënt. Zorg informatie 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: ∗ context in tijd; ∗ relatie met target of care; ∗ in geval van een observatie: de moodcode en aanwezigheid, afwezigheid of waarde; ∗ in geval van een procedure: de 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. inperking van het Clinical Statement Pattern Domein ∗ de veelvoudigheid van Clinical Statement ActChoice Act identifiers wordt aangegeven in the Pattern als (0..*), terwijl deze veelvoudigheid in de Care Statement Act identifiers is beperkt tot (1..*). De reden voor deze belangrijke inperking 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 normaalgesproken gegenereerd door het systeem dat de instance (instantiatie) authoriseert. Echter, er bestaan veel instance identifiers strategieën en de enige aanname in deze inperking is dat een instance identifier op een unieke wijze de instance identificeert in systemen die bevraagd worden. Instances kunnen in privacy 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 ClinicalStatement keuze. Echter, in de Care Strucutres 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, uitgerold en gedefinieerd wordt. Met andere woorden, in één en dezelfde R-MIM mogen condition events niet dubbel gerepresenteerd worden in zowel de Condition Tracking Structure als vanuit Condition Acts geconstrueerd uit de Care Statement. Daarom handelen de volgende Care Structures elk als een beperking op de Care
33
Statement wanneer de afgeleide Care Structure en de Care Statement in hetzelfde RMIM 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 inperkingen op vocabulaire door gebruik te maken van HL7 attributen, InfrastructureRoot.templateId en InfrastructureRoot.realmCode. Zo zullen inperkingen specifiek worden gedefinieerd in zowel de niet uitgerolde delen van de structuur en het overgebleven beperkte Care Statement portie van de structuur. Als gevolg hiervan kunnen veel Care Structures die gepubliseerd zijn in dit document opnieuw geclassificeerd worden en als templates gepubliseerd worden zodra de publicatie van templates gedefinieerd wordt. In de volgende sectie worden de RMIM’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 Structuur helpt bij het verzamelen van klinische informatie, die gedocumenteerd kan worden tijdens de zorgverlening. De keuzebox staat het uitdrukken van elke verzameling van statements over zorg in elke volgorde of in elk aantal en in elkecombinatie toe, 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 Structuur in dit Domain Message Information Model voor Care Provision om te benadrukken dat Care van toepassing kan zijn op medischa apparatuur, faciliteiten en omgevingen, als mede op patiënten. Op die manier wordt de vocabulair, gebruikt om de Care Staments 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 graduele 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 bji de reatie van de RMIM 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 representeert een standaard structuur op hoog niveau voor het opnemen van klinische informatie in Care Provision communicatie bedoeld ten behoeve van de 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 communicaties met betrekking tot klinische informatie.
34
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 wordt overgedragen; - 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..*); • waarden sets van attributen kunnen beperkt worden tot meer beperkte waarden sets; 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 dat ‘Observation Class' wordt beperkt tot 'ConditionClass'; - 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 communicatie specificatie 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 statements te linken waar er een specifieke relatie is. De klasseklonen in de CareEntry keuze zijn hetzelfde als die beschikbaar zijn in de Clinical statement Pattern ActChoice. Namen van klasseklonen en alle aspecten van de attributen zijn identiek.
35
linken van Care Statements Het modelleren van het linken van Care Statements is als volgt van dat gemodificeerd in het Care Statement Pattern: ∗ de sourceOf/targetOf relatie is uit elkaar gehaald in twee aparte relaties: sourceOf en targetOf; ∗ target van de sourceOf relatie is de buitenste Care Statement keuze; ∗ SourceOf1 is weggehaald; ∗ een inperking is toegevoegd aan de nieuwe sourceOf relatie: de waarde van contextConductionInd is ‘false’ als de target 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 varietiet van andere typen Entiteiten (o.a. hulpmiddelen). Om dit te ondersteunen is de target 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 Intance of Kind rol (gespeeld door een Material Kind dat zelf gespecificeerd kan zijn als deel van een groter geheel).
36
3.
STORYBOARDS
3.1
Doel
introductie Voor details over het gebruik van storyboards zie discussie in het HL7 Development Framework, Hoofdstuk 2 waarin staat dat het storyboard Investigation Request een model gebruikt dat bijna elke entitieit toestaat beschreven te worden. Voor de additionele storyboards, verzameld van internationale auteurs als deel vn HDF requirements analysis, zie Care Provision Domain Requirements Analysis Atrifacts PDF. Voor de storyboard die gebruikt zijn om specifieke berichten, diensten of document definities te illustreren wordt u verwezen naar de juiste topic onder het Care Provision Domain. Domein Storyboards Dit deel van het Care Provision Document wordt gebruikt om in het algemeen de scope van het Care Provision Domein te illustreren. Deze storyboards omvatten: ∗ patiëntzorg van prenatale tot pediatrische zorg tot ouderenzorg (aged care); ∗ zorg settings van thuiszorg tot ambulante zorg tot spoedeisende zorg tot ziekenhuis zorg; ∗ zorgsubjecten van populaties tot individuele patiënten tot omgevingen en faciliteiten; ∗ zorgverleners inclusief verpleegkundigen, artsen, het multidisciplinaire team, de patiënt zelf en mantelzorgers; ∗ zorg workflows van "directe zorg" tot "overdrachten van zorg" tot de "communicatie van zorgdossiers". Merk op: de storyboards in dit deel illustreren de scope van het domein in het algemeen, dit is echter geen onuitputtelijke beschrijving. De overige storyboards kunnen teruggevonden worden in de Care Provision Domain Requirements Analysis Artifacts PDF en de Care Provision topics. Het formaat dat gebruikt wordt in de HL7 storyboard beschrijvingen volgt de onderstaande indeling: Doel: een korte uitleg van de inhoud. Interactie Diagram: (meestal alleen aanwezig op het Care Provision topic niveau). Preconditie: De status van de deelnemers en de informatie voorafgaand aan het verhaal. Activiteiten: De activiteiten in het verhaal. Postconditie: De status van de deelnemers en de informatie nadat het verhaal afgelopen is. Activity Diagram: Een UML "flowchart" van opeenvolgende acties (meestal alleen aanwezig in de Care Provision Domain Requirements Analysis Artifacts PDF). Verklarende woordenlijst (Glossary): Een definitie van elk van de termen bestaand uit meerdere woorden die gebruikt worden in het storyboard (meestal alleen aanwezig in de Care Provision Domain Requirements Analysis Artifacts PDF).
37
3.2
Patiënt Vult Persoonlijk Medisch Dossier (DOPC_ST000033)
doel Dit storyboard demonstreert de communicatiestroom die geassocieerd wordt met verzoeken voor componenten van een medisch dossier , inclusief hele documenten.
Patient Populates Personal Health Record (DOPC_SN000033UV) Preconditie: Mr. Adam Everyman wenst een personlijk medisch dossier te vullen met informatie van Dr. Patricia Primary, die zijn in haar klinisch system houdt, over zijn conditie. Activiteiten: Mr. Adam Everyman vraagt om specifieke informatie van Dr. Patricia Primary, gerelateerd aan zijn cardiale conditie. Dr. Primary antwoordt dor het sturen van de antwoorden op de apecifieke informatie die aangevraagd is door Mr. Everyman die in staat is de informatie in zijn eigen persoonlijke medisch dossier op te nemen Mr Everyman uploadt de informatie over zijn cardiale conditie in zijn persoonlijk medisch dossier. Alternatieve stroom: Mr Everyman vraagt kopieen aan zijn bepaalde testresultaten en behandelingen gerelateerd aan zijn cardiale conditie bij Dr Primary Dr Primary antwoord door het sturen van de documenten aan Mr Everyman. Postconditie: Mr. Everyman heft nu alle documenten en informatie die hij nodig heft van Dr. Primary over zijn cardiale conditie. 3.3
Pediatrische Immunisatie (Vaccinatie) (DOPC_ST000030)
doel Dit storyboard demonstreert de interactie tussen een Jeugdarts en een immunisatie registratie voor de regio. In Nederland wordt vaccinatie als term gebruikt, maar omwille van de herkenbaarheid van de HL7 artifacten wordt immunisatie gebruikt voor deze tekst. Pediatrische Immunisatie (DOPC_SN000030) Pre-conditie: Billy Newpatient is 4 jaar oud. Hij is behandeld bij andere klinieken in de regio. Maar, hij is een nieuwe patiënt bij de GGD van dr Jeugdig. Hij is daar voor een peutertijd lichamelijk onderzoek. Dr Jeugdig's elektronisch kind dossier (EKD) is in staat te koppelen met een regionale immunisatie registratie. De regionale immunisatie registratie voldoet aan de standaarden van de entadministratie. Het elektronisch kind dossier (EKD) van de GGD voldoet aan het HL7 Functioneel Ontwerp voor Elektronische Patiënten Dossiers. De regionale immunisatie registratie is in staat het immunisatie dossier van de patiënt te lokaliseren via het LSP. activiteiten Tijdens een vraaggesprek ontdekt de jeugdverpleegkundige dat bij Billy zijn zorgverlener zijn immunisatie dossier niet beschikbaar is. Bij het voorbereiden van zijn nieuwe patiëntendossier voor dr Jeugdig, geeft de verpleegkundige de aanzet voor het EKD om de regionale immunisatie registratie te bevragen. De immunisatie registratie vindt en stuurt data naar het EKD van de GGD. Het EKD vult Billy zijn patiëntendossier met deze data. Het EKD van de kliniek genereert immunisatie aanbevelingen door een beslissingsondersteuning instrument te gebruiken.
38
alternatieve Stroom #1 De regionale registratie gebruikt een ondersteuningsinstrument en stuurt aanbevelingen samen met Billy zijn immunisatie data. Dr Jeugdig bekijkt het dossier en noteert (naast andere data) Billy zijn immunisatie dossier (of de afwezigheid daarvan) en aanbevelingen. Na het afnemen van een anamnese en het doen van een lichamelijk onderzoek, vraagt zij immunisaties aan. De verpleegkundige dient de shots toe en documenteert deze in het elektronisch kind dossier. Het EKD stuurt het bericht over de nieuwe immunisaties naar de entadministratie welke zijn dossier aanpast. De verpleegkundige drukt ook een aangepast dossier van Billy zijn immunisaties af op papier. alternatieve Stroom #2 Dr Jeugdig bepaalt dat Billy geen immunisaties nodig heeft of besluit in dit stadium nog geen immunisaties toe te dienen. Er worden geen aanpassingen gemaakt aan de immunisatie geschiedenis in het patiënten dossier. Er worden geen data gestuurd naar de registratie. Postconditie: De regionale registratie heeft Billy zijn immunisatie geschiedenis gestuurd. De regionale registratie heeft Billy zijn nieuwe immunisatie vastgelegd. Het EKD van de GGD heeft een aangepast immunisatie dossier. Billy zijn zorgverlener heeft een aangepast immunisatie dossier.
3.4
Huisarts Verwijst naar Specialist (DOPC_ST000034)
doel Dit storyboard demonstreert een verwijzing voor specialistische zorg, inclusief de levering van gedetailleerde klinische data die bewijs tonen voor aritmieën en een verzoek voor een afspraak. Huisarts Verwijst naar Specialist (DOPC_SN000034) Preconditie: dr Patricia Primary heeft meneer Adam Everyman, een 45-jarige oude mannelijke patiënt, gezien in haar kantoor met een klacht van episodes van snelle hartslag met kortademigheid. Ze besluit meneer Everyman te verwijzen naar cardioloog dr Patrick Pump. activiteiten Dr Primary neemt een anamnese en een lichamelijk onderzoek af bij meneer Everyman, als ook een 12-polig ECG. Het apparaat in dr Primary's kantoor geeft aan "verkorte PR-Interval, mogelijke Delta Wave; overweeg WPW". Dr Primary besluit meneer Everyman te verwijzen naar dr Pump voor verdere evaluatie. Ze schrijft meneer Everyman ook anti-aritmie medicatie voor. Mr. Chris Clerk, praktijkassistent van dr Primary, vraagt bij het kantoorpersoneel in het kantoor van dr Pump een afspraak aan voor meneer Everyman en stuurt de volgende data in de verwijzing geschreven door dr Primary: 1. Reden voor verwijzing: mogelijke WPW. 2. Belangrijkste Klacht: Kortademigheid. 3. Anamnese van Huidige Ziekte: Patiënt leidt gedurende enkele maanden aan een episode van snelle hartslag geassocieerd met kortademigheid welke niet verbeterde met rust nemen. 4. Probleemlijst: kortademigheid; palpitaties.
39
5. Medicatielijst: anti-aritmie. 6. Allergieën en Nadelige Reacties: Geen Medicatie Allergieën bekend. 7. Beoordeling van systemen: anders negatief 6. Lichamelijk Onderzoek: (structureel onderzoek). 8. Data & tests: ECG Rapport en Beeld als hierboven. 9. Zorgplan: verwachting voor follow up/aanbevelingen - Laat me alstublieft uw evaluatie en lange termijn behandelingsaanbevelingen weten. Meneer Clerk ontvangt bevestiging van dr Pump's praktijk voor een afspraak voor meneer Everyman voor aanstaande dinsdag. Postconditie: de bovenstaande informatie is beschikbaar voor dr Pump wanneer Adam Everyman naar het kantoor van dr Pump komt voor een volledige cardiologisch onderzoek. 3.5
Multidisciplinaire Zorg (DOPC_ST000032)
doel Dit storyboard demonstreert de communicatiestroom geassocieerd met verzoeken van een huisarts aan specialisten, andere klinische of gelijkwaardige gezondheidszorgverleners om bij te dragen aan de levering van een multidisciplinair zorgplan, zoals een Chronisch Ziekte Management zorgplan (CZM). CZMs zijn ontworpen om het medische management van zorg voor een persoon met chronische of complexe zorgbehoeften, die over het algemeen verzorgd worden door vele mensen met vele rollen, te verbeteren. Multidisciplinaire Zorg - Domein (DOPC_SN000032) Preconditie: dr Patricia Primary bereidt een multidisciplinair zorgplan voor meneer Adam Everyman voor om zijn gezondheidsuitkomsten en doelen voor kwaliteit van leven geassocieerd met diabetes en hypertensie te verbeteren. Ze raadt meneer Everyman aan om een fysiotherapeut, een diëtist en zijn dochter Nancy Nuclear hierbij te betrekken. Dr Primary verkrijgt toestemming van meneer Everyman om zijn medische geschiedenis en doelen met andere (zorg)verleners en zijn dochter te delen. activiteiten verzoek gedeelde zorgverlening Dr. Primary stuurt een individueel verzoek naar Fysiotherapeut Seth Stretcher, Diëtist Connie Chow en aan de dochter van meneer Everyman, Nancy Nuclear. Ieder van hen stuurt een antwoord waarin ze bevestigen dat ze een bezoek aan meneer Everyman te zullen gaan plannen om een plan te ontwikkelen om de afzonderlijke doelen, gespecificeerd door dr Primary, te halen. Op hun beurt bezoeken Seth Stretcher en Connie Chow meneer Everyman en zijn dochter om zijn doelen in relatie tot zijn diabetes en hypertensie te onderzoeken. Ieder van hen stelt een zorgplan op voor meneer Everyman welke zij samenvatten en doorsturen naar dr Primary. Dr Primary verwerkt deze bijdragen in een totaal Chronische Ziekte Management (CZM) zorgplan met activiteiten voor elk van de leden van het zorgteam en reikt kopieën van het zorgplan uit aan elk van de leden van het multidisciplinaire zorgplanningsteam. De dochter van meneer Everyman, die onderaan het plan geïdentificeerd is als verantwoordelijk voor het assisteren van meneer Everymean bij de maaltijden en de conditie van zijn keuken, maakt ook deel uit van het team. Elk van hen erkent dat zij borg staan voor het voltooien van de activiteiten in het aangepaste, samengestelde zorgplan.
40
voortdurende gedeelde zorgverlening Elke (zorg)verlener blijft meneer Everyman zien of contact met hem houden om zijn reactie op de activiteiten in het zorgplan te beoordelen. Tijdens de eerste fase van het zorgplan leveren zij een samenvatting van de voortgang aan dr Primary. bespreken gedeelde zorgverlening Drie weken later heeft dr Primary een afspraak met meneer Everyman en zijn dochter om voortgang te bespreken in de eerste fase van het zorgplan voor het begeleiden van zijn diabetes en hypertensie. Terwijl hij enkele van zijn doelen heeft bereikt, is meneer Everymen teleurgesteld in de voortgang van de doelen gerelateerd aan het stabiliseren van zijn bloedsuikerniveaus. Dr Primary wijzigt de doelen voor de volgende fase van meneer Everymen zijn zorgplan en stuurt deze, samen met de aangepaste set van opdrachten en verzoeken voor de volgende fase naar Connie Chow en Nancy Nuclear. Connie Chow en Seth Stretcher beoordelen hun zorgplannen voor meneer Everymen in het kader van de nieuwe doelen van dr Primary en leveren voortdurende voortgangsrapportages over de nieuwe zorgplannen. Postconditie: meneer Everyman ontvangt team-gebaseerde zorg, gecoördineerd en beoordeeld door zijn Primaire Zorg Arts, dr Primary. Elke zorgverlener heeft bijgewerkte kopieën van de zorgplannen, inclusief voortgangsreportages naar implementatie van de activiteiten in de zorgplannen in de lokale zorgdossiers. 3.5
Ouderenzorg (Aged Care) Overplaatsing - Domein (DOPC_ST000035)
doel Dit storyboard demonstreert de communicatiestroom tussen een partij die een plaats zoekt in een instelling voor ouderzorg en een organisatie die ouderenzorg levert. Merk op dat de uitkomst van dit storyboard gerelateerd is aan het succes of anderszins aan een verzoek tot toegang tot services (“ heeft u een vrije plaats?”) – het zegt niets over of er een opname plaatsvindt. Ouderenzorg Overplaatsing - Domein (DOPC_SN000035) Preconditie: Peter Process is de maatschappelijk werker bij het Maas Ziekenhuis die verantwoordelijk is voor de coördinatie van het patiëntenontslag van oudere patiënten. Zijn rol is het maximaliseren van de succesvolle terugkeer van zwakke oudere ziekenhuispatiënten naar de gemeenschap, inclusief naar residentiële ouderenzorg. Hij werkt nauw samen met de ouderenzorg (thuiszorg en residentieel, zoals verpleeghuizen) in de nabije omgeving. Hij zoekt een verpleeghuisplaats voor meneer Everyman die wat intensieve revalidatie vanwege een val nodig heeft voordat hij weer veilig kan wonen bij zijn dochter die fulltime werkt. Hij raadt Verpleeghuis Avondrood aan als een geschikte instelling voor meneer Everyman en zijn dochter, Nancy Nuclear, die hem autoriseert om Avondrood namens hem te benaderen, samen met drie andere verpleeghuizen binnen een straal van 5 kilometer van Mevrouw Nuclear haar huis. activiteiten stuur verzoek voor bed Peter Process stuurt een verzoek voor een plaats in een verpleeghuis aan Alice Admitter, de Opname Coördinator van Avondrood. Wanneer zij aanvragen voor plaatsen in Avondrood
41
verwerkt, controleert Alice Admitter eerst of alle basale administratieve details aangeleverd zijn door de verwijzende partij (omdat Avondrood niet zonder indicatie patiënten kan accepteren). Ze controleert ook haar opname database om in staat te zijn het verzoek te honoreren binnen de tijd die is aangegeven door de verwijzende partij. In dit geval is één van de twee tijdelijke bedden in Avondrood beschikbaar in het verpleeghuis. Maar als zij het verzoek verwerkt merkt Alice Admitter op dat Peter Process geen indicatiebesluit van het CIZ en niet alle verzekeringsgegevens van meneer Everyman heeft bijgesloten. Ze stuurt het verzoek terug naar Peter Process, waarbij ze aangeeft het verzoek in zijn huidige vorm niet te kunnen verwerken. Peter Process stuurt een aangepast verzoek met alle vereiste administratieve informatie terug naar Alice Admitter. Alice Admitter antwoordt aan Peter Process dat ze nu het verzoek behandelt. bevestigen op zich nemen van het uitvoeren van het verzoek Alice Admitter stuurt alle verwijzingen naar de verpleeghuisadministratie of relevante zorgcoördinator, in Avondrood is dat Nancy Nightingale. Nancy Nightingale beoordeelt het verzoek en doet een verzoek om aanvullende informatie van de verwijzende partij als dat nodig is. In dit geval wil zij met zekerheid weten of de cognitieve problemen een factor zijn die invloed heeft op de capaciteit van meneer Everyman om te rehabiliteren binnen de optimistische korte tijd die gesuggereerd is door de ontslaande arts bij het Maas Ziekenhuis. verzoek zorgdossier informatie Nancy Nightingale stuurt een verzoek om verdere klinische informatie over de cognitieve functionele capaciteiten van meneer Everyman aan Peter Process van het Maas Ziekenhuis die deze keer niet de volledige resultaten van de cognitieve test had meegestuurd. Omdat hij al toestemming heeft verkregen van meneer Everymen voor het delen van de resultaten van de test met andere zorgverleners, voegt Peter Process de samenvatting van meneer Everyman zijn cognitieve en gedrag meetschalen toe, inclusief de scores van de metingen die in het ziekenhuis gedaan zijn van zijn cognitieve, gedrag en stemming status. Hij stuurt dit naar Nancy Nightingale. belofte bed Concluderend uit haar beoordeling van meneer Everyman zijn revalidatie- en zorgbehoeften is Nancy Nightingale blij een vrij bed in Avondrood aan de kunnen bieden aan meneer Everyman. Ze adviseert Alice Admitter over deze beslissing. Alice Admitter belooft het bed onmiddellijk aan Peter Process voor meneer Everyman. Deze actie past tegelijkertijd het ‘Actieve Verwijzingen’ bestand aan dat onderhouden wordt door Alice Admitter, wat het proces voor het verzoek voor services voltooit. De naam van meneer Everyman wordt niet verwijderd van het ‘Actieve Verwijzingen’ bestand totdat het bericht is ontvangen dat alle contractuele documentatie op zijn plaats is, dat de indicatie akkoord is en dat hij daadwerkelijk opgenomen is in Avondrood. Postconditie: meneer Everyman heeft een gereserveerd bed in Avondrood. Dossiers zijn aangepast met meneer Everyman zijn administratieve en klinische informatie in zowel het ziekenhuis als het verpleeghuis. Processen voor het verzoek en gegeven beloften zijn compleet. alternatieve stromen 1. Volgend op de belofte van Avondrood om services te leveren, ontvangt Peter Process een telefoontje van de dochter van meneer Everyman om aan te geven dat zij 2 maanden verlof opneemt, zodat haar vader ontslagen kan worden naar huis om met haar te wonen. Aan het eind van het verlof (wanneer zij weer gaat weken) zal zij bekijken of haar vader nog steeds
42
formele ouderenzorg dient te ontvangen. Peter Process brengt Alice Admitter en Nancy Nightingale meteen op de hoogte van het feit dat het verzoek voor services voor meneer Everyman wordt ingetrokken. Postconditie: Peter Process onslaat meneer Everyman naar huis. 2. Na de gedetailleerde cognitieve en gedrag meetschalen van meneer Everyman bekeken te hebben, bepaalt Nancy Nightingale dat het bed dat zij op dit moment beschikbaar heeft (alleen voor korte termijnopnames) niet aan de voor meneer Everyman gestelde doelen kan voldoen. Zij stelt Alice Admitter op de hoogte die op haar beurt Peter Process, meneer Everyman en zijn dochter informeert over de beslissing het verzoek voor een bed af te wijzen. Postconditie: Peter Process neemt contact op met de andere verpleeghuizen in de buurt met de hoop een geschikte plaats voor meneer Everyman te vinden. 3. Alice Admitter geeft aan Mevr. Nuclear aan dat Avondrood in staat zal zijn het volgende permanente bed aan haar vader aan te bieden wanneer het beschikbaar komt, maar ze is niet in staat precies te zeggen wanneer dat zal zijn. Mevr. Nuclear is opgetogen en bereid te wachten op een plaats in Avondrood, omdat dat haar vaders eerste keus is voor een verpleeghuis. Alice Admitter voegt de naam van meneer Everyman toe aan de wachtlijst oor permanente plaatsing. Zij stelt Peter Process hiervan op de hoogte, omdat meneer Everyman nog ontslagen moet worden uit het ziekenhuis. Postconditie: Peter Process vertraagt het ontslag van meneer Everyman totdat er een bed voor hem vrijkomt in Avondrood.
43
4.
VERWIJSBERICHT
4.1
Inleiding op verwijsbericht en overdracht
Van het in hoofdstuk 2 besproken D-MIM Care provision zijn vele implementeerbare berichten of berichtenonderdelen afgeleid. In Nederland zijn twee sets van belang omdat die in verschillende ketenzorg projecten worden toegepast. Het gaat daarbij om de set interacties om binnen zorgketens te verwijzen en terug te rapporteren en om zeer gedetailleerde enprecies omschreven klinische informatie correct te kunnen doorgeven. Dit laatste wordt in de diverse projecten geoperationaliseerd door zogenaamde zorginformatiemodellen, zie www.zorginformatiemodel.nl. Het eerste wordt in de komende hoofdstukken beschreven: hoofdstuk 4 bevat het verwijsbericht, hoofdstuk 5 de acceptatie of weigering van een verwijzing, hoofdstuk 6 een query om aanvullende gegevens van een patient / cliënt op te vragen en hoofdstuk 7 het dossier dat als rapportage wordt gestuurd. De volgorde wijkt af van de internationale ballot. Dit komt doordat hier getracht wordt beter aan te sluiten op de Nederlandse situatie.
&&& Hier hoofdstuk invoegen 4.2
Care Transfer Topic
Dit hoofdstuk is een vertaling van Hoofdstuk 8 van de Care Provision uit de ballot van januari 2007 /mei 2007. Dit is de versie van deze tekst die als DSTU (Draft Standard for Trial Use) is aangeboden en omvat informatie over: Storyboards (SB) Application Roles (AR) Trigger Events (TE) Refined Message Information Models (R-MIM) Hierarchical Message Descriptions (HMD) Interacties (IN) Dit hoofdstuk omvat de business cyclus van verwijzingen (requests) en acceptatie (promises) die deel uit maken van de overdracht (transfer) van verantwoordelijkheid voor zorg. Traditiegetrouw werd deze set van communicaties een "referral" genoemd. Echter, referrals (verwijzingen) hebben de neiging om specifieke betekenissen te hebben in verschillende culturen en er is een poging gedaan om een globale definitie van verwijzing te creëren die nogal algemeen is. Om verwarring tussen culturen te vermijden, gebruiken de internationale berichten de term "referral" niet, maar voor de Nederlandse situatie wordt daar wel gebruik van gemaakt. In de uitwerking van berichten worden specifieke use cases en triggers uitgewerkt die gerelateerd zijn aan communicaties op basis van de HL7 RIM "Act" klasse van "CareProvision (PCPR)". Het gaat hierbij in eerste instantie om de uitwerkingen die de Care Provision als de "entry point" gebruiken van het refined message information model (RMIM). In dit hoofdstuk komen de RMIMs aan de orde voor de berichten voor ‘Care Transfer’.
44
4.3
Care Transfer Definitie
Care Transfer is de communicatie tussen een Author (auteur / zorgverlener) en een andere Health Care Provider (Zorgverlener) met de intentie om te onderhandelen over de overname van verantwoordelijkheid voor de zorg door de ontvanger van het verzoek. Een overname van verantwoordelijkheid wordt ingeperkt (constrained) tot een statement van de scope van de verantwoordelijkheid, inclusief het type zorg, de genoemde specifieke condities en de genoemde specifieke zorgplannen, waarbij: 'Communicatie' kan een manier zijn van Overbrengen met of zonder een bijgesloten klinisch document als bijlage zoals een samenvatting of zorgoverdracht. 'Communicatie' kan getriggered worden door Een verzoek of verwijzing (request) voor gedeelde zorg (gedeeltelijke overdracht van verantwoordelijkheid) of een verzoek (request) voor complete overdracht van verantwoordelijkheid voor zorg 'Auteur' van zorgoverdracht communicatie kan zijn zorgverlener zorgorganisaties (healthcare agencies) (inclusief wijkverpleging, GGD, maatschappelijk werk) patiënt (zelfverwijzing) familie van de patiënt /belangrijke anderen rechtbank of andere niet-zorgorgantisatie apparaten die zijn geautoriseerd door organisaties 'Zorgverleners' kunnen zijn artsen, verpleegkundigen, maatschappelijk werkers, fysiotherapeuten, dan wel de zorgorganisaties waarin zij werkzaam zijn. Dit is een interactie diagram dat alle Interacties en Applicatie Rollen die belangrijk zijn voor het Care Transfer Topic illustreert.
45
4.4
Storyboards
De volgende storyboards zijn van toepassing op verwijzign en acceptatie: Storyboards (Gesorteerd volgens titel) Aged Care (Lite) Transfer(REPC_ST004006UV) Aged Care Transfer Request(REPC_ST004005UV) Completed Specialty Care(REPC_ST004001UV) Multidisciplinary Care Provision(REPC_ST004003UV) Request for Changes in Ongoing Service(REPC_ST004008UV) Request for Pastoral Care(REPC_ST004007UV) Request Medication Chart Review(REPC_ST004004UV) Surgical Referral(REPC_ST004002UV) Deze worden hier achtereenvolgens toegelicht om mogelijke toepassingen van het verwijsbericht en acceptatie te illusteren. Referentie Voor details over de interpretatie van deze sectie, zie de storyboard discussie in de Versie 3 Guide.
46
Request for Changes in Ongoing Service (REPC_ST004008UV) Doel Dit storyboard demonstreert de communicatiestroom tussen een cliënt/bewoner of hun vertegenwoordiger die een verzoek doen tot een verandering van een bestaande service. Interaction List (interactielijst) Revise Care Transfer Request
REPC_IN002220UV
Replace Care Transfer Promise
REPC_IN003930UV
Replace Care Provision
REPC_IN004913UV
Request for Changes in Ongoing Services (REPC_SN004008UV) Preconditie: Meneer Adam Everyman, die thuis woont, ontvangt één maaltijd per dag van ‘tafeltje dekje’ maaltijdservice ’ die uitgaat van de ‘Groene Velden Verzorgingstehuizen (GVV) Groep. Zijn dochter, die de eigen bijdrage betaalt voor deze service, merkt op dat hij gewicht blijft verliezen en haalt Meneer Everyman over om zijn huidige afname te veranderen naar twee maaltijden per dag. Activiteiten: Namens haar vader stuurt Nancy Nuclear een bericht naar de klantenservice van GVV met het verzoek om de huidige maaltijden service van haar vader te veranderen [Interactie: Revise Care Transfer Request ]. Voordat de cliënt manager van de cateringservice de aanvullende maaltijd voor Meneer Everyman kan regelen, wordt mevrouw Nuclear verzocht de additionele cliëntenbijdrage te autoriseren. De diëtist, Connie Chow stuurt een autorisatieverzoek naar mevrouw Nuclear. Mevrouw Nuclear wil de extra bijdrage graag betalen voor de extra maaltijd en adviseert Connie Chow door te gaan. Na ontvangst van de autorisatieacceptatie bevestigt de klantenservice dat de nieuwe afspraken in werking gesteld worden, bijvoorbeeld het regelen van de extra maaltijd [Interactie: Replace Care Transfer Promise wordt operationeel voor de maaltijden van Meneer Everyman’door het sturen van een nieuw verpleegplan naar mevrouw Nuclear [Interactie: Replace Care Provision ]. Postconditie: Met het versturen van de aangepaste factuur naar zijn dochter is alles is geregeld voor het ontvangen van twee maaltijden per dag door Meneer Everyman. Door het ondernemen van de noodzakelijke maatregelen met de maaltijd service, stuurt het bestellingsysteem van Connie Chow automatisch een bericht naar het cliënt accountsysteem van GVV met de boodschap dat de extra kosten gefactureerd moeten worden aan mevrouw Nuclear als aangewezen betaler voor Meneer Everyman. Update Eisen Samenvatting: De communicatiepartners in dit storyboard, mevrouw Nuclear, namens haar vader, en de diëtist, Connie Chow, houden nauwlettend in de gaten of de ingediende veranderingen op de voortdurende service (in dit geval catering) op tijd uitgevoerd worden, met documentatie van de juiste autorisaties.
47
Completed Specialty Care (REPC_ST004001UV) Doel Dit storyboard beschrijft een typische consultatie van een specialist door een huisarts. Interactie Lijst Care Transfer Request
REPC_IN002120UV
Care Transfer Promise
REPC_IN003130UV
Complete Care Provision
REPC_IN004410UV
Reject Care Transfer
REPC_IN002040UV
Revise Care Transfer Request
REPC_IN002220UV
Care Transfer Completed Speciality Care (REPC_SN004001UV) Preconditie: Dr. Patricia Primary is een huisarts die een patiënt al langere tijd regelmatig ziet en waarvoor ze gebruik maakt van haar standaard behandelplannen voor de klacht. De klacht van de patiënt wordt erger en Dr. Primary wil graag de mening van een gastroenteroloog, Dr. Tony Tum. Activiteiten: Dr. Primary bereid een samenvatting voor van de bestaande elektronische medische dossiers waarbij de reden voor consultatie wordt uitgelicht, inclusief samenvattingen van de andere medische condities waarvoor de patiënt zorg ontvangt, en inclusief de medicatielijst, allergieënlijst en lijsten van vorige operaties en ziekenhuisopnames. Deze samenvatting wordt naar Dr. Tum gestuurd samen met een verzoek om de patiënt te zien [Interactie: Care Transfer Request]. Dr. Tum besluit de patiënt te zien en stuurt het juiste antwoord terug naar Dr. Primary [Interactie: Care Transfer Promise]. Dr. Tum ziet dan de patiënt, maakt een samenvatting van zijn evaluatie en meningen over het veranderen van de behandeling [Interactie: Complete Care Provision]. Dr. Tum stuurt de samenvatting naar Dr. Primary die de behandelplannen aanpast op basis van de aanbevolen veranderingen. Alternatieve stromen: 1. Dr. Tum kan het verzoek om de patiënt te zien afwijzen [Interactie: Reject Care Transfer] >>Post-Conditie: Dr. Primary probeert een andere gastroenteroloog. 2. Dr. Tum kan aanbevelingen sturen zonder de patiënt te zien (papieren consultatie). 3. Dr. Tum kan verzoeken om meer informatie voordat hij de patiënt ziet (niet afgebeeld). 4. Dr. Primary kan meer informatie sturen zonder een verzoek om meer informatie [Interactie: Revise Care Transfer Request]. Postconditie: Dr. Primary gaat de patiënt weer op regelmatige basis zien, waarbij ze gebruik maakt van de aangepaste behandelplannen voor de patiënt. Updates Samenvatting Eisen: De communicatiepartners van deze berichten, Dr. Primary en Dr. Tum richten zich op het verzoek voor verwijzing van Dr. Primary en de uitkomst van die
48
verwijzing terug naar Dr. Primary. Dit omvat de door Dr. Primary bijgewerkte informatie te leveren aan Dr. Tum als dat van pas komt tijdens de consultatie.
Multidisciplinary Care Provision (REPC_ST004003UV) Doel Dit storyboard demonstreert de communicatiestroom die geassocieerd wordt met verzoeken door een huisarts aan andere klinische of gelijkwaardige zorgverleners om bij te dragen aan een multidisciplinair zorgplan, zoals een Chronische Ziekte Management zorgplan (CZM). CZMs zijn ontwikkeld om het medische management van zorg voor een persoon met chronische of complexe zorgvragen te verbeteren. (In Australië wordt een huisarts aangemoedigd samen de werken met andere zorgverleners als de patiënt complexe zorgbehoeften heeft, welke baat zouden hebben bij inbreng van een multidisciplinair zorgteam. Gelijksoortige initiatieven bestaan in veel landen.) Interactie Lijst Care Transfer Request
REPC_IN002120UV
Care Transfer Promise
REPC_IN003130UV
49
Activate Care Provision
REPC_IN004110UV
Revise Care Transfer Request
REPC_IN002220UV
Replace Care Transfer Promise
REPC_IN003930UV
Append Care Provision
REPC_IN004211UV
Revise Care Transfer Request
REPC_IN002220UV
Replace Care Provision
REPC_IN004913UV
Multidisciplinary Care Provision (REPC_SN004003UV) Preconditie: dr Patricia Primary bereidt een multidisciplinair zorgplan voor de heer Adam Everyman voor om zijn gezondheidsuitkomsten en doelen voor kwaliteit van leven geassocieerd met diabetes en hypertensie te verbeteren. Ze raadt de heer Everyman aan om een fysiotherapeut, een diëtist en zijn dochter Nancy Nuclear hierbij te betrekken. Dr Primary verkrijgt toestemming van de heer Everyman om zijn medische geschiedenis en doelen met andere (zorg)verleners en zijn dochter te delen. Activiteiten: verzoek gedeelde zorgverlening Dr. Primary stuurt een individueel verzoek naar Fysiotherapeut Seth Stretcher, Diëtist Connie Chow en aan de dochter van de heer Everyman, Nancy Nuclear. [Interactie: Care Transfer Request ]. Ieder van hen stuurt een antwoord waarin ze bevestigen dat ze een bezoek aan de heer Everyman te zullen gaan plannen om een plan te ontwikkelen om de afzonderlijke doelen, gespecificeerd door dr Primary, te halen. [Interactie: Care Transfer Promise]. Op hun beurt bezoeken Seth Stretcher en Connie Chow de heer Everyman en zijn dochter om zijn doelen in relatie tot zijn diabetes en hypertensie te onderzoeken. Ieder van hen stelt een zorgplan op voor de heer Everyman welke zij samenvatten en doorsturen naar dr Primary. Dr Primary verwerkt deze bijdragen in een totaal Chronische Ziekte Management (CZM) zorgplan met activiteiten voor elk van de leden van het zorgteam en reikt kopieën van het zorgplan uit aan elk van de leden van het multidisciplinaire zorgteam. De dochter van de heer Everyman, die onderaan het plan geïdentificeerd is als verantwoordelijk voor het assisteren van de heer Everyman bij de maaltijden [Interactie: Revise Care Transfer Request ] en de conditie van zijn keuken, maakt ook deel uit van het team. Elk van hen erkent dat zij borg staan voor het voltooien van de activiteiten in het aangepaste, samengestelde zorgplan [Interactie: Replace Care Transfer Promise]. voortdurende gedeelde zorgverlening Elke (zorg)verlener blijft de heer Everyman zien of contact met hem houden om zijn reactie op de activiteiten in het zorgplan te beoordelen. Tijdens de eerste fase van het zorgplan leveren zij een samenvatting van de voortgang aan dr Primary [Interactie: Append Care Provision ]. bespreken gedeelde zorgverlening (niet getoond in Interactie Diagram) Drie weken later heeft dr Primary een afspraak met de heer Everyman en zijn dochter om voortgang te bespreken in de eerste fase van het zorgplan voor het begeleiden van zijn diabetes en hypertensie. Terwijl hij enkele van zijn doelen heeft bereikt, is de heer Everyman teleurgesteld in de voortgang van de doelen gerelateerd aan het stabiliseren van zijn bloedsuikerniveaus. Dr Primary wijzigt de doelen voor de volgende fase van de heer Everyman
50
zijn zorgplan en stuurt deze, samen met de aangepaste set van opdrachten en verzoeken voor de volgende fase naar Connie Chow, Seth Stretcher en Nancy Nuclear. [Interactie: Revise Care Transfer Request ]. Connie Chow en Seth Stretcher beoordelen hun zorgplannen voor de heer Everyman in het kader van de nieuwe doelen van dr Primary en leveren voortdurende voortgangsrapportages over de nieuwe zorgplannen [Interactie: Replace Care Provision]. Postconditie: de heer Everyman ontvangt team-gebaseerde zorg, gecoördineerd en beoordeeld door zijn huisarts, dr Primary. Updates Samenvatting Eisen: De deelnemers aan dit storyboard zijn Dr Primary, fysiotherapeut Seth Stretcher, diëtist Connie Chow en de dochter van de patiënt, Nancy Nuclear. Zij letten erop te antwoorden op een verzoek van Dr Primary om samen te werken aan de ontwikkeling van een geïntegreerd zorgplan voor Meneer Everyman om zijn gezondheidsuitkomsten en doelen voor kwaliteit van leven geassocieerd met diabetes en hypertensie te verbeteren. Aged Care Transfer Request (REPC_ST004005UV) doel Dit storyboard demonstreert de communicatiestroom tussen een partij die voor een cliënt een plaats zoekt in een instelling voor ouderzorg en een organisatie die ouderenzorg levert. Merk op dat de uitkomst van dit storyboard gerelateerd is aan het succes of aan een verzoek tot toegang tot services (“ heeft u een vrije plaats?”), maar niets zegt of een opname plaatsvindt. Dit laatste is afhankelijk van het aangaan van een contract.. Interactie Lijst Care Transfer Request
REPC_IN002120UV
Reject Care Transfer
REPC_IN002040UV
Notify Care Transfer Request
REPC_IN002110UV
Care Transfer Request
REPC_IN002120UV
Care Transfer Promise
REPC_IN003130UV
Abort Care Transfer Request Notification
REPC_IN002620UV
Reject Care Transfer
REPC_IN002040UV
Referral for Aging Services (REPC_SN004005UV) Preconditie: Peter Process is de maatschappelijk werker bij het Maas Ziekenhuis die verantwoordelijk is voor de coördinatie van het patiëntenontslag van oudere patiënten. Zijn rol is het maximaliseren van de succesvolle terugkeer van zwakke oudere ziekenhuispatiënten naar de gemeenschap, inclusief naar residentiële ouderenzorg. Het werkt nauw samen met de ouderenzorg (thuiszorg en residentieel, zoals verpleeghuizen) in de nabije omgeving. Hij zoekt een verpleeghuisplaats voor de heer Everyman die wat intensieve revalidatie vanwege een val nodig heeft voordat hij weer veilig kan wonen bij zijn dochter die fulltime werkt. Hij raadt ‘Groene Velden Verzorgingstehuizen (GVV) aan als een geschikte instelling voor de heer Everyman en zijn dochter, Nancy Nuclear, die hem autoriseert om GVV namens hem te
51
benaderen, samen met drie andere verpleeghuizen binnen een straal van 5 kilometer van mevrouw Nuclear haar huis. NB. In Nederland zal een dergelijke aanvraag ook leiden tot een verzoek tot indicatie. Activiteiten: stuur verwijzing Peter Process stuurt een verzoek voor een tijdelijke plaats voor Meneer Everyman in een verpleeghuis aan Alice Admitter, waarmee het proces van verwijzing voor ouderenzorg begint [Interactie: Care Transfer Request ]. Wanneer zij de aanvraag verwerkt, merkt Alice Admitter op dat Peter Process niet alle verzekeringsgegevens van Meneer Everyman’s heeft meegestuurd. Ze stuurt het verzoek terug naar Peter Process, waarbij ze aangeeft dat het verzoek niet verwerkt kan worden in zijn huidige vorm [Interactie: Reject Care Transfer ]. bevestiging het op zich nemen van het verwerken van het verzoek Alice Admitter accepteert de verwijzing voor verwerking door het verzoek te identificeren met 'Accepted' (of actief) in de GVV toelatingen database. Dit triggert een automatisch proces verslag over de verwijzing van Peter Process bij Maas Ziekenhuis [Interactie: Notify Care Transfer Request ]. Ze stuurt het verzoek dan door naar Nancy Nightingale om het te beoordelen [Interactie: Care Transfer Request ]. query verwijzing informatie Nancy Nightingale stuurt een verzoek voor verdere klinische informatie over de cognitieve functionele capaciteiten van Meneer Everyman aan Peter Process bij Maas Ziekenhuis die in dit geval niet de volledige bevindingen van de cognitieve test heeft bijgesloten. [Interactie: Care Provision Event, Query.] Omdat hij al toestemming heeft verkregen van de heer Everyman voor het delen van de resultaten van de test met andere zorgverleners, voegt Peter Process de samenvatting van de heer Everyman zijn cognitieve en gedragstesten toe, inclusief de scores van de metingen die in het ziekenhuis gedaan zijn van zijn cognitieve, gedrag en stemming status. Hij stuurt dit naar Nancy Nightingale. [Interactie: Care Provision Event Query, Response]. (Merk op dat deze query interactie buiten de scope van het huidige storyboard valt). Advies plaats beschikbaar Concluderend uit haar beoordeling van de heer Everyman zijn revalidatie- en zorgbehoeften is Nancy Nightingale blij een vrij bed in GVV aan te kunnen bieden aan de heer Everyman. Ze adviseert Alice Admitter over deze beslissing. [Interactie: Care Transfer Promise ] Alice Admitter belooft het bed onmiddellijk aan Peter Process voor de heer Everyman. [Interactie: Care Transfer Promise ] Door deze actie wordt tegelijkertijd het ‘Actieve Verwijzingen’ bestand van GVV aangepast dat onderhouden wordt door Alice Admitter. Hiermee is het proces voor het verzoek voor services voltooid. De naam van de heer Everyman wordt niet verwijderd van het ‘Actieve Verwijzingen’ bestand totdat het bericht is ontvangen dat alle contractuele documentatie in orde is, dat de indicatie akkoord is en dat hij daadwerkelijk opgenomen is in GVV. alternatieve stromen 2. Volgend op de belofte van GVV om services te leveren, ontvangt Peter Process een telefoontje van de dochter van de heer Everyman om aan te geven dat zij 2 maanden verlof opneemt, zodat haar vader ontslagen kan worden naar huis om met haar te wonen. Aan het eind van het verlof (wanneer zij weer gaat weken) zal zij bekijken of haar vader nog steeds formele ouderenzorg dient te ontvangen. Peter Process brengt Alice Admitter en Nancy
52
Nightingale meteen op de hoogte van het feit dat het verzoek voor services voor de heer Everyman wordt ingetrokken. [Interactie: Abort Care Transfer Request ]. Postconditie: Peter Process ontslaat de heer Everyman naar huis. 3. Na de gedetailleerde cognitieve en gedrag meetschalen van de heer Everyman bekeken te hebben, bepaalt Nancy Nightingale dat het bed dat zij op dit moment beschikbaar heeft (alleen voor korte termijnopnames) niet aan de voor de heer Everyman gestelde doelen kan voldoen. Zij stelt Alice Admitter op de hoogte die op haar beurt Peter Process, de heer Everyman en zijn dochter informeert over de beslissing het verzoek voor een bed af te wijzen. [Interactie: Reject Care Transfer ]. Postconditie: Peter Process neemt contact op met de andere verpleeghuizen in de buurt met de hoop een geschikte plaats voor de heer Everyman te vinden. 4. Alice Admitter geeft aan mevrouw Nuclear aan dat GVV in staat zal zijn het volgende permanente bed aan haar vader aan te bieden wanneer het beschikbaar komt, maar ze is niet in staat precies te zeggen wanneer dat zal zijn. Mevrouw Nuclear is opgetogen en bereid te wachten op een plaats in Avondrood, omdat dat haar vaders eerste keus is voor een verpleeghuis. Alice Admitter voegt de naam van de heer Everyman toe aan de wachtlijst voor permanente plaatsing. Zij stelt Peter Process hiervan op de hoogte, omdat de heer Everyman nog ontslagen moet worden uit het ziekenhuis. [Interactie: Care Transfer Promise ]. Postconditie: Peter Process vertraagt het ontslag van de heer Everyman totdat er een bed voor hem vrijkomt in Avondrood. Update Samenvatting Eisen: De communicatiepartners van deze berichten, Peter Process (namens Meneer Everyman), Alice Admitter en Nancy Nightingale zijn gericht op het verzoek voor verwijzing ontworpen om zo soepel en snel als mogelijk een plaatsing voor ouderenzorg te lokaliseren, terwijl te verzekeren dat de plaatsing geschikt is. Aged Care (Lite) Transfer (REPC_ST004006UV) Doel Het doel van dit storyboard is het illustreren van de communicatiestroom tussen een persoon die toegang vraagt tot services voor ouderenzorg en een residentiele of gemeentelijke organisatie die services voor ouderenzorg levert. Interactie Lijst Care Transfer Request
REPC_IN002120UV
Care Transfer Promise
REPC_IN003130UV
Abort Care Transfer Request Notification
REPC_IN002620UV
Aged Care (Lite) Transfer (REPC_SN004006UV) Preconditie: Peter Process, Ontslag Planner bij het Maas Ziekenhuis zoekt een plaats in een verzorgingshuis voor Meneer Adam Everyman, een 88 jaar oude patient, vlakbij waar zijn zoon woont. Hij stuurt een verzoek voor overplaatsing van Meneer Everyman naar 5
53
verzorginghuizen, inclusief ‘Groene Velden Verzorgingstehuizen’ (GVV), waar Alice Admitter beslist over de toelating. Activiteiten: service Provision Transfer (Referral for service) Handelt op basis van de autorisatie van Meneer Everyman, stuurt Peter Process een verzoek voor services door, inclusief een kopie van de geschiktheidtest, naar vijf verzorgingshuizen in de nabijheid van waar zijn zoon woont. [Interactie: Care Transfer Request ]. Hij ontvangt automatische berichtgeving van vier van deze verzorgingshuizen dat zijn verzoek is ontvangen. Drie weken later ontvangt Peter Process het advies van Alice Admitter dat Meneer Everyman een plaats aangeboden is in het GVV en dat hij de volgende dag opgenomen kan worden. [Interactie: Care Transfer Promise ]. service Provision Transfer Withdrawal Na het veilig stellen van een plaats voor Meneer Everyman in GVV brengt Peter Process meteen de andere drie verzorgingshuizen op de hoogte van het intrekken van zijn Request for Service (verzoek voor service) voor Meneer Everyman. [Interactie: Abort Care Transfer Request ]. Postconditie: Peter Process treft maatregelen voor het ontslag van Meneer Everyman en zijn overdracht naar GVV, terwijl hij de verzoeken van andere verzorgingshuizen heeft ingetrokken. Update Samenvatting Eisen: Nu hij succesvol een plaats voor Meneer Everyman heeft gevonden, kan Peter Process zijn gaan richten op de plaatsing van andere oudere patienten. Zijn informatiesysteem geeft hem informatie (via een audit trail) over hoe lang het duurt voordat verzorgingshuizen reageren op verzoeken voor service. Hij gebruikt deze informatie om zijn volgende verzoek te kiezen. N.B.Deze beschrijving is erg op de internationale situatie gericht. In Nederland loopt een deel van deze berichten via een indicatiesteller. Bovendien zullen transferpunten in ziekenhuizen hier een rol in spelen. Peter Process zou in Nederland waarschijnlijk transferverpleegkundige heten.
54
Request Medication Chart Review (REPC_ST004004UV) Doel: Dit storyboard demonstreert een verzoek van een verpleegkundige van een huisartsom een medicatietabel van een bewoner te bekijken.. Interactie Lijst Care Transfer Request
REPC_IN002120UV
Care Transfer Promise
REPC_IN003130UV
Reject Care Transfer
REPC_IN002040UV
Care Transfer Request Medication Chart (REPC_SN004004UV) Precondition: Nancy Nightingale, verpleegkundige bij ‘Groene Velden Verzorgingstehuizen’ (GVV), maakt zich zorgen over het feit dat de pijnmanagement van Meneer Everyman niet langer effectief is. Ze denkt dat een beoordeling van al zijn medicatie op zijn plaats is. Ze bespreekt haat zorgen met de Palliatieve Zorg Klinische Consultant die er mee instemt dat een beoordeling van de huidige medicatie van Meneer Everyman een goed idee is. Activiteiten: Nancy Nightingale stuurt een verzoek naar Dr. Patricia Primary waarin ze uitleg geeft over de noodzaak voor een beoordeling van de medicatielijst van Meneer Everyman. Ze levert een kopie van de bevindingen van de pijngrafiek van de afgelopen 24 uur welke aangeeft
55
dat Meneer Everyman te vaak een Request ].
doorbraak van pijn ervaart. [Interactie: Care Transfer
Dr. Primary licht Nancy Nightingale in dat zij Meneer Everyman later op de dag zal bezoeken. [Interaction: Care Transfer Promise ]. Dr. Primary bezoekt Meneer Everyman later die dag en neemt met Nancy Nightingale alle medicatie van Meneer Everyman door. Zij levert een aangepaste medicatielijst voor Meneer Everyman [Interactie: Medication Administration Order Activate, Fulfillment Request]. Wanneer Nancy Nightingale de nieuwe medicatielijst upload in het elektronische medicatiesysteem wordt automatisch een bericht gestuurd naar het apotheeksysteem om de veranderende bestelling van Meneer Everyman door te geven. [Interactie: Combined Order Activate, Fulfillment Request]. (N.B Medicatie bestelberichten vallen buiten de scope van dit storyboard en domein.). Alternatieve kijk: Dr. Primary ontvangt het verzoek van Nancy Nightingale maar vindt dat een beoordeling niet nodig is op dit moment [Interactie: Reject Care Transfer ]. Postconditie: Meneer Everyman gaat diezelfde avond verder op een nieuw medicatieschema. Nancy Nightingale continueert de tabel voor pijnmanagement en voor de komende 12 uur rapporteert Meneer Everyman geen pijndoorbraak zonder verlies van concentratie. Update Samenvatting Eisen: De communicatiepartners van dit bericht, verpleegkundige , Nancy Nightingale en Dr. Primary, zijn gericht op het verzoeken en complementeren van een beoordeling van de medicatielijst van Meneer Everyman. De uitkomst van de beoordeling, namelijk dat de nieuwe leveringen direct aan het verzorgingshuis geleverd kunnen worden, wordt gecommuniceerd naar de apotheek. Request for Pastoral Care (REPC_ST004007UV) Doel Dit storyboard illustreert de communicatiestroom die geassocieerd wordt met het leveren van pastorale zorg waarbij betaalde en onbetaalde zorgverleners betrokken zijn. Interactie Lijst Care Transfer Request
REPC_IN002120UV
Care Transfer Promise
REPC_IN003130UV
Activate Care Provision
REPC_IN004110UV
Append Care Provision
REPC_IN004211UV
Suspend Care Provision
REPC_IN004310UV
Pastoral Care (REPC_SN004007UV) Preconditie: Mevrouw Eve Everywoman is een bewoonster van de ‘Groene Velden Verzorgingstehuizen’ (GVV) die palliatieve zorg ontvangt. Ze heeft inzicht in haar achteruitgaande toestand wat haar spanning en angst oplevert. Haar man, Neville Nuclear, voelt dat ze in de relatie met haar oudste dochter een aantal zaken niet opgelost heeft. Ze is van haar vervreemd in de laatste vijf jaar, waarmee ze iets moet doen. Meneer Nuclear voelt dat deze angst de pijnmedicatie die ze neemt tegenwerkt. Hij is zich er van bewust dan GVV een uitstekende pastorale zorg heeft, welke drijft op getrainde vrijwilligers van lokale organisaties,
56
inclusief de lokale katholieke kerk. Hij bespreekt met zijn vrouw het idee om contact op te nemen met iemand om met haar te praten over hun dochter. Activiteiten: verzoek ondersteuning spirituele behoeften Larry Listener, Directeur van Pastorale Zorg, ontvangt een telefoontje van de man van mevrouw Everywoman waarin hij pastorale zorg voor zijn vrouw vraagt. Omdat GVV deel uitmaakt van de regio die geleid wordt door Pastorale Zorg Coördinator Helen Helper, stuurt Larry Listener een berichtje om Helen te vragen patorale zorg te regelen voor mevrouw Everywoman [Interactie: Care Transfer Request ]. Helen Helper bevestigt bij Larry Listener dat ze het verzoek ontvangen heeft en dat zij een afspraak heeft gemaakt om mevrouw Everywoman de volgende dag te bezoeken [Interaction: Care Transfer Promise ]. wijs pastorale zorg ondersteuningswerker toe Volgend op haar bezoek en beoordeling van mevrouw Everywoman, stelt Helen Helper een zorgplan op voor mevrouw Everywoman, gebaseerd op hun gesprek.. Ze raadpleegt haar lijst van vrijwilligers om te kijken wie de capaciteit heeft om de zorg voor mevrouw Everywoman op zich te nemen. Omdat ze alleen maandelijks haar vrijwilligers ontmoet, stuurt Helen Helper een verzoek naar Valerie Volunteer, die zowel katholiek is en wiens aantal te behandelen cliënten recent verminderd is. Ze vraagt Valerie of zij beschikbaar is om een nieuwe cliënt op zich te nemen, waarbij ze de details over de locatie van mevrouw Everywoman en de contactgegevens van de Residentiele Zorg Coördinator levert [Interactie: Care Transfer Request ]. Valerie Volunteer bekijkt het verzoek via haar mobiele telefoon. Ze licht Helen Helper in dat zij in staat is mevrouw Everywoman erbij te nemen, als mevrouw Everywoman dit accepteert [Interactie: Care Transfer Promise ]. Helen Helper deelt Larry Listener mee dat Valerie Volunteer toegewezen is aan mevrouw Everywoman en dat er een zorgplan is waarmee mevrouw Everywoman heeft ingestemd. Een kopie van dit bericht wordt naar Nancy Nightingale, de Residentiele Zorg Coördinator, gestuurd, zodat zij de contactgegevens van Valerie Volunteer en een kopie van het pastorale zorgplan kan plaatsen in het verpleegkundig documentatiesysteem [Interactie: Care Transfer Promise ]. voortdurende pastorale zorgverlening Valerie Volunteer start met het bezoeken van mevrouw Everywoman. Met referentie naar het pastorale zorgplan documenteert zijn elk bezoek, waarbij ze de duur van haar bezoek vastlegt (gedetailleerde aantekeningen van hun discussie worden niet vastgelegd). Het zorg documentatie systeem stuurt automatisch een samenvatting van Valerie Volunteer’s initiële bezoek naar Helen Helper. [Interactie: Activate Care Provision]. Hierdoor kan Helen Helper de kwaliteit en niveau van activiteiten van haar team van pastorale zorg vrijwilligers monitoren, aanvullend op het leveren van een audit trail hiervan en daarop volgende pastorale zorgactiviteiten [Interactie: Append Care Provision]. suspension of pastoral care services Na zes bezoeken heeft mevrouw Everywoman het bijgelegd met haar dochter. Mevrouw Everywoman vraagt een tijdelijk uitstel (suspension) van bezoeken terwijl zij geniet van de tijd met haar dochter. Valerie Volunteer documenteert deze uitkomst in het dossier van mevrouw Everywoman en stuurt een samenvatting van het laatste bezoek naar Helen Helper die een
57
uitstel van pastorale zorgservices vastlegt. [Interactie: Suspend Care Provision]. Vervolgens stuurt zij een kopie van dit bericht naar de Directeur van Pastorale Zorg, Larry Listener [Interaction: Suspend Care Provision]. Postconditie: Documentatie van het effect van de pastorale zorg die geleverd is aan mevrouw Everywoman door Valerie Volunteer verschijnt in de verpleegkundige documentatie. Daarbij is Helen Helper in staat geweest om zicht te houden op de frequentie en duur van de bezoeken van Valerie Volunteer. Zou mevrouw Everywoman verdere pastorale zorgservices aanvragen dan zullen de relevante details van deze recente service beschikbaar zijn voor het staflid die het opvraagt. Update Samenvatting Eisen: De communicatiepartners van dit bericht, de Directeur van Pastorale Zorg, een Regionale Pastorale Zorg Coördinator en de zorgverlener die de daadwerkelijke pastorale zorg levert, zijn gericht op het antwoorden op verzoeken voor de verlening van pastorale zorg en op het monitoren van aan wie en waar pastorale zorgservices geleverd worden. Surgical Referral (REPC_ST004002UV) Doel Het doel van dit storyboard is het illustreren van de verwijzing voor een operatie door een huisarts naar een chirurg en de ‘second opinion’ aangevraagd door een chirurg die geassocieerd is met ziekenhuis opname en behandeling. Interactie Lijst Care Transfer Request
REPC_IN002120UV
Care Transfer Promise
REPC_IN003130UV
Surgical Referral (REPC_SN004002UV) Preconditie: Meneer Adam Everyman is eenpatient bij het Maas Ziekenhuis. Zijn arts, Dr. Aaron Attend, verwijst hem voor een thorax) operatie naar Dr. Cutter die er mee instemt de operatie op neneer Everyman uit te voeren. Hij voegt hem toe aan zijn operatielijst bij het Maas Ziekenhuis op 27 juni. Volgend op de thoraxoperatie om longkanker vast te stellen of uit te sluiten, is Dr. Cutter van mening dat de operatieresultaten aangeven dat Meneer Everyman longkanker heeft. Hij verwijst meneer Everyman voor een ‘second opinion’ naar Dr. Dunst, een longarts, alvorens hij verder gaat met de zorgverlening in de Gamma Kanker Kliniek. Dr. Cutter verwijst meneer Everyman ook naar het Stop Nu met Roken educatieprogramma. Activiteiten: Dr. Attend verwijst meneer Everyman naar Dr. Cutter met een verzoek voor thorax operatie in verband met longkanker. Hij voegt een gezondheidssamenvatting toe als onderdeel van zijn verzoek. [Interactie: Care Transfer Request ]. Dr Cutter bevestigt dit verzoek en bevestigt dat hij meneer Everyman heeft toegevoegd aan zijn operatielijst van 27 juni [Interactie: Care Transfer Promise]. Postconditie: Na zorgen over zijn patient heeft Dr. Attend Meneer Everyman met success doorverwezen naar Dr. Cutter.
58
Update Samenvatting Eisen: De actoren van deze communicatie zijn, Dr. Attend, Cutter, Dunst en de Stop Nu met Roken Kliniek. De focus in de communicatie betreft Dr. Attend's gezondheidssamenvatting en het verwijsverzoek naar Dr. Cutter, Dr. Cutter’s verwijsverzoek en de samenvatting van de operatie die gestuurd is naar Dr. Dunst en de Stop Nu met Roken Kliniek.
4.5
Applicatie Rollen
Hier volgen de applicatie rollen die nodig zijn om de diverse systemen met verwijsberichten en acceptatie te laten omgaan. Application Roles (Sorted by Artifact Code) Care Transfer Tracker (REPC_AR002020UV) Care Transfer Placer (REPC_AR002030UV) Care Transfer Fulfiller (REPC_AR002040UV) Referentie Voor details over de interpretatie van deze sectie, zie de discussie over applicatie rollen en hun relaties in de Versie 3 Guide. Care Transfer Placer (REPC_AR002030UV) Beschrijving Structured Name: Care Transfer Request Placer De applicatie rol bevat de gedragingen die nodig zijn voor het creëren, communiceren en het op de juiste wijze beheren van een verzoek voor een zorgoverdracht. Dit omvat de mogelijkheid om een verwijzing uit te voeren als een bericht (notification of fulfillment request) en om de acceptatie (acceptance)of afwijzing (reject) van het verzoekbij te houden.
Care Transfer Fulfiller (REPC_AR002040UV) Beschrijving Structured Name: Care Transfer Request Fulfiller De applicatie rol bevat de gedragingen die nodig zijn voor het ontvangen, communiceren van verdere transacties en het op de juiste wijze beheren van een verzoek voor een zorgoverdracht. Dit omvat de mogelijkheid om een verzoek voor een zorgoverdracht te accepteren en om een afwijzend antwoord te geven als dat gepast is.
Care Transfer Tracker (REPC_AR002020UV) Beschrijving Structured Name: Care Transfer Request Tracker Een applicatie die in staat is een bericht te ontvangen van een ander system over een verzoek voor een zorgoverdracht.
59
4.6
Trigger Events
Dit zijn de gebeurtenissen in de applicatie, aangestuurd door de gebruiker, die leiden tot de verwijzing en reacties.
Trigger Events (georteerd volgens titel) Care Transfer Promise(REPC_TE003130UV) Care Transfer Request(REPC_TE002100UV) Notify Abort Care Transfer Request(REPC_TE002600UV) Notify Care Transfer Promise(REPC_TE003030UV) Notify Revise Care Transfer Request(REPC_TE002200UV) Reject Care Transfer(REPC_TE002040UV) Replace Care Transfer Promise(REPC_TE003933UV) Referentie Voor details over de interpretatie van deze sectie, zie de discussie over trigger events in de Versie 3 Guide. Care Transfer Request (REPC_TE002100UV) Beschrijving Structured Name: Care Transfer Request Activate Type: State-transition based State Transition: PatientCareProvisionRequest (REPC_RM002000UV) Geeft aan dat de activatie van een verzoek voor zorgoverdracht plaats heeft gevonden en de ontvangende applicatie kan gevraagd worden het verzoek uit te voeren. V2 Reference: Dit is gelijk aan de REF^I12 event in 2.x. Notify Revise Care Transfer Request (REPC_TE002200UV) Beschrijving Structured Name: Care Transfer Request Revise Type: State-transition based State Transition: PatientCareProvisionRequest (REPC_RM002000UV) Geeft aan dat het eerder aangekondigde verzoek voor een zorgverlening gewijzigd is. V2 Reference: Dit is gelijk aan de REF^I13 event in 2.x. Notify Abort Care Transfer Request (REPC_TE002600UV) Beschrijving Structured Name: Care Transfer Request Abort Type: State-transition based Geeft aan dat een verzoek voor overdracht van verantwoordelijkheid voor de zorgverlening is ingetrokken.
60
V2 Reference: Dit is gelijk aan de REF^I14 event in 2.x. Reject Care Transfer (REPC_TE002040UV) Beschrijving Structured Name: Care Transfer Request Rejection Type: Interaction based Geeft aan dat het uitbrengen van een verzoek voor een zorgverlening ontvangen is maar dat het verzoek afgewezen is. V2 V2 Reference: Dit is gelijk aan de REF^I13 event in 2.x met Referral status (RF1-1) op Rejected (R) gezet. Care Transfer Promise (REPC_TE003130UV) Beschrijving Structured Name: Care Transfer Promise Activate Confirmation Type: Interaction based State Transition: PatientCareProvisionPromise (REPC_RM003000UV) Geeft aan dat het uitbrengen van een belofte voor een zorgverlening bevestigd is als een bevestigend antwoord (response) op een verzoek en dat de ontvanger wacht op het overnemen van de verantwoordelijkheid.. V2 Reference: Dit is gelijk aan de REF^I13 event in 2.x met Referral status (RF1-1) op Accepted (A) gezet. Replace Care Transfer Promise (REPC_TE003933UV) Beschrijving Structured Name: Care Transfer Promise Obsolete Confirmation Replace Type: Interaction based State Transition: PatientCareProvisionPromise (REPC_RM003000UV) Geeft aan dat een eerder geaccepteerde zorgoverdracht verouderd is en dat die vervangen is door een latere geaccepteerde zorgoverdracht. Dit kan het gevolg zijn van een verandering in het geassocieerde verzoek voor een zorgoverdracht. V2 Reference: Er is geen equivalent event in 2.x. Notify Care Transfer Promise (REPC_TE003030UV) Beschrijving Structured Name: Care Transfer Promise Notification Type: State-transition based Geeft aan dat een status verandering van belofte voor zorgoverdracht plaats heeft gevonden welke aangekondigd moet worden. V2 Reference: Er is geen equivalent event in 2.x
61
4.7
Refined Message Information Modellen
Hier volgen de gestructureerde berichten voor verwijzing en acceptatie.
Refined Message Information Modellen (georteerd volgens titel) Care Transfer Promise(REPC_RM003000UV) Care Transfer Request(REPC_RM002000UV) Referentie Voor details over de interpretatie van deze sectie, zie de Beschrijving van RMIMs in de Versie 3 Guide.
4.8
Care Transfer Request (REPC_RM002000UV)
Diagram
Beschrijving Parent:
Care Provision (REPC_DM000000UV)
Care Transfer Request (verzoek tot zorgoverdracht) RMIM Overzicht Dit model legt de data en associaties vast die nodig zijn wanneer een zorgoverdracht wordt aangevraagd. Dit model en zijn begeleidende diagram is nagenoeg gelijk aan het Care Provision DMIM maar gebruikt "local CMETs" om te de complexiteit van de zorgstructuren, geassocieerd met de Care Provision Request Act, samen te vatten. De lezer wordt verwezen naar de DMIM discussie alvorens te kijken naar de RMIM gevolgd door de discussie voor elke zorgstructuur.
62
De discussie over dit model accepteert kenmerken die niet expliciet bestaan in de DMIM en die niet direct besproken werden in het overzicht van dat model. Care Provision Request Focal Class (verzoek tot zorgverlening Focale Klasse) Zoals aangegeven in de discussie van de DMIM, is een Care Provision Request (verzoek voor een zorgoverdracht) een verzoek tot overdracht van de verantwoordelijkheid van zorgverlening of, simpeler, een verzoek voor een zorgoverdracht. Kenmerkend is dat het verzoek wordt gedaan door een zorgverlener binnen een applicatie en wordt doorgegeven aan de uitvoerende partij via een berichten-interface. Alle deelnemers die men tegenkomt in dit model zijn al beschreven in de discussie van het DMIM in hoofdstuk 2. Associaties De volgende associaties worden gedefinieerd in een Care Provision Request (verzoek voor een zorgoverdracht). Elke associatie legt de relatie tussen het Care Provision Request en een entiteit of act vast die een belangrijke rol spelt in de zorgoverdracht (Care Transfer). Participaties recordTarget: de record target is de entiteit waarvoor het Care Transfer Request wordt vastgelegd. Er kan maar één record target zijn voor een Care Transfer Request. De entiteit informatie van de target wordt binnen de R_Patient CMET of de R_CaredEntity lokale CMET vastgelegd. Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs. subject: het subject of de subjects die het doel is/zijn van de zorgoverdracht die aangevraagd wordt wanneer het subject niet de ‘record target’ is. De subject informatie wordt vastgelegd binnen de R_Patient CMET of de R_CaredEntity lokale CMET. Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs. author: de partij die het Care Transfer Request doet. Dit kan een aangewezen persoon of een organisatie zijn (R_AssignedParty), zoals een zorgverlener, een gerelateerde partij (R_RelatedParty), zoals een familielid of rechtbank, b.v. in de psychiatrie, of de patiënt zelf (R_Patient). Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs. dataEnterer: de persoon die de informatie in het systeem invoert, zoals een medisch secretaresse. De informatie van de invoerder van de data wordt vastgelegd met de R_AssignedPerson CMET. verifier: de supervisor die het verzoek controleert. Er is ondersteuning voor meer dan één niveau van verificatie. De verifiërende persoonsinformatie wordt vastgelegd binnen de R_AssignedPerson CMET. performer: de partij die deelneemt in het daadwerkelijk uitvoeren van de aangevraagde zorgoverdracht. Er kunnen meerdere uitvoerders zijn omdat verscheidene partijen kunnen samenwerken in de aangevraagde zorgverlening. Dit kan een aangewezen persoon of organisatie zijn (R_AssignedParty), zoals een zorgverlener, een gerelateerde partij (R_RelatedParty), zoals
63
een familielid of de patiënt zelf (R_Patient). Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs. primaryInformationRecipient: de partij die bestemd is de aangevraagde zorgoverdracht te ontvangen. Deze ontvanger is niet de aangevraagde uitvoerder van de zorgverlening maar ontvangt het verzoek voor hun informatie. Dit kan een aangewezen persoon of organisatie zijn (R_AssignedParty), zoals een zorgverlener, een gerelateerde partij (R_RelatedParty), zoals een familielid of rechtbank, of de patiënt zelf (R_Patient). Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs. Act Relaties component1: verbindt het Care Provision Request aan het zorgplan dat is aangevraagd om uitgevoerd te worden gedurende de geplande zorgverlening. Voor verdere beschrijving van deze locale CMET wordt men verwezen naar de A_CarePlan in het Care Structures topic. pertinentInformation1: levert pertinente zorgplannen aan de zorgoverdracht, wat aangeeft dat deze de andere acts zijn die gerelateerd zijn, maar niet direct aangevraagd zijn als onderdeel van de zorgoverdracht. Voor verdere beschrijving van deze locale CMET wordt men verwezen naar de A_CarePlan in het Care Structures topic. pertinentInformation3: een set van pertinente clinical statements geleverd als informatie om de zorgoverdracht te ondersteunen. Voor verdere beschrijving van deze locale CMET wordt men verwezen naar de A_CareStatement in het Care Structures topic. reason: relatie naar een concern die is vastgelegd als de primaire reden voor de zorgoverdracht. Een probleem, niet specifiek een diagnose, dat de primaire reden is voor de zorgoverdracht kan ook gepresenteerd worden door deze relatie te gebruiken. Voor verdere beschrijving van deze locale CMET wordt men verwezen naar de A_ConcernTrackingEvent in het Care Structures topic. component2: een collectie van clinical statements kan geassocieerd worden als deel van het Care Provision Request. Dit is bedoeld om aan te geven dat bijvoorbeeld deze lijst van concerns beheerd worden als deel van de aangevraagde zorgoverdracht. Voor verdere beschrijving van deze locale CMET wordt men verwezen naar de A_StatementCollector in het Care Structures topic. pertinentInformation2: Een verzoek voor zorgoverdracht kan relevante informatie hebben in de vorm van bestaande zorgdossiers (Care Records), die bijgesloten kunnen worden bij het verzoek tot zorgoverdracht (Care Provision Request). Voor verdere beschrijving van deze lokale CMET wordt men verwezen het Care Record topic. reference: De encounter waarin de zorgoverdracht werd aangevraagd, gerepresenteerd door de A_Encounter CMET. replacementOf: een verbinding naar een vervangen verzoek voor zorgoverdracht (verwijzing). Het verzoek voor zorgoverdracht als zijnde het doel van de act relatie heeft een status van verouderd (obsolete) en kan of enkel de instance identifier bevatten van het vervangen verzoek
64
of de volledige details van het verzoek. MERK OP: Deze relatie zou niet gebruikt moeten worden als de Obsolete/Replace Interactie niet wordt ondersteund op dat moment.
Contained Hierarchical Message Descriptions Care Transfer Request 4.9
REPC_HD002000UV
Care Transfer Promise (REPC_RM003000UV)
Diagram
Klik op bovenstaande figuur om een grotere tekening te openen in een nieuw scherm Beschrijving Parent:
Care Provision (REPC_DM000000UV)
Care Transfer Promise (Acceptatie zorgoverdracht) RMIM Overzicht Dit model legt de data en associaties vast die nodig zijn wanneer een zorgoverdracht (Care Transfer) beloofd of geaccepteerd wordt. CareProvisionPromise Focal Class (Acceptatie Zorgverlening Focale Klasse) Een acceptatie van zorgverlening (Care Provision Promise) is een aankondiging van het nemen van de verantwoordelijkheid van zorgverlening zoals medegedeeld in het voltooide verzoek. Kenmerkend is dat de aangewezen persoon die verantwoordelijk wordt voor het uitvoeren van de zorgverlening, de auteur is van de belofte van zorgoverdracht (Care Transfer Promise). Het
65
wordt aangenomen dat het verzoek wordt vastgelegd binnen een applicatie en wordt doorgestuurd naar de uitvoerende partij via een berichten-interface; in welk geval de acceptatie van het verzoek wordt gestuurd. Alleen de minimale informatie die nodig is voor de acceptatie van het verzoek wordt in het huidige model geleverd, omdat men van mening van dat het overbodig was de details van het verzoek te herhalen in het geval waar verzoeken niet elektronisch ontvangen werden. N.B. er wordt nog over nagedacht om toch een detail te kunnen toevoegen, zoals een encounter klasse waarin een geplande afspraak is opgenomen. Associaties De volgende associaties worden gedefinieerd voor een acceptatie van een zorgoverdracht (Care Transfer Promise). ). Elke associatie legt de relatie tussen de Care Transfer Promise en een entiteit of act vast die een belangrijke rol spelt in de acceptatie van een zorgoverdracht (Care Transfer Promise). Participaties recordTarget: de record target is de entiteit waarvoor het Care Transfer Promise wordt vastgelegd. Er kan maar één record target zijn voor een Care Transfer Promise. De target entiteitinformatie wordt binnen de R_Patient CMET of de R_CaredEntity lokale CMET vastgelegd. Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs. subject: het subject is het doel waarvoor de Care Provision Promise wordt gemaakt wanneer het subject niet de ‘record target’ is. De subject informatie wordt vastgelegd binnen de R_Patient CMET of de R_CaredEntity lokale CMET. Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs. author: de leverancier die de Care Transfer Promise maakt om de verantwoordelijkheid van levering van zorg op zich te nemen, die analoog is aan een "fulfiller". Dit kan een aangewezen persoon of een organisatie zijn (R_AssignedParty), zoals een zorgverlener, een gerelateerde partij (R_RelatedParty), zoals een familielid, of de patiënt zelf (R_Patient). Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs. dataEnterer: de persoon die de informatie van de Care Transfer Promise invoert. De informatie van de invoerder van de data wordt vastgelegd binnen de R_AssignedPerson CMET. verifier: de supervisor die de belofte controleert. Er is ondersteuning voor meer dan één niveau van verificatie. De informatie over de verifiërende partij wordt vastgelegd binnen de R_AssignedPerson CMET. performer: de leverancier die belooft de zorgverlening uit te voeren. Er kunnen meerdere uitvoerders zijn omdat verscheidene partijen kunnen samenwerken in de verantwoordelijkheid voor zorgverlening. Dit kan een aangewezen persoon of organisatie zijn (R_AssignedParty), zoals een zorgverlener, een gerelateerde partij (R_RelatedParty), zoals een familielid of de patiënt zelf (R_Patient). Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs.
66
primaryInformationRecipient: de leverancier die bestemd is de acceptatie voor de zorgoverdracht te ontvangen. De ontvanger is meetal de auteur van het geassocieerde verzoek tot zorgoverdracht ofwel verwijzing, welke gerepresenteerd kan worden door een aangewezen persoon of organisatie (R_AssignedParty), een gerelateerde partij (R_RelatedParty), zoals een familielid of rechtbank, of de patiënt zelf (R_Patient). Voor verdere beschrijving wordt men verwezen naar de respectievelijke CMETs. Act Relationships InFulfillmentOf: een Care Transfer Promise wordt geassocieerd met het verzoek tot zorgoverdracht of verwijzing dat geaccepteerd wordt, waarmee het verzoek wordt vervult. Alleen het id attribuut wordt geleverd om het verzoek aan de belofte te binden. ReplacementOf: een link naar een vervangen belofte voor zorgverlening (Care Transfer Promise). De belofte voor zorgverlening, zijnde de doel van deze act relatie, heeft een status van verouderd (obsolete) en kan of alleen de unique identifier bevatten van de vervangen belofte of zijn volledige details. Contained Hierarchical Message Descriptionss Care Transfer Promise
REPC_HD003000UV
4.10 Hierarchical Message Descriptions Hier volgen de hierarchische message descriptions Hierarchical Message Descriptions Care Transfer Promise(REPC_HD003000UV) Care Transfer Request(REPC_HD002000UV) Referentie Voor details over de interpretatie van deze sectie, zie de Beschrijving van HMDs in de Versie 3 Guide. Care Transfer Request (REPC_HD002000UV) Beschrijving Berichtentypen die gebaseerd zijn op deze HMD worden gebruikt om de verzoeken voor zorgoverdracht te communiceren.. Common Message Element Types Used A_CarePlanCare provision A_CareRecordUniversal A_CareStatementCare provision A_ConditionTrackingEventCare provision A_EncounterUniversal
REPC_MT000200UV REPC_MT004000UV REPC_MT000100UV REPC_MT000301UV COCT_MT010000UV01
67
A_StatementCollectorCare provision R_AssignedPartyUniversal R_AssignedPersonUniversal R_CaredEntityCare provision R_PatientUniversal R_RelatedPartyUniversal
REPC_MT000400UV COCT_MT090400UV COCT_MT090100UV01 REPC_MT000700UV COCT_MT050000UV01 COCT_MT910000UV
Base Hierarchical Message Description Message Type List Care Transfer Request Abort
REPC_MT002600UV
Care Transfer Request
REPC_MT002000UV
Care Transfer Promise (REPC_HD003000UV) Beschrijving Berichtentypen die gebaseerd zijn op deze HMD worden gebruikt om de beloften voor zorgoverdracht te communiceren. Common Message Element Types Used R_AssignedPartyUniversal R_AssignedPersonUniversal R_CaredEntityCare provision R_PatientUniversal R_RelatedPartyUniversal
COCT_MT090400UV COCT_MT090100UV01 REPC_MT000700UV COCT_MT050000UV01 COCT_MT910000UV
Base Hierarchical Message Description Message Type List Care Transfer Promise
REPC_MT003000UV
68
4.11 Interacties Hier volgen de interacties tussen de applicaties. Lijst van interacties (gesorteerd volgens titel) Abort Care Transfer Request Notification(REPC_IN002620UV) Care Transfer Promise(REPC_IN003130UV) Care Transfer Request(REPC_IN002120UV) Notify Aborted Care Transfer Request(REPC_IN002610UV) Notify Care Transfer Promise(REPC_IN003010UV) Notify Care Transfer Request(REPC_IN002110UV) Notify Revise Care Transfer Request(REPC_IN002210UV) Reject Care Transfer(REPC_IN002040UV) Replace Care Transfer Promise(REPC_IN003930UV) Revise Care Transfer Request(REPC_IN002220UV) Referentie Voor details over de interpretatie van deze sectie, zie de definitie van Interacties in de Versie 3 Guide. Care Transfer Request (REPC_IN002120UV) Beschrijving Structured Name:
Care Transfer Request Activate Fulfillment Request
De interactie wordt gebruikt om de ontvanger te verzoeken de verantwoordelijkheid voor zorgverlening aan het subject te accepteren. De interactie heeft twee typen van mogelijke ontvanger verantwoordelijkheid. De eerste, belofte voor zorgoverdracht, wordt gebruikt door de ontvangende applicatierol wanneer deze het verzoek accepteert. De tweede ontvanger verantwoordelijkheid is Afwijzen Zorgoverdracht en wordt gebruikt door de voltooier om het verzoek af te wijzen. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Care Transfer Request Send Message Payload Trigger Event Control Act Care Transfer Request
REPC_TE002100UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT002000UV
Receiver Responsibilities (verantwoordelijkheden ontvanger) Reason Trigger Event Interactie De uitvoerder (fulfiller) stemt niet in met het REPC_TE002040UV REPC_IN002040UV uitvoeren van het verzoek De uitvoerder (fulfiller) stemt in met het REPC_TE003130UV REPC_IN003130UV uitvoeren van het verzoek
69
Sending and Receiving Roles (zendende en ontvangende rollen) REPC_AR002030UV REPC_AR002040UV
Sender Care Transfer Placer Receiver Care Transfer Fulfiller
Notify Care Transfer Request (REPC_IN002110UV) Beschrijving Structured Name:
Care Transfer Request Activate
De interactie brengt de ontvanger op de hoogte dat een zender een zorgverlener heeft verzocht om op verantwoordelijkheid voor zorg aan een subject op zich te nemen en dat de verzochte zorgoverdracht geactiveerd is en wacht op voltooiing. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Care Transfer Request Send Message Payload Trigger Event Control Act Care Transfer Request
REPC_TE002100UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT002000UV
Receiver Responsibilities (verantwoordelijkheden ontvanger) Reason Trigger Event De uitvoerder (fulfiller) stemt niet in met het REPC_TE002040UV uitvoeren van het verzoek De uitvoerder (fulfiller) stemt in met het REPC_TE003130UV uitvoeren van het verzoek De uitvoerder (fulfiller) is begonnen met de REPC_TE004110UV verantwoordelijkheid voor zorgverlening ter voltooiing van het verzoek. De uitvoerder gebruikt dit wanneer he teen verzoek wil accepteren waarbij de zorgoverdracht wordt verzocht.
Interaction REPC_IN002040UV REPC_IN003130UV REPC_IN004110UV
Sending and Receiving Roles (zendende en ontvangende rollen) Sender Receiver
Care Provision Informer Care Transfer Tracker
REPC_AR004010UV REPC_AR002020UV
Revise Care Transfer Request (REPC_IN002220UV) Beschrijving Structured Name:
Care Transfer Request Revise Fulfillment Request
70
De interactie wordt gebruikt om de ontvanger te verzoeken een wijziging van een eerder geaccepteerde verantwoordelijkheid van zorg voor een subject te accepteren. De interactie heeft twee mogelijke ontvanger verantwoordelijkheid typen. De eerste, belofte voor zorgoverdracht, wordt gebruikt door de ontvangende applicatierol wanneer deze het gewijzigde verzoek accepteert. De tweede ontvanger verantwoordelijkheid is Afwijzen Zorgoverdracht en wordt gebruikt door de voltooier (fulfiller) om het gewijzigde verzoek af te wijzen. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Notify Revise Care Transfer Request Send Message Payload Trigger Event Control Act Care Transfer Request
REPC_TE002200UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT002000UV
Receiver Responsibilities (verantwoordelijkheden ontvanger) Reason Trigger Event De uitvoerder (fulfiller) stemt niet in met het REPC_TE002040UV uitvoeren van het gewijzigde verzoek voor zorgoverdracht. De uitvoerder (fulfiller) heeft nog niet beloofd REPC_TE003130UV het verzoek voor zorgoverdracht, dat gewijzigd is, te accepteren, maar accepteert nu het gewijzigde verzoek voor zorgoverdracht. De uitvoerder (fulfiller) stemt in met het REPC_TE003933UV uitvoeren van het vervangen verzoek voor zorgoverdracht.
Interactie REPC_IN002040UV
REPC_IN003130UV
REPC_IN003930UV
Sending and Receiving Roles (zendende en ontvangende rollen) Sender Receiver
Care Transfer Placer Care Transfer Fulfiller
REPC_AR002030UV REPC_AR002040UV
Notify Revise Care Transfer Request (REPC_IN002210UV) Beschrijving Structured Name:
Care Transfer Request Revise
De interactie brengt de ontvanger op de hoogte van het feit dat een verzoek voor zorgverlening gewijzigd is en wacht op voltooiing. Trigger Event Transmission Wrapper Control Act Wrapper
Notify Revise Care Transfer Request REPC_TE002200UV Send Message Payload MCCI_MT000100UV01 Trigger Event Control Act MCAI_MT700201UV01
71
Message Type
Care Transfer Request
REPC_MT002000UV
Sending and Receiving Roles (zendende en ontvangende rollen) Sender Sender
Care Transfer Placer Care Transfer Fulfiller
REPC_AR002030UV REPC_AR002040UV
Abort Care Transfer Request Notification (REPC_IN002620UV) Beschrijving Structured Name:
Care Transfer Request Abort Fulfillment Notification
De interactie wordt gebruikt om de ontvanger in te lichten om een eerder geaccepteerde verantwoordelijkheid voor de zorg van een subject af te breken. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Notify Abort Care Transfer Request Send Message Payload Trigger Event Control Act Abort Care Transfer Request
REPC_TE002600UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT002600UV
Sending and Receiving Roles (zendende en ontvangende rollen) Sender Receiver
Care Transfer Placer Care Transfer Fulfiller
REPC_AR002030UV REPC_AR002040UV
Notify Aborted Care Transfer Request (REPC_IN002610UV) Beschrijving Structured Name:
Care Transfer Request Abort
De interactie ligt de ontvanger in dat verzocht is een eerder geaccepteerde overdracht van zorg in te trekken. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Notify Abort Care Transfer Request Send Message Payload Trigger Event Control Act Abort Care Transfer Request
REPC_TE002600UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT002600UV
Sending and Receiving Roles (zendende en ontvangende rollen) Sender Receiver
Care Transfer Placer Care Transfer Tracker
REPC_AR002030UV REPC_AR002020UV
72
Reject Care Transfer (REPC_IN002040UV) Beschrijving Structured Name:
Care Transfer Request Rejection
De interactie duidt aan dat een verzoek voor zorgverlening afgewezen is na overweging. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Reject Care Transfer Application Level Acknowledgement Trigger Event Control Act Act generic Status - Order
REPC_TE002040UV MCCI_MT000300UV01 MCAI_MT700201UV01 COMT_MT001101UV01
Sending and Receiving Roles (zendende en ontvangende rollen) Sender Receiver
Care Transfer Fulfiller Care Transfer Placer
REPC_AR002040UV REPC_AR002030UV
Care Transfer Promise (REPC_IN003130UV) Beschrijving Structured Name:
Care Transfer Promise Activate Confirmation
De interactie is een antwoord op het verzoek van zorgoverdracht en wordt gebruikt door de ontvangende applicatierol wanneer deze het verzoek en de verantwoordelijkheid van zorgverlening voor het subject accepteert. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Care Transfer Promise Application Level Acknowledgement Trigger Event Control Act Care Transfer Promise
REPC_TE003130UV MCCI_MT000300UV01 MCAI_MT700201UV01 REPC_MT003000UV
Sending and Receiving Roles (zendende en ontvangende rollen) Sender Care Transfer Fulfiller Receiver Care Transfer Placer
REPC_AR002040UV REPC_AR002030UV
Replace Care Transfer Promise (REPC_IN003930UV) Beschrijving Structured Name:
Care Transfer Promise Obsolete Confirmation Replace
73
De interactie wordt gebruikt om een eerder geaccepteerde zorgoverdracht te vervangen. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Replace Care Transfer Promise Accept Acknowledgement Trigger Event Control Act Care Transfer Promise
REPC_TE003933UV MCCI_MT000200UV01 MCAI_MT700201UV01 REPC_MT003000UV
Sending and Receiving Roles (zendende en ontvangende rollen) Sender Receiver
Care Transfer Fulfiller Care Transfer Placer
REPC_AR002040UV REPC_AR002030UV
Notify Care Transfer Promise (REPC_IN003010UV) Beschrijving Structured Name:
Care Transfer Promise Notification
De interactie ligt een ontvanger in dat de zender een nieuw verzoek accepteert voor verantwoordelijkheid voor de zorgverlening voor het subject. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Notify Care Transfer Promise Send Message Payload Trigger Event Control Act Care Transfer Promise
REPC_TE003030UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT003000UV
Sending and Receiving Roles (zendende en ontvangende rollen) Sender Receiver
Care Transfer Fulfiller Care Transfer Tracker
REPC_AR002040UV REPC_AR002020UV
74
5.
CARE RECORD QUERY TOPIC
5.1
Inleiding
Dit hoofdstuk is een vertaling van Hoofdstuk 7 van de Care Provision uit de ballot van januari / mei 2007. Het onderwerp omvat de queries en query responses die zijn gerelateerd aan de zorg die daadwerkelijk is gegeven toen een persoon of andere entiteit onder de verantwoordelijkheid viel van een zorgverlener.
5.2
Storyboards
Storyboards (gesorteerd volgens Titel) Aged Care Assessment Record Query(REPC_ST002201UV) Patient Populates Personal EHR(REPC_ST002202UV)
Voor details over de interpretatie van deze sectie, zie de storyboards discussie in de Versie 3 Guide.
Aged Care Assessment Record Query (REPC_ST002201UV) Doel Dit storyboard demonstreert het opvragen van gegevens uit een staats- of een nationale database overde geschiktheid voor ouderenzorg. Het gaat daarbij omdossiers waarin de beoordeling van geschiktheid van zorg is opgenomen, waarbij kan worden vastgesteld wat de doorloop (vervaldatum), scope (respijtzorg, permanente zorg, high care/low care, gemeenschapszorg, residentiele zorg, etc.) van een bestaand dossier zijn. Ook kan worden vastgesteld welke beoordelaars de geschiktheid van ouderenzorg voor hun rekening hebben genomen en of er een verlopen beoordeling van geschiktheid voor hetzelfde individu bestaat. (N.B. In Nederland lijkt dit voor een belangrijk deel op de indicatie voor AWBZ zorg). Aged Care Assessment Record Query (REPC_SN002201UV) Preconditie: Nancy Nightingale evalueert of zij gemeenschapszorg kan leveren aan de potentiële cliënt mevrouw Eva Everywoman. Echter, het is op basis van het aanvraagformulier (voor haar ingevuld door haar echtgenoot, Boris Betterhalf) niet duidelijk of mevrouw Everywoman beoordeeld is als geschikt voor deze gesubsidieerde service. Omdat zij geautoriseerd is voor toegang tot de nationale ouderenzorg, het uitvoeren van beoordeling van geschiktheid en toestemming heeft van meneer Betterhalf, stuurt Nancy Nightingale een verzoek naar de nationale registratie om te bepalen of er een actueel of vorig beoordeling van geschiktheid voor ouderenzorg bestaat voor mevrouw Everywoman. Activiteiten: Nancy Nightingale logt in op de nationale registratie van beoordelingen op geschiktheid voor ouderenzorg (indicaties). Ze voert de details van mevrouw Everywoman in om op te vragen (door de query) of er een actueel of vorige beoordeling op geschiktheid voor ouderenzorg bestaat voor mevrouw Everywoman. Ze ontvangt een antwoord dat er twee jaar geleden een
75
beoordeling ingevuld is die nu is verlopen en dat dit uitgevoerd werd door een beoordelingsteam in Melbourne, waar mevrouw Everywoman vroeger woonde. Postconditie: Nancy Nightingale geeft aan mevrouw Everywoman door dat ze een nieuwe beoordeling nodig heeft voordat ze haar aanvraag voor gemeenschapszorg kan uitvoeren. Ze adviseert mevrouw Everywoman dat zij voor haar zal regelen dat ze gezien wordt door een beoordelingsteam dat in staat is haar zorgbehoeften in kaart te brengen en de geschiktheid voor door de regering gesubsidieerde zorg opnieuw te beoordelen. Updates Requirement Summary: De communicatiepartners in dit query bericht, Nancy Nightingale en het nationale registratie systeem, garanderen gemakkelijke toegang door zorgverleners tot kopieën van huidige of vroegere beoordelingen van geschiktheid voor ouderenzorg, waarbij vertraging worden voorkomen in het toegang hebben tot diensten als gevolg van verlopen of niet bestaande beoordelingsdossiers. N.B. In Nederland vervult in sommige gevallen het Landelijk Schakelpunt de rol van verwijsindex om de juiste registratie te vinden waar de query naar toe moet, en de rol van controleur op autorisatie en authenticatie en het verzorgen van logging.
76
Patient Populates Personal EHR (REPC_ST002202UV) Doel Het doel van dit storyboard is het illustreren van verzoeken voor onderdelen uit zorgdossiers. Interactie Lijst Get Care Record Profile Query
QUPC_IN043100UV
Get Care Record Response
QUPC_IN040200UV
Activate Care Provision
REPC_IN004110UV
Patient Populates Personal Health Record (REPC_SN002202UV) Preconditie: Meneer Adam Everyman wil een persoonlijk zorgdossier met informatie over zijn conditie inzien bij from Dr. Patricia Primary die het dossier in haar klinische systeem bewaart. Activiteiten: Meneer Adam Everyman doet een verzoek aan Dr. Patricia Primary voor specifieke informatie die gerelateerd is aan de toestand van zijn hart [Interactie: Get Care Record Profile Query]. Dr. Primary antwoordt door het sturen van de antwoorden op de specifieke informatie die is aangevraagd door meneer Everyman die in staat is de informatie op te nemen in zijn persoonlijke zorgdossier [Interactie: Get Care Record Profile Response]. Meneer Everyman upload de informatie over de toestand van zijn hart naar zijn persoonlijk zorgdossier [Interactie: Activate Care Provision]. Alternatieve stroom: Meneer Everyman doet aan Dr Primary het verzoek voor kopieën van bepaalde testresultaten en behandelingen gerelateerd aan zijn toestand van zijn hart [Interactie: Get Care Record Profile Query]. Dr Primary antwoordt door het sturen van de documenten waar om gevraagd is naar meneer Everyman .[Interactie: Get Care Record Profile Response]. Postconditie: Meneer Everyman heeft nu van Dr. Primary alle documenten en informatie ontvangen over de toestand van zijn hart die hij nodig heeft. Updates Requirement Samenvatting: De communicatiepartners in dit storyboard, meneer Everyman en Dr. Primary, concentreren zich op het doen ontstaan van en selecteren van gegevens uit meneer Everyman’s patiëntendossier. Notitie: Dit storyboard wordt ondersteund onder het Care Record Query Topic en het Care Record Document Topic. Het Care Record Summary document is het documenttype dat teruggestuurd zou worden door dr. Primary.
77
5.3
Application Roles
Application Roles (Gesorteerd op Artifact Code) Care Record Query Placer (QUPC_AR004030UV) Care Record Query Fulfiller (QUPC_AR004040UV) Referentie Voor details over de interpretatie van deze sectie, zie de discussie van applicatie rollen en hun relatie in de Versie 3 Guide. Care Record Query Placer (QUPC_AR004030UV) Beschrijving Structured Name: Query Care Record Event Query Placer Een applicatie die in staat is een care record query te sturen naar een ander systeem en een zorgdossier te ontvangen als een antwoord op de query.
Care Record Query Fulfiller (QUPC_AR004040UV) Beschrijving Structured Name: Query Care Record Event Query Fulfiller Een applicatie die in staat is een care record query te ontvangen van een ander systeem en te antwoorden met het gevraagde zorgdossier. 5.4
Trigger Events
Hier volgen de trigger events voor de query. Trigger Events (gesorteerd op Titel) Find Care Record Candidate Query(QUPC_TE041100UV) Find Care Record Candidate Response(QUPC_TE041200UV) Get Care Record Profile Query(QUPC_TE043100UV) Get Care Record Profile Response(QUPC_TE043200UV) Get Care Record Query(QUPC_TE040100UV) Get Care Record Response(QUPC_TE040200UV) Referentie Voor details over de interpretatie van deze sectie, zie de discussie over trigger events in de Versie 3 Guide. Find Care Record Candidate Query (QUPC_TE041100UV) Beschrijving Structured Name: Query Care Record Event Find Candidate Query Type: User request
78
Een request (verzoek) om een kandidaat Care Record te vinden dat overeenkomt met de query criteria. Een lijst van samengevatte Care Records wordt als antwoord verwacht. V2 Referentie: Er is geen equivalent event in 2.x. Find Care Record Candidate Response (QUPC_TE041200UV) Beschrijving Structured Name: Query Care Record Event Find Candidate Query Response Type: Interaction based
De lijst met Care Record samenvattingen die het antwoord zijn op de Care Record Candidate Query. Get Care Record Query (QUPC_TE040100UV) Beschrijving Structured Name: Query Care Record Event Get Query Type: User request Een verzoek voor een specifiek Care Record (zorgdossier) bepaald door zijn unieke identifier. Een Care Record (zorgdossier) dat overeenkomt met de query criteria wordt als antwoord verwacht. Get Care Record Response (QUPC_TE040200UV) Beschrijving Structured Name: Query Care Record Event Get Query Response Type: Interaction based Een antwoord op een query voor een specifiek Care Record bepaald door zijn unieke identifier. Een Care Record (zorgdossier) dat overeenkomt met de query criteria wordt teruggegeven in dit antwoord. Get Care Record Profile Query (QUPC_TE043100UV) Beschrijving Structured Name: Query Care Record Event Profile Query Type: User request Een verzoek (request) een zorgprofiel op te roepen dat is afgeleid van het patiënten dossier dat overeenkomt met de query criteria. Een Care Record (zorgdossier) dat dit zorgprofiel representeert wordt als antwoord verwacht. Get Care Record Profile Response (QUPC_TE043200UV) Beschrijving Structured Name: Query Care Record Event Profile Query Response Type: Interaction based Het zorgdossier dat volgt op de Care Profile Query en daarmee overeenkomt.
79
5.5
Refined Message Information Models
Hier volgen de query modellen. Refined Message Information Models (gesorteerd op Titel) Care Record Profile Query(QUPC_RM040300UV) Care Record Query(QUPC_RM040000UV) Find Care Record Candidate Query(QUPC_RM040100UV) Referentie Voor details over de interpretatie van deze sectie, zie de Beschrijving van RMIMs in de Versie 3 Guide. Find Care Record Candidate Query (QUPC_RM040100UV) Diagram
Beschrijving Parent:
None Specified
De Find Care Record Candidate Query request RMIM levert de lijst van query parameters die nodig zijn om een lijst van samengevatte Care Records op te halen die zijn gebaseerd op de gespecificeerde criteria. Deze query parameters zijn als volgt:
80
PatientId: De unieke identifier (II) van de patiënt wiens dossiers worden opgehaald. De parameter is verplicht en zou precies één patient identifier moeten bevatten, welke niet nul moet zijn. PatientName: Het label (PN) waaronder de patiënt wiens dossiers worden opgehaald bekend is en waarmee gecommuniceerd wordt. De patiëntnaam wordt gebruikt voor verificatie van de ‘patient identifier’ voor het query verzoek. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één patiëntnaam. PatientAdministrativeGender: Indiceert het geslacht (CE) van de patiënt wiens dossiers worden opgehaald. Gebruikt om te assisteren in de accurate identificatie van de patiënt, in de context van andere parameters. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één geslacht code waarde. PatientBirthTime: De kalenderdatum (TS) waarop een patiënt wiens dossiers worden opgehaald geboren is. Gebruikt om te assisteren bij het accuraat identificeren van een patiënt in de context van andere parameters. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één datumwaarde. CareRecordTimePeriod: De datum periode (IVL) van Care Record (zorgdossier) bijdragen die geïncludeerd moeten worden in de kandidatenlijst. Een query kan nieuwe bijdragen aanvragen die voor deze patiënt zijn behandeld sinds het laatste query verzoek. Bijvoorbeeld: een systeem kan elke maand naar een patiënt informeren en alleen de nieuwe bijdragen aan het zorgdossier van de patiënt krijgen. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één datum termijn. CareProvisionCode: De code (CD) die het type van de Care Records representeert die opgehaald wordt. Een query kan een lijst van Care Records van een specifiek type opvragen, zoals ambulante patiëntenbezoeken. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één type van Care Record code value (waarde). CareProvisionReason: De code (CD) die de conditie representeert die de “reden” is voor de Care Provision (zorgverlening) die gerapporteerd wordt in the Care Record. Een query kan een lijst van Care Records opvragen die gerelateerd zijn aan het reguleren van een huidige of vorige conditie, zoals zwangerschap. Het is vereist de parameter te ondersteunen en staat meerdere care provision reason code waarden toe. MaximumCandidates: Het maximum aantal (INT) van kandidaat-zorgdossiers (Care Records) die teruggegeven worden die overeenkomt met de query criteria. Bijvoorbeeld: 15 = vijftien meest recente Care Records (zorgdossiers) die overeenkomen met de query criteria, ongespecificeerd = alle Care Records die overeenkomen met de query criteria. De default is dat alle Care Records teruggegeven worden. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één integer waarde. Contained Hierarchical Message Beschrijvingen Query Care Record Event Find Candidate
QUPC_HD040100UV
81
Care Record Query (QUPC_RM040000UV) Diagram
Beschrijving Parent:
None Specified
De Care Record Query request RMIM levert de lijst van query parameters die nodig zijn om een specifieke Care Record op te halen die wordt bepaald door zijn unieke identifier. Deze query parameters zijn als volgt: CareRecordId: De unieke identifier (II) van de Care Record die opgehaald moet worden. De parameter is verplicht en zou precies één Care Record identifier moeten bevatten welke niet nul moet zijn. PatientId: De unieke identifier (II) van de patiënt wiens dossier wordt opgehaald. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één patient identifier. Deze parameter kan geleverd worden om te verzekeren dat de Care Record die wordt opgevraagd voor de juiste patiënt is of wanneer Care Record identifiers alleen uniek zijn voor een bepaalde patiënt. VersionTimestamp: De datum/tijd (TS) waarop de toestand van een Care Record die opgehaald wordt weergegeven zou moeten worden, dat is, haal het Care Record snapshot op van dat tijdstip. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één tijdstip. IncludeCarePlanAttachment: Een indicator (BL) die, als deze op ‘true’ staat, elke zorgplan bijlage zou bevatten die beschikbaar is. Als deze op ‘false’ staat zouden zorgplan bijlagen niet gestuurd of teruggegeven worden in de ‘query response’. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één boolean indicator. MaximumHistoryStatements: Het aantal (INT) herhalingen van elk type van historisch Sare Statements (bijv. A1Cs, gewicht, uitgereikte medicatie, etc.) die teruggegeven worden. Bijvoorbeeld: 1= meest recent, 2= laatste twee Care Statements, ongespecificeerd= alle beschikbare Care Statements. De default is dat alle dossiers
82
worden teruggegeven. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één integer waarde. Contained Hierarchical Message Beschrijvingen Query Care Record Event Get
QUPC_HD040000UV
Care Record Profile Query (QUPC_RM040300UV) Diagram
Beschrijving Parent:
None Specified
De Care Record Profile Query request RMIM levert de lijst van query parameters die nodig zijn om een care profile op te halen dat afgeleid is van het patiënten dossier dat overeenkomt met de criteria parameters. Deze query parameters zijn als volgt: PatientId: De unieke identifer (II) van de patiënt wiens dossiers opgehaald worden. De parameter is verplicht en zou precies één patient identifer moeten bevatten welke niet nul moet zijn.
83
PatientName: Het label (PN) waaronder de patiënt wiens dossiers worden opgehaald bekend is en waarmee gecommuniceerd wordt. De patiëntnaam wordt gebruikt voor verificatie van de ‘patient identifier’ voor het query verzoek. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één patiëntnaam. PatientAdministrativeGender: Indiceert het geslacht (CE) van de patiënt wiens dossiers worden opgehaald. Gebruikt om te assisteren in de accurate identificatie van de patiënt, in de context van andere parameters. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één geslacht code waarde. PatientBirthTime: De kalenderdatum (TS) waarop een patiënt wiens dossiers worden opgehaald geboren is. Gebruikt om te assisteren bij het accuraat identificeren van een patiënt in de context van andere parameters. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één datumwaarde. ClinicalStatementTimePeriod: De datum termijn (IVL) van de Care Statements die geïncludeerd worden in het teruggekregen Care Record profiel. Bijvoorbeeld wanneer het resultaat van de labtest tot stand kwam, wanneer de medicatie werd uitgereikt, wanneer de procedure plaatsvond, etc. Deze parameter staat het filteren van Care Statments in een query response toe. Enkele Care Statements met data-attributen die in deze datum termijn vallen zullen geïncludeerd worden in de query response. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één datum termijn. CareRecordTimePeriod: De datum periode (IVL) van Care Record (zorgdossier) bijdragen die geïncludeerd moeten worden in de kandidatenlijst. Een query kan nieuwe bijdragen aanvragen die voor deze patiënt zijn behandeld sinds het laatste query verzoek. Bijvoorbeeld: een systeem kan elke maand naar een patiënt informeren en alleen de nieuwe bijdragen aan het zorgdossier van de patiënt krijgen. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één datum termijn. CareProvisionCode: De code (CD) die het type van de Care Records representeert die opgehaald wordt. Een query kan een lijst van Care Records van een specifiek type opvragen, zoals een samenvatting van een ziekenhuisontslag, of een meer algemene groepering van Care Record typen, zoals ambulante patiëntenbezoeken. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één type van Care Record code value (waarde). CareProvisionReason: De code (CD) die de conditie representeert die de “reden” is voor de Care Provision (zorgverlening) die gerapporteerd wordt in the Care Record. Een query kan een lijst van Care Records opvragen die gerelateerd zijn aan het reguleren van een huidige of vorige conditie, zoals zwangerschap. Het is vereist de parameter te ondersteunen en staat meerdere care provision reason code waarden toe. De default waarde is dat alle records worden verstrekt als antwoord op de query. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één integer waarde IncludeCarePlanAttachment: Een indicator (BL) die, als deze op ‘true’ staat, elke zorgplan bijlage zou bevatten die beschikbaar is. Als deze op ‘false’ staat worden bijlagen (attachments) niet gestuurd of teruggegeven in de query response. De default is 'false'. Het is vereist de parameter te ondersteunen, maar heeft een maximum van slechts één boolean indicator. Contained Hierarchical Message Beschrijvingen Query Care Record Event Profile
QUPC_HD040300UV
84
5.6
Hierarchical Message Descriptions
Hierarchical Message Descriptions (gesorteerd op Titel) Care Record Profile Query(QUPC_HD040300UV) Care Record Query(QUPC_HD040000UV) Find Care Record Candidate Query(QUPC_HD040100UV) Referentie Voor details over de interpretatie van deze sectie, zie de Beschrijving van HMDs in de Versie 3 Guide. Find Care Record Candidate Query (QUPC_HD040100UV) Beschrijving Een verzoek (request) voor het vinden van een kandidaat van Care Record dat overeenkomt met de query criteria. Op dit moment is er geen inhoud voor deze sectie. Base Hierarchical Message Description Message Type List Query Care Record Event Find Candidate
QUPC_MT040100UV
Care Record Query (QUPC_HD040000UV) Beschrijving Een verzoek (request) voor een specifieke Care Record bepaald door zijn unique identifer. Op dit moment is er geen inhoud voor deze sectie. Base Hierarchical Message Description Message Type List Query Care Record Event Get
QUPC_MT040000UV
Care Record Profile Query (QUPC_HD040300UV) Beschrijving Een verzoek (request) voor het ophalen van een zorgprofiel dat is afgeleid van het patiëntendossier dat overeenkomt met de query criteria. Op dit moment is er geen inhoud voor deze sectie.
85
Base Hierarchical Message Description Message Type List Query Care Record Event Profile 5.7
QUPC_MT040300UV
Interacties
Dit zijn de interacties tussen de applicaties. Lijst vanInteracties (gesorteerd op Titel) Find Care Record Candidate Query(QUPC_IN041100UV) Find Care Record Candidate Response(QUPC_IN041200UV) Get Care Record Profile Query(QUPC_IN043100UV) Get Care Record Profile Response(QUPC_IN043200UV) Get Care Record Query(QUPC_IN040100UV) Get Care Record Response(QUPC_IN040200UV) Referentie Voor details over de interpretatie van deze sectie, zie de definitie van Interacties in de Versie 3 Guide. Find Care Record Candidate Query (QUPC_IN041100UV) Beschrijving Structured Name:
Query Care Record Event Find Candidate Query
Een verzoek (request) voor het vinden van een kandidaat van Care Record dat overeenkomt met de query criteria. Een lijst van samengevatte Care Records wordt als antwoord verwacht. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Find Care Record Candidate Query QUPC_TE041100UV Send Message Payload MCCI_MT000100UV01 Query Control Act Request : Parameter QUQI_MT020001UV01 List Find Care Record Candidate Query QUPC_MT040100UV
Receiver Responsibilities (verantwoordelijkheden ontvanger) Reason Trigger Event Interaction Dit is het verwachte antwoord op de Find QUPC_TE041200UV QUPC_IN041200UV Care Record Candidates query
Sending and Receiving Roles (Zendende en ontvangende rollen) Care Record Query Placer Care Record Query Fulfiller
QUPC_AR004030UV QUPC_AR004040UV
86
Find Care Record Candidate Response (QUPC_IN041200UV) Beschrijving Structured Name:
Query Care Record Event Find Candidate Query Response
Een antwoord (response) op een query voor het vinden van een kandidaat Care Record dat overeenkomt met de query criteria. Een lijst van samengevatte Care Records wordt als antwoord teruggegeven. Find Care Record Candidate Response QUPC_TE041200UV Trigger Event MCCI_MT000300UV01 Transmission Wrapper Application Level Acknowledgement Master File / Registry Query Response, MFMI_MT700712UV01 Control Act Wrapper Act Subject REPC_MT004005UV Query Response Type Care Record Candidate Find Care Record Candidate Query QUPC_MT040100UV Query Definition
Sending and Receiving Roles (Zendende en ontvangende rollen) QUPC_AR004040UV QUPC_AR004030UV
Sender Care Record Query Fulfiller Receiver Care Record Query Placer Get Care Record Query (QUPC_IN040100UV) Beschrijving Structured Name:
Query Care Record Event Get Query
Een verzoek (request) voor een specifiek Care Record bepaald door zijn unieke identifier. Een Care Record dat overeenkomt met de query criteria wordt als antwoord verwacht. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Get Care Record Query QUPC_TE040100UV MCCI_MT000100UV01 Send Message Payload Query Control Act Request : QUQI_MT020001UV01 Parameter List Care Record Query QUPC_MT040000UV
Receiver Responsibilities (verantwoordelijkheden ontvanger) Reason Trigger Event Interaction Dit is het verwachte antwoord op de Get Care QUPC_TE040200UV QUPC_IN040200UV Record Query
87
Sending and Receiving Roles (Zendende en ontvangende rollen) Sender Receiver
QUPC_AR004030UV QUPC_AR004040UV
Care Record Query Placer Care Record Query Fulfiller
Get Care Record Response (QUPC_IN040200UV) Beschrijving Structured Name:
Query Care Record Event Get Query Response
Een antwoord (response) op een query voor een specifieke Care Record bepaald door zijn unieke identifier. Een Care Record dat overeenkomt met de query criteria wordt in dit antwoord teruggegeven. Get Care Record Response QUPC_TE040200UV Trigger Event Transmission Wrapper Application Level Acknowledgement MCCI_MT000300UV01 Master File / Registry Query MFMI_MT700712UV01 Control Act Wrapper Response, Act Subject REPC_MT004000UV Query Response Type Care Record QUPC_MT040000UV Care Record Query Query Definition
Sending and Receiving Roles (Zendende en ontvangende rollen) Care Record Query Fulfiller Care Record Query Placer
QUPC_AR004040UV QUPC_AR004030UV
Get Care Record Profile Query (QUPC_IN043100UV) Beschrijving Structured Name:
Query Care Record Event Profile Query
Een verzoek (request) voor het ophalen van een zorgprofiel dat is afgeleid van het patientendossier . Een Care Record dat dit zorgprofiel representeert, en overeenkomt met de query criteria, wordt als antwoord verwacht. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Get Care Record Profile Query QUPC_TE043100UV Send Message Payload MCCI_MT000100UV01 Query Control Act Request : QUQI_MT020001UV01 Parameter List Care Record Profile Query QUPC_MT040300UV
88
Receiver Responsibilities (verantwoordelijkheden ontvanger) Reason Trigger Event Interaction Dit is het verwachte antwoord op de Get Care QUPC_TE043200UV QUPC_IN043200UV Record Profile query
Sending and Receiving Roles (Zendende en ontvangende rollen) QUPC_AR004030UV QUPC_AR004040UV
Sender Care Record Query Placer Receiver Care Record Query Fulfiller
Get Care Record Profile Response (QUPC_IN043200UV) Beschrijving Structured Name:
Query Care Record Event Profile Query Response
Een antwoord (response) op een query voor een zorgprofiel afgeleid van het gezondheidsdossier van de patiënt. Een Care Record die dit zorgprofiel representeert, die overeenkomt met de query criteria, wordt teruggegeven in dit antwoord. Get Care Record Profile Response QUPC_TE043200UV Trigger Event MCCI_MT000300UV01 Transmission Wrapper Application Level Acknowledgement Master File / Registry Query Response, MFMI_MT700712UV01 Control Act Wrapper Act Subject REPC_MT004000UV Query Response Type Care Record Care Record Profile Query QUPC_MT040300UV Query Definition
Sending and Receiving Roles (Zendende en ontvangende rollen) Sender Care Record Query Fulfiller Receiver Care Record Query Placer
QUPC_AR004040UV QUPC_AR004030UV
89
6.
OVERDRACHT/ ONTSLAGSAMENVATTING: CARE RECORD TOPIC
6.1
Inleiding
Dit hoofdstuk is een vertaling van Hoofdstuk 6 van de Care Provision uit de ballot van januari / mei 2007. De volgende onderwerpen komen aan de orde: Storyboards Application Roles Trigger Events Refined Message Information Models Hierarchical Message Descriptions Interacties Het onderwerp omvat de professionele samenvatting van het elektronisch patiëntendossier en de daarbij passende berichten die worden gebruikt om de zorg te communiceren die daadwerkelijk is verleend in de periode dat een client onder behandeling was van een verantwoordelijke zorgverlener. In de Nederlandse tekst wordt verder gesproken over het elektronisch cliënten dossier, zowel als het betrekking heeft op het complete dossier, dan wel op een uittreksel er uit. Onder elektronisch cliënten dossier kan ook worden verstaan elektronisch patiënten dossier, cliëntvolgsysteem en andere synoniemen. Onderstaand interactiediagram illustreert alle Interacties en Applicatie Rollen die relevant zijn voor het elektronisch cliënten dossier (Care Record Topic).
90
6.2
Storyboards
Storyboards (georteerd volgens titel) Emergency Encounter(REPC_ST002001UV) Hospital Discharge Summary(REPC_ST002002UV) Mandatory Care Activation(REPC_ST002006UV) Ongoing Specialist Care Provision(REPC_ST002003UV) Separation of Care(REPC_ST002004UV) Temporary Handover of Care(REPC_ST002005UV) Referentie Voor details over de interpretatie van deze sectie, zie de storyboard discussie in de Versie 3 Guide. Mandatory Care Activation (REPC_ST002006UV) Doel Het doel van dit storyboard is om het rapportagebericht te illustreren dat is gerelateerd aan een gemandateerde start (activation) van zorg, bijvoorbeeld een verwijzing of rapportage van een huisarts aan een zorginstelling of zorgverlener. Interactie Lijst Report Care Provision
REPC_IN004014UV
Notify Care Provision Summary (REPC_SN002006UV) Activiteiten: Dr. Primary schrijft samenvattingen van de zorgverlening (Care Provision Summaries) ten behoeve van een zorginstelling. De samenvattingen beschrijven de zorg voor de patiënt tot op heden. Dr. Primary noteert de datum waarop de zorgverlening door haar praktijk is gestart. Alle informatie, inclusief problemenlijsten, allergielijsten, medicatielijsten, voortgangsnotities, zorgplannen en alle andere informatie die is opgenomen in het dossier worden opgenomen in de samenvatting. Postconditie: The Care Provision summary voor de heer Adam Everyman wordt ontvangen door de zorginstelling die de zorg zal leveren in overeenstemming met de zorgplannen die zijn beschreven door Dr. Primary. Update Requirements Summary: De communicatiepartners in dit bericht zijn Dr. Primary en de ontvangende zorgverlener in de zorginstelling. De focus van de communicatie is het leveren van gegevens die de zorginstelling in staat stellen om de zorg aan de heer Adam Everyman voort te zetten. Hoewel hier niet geïllustreerd, behoudt Dr. Primary’s zorgsysteem een aantekening wanneer de Care Provision summary is verstuurd naar de zorginstelling.
91
Temporary Handover of Care (REPC_ST002005UV) Doel Het doel van dit storyboard is om het rapportagebericht te illustreren dat is gerelateerd aan het tijdelijk overdragen van verantwoordelijkheid van zorg van een zorgverlener die met verlof gaat aan een andere zorgverlener. Interactie Lijst Suspend Care Provision
REPC_IN004310UV
Temporary Handover of Care (REPC_SN002005UV) Preconditie: De heer Adam Everyman, een mannelijke patiënt van 75 jaar, ontvangt in opdracht van zijn nefroloog Dr. Roy Renal, een peritoneale dialyse op proefbasis in de zorginstelling waar hij woont, Home Away from Home. Na drie maanden lijkt de heer Everyman hersteld. Hij heeft Dr. Renal gevraagd om een onderbreking van de dialyse om te zien hoe het gaat. Dr. Renal gaat akkoord. Hij bereidt een samenvatting voor voor de huisarts van de heer Everyman, Dr. Patricia Primary, waarin hij een gedetailleerde beschrijving geeft van de zorg die hij tot op heden heeft verleend aan de heer Everyman en het advies aan haar voor de tijdelijke stopzetting van de dialyse van de heer Everyman. Activiteiten: Dr. Renal registreert de aanvangsdatum van zijn supervisie op de peritoneale dialyse van de heer Everyman. Relevante informatie inclusief probleemlijsten, allergielijsten, medicatielijsten, voortgangsnotities en zorgplannen worden opgenomen in de samenvatting. [Interactie: Suspend Care Provision] Postconditie: Het bericht met de samenvatting van de zorg die is verleend aan de heer Everyman wordt ontvangen door Dr. Primary en ingelezen in haar zorgsysteem (huisarts informatie systeem). Update Requirements Summary: De actoren in deze communicatie zijn Dr. Renal en Dr. Primary. De focus van de communicatie is de heer Everymans huidige dossier met betrekking tot de peritoneale dialyse die is verzorgd door Dr. Renal, zijn status en het plan voor de voortgang van de zorg. Emergency Encounter (REPC_ST002001UV) Doel Het doel van dit storyboard is om het bericht van het ontslag van de zorgverlening (Care Provision Separation Notification) en verzoeken om zorgverlening (Care Provision Requests) voor een follow-up van specialistische zorg te illustreren. Het voorbeeld dat hier is gebruikt is een bericht van een arts van spoedeisende hulp over een patiënt die nazorg behoeft van specialistische hulp (Physician Notification of Emergency Encounter Requiring Follow up Specialist Care).
92
Interactie Lijst Complete Care Provision
REPC_IN004410UV
Care Transfer Request
REPC_IN002120UV
Care Record Emergency Encounter (REPC_SN002001UV) Preconditie: De heer Adam Everyman is een patiënt die met de ambulance op de Spoed Eisende Hulp (SEH) arriveert van het Good Health Ziekenhuis (GHZ) met ademhalingsstoornissen en een verhoogde hartslag. Hij wordt gezien door de dienstdoende arts, Dr. Eric Emergency, welke beslist dat de heer Everyman direct moet worden behandeld. De heer Everyman wordt ingecheckt voor de SEH door de heer Christopher Clerk, de SEHassistent die de heer Everymans gegevens van de GHZ-patiëntenregistratie ontvangt en de opname bij de SEH verzorgt. Nadat de heer Everyman een behandeling met een verstuiver heeft gekregen en hij weer stabiel is voor ontslag, stuurt Dr. Emergency een samenvatting van het spoedconsult aan de huisarts van de heer Everyman, Dr. Patricia Primary. Daarnaast adviseert Dr. Emergency de heer Everyman een nabehandeling bij een longarts en schrijft een doorverwijzing aan Dr. Penny Puffer. Activiteiten: Adam Everyman arriveert op de GHZ SEH en wordt gezien door Dr. Eric Emergency die hem stabiliseert en vaststelt dat hij met ontslag kan. Dr. Emergency schrijft een samenvatting van het bezoek en verstuurt dit naar Dr. Patricia Primary. Op deze manier geeft hij details van het onderzoek, de gegeven behandeling en de vereiste nazorg. [Interactie: Complete Care Provision]. Ook stuurt Dr. Emergency een verwijzing voor Adam Everyman voor een nabehandeling aan Dr. Penny Puffer [Interactie: Care Transfer Request]. Postconditie: De samenvatting van het bezoek van de heer Adam Everyman aan de SEH wordt ontvangen door Dr. Primary and wordt gebruikt om de verdere behandeling van Adam Everyman vorm te geven. Dr. Primary ziet dat er een doorverwijzing naar Dr. Puffer is opgesteld en maakt een aantekening om bij Dr. Puffer te informeren naar de uitkomst van de nabehandeling. De GHZ SEH-assistent maakt de ontslaginformatie voor de heer Everyman af en ontslaat hem van de GHZ SEH. Update Requirements Summary: De primaire actoren van deze communicatie zijn Dr. Emergency, Dr. Primary en Dr. Puffer. De focussen van de communicatie zijn Dr. Emergency’s verzoek voor een doorverwijzing aan Dr. Puffer en Adam Everymans bezoek aan de SEH die is verstuurd naar Dr. Primary en Dr. Puffer.
93
Hospital Discharge Summary (REPC_ST002002UV) Doel Het doel van dit storyboard is om de ontslagsamenvatting en de verzoeken om nabehandeling van de behandelend arts te illustreren en het aanvragen en regelen van zorg na ontslag die voortvloeien uit een opname in het ziekenhuis. Interactie Lijst Care Transfer Request
REPC_IN002120UV
Care Transfer Promise
REPC_IN003130UV
Complete Care Provision
REPC_IN004410UV
Activate Care Provision
REPC_IN004110UV
6.1.4.1
Care Record Hospital Discharge Summary (REPC_SN002002UV)
Preconditie: De heer Adam Everyman is opgenomen in het Good Health Ziekenhuis (GHZ). Zijn arts, Dr. Aaron Attend, verwijst hem voor thoracale chirurgie door naar Dr. Cutter die ermee instemt om de heer Everyman te opereren en hem in het GHZ toevoegt aan zijn chirurgische lijst op 27 juni. De thoracale chirurgie wordt uitgevoerd om na te gaan of de heer Everyman longkanker heeft. Dr. Cutter is van mening dat de chirurgische resultaten indiceren dat de heer Everyman longkanker heeft. Voordat hij een behandeling start bij zichzelf in de Gamma Cancer Clinic, verwijst hij de heer Everyman voor een second opinion door naar Dr. Dunst, een longchirurg. Ook verwijst Dr. Cutter de heer Everyman door naar het stoppen-metroken onderwijsprogramma ‘Quit Now’. Dr. Cutter levert een samenvatting van de chirurgie aan aan Dr. Attend, die ook een kopie ontvangt van de heer Everymans bezoek aan Quit Now. Activititeiten: Dr. Attend verwijst de heer Everyman door naar Dr. Cutter met een verzoek voor thoracale chirurgie om longkanker uit te sluiten. Hij voegt een gezondheidssamenvatting toe als onderdeel van zijn verzoek [Interactie: Care Transfer Request ]. Dr Cutter beantwoordt het verzoek en bevestigt dat hij de heer Everyman aan zijn chirurgische lijst heeft toegevoegd op 27 juni. [Interactie:Care Transfer Promise]. Na de thoracale chirurgie op de heer Everyman verwijst Dr. Cutter de heer Everyman voor een second opinion door naar Dr. Dunst. Dr. Cutter stelt een samenvatting van de heer Everymans’ chirurgie op, samen met de gezondheidssamenvatting van Dr. Attend en stuurt een verzoek om doorverwijzing naar Dr. Dunst en een naar het stoppen-met-roken onderwijsprogramma ‘Quit Now’. [Interactie: Care Transfer Request ]. Dr. Cutter stelt dezelfde samenvatting op van de heer Everymans chirurgie, samen met een voorstel voor een zorgplan en stuurt deze naar de Chirurgische Staf, de ongevallen commissie en naar Dr. Attend. Deze notitie bevat details van de gevolgde procedure, de chirurgische bevindingen en een ongunstige gebeurtenis (adverse event) tijdens de procedure. [Interactie: Complete Care Provision]. Na de heer Everymans bezoeken aan Quit Now wordt een rapport van zijn bezoeken door Quit Now verstuurd naar Dr. Primary voor in haar dossier [Interactie: Activate Care Provision].
94
Postconditie: Nadat Dr. Attend de heer Everyman heeft doorverwezen naar Dr. Cutter ontvangt hij een bericht van de ontslagsamenvatting over de uitkomsten van de chirurgische doorverwijzing, inclusief postchirurgische nabehandeling en zorg, en voortgangsrapporten van Quit Now. Update Requirements Summary: De actoren van deze communicatie zijn Dr. Attend, Dr. Cutter, Dr. Dunst en de Quit Now kliniek. De focussen van de communicatie zijn Dr. Attends gezondheidssamenvatting en het verzoek voor doorverwijzing aan Dr. Cutter, Dr. Cutters verzoek voor doorverwijzing en chirurgische samenvatting verstuurd naar Dr. Dunst and de Quit Now kliniek, Dr. Cutters chirurgische samenvatting en het voorstel voor een zorgplan verstuurd naar Dr. Attend, en de samenvatting van de bezoeken van de Quit Now kliniek verstuurd aan Dr. Attend. Ongoing Specialist Care Provision (REPC_ST002003UV) Doel Het doel van dit storyboard is om het verzoek- en rapportagebericht gerelateerd aan de zorgverlening te illustreren (Event Summary). Het voorbeeld dat is gebruikt is het verzoek van een huisarts (General Practitioner (GP)) voor specialistische zorg met een bericht voor vervolgbehandeling. Interactie Lijst Care Transfer Request
REPC_IN002120UV
Care Transfer Promise
REPC_IN003130UV
Activate Care Provision
REPC_IN004110UV
Append Care Provision
REPC_IN004211UV
Care Record Ongoing Specialist Care Provision (REPC_SN002003UV) Preconditie: Dr. Primary, eerstelijns arts in de polikliniek van het Good Health Ziekenhuis (GHZ), heeft de heer Everyman onder behandeling, een 75-jarige mannelijke patiënt die klaagt over pijn in zijn heupgewricht. Zij verwijst de heer Everyman door naar Dr. Joint, een reumatoloog in het GHZ, met het verzoek om een afspraak te maken met de heer Everyman en advies te geven over zijn klacht. Dr. Joint heeft geen contract of wettelijke verplichting om de patiënt te zien. Dr. Joint stemt in met een afspraak met de heer Everyman. De heer Everyman heeft een eerste consult met Dr. Joint gevolgd door driemaandelijkse bezoeken. Na elk bezoek stuurt Dr. Joint een voortgangsrapport van de heer Everyman naar Dr. Primary. Activiteiten: Dr. Primary verwijst de heer Everyman door naar Dr. Joint met een kopie van de heer Everymans klinische samenvatting en relevante klinische voorgeschiedenis tot op heden [Interactie: Care Transfer Request ]. Dr. Joint stemt in met een afspraak met de heer Everyman en bericht dit aan Dr. Primary [Interactie: Care Transfer Promise ]. Nadat Dr. Joint de heer Everyman heeft gezien zendt hij Dr. Primary een rapport met een samenvatting van zijn onderzoek en een overzicht van zijn voorgenomen vervolgbehandeling [Interactie: Activate Care Provision]. Elke volgende drie maanden stuurt Dr. Joint
95
voortgangsrapporten over de heer Everyman aan Dr. Primary [Interactie:Append Care Provision ]. Postconditie: Dr. Primary ontvangt een aanvangsrapport en driemaandelijkse rapporten van Dr. Joint over de vorderingen van de heer Everyman en neemt de informatie uit de rapporten mee in haar verdere behandeling van de heer Everymans andere gezondheidsproblemen. Update Requirements Summary: De actoren van deze communicatie zijn Dr. Primary en Dr. Joint. De focussen van deze communicatie zijn Dr. Primary’s verzoek om een doorverwijzing aan Dr. Joint, Dr. Joints aanvangssamenvatting plus de daaropvolgende onderzoekssamenvattingen van Dr. Joint en vervolgzorgplannen aan Dr. Primary. Separation of Care (REPC_ST002004UV) Doel Het doel van dit storyboard is om het rapportbericht te illustreren dat is gerelateerd aan het stopzetten van de zorgverlening. Interactie Lijst Complete Care Provision
REPC_IN004410UV
Separation of Care (REPC_SN002004UV) Preconditie: Dr. Primary, eerstelijns arts in de polikliniek van het Good Health Ziekenhuis (GHZ), heeft de heer Everyman onder behandeling, een 75-jarige mannelijke patiënt met meerdere gezondheidsproblemen. Dr. Primary sluit haar praktijk en schrijft samenvattingen van de zorgverlening (Care Provision Summaries) voor het gebruik door de patiënt en de zorgverleners bij wie de patiënt graag in behandeling wil worden genomen. Activiteiten: Dr. Primary registreert de aanvangsdatum van de zorgverlening door haar praktijk en de datum waarop de zorgverlening door haar praktijk is gestopt. Alle informatie inclusief probleemlijsten, allergielijsten, medicatielijsten, voortgangsnotities, zorgplannen, en alle andere informatie die is opgenomen in haar dossiers wordt opgenomen in de samenvatting [Interactie: Complete Care Provision]. Postconditie: De heer Everymans gezondheidsdossier wordt bijgewerkt als gevolg van de Care Provision samenvattingen van Dr. Primary zodat zij beschikbaar zijn voor hem en andere zorgverleners met wie hij de informatie wil delen. Update Requirements Summary: De actor van deze communicatie is Dr. Primary. De focus van deze communicatie is de heer Everymans zorgdossier verzorgd door Dr. Primary.
96
6.3
Applicatierollen
Application Roles (Georteerd volgens Artifact Code) Care Provision Informer (REPC_AR004010UV) Care Provision Reporter (REPC_AR004014UV) Care Provision Tracker (REPC_AR004020UV) Care Provision Reporting Receiver (REPC_AR004024UV) Referentie Voor details over de interpretatie van deze sectie, zie de discussie van applicatie rollen en hun verbanden in de Versie 3 Guide.
Care Provision Informer (REPC_AR004010UV) Beschrijving Structured Name: Care Record Event Informer Een applicatie die in staat is om een ander systeem te wijzen op een handeling in een zorgdossier (care record event).
Care Provision Reporter (REPC_AR004014UV) Beschrijving Structured Name: Care Record Event Informer Report Een applicatie die in staat is om een ander systeem te wijzen op een zorgdossier dat wordt opgestart/getriggered door een gebruiker of een andere externe actie. Care Provision Tracker (REPC_AR004020UV) Beschrijving Structured Name: Care Record Event Tracker Een applicatie die in staat is om een bericht van een ander systeem te ontvangen over een handeling in een zorgdossier (care record event). Care Provision Reporting Receiver (REPC_AR004024UV) Beschrijving Structured Name: Care Record Event Tracker Report Een applicatie die in staat is om een bericht te ontvangen van een ander systeem over een zorgdossier dat wordt opgestart/getriggered door een gebruiker of een andere externe actie.
97
6.4
Trigger Events
Trigger Events (Georteerd volgens titel) Activate Care Provision(REPC_TE004110UV) Append Care Provision(REPC_TE004211UV) Complete Care Provision(REPC_TE004410UV) Correct Care Provision(REPC_TE004210UV) Nullify Care Provision(REPC_TE004810UV) Replace Care Provision(REPC_TE004913UV) Report Care Provision(REPC_TE004014UV) Resume Care Provision(REPC_TE004510UV) Suspend Care Provision(REPC_TE004310UV) Referentie Voor details over de interpretatie van deze sectie, zie de discussie van trigger events in de Versie 3 Guide. Replace Care Provision (REPC_TE004913UV) Beschrijving Structured Name: Type:
Care Record Event Replace Obsolete Notification State-transition based
Geeft aan dat details over de zorgverlening aan een cliënt verouderd (obsolete) waren en zijn aangepast. Activate Care Provision (REPC_TE004110UV) Beschrijving Structured Name: Type: State Transition:
Care Record Event Activate State-transition based PatientCareProvisionEvent (REPC_RM004000UV)
Geeft aan dat de verantwoordelijkheid van zorgverlening is geactiveerd (gestart) en dat de ontvangende applicatie wordt geïnformeerd zonder daarop actie te hoeven ondernemen. Append Care Provision (REPC_TE004211UV) Beschrijving Structured Name: Type:
Care Record Event Revise Appended State-transition based
Geeft aanvullende details over de zorgverlening aan een subject.
98
Correct Care Provision (REPC_TE004210UV) Beschrijving Structured Name: Type:
Care Record Event Revise Corrected State-transition based
Geeft correcties op details over de zorgverlening aan een subject. Suspend Care Provision (REPC_TE004310UV) Beschrijving Structured Name: Type: State Transition:
Care Record Event Suspend State-transition based PatientCareProvisionEvent (REPC_RM004000UV)
Geeft aan dat de verantwoordelijkheid voor zorgverlening wordt onderbroken (suspended) en dat de ontvangende applicatie wordt geïnformeerd zonder daarop actie te hoeven ondernemen. Resume Care Provision (REPC_TE004510UV) Beschrijving Structured Name: Type: State Transition:
Care Record Event Resume State-transition based PatientCareProvisionEvent (REPC_RM004000UV)
Geeft aan dat de verantwoordelijkheid voor zorgverlening is hervat en dat de ontvangende applicatie wordt geïnformeerd zonder daarop actie te hoeven ondernemen. Complete Care Provision (REPC_TE004410UV) Beschrijving Structured Name: Type: State Transition:
Care Record Event Complete State-transition based PatientCareProvisionEvent (REPC_RM004000UV)
Geeft aan dat de zorgverlening is afgerond (completion has occurred) en dat de ontvangende applicatie wordt geïnformeerd zonder daarop actie te hoeven ondernemen. Een afgeronde zorgverlening geeft aan dat de uitvoerder (performer) niet langer verantwoordelijk is voor de zorgverlening aan de patiënt. Nullify Care Provision (REPC_TE004810UV) Beschrijving Structured Name: Type:
Care Record Event Nullify State-transition based
99
Geeft aan dat de eerdere registratie betreffende de zorgverlening incorrect of onjuist was en is verwijderd. Report Care Provision (REPC_TE004014UV) Beschrijving Structured Name: Type:
Care Record Event Report User request
Geeft aan de ontvanger details over de zorgverlening die zijn verzameld rapporteert tot op dat moment. 6.5
Refined Message Information Models
Refined Message Information Models Care Record(REPC_RM004000UV) Referentie Voor details over de interpretatie van deze sectie, zie de beschrijving van RMIMs in de Versie 3 Guide.
Care Record (REPC_RM004000UV) Diagram
100
Beschrijving Parent:
Care Provision (REPC_DM000000UV)
Care Record RMIM Overview Het Care Record RMIM beschrijft de gegevens en verbanden die nodig zijn wanneer de verantwoordelijkheid voor zorgverlening wordt verondersteld en een samenvatting van het dossier van de zorgactiviteiten (acts) die relevant zijn voor de zorgverlening inclusief elke gevraagde (request), voorgestelde (proposal) en/of geactiveerde (activate) zorgplannen. Dit model en het begeleidende diagram lijken op het Care Provision DMIM maar gebruiken "lokale CMETs (een CMET die voorlopig alleen binnen Care Provision wordt gebruikt en nog niet in andere onderdelen van HL7)" om een overzicht te geven van de complexiteit van de zorgstructuren die horen bij de Care Provision Request Act. De lezer wordt terugverwezen naar de DMIM discussie alvorens het RMIM te bestuderen, gevolgd door de discussie voor elke structuur. De discussie van dit model zal zich concentreren op de kenmerken die niet voorkomen in het DMIM en niet direct worden behandeld in de bespreking van dat model. CareProvisionEvent Focal Class Zoals aangegeven in de discussie van de DMIM registreert een Care Provision Event en geeft het samenvattingen van de relevante acties in de periode dat een uitvoerder verantwoordelijk is voor de zorgverlening aan het onderwerp of doel (target) van zorg. Verbanden/Associaties De volgende verbanden/associaties worden gedefinieerd voor een elektronisch patiëntendossier (Care Record). Elk associatie beschrijft de relatie tussen de gebeurtenis (Care Provision Event) en de entiteit (entity) of actie (act) die een belangrijke rol speelt in het elektronisch patiëntendossier (Care Record). Participaties recordTarget: de target van de registratie is de cliënt (entity) waarvoor het Care Record wordt aangelegd en bijgehouden. Er kan maar één record target zijn voor een Care Record. De informatie van de bedoelde cliënt (entity) wordt beschreven in de R_Patient CMET of R_CaredEntity local CMET. Voor een verdere beschrijving wordt verwezen naar de respectievelijke CMETs. Die zijn uitvoerig beschreven in de implementatiehandleiding data typen en CMETs van HL7 Nederland en NICTIZ. subject: wanneer het subject van een gegeven niet de target van de registratie is, dan wordt het subject geregistreerd als de target(s) van de zorgverlening. Denk hierbij bijvoorbeeld aan het vastleggen van de foetale hartslag in het dossier van de zwangere. De informatie van het subject wordt beschreven in de R_Patient CMET of R_CaredEntity local CMET. Voor een verdere beschrijving wordt verwezen naar de respectievelijke CMETs. author: de zorgverlener die de registratie van het Care Provision Event produceert. Dit kan een aangestelde/toegewezen (assigned) persoon of organisatie zijn (R_AssignedParty) zoals een zorgverlener, een gerelateerde (R_RelatedParty) zoals een familielid of een organisatie buiten
101
de gezondheidszorg, of de cliënt / patiënt zelf (R_Patient). Voor een verdere beschrijving wordt verwezen naar de respectievelijke CMETs. dataEnterer: de datatypist of secretaresse die de informatie in het Care Record invoert. De informatie van de datatypist wordt beschreven in de R_AssignedPerson CMET. verifier: de supervisor die het Care Record verifieert. Er is steun voor meerdere verificatieniveaus. De informatie van de verifiërende partij wordt beschreven in de R_AssignedPerson CMET. performer: de partijen die deelnemen aan het daadwerkelijk uitvoeren van de Care Provision Event die wordt geregistreerd. Er kunnen meerdere performers zijn omdat verschillende partijen kunnen meewerken aan het uitvoeren van de zorgverlening. Deze partijen kunnen aangesteld/aangewezen personen of organisaties zijn (R_AssignedParty) zoals een zorgverlener, een gerelateerde partij (R_RelatedParty) zoals een familielid of een organisatie buiten de gezondheidszorg, of de cliënt / patiënt zelf (R_Patient). Voor een verdere beschrijving wordt verwezen naar de respectievelijke CMETs. primaryInformationRecipient: de partij die is bedoeld om het Care Record bericht te ontvangen. De ontvanger is gewoonlijk de auteur van het verzoek om de zorg over te dragen (het care transfer request) of de eerstelijns zorgverlener. Deze worden soms vertegenwoordigd door een aangestelde/toegewezen persoon of organisatie (R_AssignedParty), een gerelateerde partij (R_RelatedParty) zoals een familielid of een rechtbank of de cliënt / patiënt zelf (R_Patient). Voor een verdere beschrijving wordt verwezen naar de respectievelijke CMETs. Act Relationships inFullfilmentOf: deze relatie verbindt de Care Provision Event met de beloofde (promise) en/of verzochte (request) Act die het vervult. Alleen het id attribuut is bevoegd om de Act te verbinden aan de Care Provision Event die het vervult. component: verbindt de Care Provision Event aan het zorgplan dat wordt uitgevoerd als onderdeel van de zorgverlening. Voor een verdere beschrijving van deze local CMET wordt verwezen naar het A_CarePlan in het onderwerp/hoofdstuk (topic) Care Plan. pertinentInformation1: verbindt de Care Provision Event aan het zorgplan dat informatie geeft voor de context van de zorgverlening, maar dat niet direct relevant is voor dit Care Record. Voor een verdere beschrijving van deze local CMET wordt verwezen naar het A_CarePlan in het onderwerp/hoofdstuk (topic) Care Plan. pertinentInformation3: verbindt de Care Provision Event aan een set van bijbehorende klinische verklaringen die worden bijgevoegd als onderdeel van de informatie die wordt aangeleverd in het Care Record. Voor een verdere beschrijving van deze local CMET wordt verwezen naar de A_CareStatement in het onderwerp/hoofdstuk (topic) Care Provision D-MIM en Care Structures. reason: een relatie met een conditie die wordt geregistreerd als de primaire reden voor de zorgverlening. Een probleem dat de primaire reden voor de zorgverlening is, niet specifiek een diagnose, kan ook met deze relatie worden gepresenteerd. Voor een verdere beschrijving van
102
deze local CMET wordt verwezen naar het A_ConcernTrackingEvent in het onderwerp/hoofdstuk (topic) Care Structures (N.B. HL7 TC Patient Care is bezig de inhoud van het domein te herstructureren. Daardoor kan het in een ander topic terecht komen. pertinentInformation2: een Care Record heeft een set van lijsten die verschillende klinische verklaringen bevatten als relevante informatie die van voortdurende aard is en die niet specifiek wordt beschreven als onderdeel van de Care Provision Event. Dit kan een problemenlijst zijn, een actuele medicatielijst of een lijst met risicofactoren. Voor een verdere beschrijving van deze local CMET wordt verwezen naar de A_StatementCollector in het onderwerp/hoofdstuk (topic) Care Structures. Reference: het consult/de consulten (encounter) die betrekking hebben op het Care Record, gepresenteerd door de A_Encounter CMET. ReplacementOf: een verbinding aan een vervangen/vernieuwd (replaced) Care Record. De Care Provision Event als target van deze act relationship heeft de status van verouderde versie (obsolete) en kan of alleen de instance identifier van het vervangen Care Record bevatten of de gehele inhoud. Contained Hierarchical Message Descriptions Care Record Event 6.6
REPC_HD004000UV
Hierarchical Message Descriptions
Hierarchical Message Descriptions Care Record (REPC_HD004000UV) Referentie Voor details over de interpretatie van deze sectie, zie de beschrijving van de HMDs in de Versie 3 Guide. Care Record (REPC_HD004000UV) Beschrijving Typen berichten gebaseerd op deze HMD die moeten worden gebruikt om de Care Record samenvattingen of rapportages te communiceren. Common Message Element Types Used A_CarePlanCare provision A_CareStatementCare provision A_ConditionTrackingEventCare provision A_EncounterUniversal A_StatementCollectorCare provision R_AssignedPartyUniversal
REPC_MT000200UV REPC_MT000100UV REPC_MT000301UV COCT_MT010000UV01 REPC_MT000400UV COCT_MT090400UV
103
R_AssignedPersonUniversal R_CaredEntityCare provision R_PatientUniversal R_RelatedPartyUniversal Base Hierarchical Message Description
COCT_MT090100UV01 REPC_MT000700UV COCT_MT050000UV01 COCT_MT910000UV
Message Type List Care Record Event
REPC_MT004000UV
Care Record Event Candidate
REPC_MT004005UV
Care Record Event Status
REPC_MT004009UV
6.7
Interacties
Lijst van Interacties (Georteerd volgens titel) Activate Care Provision(REPC_IN004110UV) Append Care Provision(REPC_IN004211UV) Complete Care Provision(REPC_IN004410UV) Correct Care Provision(REPC_IN004210UV) Nullify Care Provision(REPC_IN004810UV) Replace Care Provision(REPC_IN004913UV) Report Care Provision(REPC_IN004014UV) Resume Care Provision(REPC_IN004510UV) Suspend Care Provision(REPC_IN004310UV)
Referentie Voor details over de interpretatie van deze sectie, zie de definitie van Interacties in de Versie 3 Guide. Activate Care Provision (REPC_IN004110UV) Beschrijving Structured Name: Care Record Event Activate De interactie stelt de ontvanger op de hoogte van de details die zijn verzameld als onderdeel van de start van de zorgverlening aan een subject. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Activate Care Provision Send Message Payload Trigger Event Control Act Care Record
104
REPC_TE004110UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT004000UV
Sending and Receiving Roles Sender Receiver
REPC_AR004010UV REPC_AR004020UV
Care Provision Informer Care Provision Tracker
Append Care Provision (REPC_IN004211UV) Beschrijving Structured Name: Care Record Event Revise Appended Deze interactie wordt gebruikt om de ontvanger op de hoogte te stellen van aanvullende details die zijn verzameld als onderdeel van de verantwoordelijkheid van de zorgverlening aan een subject. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Append Care Provision Send Message Payload Trigger Event Control Act Care Record
REPC_TE004211UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT004000UV
Sending and Receiving Roles Sender Receiver
Care Provision Informer Care Provision Tracker
REPC_AR004010UV REPC_AR004020UV
Correct Care Provision (REPC_IN004210UV) Beschrijving Structured Name: Care Record Event Revise Corrected Deze interactie wordt gebruikt om de ontvanger op de hoogte te stellen van correcties op details die zijn verzameld als onderdeel van de verantwoordelijkheid van de zorgverlening aan een subject. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Correct Care Provision Send Message Payload Trigger Event Control Act Care Record
REPC_TE004210UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT004000UV
Sending and Receiving Roles Sender Receiver
Care Provision Informer Care Provision Tracker
REPC_AR004010UV REPC_AR004020UV
105
Suspend Care Provision (REPC_IN004310UV) Beschrijving Structured Name: Care Record Event Suspend Deze interactie stelt de ontvanger op de hoogte van details die zijn verzameld als onderdeel van de tijdelijke onderbreking van de zorgverlening aan een subject. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Suspend Care Provision Send Message Payload Trigger Event Control Act Care Record Status
REPC_TE004310UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT004009UV
Sending and Receiving Roles Sender Receiver
REPC_AR004010UV REPC_AR004020UV
Care Provision Informer Care Provision Tracker
Resume Care Provision (REPC_IN004510UV) Beschrijving Structured Name: Care Record Event Resume Deze interactie stelt de ontvanger op de hoogte van details die zijn verzameld als onderdeel van de hervatting van de zorgverlening aan een subject. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Resume Care Provision Send Message Payload Trigger Event Control Act Care Record Status
REPC_TE004510UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT004009UV
Sending and Receiving Roles Sender Receiver
Care Provision Informer Care Provision Tracker
REPC_AR004010UV REPC_AR004020UV
Complete Care Provision (REPC_IN004410UV) Beschrijving Structured Name: Care Record Event Complete Deze interactie stelt de ontvanger op de hoogte van details die zijn verzameld als onderdeel van de afronding van de zorgverlening aan een subject.
106
Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Complete Care Provision Send Message Payload Trigger Event Control Act Care Record
REPC_TE004410UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT004000UV
Sending and Receiving Roles Care Provision Informer Care Provision Tracker
Sender Receiver
REPC_AR004010UV REPC_AR004020UV
Nullify Care Provision (REPC_IN004810UV) Beschrijving Structured Name: Care Record Event Nullify Deze interactie stelt de ontvanger ervan op de hoogte dat de eerder aangeleverde details die zijn verzameld als onderdeel van de zorgverlening niet correct of niet juist waren aangeleverd en uit het dossier zijn verwijderd. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Nullify Care Provision Send Message Payload Trigger Event Control Act Care Record Status
REPC_TE004810UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT004009UV
Sending and Receiving Roles Sender Receiver
Care Provision Informer Care Provision Tracker
REPC_AR004010UV REPC_AR004020UV
Replace Care Provision (REPC_IN004913UV) Beschrijving Structured Name: Care Record Event Obsolete Replace Deze interactie stelt de ontvanger ervan op de hoogte dat de details die zijn verzameld als onderdeel van de zorgverlening verouderd zijn en zijn vervangen. Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Replace Care Provision Send Message Payload Trigger Event Control Act Care Record
REPC_TE004913UV MCCI_MT000100UV01 MCAI_MT700201UV01 REPC_MT004000UV
Sending and Receiving Roles Sender
Care Provision Informer
REPC_AR004010UV
107
Receiver
Care Provision Tracker
REPC_AR004020UV
Report Care Provision (REPC_IN004014UV) Beschrijving Structured Name: Care Record Event Notification Report De interactie wordt gebruikt door een zender om de ontvanger een samenvatting aan te leveren van de huidige zorgverlening tot op dat moment. Report Care Provision Trigger Event Transmission Wrapper Send Message Payload Master File / Reg. Notif Control Act, Control Act Wrapper Act Subject Care Record Message Type
REPC_TE004014UV MCCI_MT000100UV01 MFMI_MT700702UV01 REPC_MT004000UV
Sending and Receiving Roles Sender Receiver
Care Provision Reporter Care Provision Reporting Receiver
108
REPC_AR004014UV REPC_AR004024UV
7.
CLINICAL STATEMENT
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. scope van Clinical Statement Pattern Domain Het model dat in dit document beschreven wordt is een ‘patroon’ dat ontworpen is om gebruikt te worden binnen verscheidene HL7 Versie 3 domeinmodellen. Dit patroon wordt bedoeld om het consistente ontwerp van communicaties 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 databasae, hoewel het veel van de types van klinische informatie beslaat die deel zouden uitmoeten 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 met 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: de ‘mood’ en de aanwezigheid, afwezigheid, of de waarde; ∗ in het geval van een procedure: een ‘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
109
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..*); • waarden 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 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 'Condition 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 al zulke 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:
110
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. 7.1
Clinical Statement Patroon (COCS_DM000000)
111
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 statements expliciet te verbinden daar waar een specifieke relatie is. Daar waar een Clinical Statement voorheen overgedragen is in een communicatie en hierdoor bekend is binnen een informatiesysteem, kan de Clinical Statement toegevoegd worden door middel van referentie of door het herhalen van de volledige statement. Wanneer de volledige statement 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 Obesrvatie 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 implementatiehandleidingen 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
112
Een afgeleide van de RIM SubstanceAdministration klasse, gebruikt voor het representeren van medicatiegerelateerde gebeurtenissen, zoals medicatiegeschiedenis of geplande medicatietoediening 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
SubstanceAdministration.doseQuantity
SubstanceAdministration.rateQuantity
SubstanceAdministration.maxDoseQuantity
SubstanceAdministration.effectiveTime
Categorizes the priority of a substance administration Categoriseert de prioriteit van een toediening van een substantie Indicates how much medication is given per dose Geeft aan hoeveel medicatie per dosis gegeven wordt 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 het tempo aan te geven waarin de dosis wordt toegediend (bijv. de stroomsnelhid van intraveneuse infusen) 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) 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 as 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 statement van substantie toediening met negationInd is nog steeds een statement 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 statement en dezelfde eis om bewijs te hebben voor zo’n statement als wanneer hij de ontkenning niet gebruikt had.
113
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 gerepresenteerd 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 statement met negationInd is nog steeds een statement 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 statement 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.
114
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 statements 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 workflow 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 Organizer 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 statements 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 statement 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.
115
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 statement 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 modelvoor 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
116
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;
117
∗ 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 ClinicalStatement structuur ondersteunt.
118
Het groeperen kan voor verschillende doeleinden gebruikt worden, inclusief: ∗ statements 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.; ∗ statements 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 ClinicalStatement, met ActRelationship.typeCode die de aard van de link tussen de statements ondersteunt. Het wordt gebruikt om een ClinicalStatement toe te voegen aan een communicatie die relateert aan een andere toegevoegde ClinicalStatement, maar niet direct relevant is voor de Focal Act, bron Act of doel van de communicatie. Als een vorige conditie een observatie verklaart die gedaan is tijdens een contact (encounter), kan een voorbeeld hiervan zijn. 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 ClinicalStatement 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 communicatieinstantiatie 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 nietgerelateerde 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: ∗ elimineert de noodzaak 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; ∗ reikt een mechanisme aan 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.
119
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;
120
∗ 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 auteurparticipant 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 class, 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 focale of bron Act en verspreidt aan geneste Acts.
121
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 volgende tabel is een richtlijn voor zinvolle relaties tussen Clinical Statement Acts en is geen beperking. 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 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.
122
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.
123
