TITEL - HL7 Nederland

GENERIEKE
IMPLEMENTATIEHANDLEIDING
CARE
PROVISION
D-MIM,
STORYBOARDS CARE PROVISION, CLINICAL STATEMENT PATTERN EN
VERWIJS EN OVERDRACHTBERICHTEN
- concept 0.99 Dit is de versie die is bijgesteld na de 1e ballot ronde van augustus 2007 en bedoeld
voor de 2e ballotronde in Nederland die op 18 maart 2008 van start gaat.
Datum:
Versie:
Status:
17 maart 2008
0.99
Concept op basis van DSTU materiaal Care Provision van mei 2008
Vertalers:
dr. Kai Heitmann, dr. Ineke Jonkersz, drs. Judith van der Kooij, drs.
Lisanne van Beek en dr. William Goossen.
ir Michael Tan, Astrid Koenders, drs. Ernst de Bel, André Achterberg
Reviewers:
Verantwoordelijken 2e ronde:
drs Anneke Goossen, dr. William Goossen Results 4 Care.
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
INHOUD
1.
INLEIDING
5
1.1 De generieke toepasbaarheid van het domein model Care Provision
5
1.2 Relevante implementatiegidsen
6
1.3 Leeswijzer
7
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
12
2.4 Care Provision D-MIM Walk-through
16
2.5 Care Statement Structuur Overzicht (januari 2007)
36
Mis 4.2Hierarchical Message Descriptions
Error! Bookmark not defined.
3. STORYBOARDS
44
3.1 Doel
44
3.2 Patiënt Vult Persoonlijk Medisch Dossier (DOPC_ST000033UV)
44
3.3 Pediatrische Immunisatie (Vaccinatie) (DOPC_ST000030)
45
3.4 Huisarts Verwijst naar Specialist (DOPC_ST000034)
46
3.5 Multidisciplinaire Zorg (DOPC_ST000032)
47
3.5 Ouderenzorg (Aged Care) Overplaatsing - Domein (DOPC_ST000035)
48
4. VERWIJSBERICHT
51
4.1 Inleiding op verwijsbericht en overdracht
51
4.2 Care Transfer Topic
51
4.3 Care Transfer Definitie
52
4.4 Storyboards
53
4.5 Applicatie Rollen
66
4.6 Trigger Events
67
4.7 Refined Message Information Modellen
69
4.8 Care Transfer Request (REPC_RM002000UV)
69
4.9 Care Transfer Promise (REPC_RM003000UV)
73
4.10 Hierarchical Message Descriptions
75
4.11 Interacties
77
5. CARE RECORD QUERY TOPIC
84
5.1 Inleiding
84
5.2 Storyboards
84
5.3 Application Roles
87
5.4 Trigger Events
87
5.5 Refined Message Information Models
89
5.6 94
Hierarchical Message Descriptions
94
5.7 Interacties
95
6. OVERDRACHT/ONTSLAGSAMENVATTING: CARE RECORD TOPIC
100
6.1 Inleiding
100
6.2 101
Storyboards
101
6.3 Applicatierollen
108
6.4 Trigger Events
109
6.5 Refined Message Information Models
111
6.6 Hierarchical Message Descriptions
115
6.7 Interacties
116
3
7.
CLINICAL STATEMENT
7.1 Clinical Statement Patroon (COCS_DM000000)
4
121
124
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 Domein Message
Informatie Model (D-MIM1) en de bijbehorende berichten voor verwijzing, acceptatie en
dossieroverdracht zijn 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).In dit project speelt het care provision bericht een belangrijke rol. In dit project
zijn overigens aanpassingen nodig gebleken op het Care Provision model van HL7,
die in een later stadium als voorstel naar HL7 internationaal 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;
 een project voor het overdragen van informatie uit een 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 domein model
Care Provision en de bijbehorende berichten. Doordat dit domein model zo generiek is,
zijn er bovendien legio gebruikstoepassingen mogelijk in andere domeinen. Dit is de
reden dat het initiatief is genomen de beschrijving van het D-MIM en de vier
belangrijkste berichten (R-MIMs of Refined Message Information Model) 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
1
Uitleg van het Care Provision Domein Message Informatie Model (D-MIM) volgt in hoofdstuk 2.
5
dan meer naar het in het domein zelf vaststellen van de Basis Dataset voor dat domein
en de mapping naar vocabulaire en de Care Provision berichten. De onderdelen waarin
de use cases, storyboards, de dynamische modellen en de specifieke berichten
worden gedefinieerd blijven gewoon noodzakelijk in de domeinspecifieke
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.
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 D-MIM gebruikt. Deze versie
is consistent gemaakt met de mei 2008 ballot. Deze versie is sinds 2007 niet gewijzigd
omdat deze versie de DSTU status heeft. DSTU staat voor Draft Standard for Trial Use
en deze status richt zich op het stabiel houden van de Care Provision materialen
gedurende 2 tot 3 jaar. Daarnaast wordt via drafts gewerkt aan nieuwe topics.
Van de volgende volgende implementatiehandleidingen is gebruik gemaakt:
 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 May ballot version (2008) Ann Arbor,
Health Level Seven.
 NICTIZ implementatiegids Prica-GGZ voor de verwijzing 1e lijns geestelijke
gezondheidszorg.
 Clinical Statement Pattern van HL7 internationaal ballot september 2006. (De
recente wijzigingen daarvan zijn nog niet in Care Provision doorgevoerd ivm
DSTU status, dit zal later worden geharmoniseerd).
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 op dat moment nog 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 concern
tracker R-MIM: een uitwerking die diagnostiek en klachten op indvidueel patienten
niveau kan volgen in de tijd. De harmonisatie heeft geleid tot een 99% overeenkomst
tussen beide modellen.
NICTIZ heeft het voornemen op termijn het Prica D-MIM2 volledig te harmoniseren met
Care Provision. De verzamelde ervaringen uit de WDH implementatie zijn
voorwaardelijk om tot een geslaagde harmonisatie te kom en. Met andere woorden:
2
Prica D-MIM is het domein model voor het Waarneem Dossier Huisartsen
6
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. Dit is een
vertaling van de volledige walk-through uit de ballot van September 2006, waarbij niet
relevante voorbeelden zijn verwijderd. Het ballot materiaal van Mei 2008 voor Care
Provision D-MIM en de R-MIMs voor verwijzing, acceptatie, dossier query en dossier
overdracht is consistent met deze Nederlandse gids. De overige Topics van Care
Provision zijn nog niet vertaald.
Over de vertaling is het nog belangrijk te melden dat klassenamen en attribuut namen
en data specificaties zoveel als mogelijk in het Engels zijn gehouden om sneller
terugvinden te vergemakkelijken.
Hoofdstuk 2 omvat een algemene beschrijving van het Care Provision Domain Model.
Hoofdstuk 2 bevat als toevoeging op de Engelse versie ook 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, een aanduiding van de precieze plaats in het D-MIM en de ervan
afgeleide berichten. Waar nodig worden nadere specificaties aangegeven.
In hoofdstuk 3 komen de storyboards aan de orde. Hoofdstuk 4 bevat het R-MIM met
het
verwijsbericht
(REPC_RM002000UV)
en
het
acceptatiebericht
e
(REPC_RM003000UV). In het 5 hoofdstuk wordt de record query toegelicht. Deze kan
worden gebruikt om uit een (extern) dossier gegevens op te vragen. Het 6e hoofdstuk
bevat het care record topic: het ontslagbericht / overdrachtsbericht
(REPC_RM004000UV). Omdat de clinical statement een belangrijk onderdeel vormt en
een complete walk through nodig is, is dat ook in het laatste (7e) hoofstuk integraal
opgenomen.
7
2.
HET CARE PROVISON DOMAIN MESSAGE INFORMATION
MODEL (D-MIM)
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). Dit is nog consistent met de ballot van Mei
2008 vanwege de DSTU status (Draft Standard for Trial Use). 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 domeinniveau de opbouw en inhoud van het Care Provision
D-MIM van HL7 v3 ballot versie september 2006. Dit 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ëntendossiers. 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 (die is in deze figuur overigens de
Care Provision, maar niet expliciet zo aangegeven via een entry point). De associaties
in figuur 1 omvatten de participaties naar Providers (zorgverlener) en Targets of Care
(patient als doel van de zorg) (2), relaties naar de keuzebox (3), de CareStatement (4)
waarin relevante informatie (pertinentInformation) is opgenomen, waaronder de reden
voor zorg. Aan de keuzebox is een RelatedParty (relatie) verbonden om over een
andere persoon dan de patient in kwestie gegevens vast te leggen, bijvoorbeeld
gegevens over de foetus in het dossier van de zwangere.
8
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 wanneer deze voor Nederland relevant zijn. Een eerste topic dat zo
mogelijk wordt opgepakt betreft allergy model.
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), Concern 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
Mapping tabel en zorginformatiemodel / Detailed Clinical Model
Per domein in de zorg, per type verwijzing, moeten de gegevens die een rol spelen
precies op een rijtje worden gezet en uniek gecodeerd (ICD, Snomed CT, procedure of
DBC codes). Vervolgens wordt de plaats van elk gegeven in het HL7 v3 bericht Care
Provision aangeven. In deze domeinspecifieke Domein Basis Dataset worden alle
items uniek gecodeerd.
In de berichten die van het D-MIM Care Provision worden afgeleid is een aantal
generieke en specifieke elementen opgenomen. De generieke elementen zijn in elk
vakdomein gelijk, terwijl de specifieke elementen juist het domein eigene uitmaken.
Deze elementen worden in de implementatiehandleiding op verschillende manieren en
detailniveaus weergegeven. Bijvoorbeeld persoonsgegevens als naam, geslacht en
geboortedatum zullen in alle domeinen relevant zijn. Het gebruik van hulpmiddelen zal
in veel domeinen van toepassing zijn, maar niet altijd.
De ervaring met diverse projecten van NICTIZ, eenheid van taal in de Care sector en
de uitwisseling van gegevens in de WMO pilot leert dat veel gegevens prima in kleine –
herbruikbare – subsets kunnen worden uitgewerkt. Dit zijn de zogenaamde
zorginformatiemodellen (www.zorginformatiemodel.nl). Zorginformatiemodellen (soms
tot ZIM afgekort) worden gebruikt om de ontwikkeling van elektronische dossiers en
elektronische berichten te ondersteunen. Ze zijn specifiek gericht op toepassing binnen
de HL7 v3 berichtenset Care Provision, maar ook bruikbaar in andere HL7 v3
berichten.
Internationaal wordt inmiddels over Detailed Clinical Model gesproken. Hierin worden
de vakkennis, dataset, terminologie en coderingen in detail uitgwerkt voor een klein
onderwerp en wordt een model gemaakt dat het toepassen in meerdere standaarden
mogelijk maakt.
9
2.4
Mapping tabel
Relatie tussen implementatiehandleiding, zorginformatiemodel en de mapping tabel
De mappingtabel voor voor een domein is een belangrijke bijlage bij deze
implementatiehandleiding. In de mapping tabel zijn de voor de overdracht gebruikte
data-elementen opgenomen. Daarna zijn ze van aanvullende informatie voorzien en
gemapt naar het CP bericht. Hierbij zijn gegevens gespecificeerd om technisch
implementeerbaar te worden. Dit technisch specificeren van de gegevens in de
mapping tabel betreft vooral het opnemen van een unieke code voor elk gegeven, de
mapping naar de juiste HL7 klasse in de berichtenstructuren, het benoemen van
datatypes, het specificeren van de waarden en/of vocabulaires (antwoordcategorieën)
en de cardinaliteiten (aantal keren dat een gegeven voor mag of moet komen).
Verder zijn in de mapping tabel de te volgen route in het berichtenmodel aangegeven,
bijvoorbeeld “Care Statement naar Observatie”. Hiermee wordt aangegeven op welke
manier de gegevens moeten worden gerepresenteerd in het berichtenmodel.
Vervolgens kunnen deze gegevens ook feitelijk in een HL7 v3 XML bericht worden
opgenomen.
De generieke elementen zijn voor elk type bericht de volgende:

Als eerste betreft dit de naam en demografische gegevens en adres en
woonplaats gegevens van de patiënt. Deze gegevens worden opgenomen en
doorgegeven in de CMETs E_Person (vaste gegevens) en R_Patient
(wijzigende gegevens).

Een tweede groep generieke elementen betreft de NAW gegevens van de
zorgverleners via de CMET R_AssignedPerson. Daar komen ook de NAW
gegevens van dienstverlenende organisaties en instellingen, personen terecht.

Verder wordt de aanleiding en het doel van het bericht aangegeven,
bijvoorbeeld een consultatie of een overdracht begeleidt door aanvullende
gegevens die voor de ontvanger als belangrijk worden beschouwd. Verder zijn
er retourberichten, simpelweg als bevestiging van de vraag of het verzoek of als
uitgebreid terugrapportage met alle bevindingen en het verzoek van
terugovername. Deze gegevens zijn onderdeel van de Care Provision Act en
daarbinnen worden ze opgenomen in de Care Statement keuzebox.
De kracht van het CP bericht is dat deze variabele hoeveelheid gegevens en de
variabele inhoud van gegevens via de unieke coderingen van elk element kunnen
worden opgenomen en doorgegeven.
De mapping tabel, die hieronder is samengevat, geeft voorbeelden van zowel
generieke als specifieke informatie weer die voor de gegevensuitwisseling in de
zorgketen nodig is. Deze gegevens van de persoon zijn hiërarchisch geordend en
worden met hoofdrubrieken geklasseerd.
In de samenvatting hieronder zijn de hoofdrubrieken, subrubrieken en elementen uit de
mappingtabel opgenomen. Details zijn niet toegevoegd.
10
2.5
Voorbeeld hoofdrubrieken mapping tabel
Hieronder volgt de samenvattende mapping tabel.
Rubriek/Sectie/
Representatie in D-MIM
1. Basisgegevens
Target & Provider Participatie
Demografische Gegevens patiënt
CMET R_Patient
Identificatie, naam en demografie, adres,
CMET R_Patient
woonplaats, telefoon
Gegevens zorgverleners
CMET R_AssignedProvider
2. Zorginhoudelijke gegevens
Care Provision en aanhangende structuren zoals
Care Statement.
Overzicht anamnese
Organiser in Care Statement
Gegevens uit voorgeschiedenis
Organiser in Care Statement
Ziekten
Observatie in Care Statement
behandeling
Procedure in Care Statement
Familieanamnese
Organiser in Care Statement
Ziekten familielid 1
Observatie in Care Statement
Risico factoren
Organiser in Care Statement
Allergie voor jodium
Observatie in Care Statement
Medische gegevens
Organiser in Care Statement
Bloedverlies
Organiser in Care Statement
Bloeddruk
Organiser in Care Statement
Diastolische bloedruk
Observatie in Care Statement
Brochure over ziekte
Supply in Care Statement
Sociale gegevens
Organiser in Care Statement
Gegevens gezin
Organiser in Care Statement
Thuisfront
Observatie in Care Statement
Klinimetrische gegevens
Organiser in Care Statement
Schalen
Organiser in Care Statement
Pijnschaal
Observatie in Care Statement
Decubitus schaal
Observatie in Care Statement
Gegevens over de eerder verleende zorg
Act List
11
Overzicht zorghistorie
Act List  Encounters uit Care Statements
Huidige medicatie
Act List
Act List 
administration
overzicht huidige medicatie
Care
Statements
Substance
Diagnostiek / Conclusie
Een vraagstelling waarom wordt opgenomen /
Organiser in Care Statement
doorverwezen / overgedragen
Omschrijving vraag patiënt
Observatie in Care Statement
Behandelplan
Care Plan
Behandelplan
Care Plan
Behandeling van hypertensie
Procedure in Care Statement
Werklijst
Act List
Rapportage
Care statement
Rapportages
Care statement
Rapportage opmerking op datum / tijd
Observatie in Care Statement
Tabel. Uittreksel uit de mapping tabel met de hoofdrubrieken en de relatie ervan met
de onderdelen van het Care Provision (CP) model, zoals bijvoorbeeld de Care
Statements, Care Plan en rubrieken geordend via Organiser klasse. Groen is een
hoofdrubriek. Blauw is een rubriek. Geel is een item of onderdeel. Geel correspondeert
met een groep bijeen horende gegevens in een werkblad of een zorginformatiemodel.
2.6
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
(de behandelingsovereenkomst) tussen patiënten en zorgverleners. In Nederland wordt
dit via de WGBO geregeld (Wet Geneeskundige Behandelings-Overeenkomst). 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 contact 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
12
zorg te verbreden naar zorgverlening 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.
ZORG, SUPERVISIE, MANAGEMENT: verantwoordelijkeheid voor zorg veiligheid en
welbevinden
Provision (2a)
The act or process of providing (the ... of a play area for the children).
De activiteit zorgverlening
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 19612002.
Het voorzien in wat nodig is voor
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’ het zelfstandig naamwoord is van de onbepaalde wijs ‘to
provide care (zorgvelenen)’.Daarom is de ‘Act Care Provision’ het vastleggen van een
proces dat de verantwoordelijkheid van het leveren van zorg omvat. Het is een
bewering 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 primair 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 wezen 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 ook richten op een medische apparaat, het huis van
de patiënt of andere niet-levende voorwerpen. 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 ‘Concern Tracking’ en met ‘Care
Plan’, structuren die opgenomen zijn in de Care Structures. De volgende voorbeelden
13
illustreren de mogelijkheden van het Care Provision D-MIM: 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 (uitvoerder) 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.
14
2.7
Care Provision D-MIM Walk-through
2.7.1 CareProvision Focal Class3
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.7.2
CareProvision 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 D-MIM 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 of verwijzing is een vraag aan een andere zorgverlener
met betrekking tot de 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 kan ook worden gebruikt voor zelfverwijzing
door patiënten. Een verwijzende verantwoordelijke partij, zoals een regering of
rechtbank, kan 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
3
Care Provision Focal Class is de Care Provision: de centrale Act.
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 v3. 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 een
nog voortdurende service zijn of een documentatie van een service uit het verleden.
Een Care Provision in Event mood beschrijft (een deel van) de periode waarin een
zorgverlener aaneengesloten verantwoordelijk is (geweest) voor de zorg, inclusief alle
relevante toestanden en gebeurtenissen uit die periode. 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. Er kunnen ook meerdere auteurs zijn. Care Provision in
Event mood 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 en alle
activiteiten te beschrijven die gedurende het verlening van zorg hebben
plaatsgevonden. In dit geval is de uitvoerder de zendende partij.
definition mood
Definition mood kan gebruikt worden om een richtlijn of protocol uit te drukken.
Een voorbeeld van een definition is een specificatie van een bepaalde observatie,
bijvoorbeeld het meten van de lichaamslengte. De klasse lichaamslengte geeft dan aan
hoe gemeten moet worden, in welke eenheid de waarde moet worden vastgelegd met
welk datatype en welke code uit welk codestelsel moet worden gebruikt. De definition
mood staat het toe om alle gegevens die uitgewisseld worden te specificeren zoals ze
in een bericht moeten worden opgenomen.
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.
Bij lichaamgewicht kan bijvoorbeeld een streefgewicht voor over 4 weken worden
gedefinieerd.
intention mood
intention mood
De Care Provision in 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.
17
Bijvoorbeeld: in een zorgplan wordt opgenomen dat bij een diabeet de HbA1c waarde
over 3 weken weer bepaald wordt. (In de definition mode staat dan dat het een
labbepaling betreft met een bepaalde LOINC code en in een bepaalde unit moet
worden uitgedrukt).
proposal
De Proposal mood 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.
id:
Dit attribuut identificeert een bepaalde Care Provision. Identifier moet worden gebruikt
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 zijn van het datatype instantiatie indenfiers (SET<II>) en
hebben over het algemeen 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 bijvoorbeeld 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 te identificeren en terug te vinden voor bijvoorbeeld voorgaande
condities of gerelateerde condities en dergelijke.
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 CWE4 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: JCAHO5; staten geven
vergunningen aan ziekenhuizen, verpleeghuizen en thuiszorgorganisaties; medisch en
verpleegkundige specialismen commissies; etc.
4
CWE staat voor Code with Extensions: er mogen zelf codes worden toegevoegd aan een standaard lijst
JCAHO staat voor Joint Commission on Accreditation of Healthcare Organizations. De Joint
Commission, tot 2007 de Joint Commission on Accreditation of Healthcare Organizations (JCAHO,), is een
non-profit organisatie, USA gebaseerd, opgericht in 1951, met de volgende missie: het behouden, en
verhogen van de standaarden voor de zorgverlening door evaluatie en accreditatie van
gezondheidszorgorganisaties.
Bezocht
20
november
2007.
(http://en.wikipedia.org/wiki/Joint_Commission_on_Accreditation_of_Healthcare_Organizations.
5
18
Voor Nederland kan dit bijvoorbeeld worden gebruikt door aan te geven of een
ziekenhuis of zorginstelling erkend is, of dat een verantwoordelijk zorgverlener
gecertificeerd is. Deze code moet niet geïnterpreteerd worden als een code voor een
context of een code voor een afspraak, maar moet consistent zijn met uitgegeven
vergunningen of accreditaties van een deelnemende (zorg)verlener. 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.
derivationExpr:.
Het derivation expression attribuut biedt de mogelijkheid een afleiding op te nemen van
de manier waarop een gegeven tot stant komt. Technisch gezien: het staat een string
expressie toe waarin de afleiding van een gegeven wordt aangegeven en wordt
ondersteund 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).
negationInd:
Er zijn twee antwoordmogelijkheden voor de negation indicator: true, false. True
betekent zorg is geleverd, false betekent er is geen zorg is 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.
19
title:
Care Provision kan één titel krijgen in vrije tekst.
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.
statusCode:
Het statusCode attribuut wordt gebruikt om de huidige status van de Care Provision
klasse aan te geven. Het statusCode attribuut correspondeert met de mogelijke
statussen 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 was (acties konden
uitgevoerd worden of zijn uitgevoerd), maar tijdelijk is
suspended
uitgeschakeld. Er moet hier geen verdere actie ondernomen
worden totdat het weer wordt voortgezet.
completed
Een care provision
die normaal geëindigd is nadat al
zijnonderdelen zijn uitgevoerd.
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 bewaard voor doeleinden m.b.t. de account.
De afhandeling van de status wordt in de implementatiehandleiding bij de verschillende
R-MIM’s expliciet gemaakt. Dan is het gekoppeld aan de feitelijke toepassing van een
specifiek bericht.
effectiveTime:
Het effectiveTime attribuut vertegenwoordigt het tijdsinterval waarvoor de zorgverlening
is of wordt geleverd. Voor bijvoorbeeld intent zorgverleningen zal, waar van
toepassing, de voorgestelde start en eind tijd/datum zijn, terwijl voor zorgverlening in
event mood de tijd de daadwerkelijke start en eind datum/tijd zal zijn. Voor een meer
algemene beschrijving van effectiveTime wordt u verwezen naar het RIM).
priorityCode:
20
Het priorityCode attribuut wordt gebruikt om de urgentie aan te geven weermee moet
worden gereageerd op een verzoek of Act.Het gebruik van dit attribuut heeft een
potentiele overlap met enkele vocabulaires. De priorityCode kan dan iets aangeven dat
door de vocabulaire wordt ontkent.
Deze potentiele conflicten worden als volgt opgelost:
* De priorityCode zou alleen gebruikt moeten worden om de urgentie waarmee de
cummuncatie-ontvanger zou moeten reageren op de informatie in de Act aan te
duiden. Bijvoorbeeld : het verzoek voor een procedure 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.
‘Om de klinische urgentie uit te drukken, moet men gebruik maken van de
mogelijkheden in Act.code’. Bijvoorbeeld: het concept ‘een spoed verwijdering van de
blinde darm’ zou in z’n geheel uitgedrukt moeten worden binnen een Act.code.
Hiervoor kan dan b.v. met SNOMED CT een precoordinatie plaatsvinden van de drie
concepten ‘blinde darm’, ‘chirurgische verwijdering’ en ‘spoed’.
Code
Definitie
S (stat)
With highest priority (met de hoogst prioriteit) (dus spoed).
A (ASAP)
As soon as possible (zo spoedig mogelijk), de hoogste prioriteit
na stat.
R
(routine)
Routine service, doen in normale werktijd.
confidentiality.Code Het ConfidentialityCode attribuut
Code
Definitie
Een waardenset die toegang tot informatie toe
staat door op rol en relatie gebaseerde rechten.
ConfidentialityByAccessKind (Deze concepten sluiten elkaar uit, één en
slechts één is vereist voor een valide
vertrouwelijke codering).
ConfidentialityModifiers
Wijzigende factoren van op rollen gebaseerde
toegangsrechten (veelvoud toegestaan).
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) gelinkt aan een Observation waarin de reden kan worden
verwoord.
Code
Definitie
PAT (patient request)
De patiënt heeft
aangevraagd.
21
de
zorgverlening
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 valse
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
D-MIM 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 of alleen binnen een specifieke zorgfaciliteit. De relatie is
meestal solide in de tijd en wordt alleen voor administratieve doeleinden vastgelegd;
de daadwerkelijke zorg die door deze zorgverlener geleverd wordt, wordt met
behulp van een aparte Care Provision 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 worden
verwacht .
De attributen van CareProvision, de codering, waarden, cardinaliteiten en korte
beschrijving zijn in onderstaande tabel samengevat.
2.7.3
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:
22
 participaties
naar
Provider
keuzebox
(author,
performer,
primaryInformationRecipient);
 participaties naar Target keuzebox (subject, recordTarget);
 participaties naar R_AssignedPerson CMET (author, performer, verifier,
dataEnterer);
 recursieve relatie via “ ActRelatie” voor "SequelTo", waarin een eerdere of latere
zorgverleningsrelatie vastgesteld kan worden. (sequel to);
 recursieve relatie via “Has Component” ActRelationship (component 3);
 recursieve
relatie
via
“Has
Pertinent
Information”
ActRelationship
(pertinentInformation3);
 de "Refers To" ActRelationship naar huidige Encounter (reference);
 de Care Provision "Has Reason" ActRelationship naar Concerns (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 verantwoordelijke zorgverlener?
 voor wat of wie is de zorgverlener 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 Concern tracking structuur) toegevoegd aan dat wat binnen de
verantwoordelijkheid valt van de zorgverlener?;
 wat voor Care Plan activiteiten worden toegevoegd aan dat wat binnen de
verantwoordelijkheid valt van de zorgverlener?;
 wat voor Observaties en “ Acts” zijn uitgevoerd in deze zorgverlening of in eerdere
zorgverleningen?
De associaties worden hieronder beschreven.
Algemene Associatie Attributen
contextControlCode:
De “ contextControlCode specificeert hoe participanten bijdragen aan de context van
een Act en of de context geleid kan worden naar gerelateerde “ child “ (kind) acts.
Het attribuut is een tweeletterige code die het leidende gedrag specificeert:
'AN'– gerelateerd aan context en niet gerelateerd aan een “ child” Act
'AP' - gerelateerd aan context en mogelijk gerelateerd aan een of meerdere “ child”
Act(s)
23
‘ON'- elke associatie van hetzelfde of meer specifieke type die geleid wordt van de
“parent” (ouder of hoger in hierarchie) wordt vervangen door deze associatie
die niet gerelateerd is aan een “child” (kind, of lager in hierarchie) Act. (met
andere woorden: de relatie tussen een hoofdact en subact).
'OP'- elke associatie 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 die in het dossier van de moeder worden vastgelegd. Er kan maar
één doel van vastlegging zijn voor een Care Provision. De “target” (doel) entiteit
informatie wordt vastgelegd binnen de R_Patient 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.
Nota bene: voor domein specifieke uitwerkingen in Nederland wordt verwezen naar de
aanvullingen op deze implementatiegids die voor dat domein wordt uitgewerkt.
Attributen
typeCode: De type code is RCT (record target).
contextControlCode: Zie bovenstaande beschrijving in “Common Participation”
(Algemene associatie) attributen. De default waarde is "OP" (overriding, propagating).
subject:
De subject is het hoofddoel van de zorgverlening wanneer de subject niet het record
target is, bijvoorbeeld de patiënt tijdens het lichamelijk onderzoek, een monster in een
laboratorium. Het kan ook een familielid van de patiënt zijn (bijvoorbeeld bij
voorlichting) of een apparaat of kamer (schoonmaken, desinfecteren, huishouden). De
subject informatie wordt vastgelegd binnen de R_Patient CMET of een “ Maintained
Entity” 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
Degene 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).
24
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.
code
Beschrijving
The author intends to provide a signature.
I
(intended)
S
(signed)
X
(required)
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.
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.
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”.
tijd: Het tijdstip waarop de “ dataEnterer” de documentatie in relatie tot de “ Care
Provision Act” getekend of gecomplementeerd heeft.
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.
25
signatureCode: De code die specificeert of de “ dataEnterer” de Care Provision Act
officieel 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.
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 data entry persoon, de care provision act
goedkeurend.
Verifier (validator)
De supervisor die de aanvraag voor “ Care Provision” (zorgverlening) verifieert
(validator), 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 juistheid? 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.Een
voorbeeld is een arts ide de patient ziet, notities dicteert, deze later van een
handtekening voorziet. De handtekening is een wettelijke authenticatie.
contextControlCode: Zie de beschrijving die hierboven gegeven is in de Algemene
Participatie attributen. De default waarde is “OP”.
noteText: Commentaar inzake validatorparticipatie.
26
time: Tijdstip waarop de validator de “ Care Provision Act” getekend of geaccepteerd
heeft.
modeCode: Specificeert hoe de validator heeft geaccepteerd, bijvoorbeeld mondeling,
elektronisch of schriftelijk. Gebruik elke waarde van de ParticipationModeWritten,
ParticipationModeVerbal or ParticipationModeElectronicData.
signatureCode: Code die specificeert of de validator de Care Provision Act officieel
goedgekeurd heeft of dat goedkeuring hiervoor vereist is.
code
I
(intended)
S
(signed)
X
(required)
Beschrijving
The author intends to provide a signature.
De auteur heeft de intentie om te voorzien van een handtekening.
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 validator, die 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 breed spectrum van zorgverleners (providers) . In
een voorbeeld uit de patiëntenzorg kan zorg geleverd 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 de zorg. In een niet-patiëntenzorg 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 verzoekt en de ‘performer’ degene die de verantwoordelijkheid
voor zorg zal nemen.
Attributen
typeCode: waarde uit onderstaande lijst uit “ ParticipationPhysicalPerfomrer” domein.
code
PRF
(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.
27
PPRF
(primary
performer)
SPRF
(secondary
performer)
Degene die feitelijk de zorg verleent. Dit hoeft niet de hoofdbehandelaar te zij,
maar bijvoorbeeld een assistent chirurg die opereert onder supervisie van een
hoofdchirurg,
The principal or primary performer of the care provision.
De hoofdbehandelaar van de “Care Provision”.
A person assisting in care provision through his substantial presence and
involvement.
Degene die assisteert bij het uitvoeren van de “Care Provision”
substantiele aanwezigheiden betrokkenheid.
door
functionCode: Een optionele code die aanvullende details specificeert over de functie
die de “ performer” heeft in de zorgverlening, bijvoorbeeld de huisarts, hoofd chirurg,
asisterende chirurg, anesthesist, verpleegkundige, waarnemende arts.
contextControlCode:
Attributen’.
Zie
beschrijving
hierboven
onder
‘Algemene
participatie
tijd: Begin- en eindtijd van verantwoordelijkheid van “performer” voor de zorg aan een
subject.
modeCode: Specificeert hoe de “performer” de zorg heeft verleend, en omvat meer
dan alleen de communicatie. 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 door 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 door directe actie waarbij subject en actorop verschillende
locaties en waarbij de acties van de actor via electronische of mechanische
wijze verstuurd worden.
PrimaryInformationRecipient
De toekomstige partij die het verzoek voor zorgoverdrachten of bevestigingen zal
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. Zij hoeven niet te handelen naar aanleiding van dit
verzoek. Een andere mogelijkheid is dat de toekomstige ontvanger van een
bevestiging van zorgoverdracht (promise) meestal de auteur van een corresponderend
verzoek is maar ook een ‘copy to’ ontvanger kan zijn. De toekomstige ontvanger kan
een toegewezen persoon of organisatie zijn (R_AssignedParty), zoals een
zorgverlener, een gerelateerde partij (R_RelatedParty), bijvoorbeelde een familielid of
rechter, of de patiënt zelf (R_Patient).
Attributen
typeCode: De type code is PRCP (primary information recipient).
28
contextControlCode: Zie de beschrijving die hierboven gegeven is in de Algemene
Participatie attributen. De default waarde is “OP”.
In dit domein gaat de in een bericht verstuurde pertinente informatie van patiënten
variëren, afhankelijk van de behoeften van de patiënt en de behoeften van de
zorgverleners. Dienovereenkomstig 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.
Dit zijn R-MIMs of soms CMETs. Dit laatste wordt in de diverse projecten
geoperationaliseerd
door
zogenaamde
zorginformatiemodellen,
zie
www.zorginformatiemodel.nl. Inmiddels wordt internationaal ook de term Detailed
Clinical Models (DCM) gebruikt. Het gaat om gestandaardiseerde specificaties van
klinische gegevens die naar keuze in de Care Statement kunnen worden opgenomen.
In een DCM zijn de kennis, classificaties en codering en modellering en technische
specificatie geïntegreerd.
Algemene ActRelationship Attributen
De volgende “ActRelationship” attributen worden meestal gebruikt in “Act
Relationships” die gerelateerd zijn aan de focale “CareProvision Act” en andere
gerelateerde 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 gemarkeerd is als ‘propagating’,
naar de gerelateerde “child act” geleid. Het alternatief is dat wanneer deze op ‘false’
gezet er geen context geleid wordt naar de gerelateerde “child act”.
contextControlCode: Specificeert hoe een “child act” bijdraagt aan de context van de
“parent act”. Als context 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 wordt alleen toegevoegd aan de context van deze act en word
niet geleid door een “child act”.
'AP' : de associatie wordt toegevoegd aan context van deze act en kan geleid worden
door een “child act”
‘ON': elke associatievan hetzelfde of meer specifieke type die geleid worden van de
“parent” wordt vervangen door deze associatie en deze associatie wordt niet
geleid door elke “child act”.
'OP': elke associatie van hetzelfde of meer specifieke type worden van de parent
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.
29
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 “Care Provision
Acts aan. Bijvoorbeeld: voor preventieve zorg tijdens een derde zwangerschap zou het
relevant kunnen zijn om 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” waarvan de “Event”
de invulling is; of een vervangende “Care Provision Event” die een voorgaande
beschrijving van het “Event” corrigeert.
Attributen
typeCode: de type code is een subset van de waarden uit het “ActRelationshipSequel”
domein (zie tabel 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
ProvisionAct” 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”. De bron dient in de “mood equal” of ????? Bron moet in een
mood gelijk zijn aan het doel of in een meer actuele mood.???
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 “Care Provision 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.
30
ContextControlCode: Zie beschrijving in Common ActRelationship attributen.
ContextConductionInd: Zie beschrijving in Common ActRelationship attributen.
Component 3
De component3 relatie heeft “CareProvision” als bron en heeft een andere “Care
Provision” 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 behandeling van
een allergie voor antibiotica, als 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 zijn: operatiegeschiedenis
uit het verleden, een familie geschiedenis profiel, historische lijst van vrijgestelde
medicatie.
Attributen
typeCode: De type code is de waarde afgeleid van de volgende subset van het
ActRelationshipPertains domein (zie tabel hieronder).
code
PERT
(has
pertinent
information)
SAS (starts
after start of)
PREV
(has
previous
instance)
SUMM
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
31
(summarized
by)
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 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 gerelateerde richtlijnen; wat is voorgesteld, wat is besteld of
gepland, wat was afgerond en wat moet nog afgerond worden.
 beweringen over de condities 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 Concerns 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).
32
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 gerelateerde “Care Provision 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” pertinent toe die expliciet ddel
uit maken 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.
.
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 pertinent” die niet direct gerelateerd zijn 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).
33
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
beweringen mogelijk die aanvullende 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 klinische bewering 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.7.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” omvat.
Andere pertinente klinische informatie is te vinden in het “Care Structures topic”. Een
lijst van onderwerpen die bedoeld zijn voor het “Care Provision Domein” omvat:
 “Care Structures topic” . Dit onderwerp omvat CMET’s 6 voor het “Care Provision
Domein”. Specifieke “Care Provision” structuren omvatten de “Concern Tracking”
structuur, de “Care Plans/Guidelines” structuur en andere specifieke structuren. De
“ Care Statement” structuur, welke een bewerkte versie is van het “Clinical
Statement Patroon” , is onderdeel van deze sectie;
6
CMET’s: Common Message Elements Types
34
 “Care Record topic” . Dit onderwerp bevat de samenvatting en uittreksels van




notities uit het dossier 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 opvragingen over de feitelijk verstrekte zorg tijdens de zorg
aan een subject onder de verantwoordelijkheid van een zorgverlener;
“Care Transfer topic”. Dit onderwerp bevat de onderhandelingsberichten in de
zakelijke cyclus van verzoeken en acceptaties 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.
35
2.8
Care Statement Structuur Overzicht (januari 2007)
2.8.1 Bereik van de Care Statement Structuur Domein
Het “Care Structures topic” definieert de vele UML klasse diagrammen, de zgn. “Care
Structures”, die de informatie pertinent aan de voortdurende zorgverlening modelleren.
Deze worden beschreven als lokale “CMET’s” die lokaal zijn voor het “Care Provision”
Domein. Deze lokale “CMET’s” zullen worden opgenomen in de groep van gedeelde HL7
“CMET’s” als deze lokale “CMET’s” de ballot passeren op domein niveau. Deze “CMET’s”
of bouwstenen binnen het “Care Provision” Domein representeren herbruikbare objecten in
grote modeldiagrammen.
In vele gevallen, handhaven deze structuren de basis van de verantwoordelijkheid voor
zorg door het aangeven van de “concerns” en zorgplannen als componenten van de
verantwoordelijkheden gekoppeld aan de scope (als bereik of aandachtsgebied). De Care
Structures vertegenwoordigen de variabele delen van een communicatie met betrekking tot
de verantwoordelijkheid voor de “Care Provision”. Zoals beschreven in de scope van het
“Care Provision” Domein, wordt deze zorg geleverd aan individuen, populaties en andere
doelen van zorg en communicatie. Deze informatie is ontworpen om de samenwerking
tussen zorgverleners te ondersteunen. Dit “Care Structures” topic bestaat onder het “Care
Provision” Domein. Voor een volledige beschrijving van het domein en een discussie van
de verantwoordelijkheid van zorg wordt verwezen naar het “Care Provision Domein”
Overzicht.
Type informatie die gemodelleerd wordt in de Care Structures:
 “basic Care Statements”, i.e. ruwe data met minimale samenvatting of interpretatie
(bijv. gewicht, lengte, bloeddruk);
 informatie in een samenvating gecreëerd in lijsten (bijv. lijsten van medicatie, operaties);
 “judgment-related Care Statements” (bijv. lijsten van problemen, allergieën,
diagnostische schalen zoals depressieschaal, Barthel index voor activiteiten voor het
dagelijks leven of valrisico voor patiënten);
 zorgplannen en hun gerelateerde richlijndefinities (wat is gedaan, wat moet nog, wie is
verantwoordelijk );
 beweringen over toestand van verzorgers van de patiënt (bijv. familieleden).
Natuurlijk zal de pertinente informatie die wordt bijgesloten in een individuele
communicatie variëren afhankelijk van de behoefte van de patiënt en de behoeften van de
samenwerkende zorgverleners. Door “Care Structures” toe te voegen aan run-time
berichten kunnen de berichten worden uitgebreid als dat nodig is.
Het “Care Structures topic” refereert aan het domein “Clinical Statement” Patroon (waarvan
de beschrijving is opgenomen in een apart document) en begeleidt lezers hoe specifieke
Clinical Statement kwesties te ballotten. Alleen “Care Provision” aanpassingen van het
“Clinical Statement” Patroon zullen worden geballot in de “Care Structure topic”. Specifieke
“Care Structures” bevatten de “Concern Tracking” Structuur, de “Care Plans/Guidelines”
Structuur, en “Assessment" structuren, alsmede de meest belangrijke zorgstructuur, de
“Care Provision” Domein versie van de “Clinical Statement” keuzebox waar naar verwezen
wordt in dit topic als de “Care Statement Structure”.
36
2.5.2 Grenzen van het bereik
“Care Structuren” zijn niet bedoeld om alle informatie te representeren die
gecommuniceerd wordt door systemen die gedetailleerde pertinente informatie
voortbrengen, zoals observatiegegevens of persoonsregistratiegegevens. Domeinen die
de communicatie ondersteunen van deze data genererende systemen, voorzien vaak in
veel meer details, gezien de complexe data context waarin de data worden gegenereerd.
De bedoeling van “Care Structuren” is de ”instance identifiers” te communiceren en de
meta data voor deze kleine instantiaties, zodanig dat het ontvangende systeem genoeg
informatie heeft om queries te verzenden voor meer details over bepaalde items van
pertinente informatie. Daarbij wordt aangenomen dat de verzendende systemen queries en
instance identifiers ondersteunen. Echter, andere implementatie specificaties kunnen deze
scope op “Information Content” uitbreiden om meer detail te vereisen in de originele
communicatie en minder afhankelijk te zijn van queries en respons methodologie.
Deze “Care Structures” kunnen verder beperkt worden voor gebruik in andere “Care
Provision” Domein topics en/of implementatiehandleidingen van verschillende commissies
en organisaties buiten HL7. Het is NIET de bedoeling dat dit “Care Provision” topic alle
mogelijke beperkingen op deze meer algemene “Care Structures” beschrijft. Binnen de
templates werkgroep wordt gezocht naar eenduidige structuren die wel de details en
beperkingen specificeren en binnen de ”Care Statement” structuur passen en kunnen
leiden tot nadere detaillering in berichten.
2.5.3 Plaatsing van Care Structuren in het Care Provision Domein Model:
De structuren rechts van de “Care Proivision Act” worden hieronder beschreven:
samenvatting van de “Care Structuren of Care Structures”
De “Care Structures topic” is bedoeld als een bibliotheek van herbruikbare en te
vervangen “care structures” of Detailed Clinical Models uit de “Care Provision D-MIM” die
opnieuw te gebruiken zijn. Op dit moment levert de topic alleen de kern structuren waarvan
specifieke “care structures ”, zoals bloeddruk en allergieen, kunnen worden afgeleid.
Sommige van deze specifieke “care structures” worden geleverd als informatieve
voorbeelden:
Normatieve Care Structuren:
 “Care Statement”;
 “Composition Content”;
 “Statement Collector”;
 “Concern Tracking Structure”;
 “Care Provider”;
 “Care Target”;
 “Involved Person”;
Informatieve “Care Structures” zijn vooralsnog opgenomen als zorginformatiemodellen:
 Blood Pressure (Bloeddruk);
 Heart Rate (Hartslag);
 Weight (Gewicht);
 Height (Lengte);
 Allergy (Allergie);
 Barthel Index.
37
local CMET's
De “Care Structuren” in deze sectie zijn locale “CMET’s” (lokaal voor het Care Provision
Domein). Een “Care Structuur CMET” gebruikt de “Common Message Element Type”
benadering om herbruikbare structuren weer te geven en te gebruiken in het “Care
Provision” Domein, welke afgeleid zijn van zijn “D-MIM”. De “CMET” wordt gebruikt om
deze complexe “care structuren” te representeren die worden gebruikt in meerdere
“RMIM’s”. Dit vereenvoudigt de “R-MIM” dramatisch wat toestaat dat de focus nu op de
focale klasse en de associatie ligt, terwijl de vervanging van de beperkte “CMET”
ondersteund wordt voor een universele “CMET”, of bij het ontwerp van het bericht ,
implementatie of ontwikkeltijd.
Het “Care Plan” (zorgplan), de “Involved Person” (betrokken persoon), de “Care Taker”
(zorgverlener) en “Care Target” (doel van zorg) structuren hebben op dit moment geen
verder beperkte modellen maar worden nu geleverd als een “Care Structuur” die steeds
opnieuw gebruikt kan worden.
Een belangrijk concept in dit topic is de hiërarchie van “Constraints”van de abstracte
structuren in het “Care Provision D-MIM”. De “Care Statement” structuur is beperkt tot het
definiëren van de “Concern Tracking” Structuur. De “Composition Content” structuur is ook
een beperking op de “Care Statement” . Elke van deze beperkingen kan vervangen
worden door de “Care Statement” die wordt geassocieerd met het “Care Plan” en de
“Statement Collector” structuren, en de “Care Provision Act”.
clinical Statement Pattern
Zoals hierboven vermeld, focust de ballot voor dit document op de uitbreidingen en
beperkingen die het “Care Provision Domein” heeft opgelegd aan het “Clinical Statement
Patroon”. Deze uitbreidingen of beperkingen zullen duidelijk geïdentificeerd worden in de
bespreking van elke “care structure”. Ballot kwesties gerelateerd aan het “Clinical
Statement Patroon” zelf zouden verwezen moeten worden naar de “Clinical Statement
Pattern” ballot. Ter vergelijking wordt de “Clinical Statement Definitie” vergeleken met de
“Care Statement Definitie”.
definitie Clinical Statement
De formele definitie van een “clinical statement” voor patiëntenzorg is:
“An expression of a discrete item of clinical (or clinically related) information that is
recorded because of its relevance to the care of a patient."
“Een uitdrukking van een afzonderlijk item van klinische (of klinisch gerelateerde)
informatie dat wordt vastgelegd, omdat het relevant is voor de zorg van een patiënt”.
Klinische informatie bestaat altijd uit stukjes informatie en daarom kan de informatie per
bewering qua hoeveelheid en betekenis van informatie erg variëren.
Klinische informatie vereist dat de informatie wordt geassocieerd met een patiënt waarbij
duidelijk wordt:
 zijn tijdelijke context;
 zijn relatie met de patiënt;
 in geval van een observatie: zijn moodcode en de aanwezigheid of afwezigheid ervan of
een waarde,
 in geval van een procedure: zijn moodcode en de status.
38
Deze duidelijkheid kan worden verkregen door:
 expliciete representatie of;
 impliciet gebruik van defaults ALLEEN als expliciet regels zijn gemodelleerd die de
geschikte defaultwaarde vaststellen.
Het “Clinical Statement Patroon” is een veralgemeniseerd HL7 abstractie patroon dat
gebruikt wordt in meer HL7 domein “message information models” die basisdata leveren
over het doel van zorg. Dit HL7 patroon kan worden beperkt, uitgebreid, of ongewijzigd
gelaten worden door HL7 Technische commissies die dit patroon gebruiken om een
domein te definiëren.
care Statement Structure (REPC RM00100)
Als men kijkt naar het “Clinical Statement Patroon” dan ziet men dat er geen grote
verschillen zijn tussen dat patroon en de “Care Statement Structure” die in hoofdstuk 7 is
uitgewerkt. hieronder.
uitbreidingen op het Clinical Statement Patroon Domein
Het “Clinical Statement Patroon” is hernoemd en heet nu “Care Statement Structuur” in dit
“Care Structure topic” om te benadrukken dat zorg zowel betrekking heeft op medische
hulpmiddelen, diensten en omgeving/plaatsen als ook op patiënten/ cliënten. In die zin is
het vocabulair dat wordt gebruikt om de “Care Statements” te ondersteunen meer
uitgebreid dan het vocabulair dat slechts gebruikt wordt om de zorg aan patiënten te
ondersteunen. Deze uitbreidingen zullen gedocumenteerd worden door een geleidelijke
toename in het aantal en de variëteit van HL7 vocabulair waardensets.
De intentie is dat een instantiatie van een “care statement” door zichzelf kan worden
toegevoegd aan de “Care Provision Act” bij het maken van een “R-MIM” of bij “run-time”
uitvoering van een applicatie om de variabilitiet van mate en detail te kunnen ondersteunen
welke beschreven wordt in de bovenstaande “clinical statement definitie”. Natuurlijk kan de
“care statement”toegevoegd worden aan de “Care Provision Act” samen met het
toevoegen van andere structuren van het “Care Provision” Domein.
De uitbreiding van de “Clinical Statement” naar “Care Statement” verbreedt de definitie van
“Care Statement” naar:
“Een uitdrukking van een afzonderlijk item van zorggerelateerde informatie welke wordt
vastgelegd, omdat het relevant is voor de zorg van een patiënt / cliënt. Zorginformatie
bestaat altijd uit stukjes informatie en daarom kan de informatie per “statement” qua
hoeveelheid en betekenis van informatie variëren”.
Om als “Care Statement” te worden beschouwd, moet een concept worden geassocieerd
met een “target of care” waaruit blijkt:
 zijn tijdelijke context;
 zijn relatie met “ target of care” ;
 in geval van een observatie: zijn moodcode en aanwezigheid, afwezigheid of waarde;
 in geval van een procedure: zijn mood en de status.
Duidelijkheid kan worden verkregen door:
 expliciete representatie of;
 impliciet gebruik van defaults ALLEEN daar waar expliciet gemodelleerde regels de
geschikte defaultwaarden vaststellen.
39
beperkingen van het Clinical Statement Pattern Domein
 de veelheid van “ Clinical Statement ActChoice Act identifiers” wordt aangegeven in the
“ Pattern” als (0..*), terwijl deze veelheid in de “ Care Statement Act identifiers” is
beperkt tot (1..*). De reden voor deze belangrijke beperking is dat het uitgebreide
gebruik van “ ActReference” en queries in het “ Care Provision” Domein afhankelijk is
van het bestaan van “instance identifiers”. Deze “ instance identifiers” zijn normaal
gesproken gegenereerd door het systeem dat de instance (instantiatie) authoriseert.
Echter, er bestaan veel strategieën voor “ instance identifiers” en de enige aanname in
deze beperking is dat een “ instance identifier” op een unieke wijze de “ instance”
identificeert in systemen die bevraagd worden. “ Instances” kunnen afgeschermd
gecommuniceerd worden van een zendend systeem naar een ontvangend systeem of
interface engine die unieke systeem identifiers toevoegt en dan de “ instances”
opnieuw stuurt naar de andere systemen. In dit geval kan het originele systeem niet
bevraagd worden. Alleen de systemen die unieke “ instance identifiers” gegenereerd of
ontvangen hebben, kunnen bevraagd worden.
 twee beperkingen zijn toegevoegd aan specifieke “ Care Structure” klassen van de
“Infrastructure Root Class” : de “ InfrastructureRoot.realmCode”
en de
“InfrastructureRoot.templateID” . Deze twee beperkingen zijn bedoeld om gebruikt te
worden in “Care Structures” op dezelfde manier als ze gebruikt worden in “ CDA
Release 2” documenten. Dat wil zeggen, totdat er overeenstemming is over meer
specifieke HL7 methoden voor “templates” , refereert de “ template ID” aan een unieke
specificatie handleiding binnen de “ Care Provision topic” . De “ realmCode” wordt dan
gebruikt om een “ templateID” verder in te perken, waardoor verschillende “ realms” de
mogelijkheid gegeven wordt een specifieke “template” op een unieke manier te
gebruiken (vooral door additionele berperkingen op vocabulair gebruik). Alle klassen in
de “Care Statement” bevatten de “templateId and realmCode attributen”.
 “Care Structure Constraints”. Het “Clinical Statement Pattern” is erg algemeen en staat
toe dat alle “Clinical Statements” (of in het geval van dit topic, de “Care Statements”)
gerepresenteerd worden van recursies op de “ Clinical Statement” keuze. Echter, in de
“ Care Structures topic” wordt de “Care Statement” beperkt in het representeren van
dezelfde structuur in hetzelfde “RMIM” wanneer een “Care Structure” , afgeleid van het
“Care Statement Patroon”, wordt uitgerold en gedefinieerd. Met andere woorden, in één
en dezelfde “RMIM” mogen “Concern events” niet dubbel gerepresenteerd worden in
zowel de “Concern Tracking Structure” als vanuit “Concern Acts” geconstrueerd uit de
“Care Statement”. Daarom handelen de volgende “Care Structures” elk als een
beperking op de “Care Statement” wanneer de afgeleide “Care Structure” en de “Care
Statement” in hetzelfde “R-MIM” gebruikt worden.
In de toekomst zullen additionele “Care Structures” opgenomen worden in de “Care
Structures topic”. Deze nieuwe structuren zullen gebruikt worden door specifieke “realms”
voor specifieke doeleinden met specifieke beperkingen op vocabulaire door gebruik te
maken
van
HL7
attributen,
“InfrastructureRoot.templateId”
en
“InfrastructureRoot.realmCode”. Zo zullen beperkingen specifiek worden gedefinieerd in
zowel de niet uitgerolde delen van de structuur als in het overgebleven beperkte “Care
Statement” gedeelte van de structuur. Als gevolg hiervan kunnen veel “Care Structures”
die gedefinieerd zijn in dit document opnieuw geclassificeerd worden en als “templates”
gepubliseerd worden.
In de volgende sectie worden de “R-MIM’s” voor de specifieke “Care Structures”
beschreven. Ze worden eerst op een ‘klinisch relevante manier’ beschreven in een
algemene beschrijving. Na de algemene klinische beschrijving zal er een formele “walk-
40
thru” zijn zoals men ook tegenkomt in typische engineering specificaties. Niet alles van de
formele “walk-thru’s” is afgerond voor deze ballot.
Care Statement Structure Overview:
De “Care Statement Structure” helpt bij het verzamelen van klinische informatie, die
gedocumenteerd kan worden tijdens de zorgverlening. De keuzebox staat het uitdrukken
van elke verzameling van beweringen toe over zorg in elke volgorde of in elk aantal en in
elke combinatie, afhankelijk van het doel en de aard van het bericht.
De “Care Statement Structure” is het model waarvan alle andere “Care Structures” zijn
afgeleid. Deze afleiding gebeurt door beperking. Gebaseerd op het “Clinical Statement
Patroon” wordt het hernoemd in de “Care Provision Structure” in dit “Domain Message
Information Model” voor “Care Provision” om te benadrukken dat zorg van toepassing kan
zijn op medische apparatuur, faciliteiten en omgevingen, als mede op patiënten. Op die
manier wordt de vocabulair, gebruikt om de “Care Statements” te ondertsteunen, meer
uitgebreid dan het vocabulair dat gebruikt wordt om simpelweg de zorg voor de patiënten
te ondersteunen. Deze uitbreidingen zullen gedocumenteerd worden door een geleidelijke
toename in het aantal en de variëteit van de HL7 vocabulair waardensets. Deze
beschrijving geeft niet de volledige details van het “Clinical Statement Patroon” weer, maar
documenteert die aspecten die significant verschillen van het basispatroon.
De intentie is dat een “care statement instantiatie” door zichzelf toegevoegd kan worden
aan de “Care Provision Act” bij de relatie van de “R-MIM” of toegevoegd kan worden
tijdens uitvoering door een applicatie om de variabiliteit van mate en detail, beschreven in
de “care statement” definitie hierboven, te ondersteunen. Natuurlijk kan de “care
statement toegevoegd” worden aan de “Care Provision Act” samen met het toevoegen van
ook andere strucutren van het “Care Provision” Domein.
Gebruik van het Care Statement Model:
Het “Care Statement Model” presenteert een standaard structuur op hoog niveau voor
het opnemen van klinische informatie in “Care Provision” communicatie bedoeld ter
ondersteuning van specifieke zakelijke functionaliteiten. Hoewel niet bedoeld om
geïmplementeerd te worden ”as is”, kan het “Care Statement model” beperkt worden
om aan de eisen tegemoet te komen van vele specifieke communicatie met betrekking
tot klinische informatie.
Opties voor patroonbeperkingen omvatten:
 De generieke “Care Statement” klasse attributen kunnen worden beperkt om de
exacte aard van de data die gecommuniceerd moeten worden duidelijk over te
dragen;
- optionele attributen kunnen verwijderd worden wanneer deze niet van toepassing
zijn voor de business case;
- attributen kunnen zelf beperkt zijn:
 cardinaliteiten kunnen beperkt worden naar meer beperkte sets; (0..*) kan
bijvoorbeeld beperkt worden tot (1..*);
 waarde sets van attributen kunnen beperkt worden tot meer beperkte
waardensets; de 'mood code' kan bijvoorbeeld gelimiteerd worden tot 'Event'.
- data typen voor een attribuut kunnen beperkt worden, bijvoorbeeld 'ANY naar
CD'.
41
 associaties kunnen beperkt worden om de mogelijkheid tot complexiteit te
verwijderen, bijvoorbeeld: het beperken van een implementatie naar 3 niveaus van
nesten; het verwijderen van 'Episode Link' om een implementatie te definiëren naar
de laagst mogelijke gemeenschappelijke noemer met betrekking tot het systeem
vermogen;
 klassen kunnen worden beperkt:
- klassen kunnen worden verwijderd als ze niet vereist zijn;
- klassen kunnen worden beperkt tot specifieke subklassen, bijvoorbeeld de
”Observation Class” wordt beperkt tot “ConcernClass”;
- klassen kunnen worden ‘gekloond’ om specifieke beperkingen voor attributen of
associaties te documenteren;
- klassen waarop specifieke beperkingen op toegepast zijn, kunnen worden
‘uitgerold’ van de “Clinical Statement Choice box” om hun gebruik te beperken
tot een specifieke structuur (in dat geval kan niet langer aangenomen worden dat
de beperkte versie van de klasse aanwezig is in de algemene “Care Statement
Choice Box”).
 klassen kunnen worden gecombineerd tot specifieke klinische groepen (artefacten)
zoals gecombineerde observaties in het geval van bloeddruk, of klinische schalen
zoals de Apgar score en Barthel Index.
Aan dit model wordt gerefereerd via een externe “Act” naar de “Care Statements”. Vaak
levert deze externe “Act” de “Entry Point” naar een specificatie voor communicatie en
representeert de context waarin de “care statement” informatie wordt verzonden.
Bijvoorbeeld: informatie over degene die de informatie verzendt zit in een externe “Act”
naar de “Care Statements”. De “Care Provision Act” in het “Care Provision” Domein is een
voorbeeld van een externe “Act” naar de “Care Statement”.
het Care Statement Model (REPC_RM000100)
Het model kan verdeeld worden in 3 gerelateerde onderdelen:
 “Care Entry” Keuzebox;
 participaties om de “Acts” heen;
 ”Acts” buiten de “CareEntry” Keuzebox.
de Care Entry keuzebox
Dit deel van het model wordt gebruikt voor het overbrengen van de gedetailleerde “care
statements” die verzonden worden ter ondersteuning van de specifieke zakelijke
behoeften. Evenals het leveren van een mechanisme voor het overbrengen van de
componenten van deze informatie ondersteunt het het groeperen van deze componenten
en levert het mechanismen om expliciet beweringen te linken waar er een specifieke relatie
is.
De gekloonde klassen in de “CareEntry” keuze zijn hetzelfde als die beschikbaar zijn in de
“Clinical statement Pattern ActChoice”. Namen van gekloonde klassen en alle aspecten
van de attributen zijn identiek.
linken van Care Statements
The modeling of the linking of Care Statements has been modified from that in the Clinical
Statement Pattern as follows:
42
Het modelleren van het linken van “Care Statements” is als volgt gemodificeerd van
hetgeen staat in het Care Statement Pattern:
 de “sourceOf/targetOf” relatie is uit elkaar gehaald in twee aparte relaties:
“sourceOf” en “targetOf”;
 doel van de “sourceOf” relatie is de buitenste “Care Statement” keuze;
 “SourceOf” is weggehaald;
 een beperking is toegevoegd aan de nieuwe “sourceOf” relatie: de waarde van
“contextConductionInd” is ”false” als het doel een “ActReference” is (context kan niet
worden herleid tot ActReference).
Deze nieuwe modelleerbenadering bevat nu dezelfde semantiek als die in de “Clinical
Statement Pattern”, maar wordt gezien als een minder gecompliceerde benadering.
record Target en Subject
Naast het toepassen op patiënten kan een “Care Statement” ook van toepassing zijn
op variëtiet van andere typen Entiteiten (o.a. hulpmiddelen). Om dit te ondersteunen is
het doel van de “RecordTarget” participatie een keuze tussen “R_CarePatient” en
“R_CaredEntity CMET’s”.
Evenzo kan het subject van een “Care Statement” één van diverse typen entiteiten
omvatten: de patiënt, een ander persoon, een soort, een apparaat, een dienst, een
plaats. Om dit te ondersteunen is in de “SubjetChoice” keuzebox, “target” van subject
participatie, een uitgebreide set van rollen opgenomen.
consumable
De “consumable” participatie wordt gebruikt om de “Consumble Choice” in te brengen.
Dit kan een “Manufactures Product” rol zijn (gespeeld door een “Labeled Drug” of een
“Material”) of een “Instance of Kind” rol (gespeeld door een “Material Kind” dat zelf
gespecificeerd kan zijn als deel van een groter geheel).
43
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 van “HDF
requirements analysis”, zie “Care Provision Domain Requirements Analysis Atrifacts
PDF”. Voor de storyboards die gebruikt zijn om specifieke berichten, diensten of
document definities te illustreren wordt u verwezen naar de juiste topic onder het “Care
Provision” Domein.
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 werkprocessen, 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”.
De opzet die 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 elke term bestaand uit
meerdere woorden die gebruikt worden in het storyboard (meestal alleen aanwezig
in de “Care Provision Domain Requirements Analysis Artifacts PDF”).
3.2
Patiënt Vult Persoonlijk Medisch Dossier (DOPC_ST000033UV)
44
doel
Dit storyboard demonstreert de communicatiestroom die geassocieerd wordt met
verzoeken voor delen 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, over zijn conditie, van Dr. Patricia Primary, die zij in haar klinisch system
houdt.
Activiteiten: Mr. Adam Everyman vraagt om specifieke informatie, gerelateerd aan
zijn cardiale conditie , van Dr. Patricia Primary,. Dr. Primary antwoordt door het sturen
van de antwoorden op de specifieke informatie die aangevraagd is door Mr. Everyman.
Hij is in staat 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 op van bepaalde testresultaten en
behandelingen, gerelateerd aan zijn cardiale conditie, bij Dr Primary. Dr Primary
antwoordt door het sturen van de documenten aan Mr Everyman.
Postconditie: Mr. Everyman heeft nu alle documenten en informatie, over zijn cardiale
conditie ,die hij nodig heeft van Dr. Primary.
3.3
Pediatrische Immunisatie (Vaccinatie) (DOPC_ST000030)
doel
Dit storyboard demonstreert de interactie tussen een Jeugdarts en de entadministratie
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 ziekenhuizen
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 entadministratie. De entadministratie 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 entadministratie is in staat het entdossier van de patiënt te lokaliseren via
het LSP.
Activiteiten: Tijdens een vraaggesprek ontdekt de jeugdverpleegkundige dat de
zorgverlener van Billy het entdossier van Billy niet heeft. Bij het voorbereiden van een
nieuw patiëntendossier voor dr Jeugdig, geeft de verpleegkundige de aanzet voor het
EKD om de regionale entadministratie te bevragen. De entadministratievindt 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
instrument voor beslissingsondersteuning te gebruiken.
45
Alternatieve Stroom #1: De regionale entadministratie 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 immunisaties toe en documenteert deze in het EKD
Het EKD stuurt het bericht over de nieuwe immunisaties naar de entadministratie die
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 vinden geen aanpassingen plaats op de
immunisatie geschiedenis in het patiënten dossier. Er worden geen data gestuurd naar
de registratie.
Postconditie: De regionale entadministratie heeft Billy zijn immunisatie geschiedenis
gestuurd.
De regionale entadministratieheeft 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 af en verricht een lichamelijk onderzoek
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 van
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.
46
4.
5.
6.
7.
Probleemlijst: kortademigheid; palpitaties.
Medicatielijst: anti-aritmie.
Allergieën en nadelige reacties: geen medicatie allergieën bekend.
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 zullen inplannen 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 zorgteam.
47
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.
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 de voortgang te bespreken in de eerste fase van het zorgplan ten behoeve van 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 in het zorgplan van meneer Everymen en stuurt deze, samen met de
aangepaste set van opdrachten en verzoeken voor de volgende fase, naar Connie
Chow, Seth Stretcher 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 voortgangsrapportages 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 maatschappelijk werker bij het Maas Ziekenhuis en
verantwoordelijk 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. Zijn dochter, Nancy Nuclear,
48
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 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 te kijken of zij in staat is 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.Iin 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 is 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 gedrag en 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.
49
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
bij 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 Nightingale meteen op de hoogte van het
feit dat het verzoek voor services voor meneer Everyman wordt ingetrokken.
2.
Postconditie: Peter Process onslaat meneer Everyman naar huis.
2. Na de gedetailleerde meetschalen over cognitie en gedrag 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.
50
4.
R-MIM 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 ketenzorgprojecten worden toegepast. Het gaat daarbij om
de set interacties om binnen zorgketens te verwijzen en terug te rapporteren en om
zeer gedetailleerde en precies omschreven klinische informatie correct te kunnen
doorgeven.
4.2
Care Transfer Topic
4.2.1 Inleiding
Dit hoofdstuk is een vertaling van Hoofdstuk 8 van de Care Provision uit de ballot van
januari 2007 / mei 2008. Dit is de versie van de 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 wordt deze set van communicatie 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 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 communicatie
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 "entry point" gebruiken
van het “Refined Message Information Model (R-MIM)”. In dit hoofdstuk komen de RMIMs aan de orde voor de berichten voor ”Care Transfer”.
51
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 beperkt tot een bewering van
de scope van de verantwoordelijkheid, inclusief het type zorg, de genoemde specifieke
condities en de genoemde specifieke zorgplannen, waarbij:
 'Communicatie' een manier kan zijn van
- Overbrengen met of zonder een bijgesloten klinisch document als bijlage, zoals
een samenvatting of zorgoverdracht.
 'Communicatie' getriggered kan 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 die alle Interacties en Applicatie Rollen die belangrijk zijn
voor het Care Transfer Topic illustreert.
52
4.4
Storyboards
De volgende storyboards zijn van toepassing op verwijzigen en acceptatie:
Storyboards
Request for Changes in Ongoing Service(REPC_ST004008UV)
Completed Specialty Care(REPC_ST004001UV)
Multidisciplinary Care Provision(REPC_ST004003UV)
Aged Care Transfer Request(REPC_ST004005UV)
Aged Care (Lite) Transfer(REPC_ST004006UV)
Request Medication Chart Review(REPC_ST004004UV)
Request for Pastoral Care(REPC_ST004007UV)
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.
53
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 doet tot een verandering van een bestaande
service.
Interaction List (interactielijst)
Revise Care Transfer Request
Replace Care Transfer Promise
Replace Care Provision
REPC_IN002220UV
REPC_IN003930UV
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’, een
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
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
maaltijdservice) op tijd uitgevoerd worden, met documentatie van de juiste autorisaties.
54
Completed Specialty Care (REPC_ST004001UV)
Doel
Dit storyboard beschrijft een typische consultatie van een specialist door een huisarts.
Interactie Lijst
Care Transfer Request
Care Transfer Promise
Complete Care Provision
Reject Care Transfer
Revise Care Transfer Request
REPC_IN002120UV
REPC_IN003130UV
REPC_IN004410UV
REPC_IN002040UV
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 verwijzing terug naar Dr. Primary. Dit omvat de door Dr. Primary
55
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 gedaan 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 te
werken met andere zorgverleners als de patiënt complexe zorgbehoeften heeft en die
baat zouden hebben bij de inbreng van een multidisciplinair zorgteam. Gelijksoortige
initiatieven bestaan in veel landen.)
Interactie Lijst
Care Transfer Request
Care Transfer Promise
REPC_IN002120UV
REPC_IN003130UV
56
Activate Care Provision
Revise Care Transfer Request
Replace Care Transfer Promise
Append Care Provision
Revise Care Transfer Request
Replace Care Provision
REPC_IN004110UV
REPC_IN002220UV
REPC_IN003930UV
REPC_IN004211UV
REPC_IN002220UV
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 de voortgang te bespreken in de eerste fase van het zorgplan voor het begeleiden
57
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 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
Reject Care Transfer
Notify Care Transfer Request
Care Transfer Request
Care Transfer Promise
Abort Care Transfer Request Notification
Reject Care Transfer
REPC_IN002120UV
REPC_IN002040UV
REPC_IN002110UV
REPC_IN002120UV
REPC_IN003130UV
REPC_IN002620UV
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
58
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 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.
59
Alternatieve stromen:
1. 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 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.
2. Na de gedetailleerde meetschalen over cognitie en gedrag 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.
1. 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, om zo soepel en snel als mogelijk een plaats in de
ouderenzorg te lokaliseren, terwijl zij zich ervan 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.
60
Interactie Lijst
Care Transfer Request
Care Transfer Promise
Abort Care Transfer Request Notification
REPC_IN002120UV
REPC_IN003130UV
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 verzorginghuizen, inclusief ‘Groene Velden Verzorgingstehuizen’
(GVV), waar Alice Admitter beslist over de toelating.
Activiteiten:
service Provision Transfer (Referral for service)
Handelend, 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.
61
Request Medication Chart Review (REPC_ST004004UV)
Doel:
Dit storyboard demonstreert een verzoek van een verpleegkundige van een huisarts
om een medicatietabel van een bewoner te bekijken..
Interactie Lijst
Care Transfer Request
Care Transfer Promise
Reject Care Transfer
REPC_IN002120UV
REPC_IN003130UV
REPC_IN002040UV
Care Transfer Request Medication Chart (REPC_SN004004UV)
Nancy Nightingale,
verpleegkundige
bij
‘Groene
Velden
Precondition:
Verzorgingstehuizen’ (GVV), maakt zich zorgen over het feit dat het pijnmanagement
van Meneer Everyman niet langer effectief is. Ze denkt dat een beoordeling van al zijn
medicatie op zijn plaats is. Ze bespreekt haar 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.
62
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 dat Meneer Everyman te vaak een doorbraak van pijn ervaart.
[Interactie: Care Transfer Request ].
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 op dit moment niet nodig is [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
Care Transfer Promise
Activate Care Provision
Append Care Provision
Suspend Care Provision
REPC_IN002120UV
REPC_IN003130UV
REPC_IN004110UV
REPC_IN004211UV
REPC_IN004310UV
Pastoral Care (REPC_SN004007UV)
63
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 in de laatste vijf jaar van haar vervreemd, 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, 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
echtgenoot 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
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
64
Provision]. Hierdoor kan Helen Helper de kwaliteit en het 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 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
Care Transfer Promise
REPC_IN002120UV
REPC_IN003130UV
Surgical Referral (REPC_SN004002UV)
Preconditie: Meneer Adam Everyman is een patient 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 meneer 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
65
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 een thoraxoperatie 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.
Update Samenvatting Eisen: De actoren van deze communicatie zijn, Dr. Attend, Dr.
Cutter, Dr. 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
Deze 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. Het 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 verzoek bij te houden.
Care Transfer Fulfiller (REPC_AR002040UV)
Beschrijving
Structured Name:
Care Transfer Request Fulfiller
66
Deze 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. Het 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.
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 het activeren 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
67
Structured Name:
Type:
State Transition:
Care Transfer Request Revise
State-transition based
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.
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 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 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
68
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
4.7
Refined Message Information Modellen
Hier volgen de gestructureerde berichten voor verwijzing en acceptatie.
Refined Message Information Modellen
Care Transfer Request (REPC_RM002000UV)
Care Transfer Promise (REPC_RM003000UV)
Referentie
Voor details over de interpretatie van deze sectie, zie de Beschrijving van R-MIMs in
de Versie 3 Guide.
4.8
Care Transfer Request (REPC_RM002000UV)
Diagram
69
Beschrijving
Parent:
Care Provision (REPC_DM000000UV)
Care Transfer Request (verzoek tot zorgoverdracht) R-MIM 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” D-MIM maar gebruikt "local CMET’s" om de complexiteit van de
zorgstructuren, geassocieerd met de “Care Provision Request Act”, samen te vatten.
De lezer wordt verwezen naar de D-MIM discussie alvorens te kijken naar de R-MIM,
gevolgd door de discussie voor elke zorgstructuur. De discussie over dit model
accepteert kenmerken die niet expliciet bestaan in de D-MIM en die niet direct
besproken werden in het overzicht van dat model.
Care Provision Request Focal Class7 (verzoek tot zorgverlening Focale Klasse)
7
De Focal Class van dit R-MIM is de Care Provision klasse
70
Zoals aangegeven in de discussie van de D-MIM, 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 D-MIM 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 CMET’s.
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 CMET’s.
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 CMET’s.
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 validator 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 een familielid of de
71
patiënt zelf (R_Patient). Voor verdere beschrijving wordt men verwezen naar de
respectievelijke CMET’s.
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 CMET’s.
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 klinische beweringen 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 klinische beweringen kan geassocieerd worden als
deel van het “Care Provision Request”. Dit is bedoeld om aan te geven dat bijvoorbeeld
deze lijst van concerns beheerd wordt 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
gerepresenteerd door de “A_Encounter CMET”.
72
werd
aangevraagd,
replacementOf: een verbinding naar een vervangend 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 vervangend verzoek 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
Beschrijving
Parent:
Care Provision (REPC_DM000000UV)
Care Transfer Promise (Acceptatie zorgoverdracht) R-MIM Overzicht
Dit model legt de data en associaties vast die nodig zijn wanneer een zorgoverdracht
(Care Transfer) beloofd of geaccepteerd wordt.
73
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 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 is 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 speelt 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 CMET’s.
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 CMET’s.
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 CMET’s.
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”.
74
verifier: de validator 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 CMET’s.
primaryInformationRecipient: de leverancier die bestemd is de acceptatie voor de
zorgoverdracht te ontvangen. De ontvanger is meestal 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 CMET’s.
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 (HMD)
Hier volgen de hierarchische message descriptions
Hierarchical Message Descriptions
Care Transfer Request (REPC_HD002000UV)
Care Transfer Promise (REPC_HD003000UV)
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
75
Berichtentypen die gebaseerd zijn op deze HMD worden gebruikt om de verzoeken
voor zorgoverdracht te communiceren..
Gebruikte “Common Message Element Types”
A_CarePlanCare provision
A_CareRecordUniversal
A_CareStatementCare provision
A_ConcernTrackingEventCare provision
A_EncounterUniversal
A_StatementCollectorCare provision
R_AssignedPartyUniversal
R_AssignedPersonUniversal
R_CaredEntityCare provision
R_PatientUniversal
R_RelatedPartyUniversal
REPC_MT000200UV
REPC_MT004000UV
REPC_MT000100UV
REPC_MT000301UV
COCT_MT010000UV01
REPC_MT000400UV
COCT_MT090400UV
COCT_MT090100UV01
REPC_MT000700UV
COCT_MT050000UV01
COCT_MT910000UV
Base Hierarchical Message Description
Lijst van “Message Type”
Care Transfer Request Abort
Care Transfer Request
REPC_MT002600UV
REPC_MT002000UV
Care Transfer Promise (REPC_HD003000UV)
Beschrijving
Berichtentypen die gebaseerd zijn op deze HMD worden gebruikt om de beloften voor
zorgoverdracht te communiceren.
Gebruikte “Common Message Element Types”
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
Lijst van “Message Type”
Care Transfer Promise
REPC_MT003000UV
76
4.11 Interacties
Hieronder volgen de interacties tussen de applicaties.
Lijst van interacties (gesorteerd volgens titel)
Care Transfer Request(REPC_IN002120UV)
Notify Care Transfer Request(REPC_IN002110UV)
Revise Care Transfer Request(REPC_IN002220UV)
Notify Revise Care Transfer Request(REPC_IN002210UV)
Abort Care Transfer Request Notification(REPC_IN002620UV)
Notify Aborted Care Transfer Request(REPC_IN002610UV)
Reject Care Transfer(REPC_IN002040UV)
Care Transfer Promise(REPC_IN003130UV)
Replace Care Transfer Promise(REPC_IN003930UV)
Notify Care Transfer Promise(REPC_IN003010UV)
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 verantwoordelijkheid van de tweede ontvanger is Afwijzen
Zorgoverdracht en wordt gebruikt door de uitvoerder 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 REPC_TE002040UV REPC_IN002040UV
het uitvoeren van het verzoek
De uitvoerder (fulfiller) stemt in met het REPC_TE003130UV REPC_IN003130UV
uitvoeren van het verzoek
77
Sending and Receiving Roles (zendende en ontvangende rollen)
Sender Care Transfer Placer
Receiver Care Transfer Fulfiller
REPC_AR002030UV
REPC_AR002040UV
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 de 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
De uitvoerder (fulfiller) stemt niet
in met het uitvoeren van het
verzoek
Trigger Event
REPC_TE002040UV
Interaction
REPC_IN002040UV
De uitvoerder (fulfiller) stemt in
met het uitvoeren van het
verzoek
REPC_TE003130UV
REPC_IN003130UV
De
uitvoerder
(fulfiller)
is
begonnen
met
de
verantwoordelijkheid
voor
zorgverlening ter voltooiing van
het verzoek. De uitvoerder
gebruikt dit wanneer he teen
verzoek wil accepteren waarbij
de
zorgoverdracht
wordt
verzocht.
REPC_TE004110UV
REPC_IN004110UV
Sending and Receiving Roles (zendende en ontvangende rollen)
Sender
Receiver
Care Provision Informer
Care Transfer Tracker
REPC_AR004010UV
REPC_AR002020UV
78
Revise Care Transfer Request (REPC_IN002220UV)
Beschrijving
Structured Name:
Care Transfer Request Revise Fulfillment Request
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 uitvoerder (fulfiller) om het
gewijzigde verzoek af te wijzen.
Trigger Event
Transmission Wrapper
Control Act Wrapper
Message Type
Notify Revise Care Transfer REPC_TE002200UV
Request
Send Message Payload
MCCI_MT000100UV01
Trigger Event Control Act
MCAI_MT700201UV01
Care Transfer Request
REPC_MT002000UV
Receiver Responsibilities (verantwoordelijkheden ontvanger)
Reason
Trigger Event
Interactie
De uitvoerder (fulfiller) stemt niet in met REPC_TE002040UV REPC_IN002040UV
het uitvoeren van het gewijzigde verzoek
voor zorgoverdracht.
De uitvoerder (fulfiller) heeft nog niet REPC_TE003130UV REPC_IN003130UV
beloofd 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 REPC_IN003930UV
uitvoeren van het vervangen verzoek voor
zorgoverdracht.
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
79
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
Message Type
Notify Revise Care Transfer REPC_TE002200UV
Request
Send Message Payload
MCCI_MT000100UV01
Trigger Event Control Act
MCAI_MT700201UV01
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 REPC_TE002600UV
Request
Send Message Payload
MCCI_MT000100UV01
Trigger Event Control Act
MCAI_MT700201UV01
Abort Care Transfer Request
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.
80
Trigger Event
Transmission Wrapper
Control Act Wrapper
Message Type
Notify Abort
Care
Transfer REPC_TE002600UV
Request
Send Message Payload
MCCI_MT000100UV01
Trigger Event Control Act
MCAI_MT700201UV01
Abort Care Transfer Request
REPC_MT002600UV
Sending and Receiving Roles (zendende en ontvangende rollen)
Sender
Receiver
Care Transfer Placer
Care Transfer Tracker
REPC_AR002030UV
REPC_AR002020UV
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
Reject Care Transfer
Application Level
Transmission Wrapper
Acknowledgement
Control Act Wrapper
Trigger Event Control Act
Message Type
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
Care Transfer Promise
81
REPC_TE003130UV
Transmission Wrapper
Control Act Wrapper
Message Type
Application Level
Acknowledgement
Trigger Event Control Act
Care Transfer Promise
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
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
82
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
83
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 over de geschiktheid voor ouderenzorg. Het gaat daarbij om
dossiers waarin de beoordeling van geschiktheid van zorg is opgenomen, waarbij kan
worden vastgesteld wat de doorloop (vervaldatum) en 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 vroegere 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 vroegere beoordeling op
geschiktheid voor ouderenzorg bestaat voor mevrouw Everywoman. Ze ontvangt een
84
antwoord dat er twee jaar geleden een 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.
85
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
Get Care Record Response
Activate Care Provision
QUPC_IN043100UV
QUPC_IN040200UV
REPC_IN004110UV
Patient Populates Personal Health Record (REPC_SN002202UV)
Preconditie:
Meneer Adam Everyman wil een persoonlijk zorgdossier met informatie over zijn
conditie inzien bij 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. Deze is in staat 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 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.
86
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 over 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
87
Een request (verzoek) om een mogelijke “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 specifieke “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.
88
5.5
Refined Message Information Models
Hier volgen de query modellen.
Refined Message Information Models
Find Care Record Candidate Query(QUPC_RM040100UV)
Care Record Query(QUPC_RM040000UV)
Care Record Profile Query(QUPC_RM040300UV)
Referentie
Voor details over de interpretatie van deze sectie, zie de Beschrijving van R-MIMs in
de Versie 3 Guide.
Find Care Record Candidate Query (QUPC_RM040100UV)
Diagram
Beschrijving
Parent:
None Specified
De “Find Care Record Candidate Query request R-MIM” 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:
89
PatientId: de unieke identifier (II) van de patiënt waarvan zijn 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 zijn 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
waarvan de dossiers worden opgehaald. Wordt 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 waarvan zijn
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<TS>) van “Care Record”
(zorgdossier) 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) en die gerapporteerd wordt
in het “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 en 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” ( geheel getal) waarde.
Contained Hierarchical Message Beschrijvingen
Query Care Record Event Find Candidate
QUPC_HD040100UV
90
Care Record Query (QUPC_RM040000UV)
Diagram
Beschrijving
Parent:
None Specified
De “Care Record Query request R-MIM” 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” op van dat tijdstip. Dit werkt als een tijdgebonden afspeigeling
van het dossier. 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 bijlagen zou bevatten die beschikbaar zijn. Als deze op ”false”
staat zouden bijlagen bij een zorgplan 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 “Care Statements” (bijv. A1Cs, gewicht, uitgereikte medicatie, etc.)
die teruggegeven worden. Bijvoorbeeld: 1= meest recent, 2= laatste twee “Care
91
Statements”, ongespecificeerd= alle beschikbare “Care Statements”. De default
is dat alle dossiers 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 R-MIM” levert de lijst van query parameters die
nodig zijn om een “care profile” of zorgprofiel op te halen dat afgeleid is van het
patiëntendossier dat overeenkomt met de criteria parameters. Deze query parameters
zijn als volgt:
92
PatientId: de unieke identifer (II) van de patiënt wiens dossiers opgehaald
wordenDe parameter is verplicht en zou precies één patient identifer 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.
ClinicalStatementTimePeriod: de datum periode (IVL<TS>) 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<TS>) van “Care Records”
(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
93
IncludeCarePlanAttachment: een indicator (BL) die, als deze op ”true” staat,
elke bijlage bij een zorgplan 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
5.6
QUPC_HD040300UV
Hierarchical Message Descriptions
Hierarchical Message Descriptions (gesorteerd op Titel)
Find Care Record Candidate Query(QUPC_HD040100UV)
Care Record Query(QUPC_HD040000UV)
Care Record Profile Query(QUPC_HD040300UV)
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 hiervoor geen beschrijving.
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 hiervoor geen beschrijving.
94
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 hiervoor geen beschrijving.
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 Query(QUPC_IN040100UV)
Get Care Record Response(QUPC_IN040200UV)
Get Care Record Profile Query(QUPC_IN043100UV)
Get Care Record Profile Response(QUPC_IN043200UV)
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
Find Care Record Candidate Query QUPC_TE041100UV
95
Transmission Wrapper Send Message Payload
MCCI_MT000100UV01
Query Control Act Request : QUQI_MT020001UV01
Control Act Wrapper
Parameter List
Message Type
Find Care Record Candidate Query QUPC_MT040100UV
Receiver Responsibilities (verantwoordelijkheden ontvanger)
Reason
Trigger Event
Interaction
Dit is het verwachte antwoord op de QUPC_TE041200UV QUPC_IN041200UV
Find Care Record Candidates query
Sending and Receiving Roles (Zendende en ontvangende rollen)
Care Record Query Placer
Care Record Query Fulfiller
QUPC_AR004030UV
QUPC_AR004040UV
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.
Trigger Event
Transmission
Wrapper
Find
Care
Record
Candidate QUPC_TE041200UV
Response
Application Level Acknowledgement MCCI_MT000300UV01
Master File / Registry
Response, Act Subject
Response Care Record Candidate
Control Act Wrapper
Query
Type
Query Definition
Query MFMI_MT700712UV01
Find Care Record Candidate Query
REPC_MT004005UV
QUPC_MT040100UV
Sending and Receiving Roles (Zendende en ontvangende rollen)
Sender Care Record Query Fulfiller
Receiver Care Record Query Placer
QUPC_AR004040UV
QUPC_AR004030UV
Get Care Record Query (QUPC_IN040100UV)
Beschrijving
96
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
Get Care Record Query
QUPC_TE040100UV
Transmission Wrapper Send Message Payload
MCCI_MT000100UV01
Query Control Act Request : QUQI_MT020001UV01
Control Act Wrapper
Parameter List
Message Type
Care Record Query
QUPC_MT040000UV
Receiver Responsibilities (verantwoordelijkheden ontvanger)
Reason
Trigger Event
Interaction
Dit is het verwachte antwoord op de Get QUPC_TE040200UV QUPC_IN040200UV
Care Record Query
Sending and Receiving Roles (Zendende en ontvangende rollen)
Sender
Receiver
Care Record Query Placer
Care Record Query Fulfiller
QUPC_AR004030UV
QUPC_AR004040UV
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.
Trigger Event
Transmission
Wrapper
Get Care Record Response
QUPC_TE040200UV
Application
Level MCCI_MT000300UV01
Acknowledgement
Master File / Registry Query MFMI_MT700712UV01
Control Act Wrapper
Response, Act Subject
Query
Response Care Record
REPC_MT004000UV
Type
Query Definition
Care Record Query
QUPC_MT040000UV
Sending and Receiving Roles (Zendende en ontvangende rollen)
97
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.
Get Care Record Profile QUPC_TE043100UV
Query
Transmission Wrapper Send Message Payload
MCCI_MT000100UV01
Query Control Act Request : QUQI_MT020001UV01
Control Act Wrapper
Parameter List
Message Type
Care Record Profile Query QUPC_MT040300UV
Trigger Event
Receiver Responsibilities (verantwoordelijkheden ontvanger)
Reason
Trigger Event
Interaction
Dit is het verwachte antwoord op de Get QUPC_TE043200UV QUPC_IN043200UV
Care Record Profile query
Sending and Receiving Roles (Zendende en ontvangende rollen)
Sender Care Record Query Placer
Receiver Care Record Query Fulfiller
QUPC_AR004030UV
QUPC_AR004040UV
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.
Trigger Event
Transmission
Get Care Record Profile Response QUPC_TE043200UV
Application Level Acknowledgement MCCI_MT000300UV01
98
Wrapper
Master File / Registry
Response, Act Subject
Response Care Record
Control Act Wrapper
Query
Type
Query Definition
Care Record Profile Query
Query MFMI_MT700712UV01
REPC_MT004000UV
QUPC_MT040300UV
Sending and Receiving Roles (Zendende en ontvangende rollen)
Sender Care Record Query Fulfiller
Receiver Care Record Query Placer
QUPC_AR004040UV
QUPC_AR004030UV
99
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).
100
6.2
Storyboards
Storyboards (georteerd volgens titel)
Mandatory Care Activation(REPC_ST002006UV)
Temporary Handover of Care(REPC_ST002005UV)
Emergency Encounter(REPC_ST002001UV)
Hospital Discharge Summary(REPC_ST002002UV)
Ongoing Specialist Care Provision(REPC_ST002003UV)
Separation of Care(REPC_ST002004UV)
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.
101
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: de “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.
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
102
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 de spoedeisende hulp
over een patiënt die nazorg behoeft van specialistische hulp (Physician Notification of
Emergency Encounter Requiring Follow up Specialist Care).
103
Interactie Lijst
Complete Care Provision
Care Transfer Request
REPC_IN004410UV
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, die beslist dat de heer Everyman direct moet
worden behandeld. De heer Everyman wordt ingecheckt voor de SEH door de heer
Christopher Clerk, de SEH-assistent die van 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 en 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.
104
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 voortvloeit 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-met-roken 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’ operatie op, samen met de gezondheidssamenvatting van Dr. Attend
en stuurt een verzoek om doorverwijzing naar Dr. Dunst en een naar het stoppen-metroken onderwijsprogramma ‘Quit Now’. [Interactie: Care Transfer Request ].
Dr. Cutter stelt dezelfde samenvatting op van de heer Everymans operatie, 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
aan Quit Now verstuurd naar Dr. Primary voor in haar dossier [Interactie: Activate Care
Provision].
105
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 en 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 voor specialistische zorg met een bericht voor
vervolgbehandeling.
Interactie Lijst
Care Transfer Request
Care Transfer Promise
Activate Care Provision
Append Care Provision
REPC_IN002120UV
REPC_IN003130UV
REPC_IN004110UV
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
106
stuurt Dr. Joint 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.
107
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 over 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
108
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.
6.4
Trigger Events
Trigger Events
Replace Care Provision(REPC_TE004913UV)
Activate Care Provision(REPC_TE004110UV)
Append Care Provision(REPC_TE004211UV)
Correct Care Provision(REPC_TE004210UV)
Suspend Care Provision(REPC_TE004310UV)
Resume Care Provision(REPC_TE004510UV)
Complete Care Provision(REPC_TE004410UV)
Nullify Care Provision(REPC_TE004810UV)
Report Care Provision(REPC_TE004014UV)
Referentie
Voor details over de interpretatie van deze sectie, zie de discussie over 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
109
Geeft aanvullende details over de zorgverlening aan een subject.
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)
110
Beschrijving
Structured Name:
Type:
Care Record Event Nullify
State-transition based
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 en 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 R-MIMs in de
Versie 3 Guide.
Care Record (REPC_RM004000UV)
Diagram
111
Beschrijving
Parent:
Care Provision (REPC_DM000000UV)
Care Record R-MIM Overview
Het “Care Record R-MIM” 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 D-MIM, maar gebruikt "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 D-MIM discussie
112
alvorens het R-MIM 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 D-MIM en niet direct worden behandeld in de bespreking van dat model.
CareProvisionEvent Focal Class
Zoals aangegeven in de discussie van de D-MIM 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). Elke 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 CMET’s. Die zijn uitvoerig beschreven in de
implementatiehandleiding “Data typen en CMET’s 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 CMET’s.
author: de zorgverlener die de registratie van het “Care Provision Event” verricht. 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 de gezondheidszorg, of de cliënt / patiënt zelf
(R_Patient). Voor een verdere beschrijving wordt verwezen naar de respectievelijke
CMET’s.
dataEnterer: de datatypist of secretaresse die de informatie in het “Care Record”
invoert. De informatie over de datatypist wordt beschreven in de “R_AssignedPerson
CMET”.
verifier: de validator die het “Care Record” verifieert. Er is steun voor meerdere
verificatieniveaus. De informatie over de verifiërende partij wordt beschreven in de
“R_AssignedPerson CMET”.
113
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 CMET’s.
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 CMET’s.
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 o (topic) “Care Plan” van Care
Provision. Deze kan mogelijk in een later stadium worden toegevoegd.
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 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 lokale “CMET” wordt verwezen naar de “A_CareStatement” in het
onderwerp/hoofdstuk (topic) “Care Provision D-MIM” en topic “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 deze lokale “CMET” wordt verwezen naar het
“A_ConcernTrackingEvent” in het onderwerp (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 van voortdurende aard en die
niet specifiek wordt beschreven als onderdeel van de “Care Provision Event”. Dit kan
114
een problemenlijst zijn, een actuele medicatielijst of een lijst met risicofactoren. Voor
een verdere beschrijving van deze lokale “CMET” wordt verwezen naar de
“A_StatementCollector” in het onderwerp (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 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_ConcernTrackingEventCare provision
A_EncounterUniversal
A_StatementCollectorCare provision
R_AssignedPartyUniversal
R_AssignedPersonUniversal
R_CaredEntityCare provision
R_PatientUniversal
R_RelatedPartyUniversal
REPC_MT000200UV
REPC_MT000100UV
REPC_MT000301UV
COCT_MT010000UV01
REPC_MT000400UV
COCT_MT090400UV
COCT_MT090100UV01
REPC_MT000700UV
COCT_MT050000UV01
COCT_MT910000UV
Base Hierarchical Message Description
115
Message Type List
Care Record Event
Care Record Event Candidate
Care Record Event Status
6.7
REPC_MT004000UV
REPC_MT004005UV
REPC_MT004009UV
Interacties
Lijst van Interacties (Georteerd volgens titel)
Abort Care Provision (REPC_IN004610UV)
Activate Care Provision (REPC_IN004110UV)
Append Care Provision (REPC_IN004211UV)
Correct Care Provision (REPC_IN004210UV)
Suspend Care Provision (REPC_IN004310UV)
Resume Care Provision (REPC_IN004510UV)
Abort Care Provision (REPC_IN004610UV)
Complete Care Provision (REPC_IN00441 0UV)
Nullify Care Provision (REPC_IN004810UV)
Replace Care Provision (REPC_IN004913UV)
Report Care Provision (REPC_IN004014UV)
Referentie
Voor details over de interpretatie van deze sectie, zie de definitie van Interacties in de
Versie 3 Guide.
Abort Care Provision (REPC_IN004610UV)
Description
Structured Name: Care Record Event Abort
De interactie stelt de ontvanger op de hoogte van de details die zijn verzameld als
onderdeel van het (voortijdig) beeindigen van de zorgverlening aan een subject.
Trigger Event
Abort Care Provision
Transmission Wrapper Send Message Payload
Control Act Wrapper
Trigger Event Control Act
Message Type
Care Record Status
Sending and Receiving Roles
REPC_TE004610UV
MCCI_MT000100UV01
MCAI_MT700201UV01
REPC_MT004009UV
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.
116
Trigger Event
Transmission Wrapper
Control Act Wrapper
Message Type
Activate Care Provision
Send Message Payload
Trigger Event Control Act
Care Record
REPC_TE004110UV
MCCI_MT000100UV01
MCAI_MT700201UV01
REPC_MT004000UV
Sending and Receiving Roles
Sender
Care Provision Informer
Receiver Care Provision Tracker
REPC_AR004010UV
REPC_AR004020UV
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
117
REPC_TE004210UV
MCCI_MT000100UV01
MCAI_MT700201UV01
REPC_MT004000UV
Sending and Receiving Roles
Sender
Care Provision Informer
Receiver Care Provision Tracker
REPC_AR004010UV
REPC_AR004020UV
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
Care Provision Informer
Care Provision Tracker
REPC_AR004010UV
REPC_AR004020UV
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
118
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.
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
Sender
Receiver
Care Provision Informer
Care Provision Tracker
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.
119
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
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.
Trigger Event
Transmission
Wrapper
Control Act Wrapper
Message Type
Report Care Provision
Send Message Payload
REPC_TE004014UV
MCCI_MT000100UV01
Master File / Reg. Notif Control MFMI_MT700702UV01
Act, Act Subject
Care Record
REPC_MT004000UV
Sending and Receiving Roles
Sender
Receiver
Care Provision Reporter
Care Provision Reporting Receiver
120
REPC_AR004014UV
REPC_AR004024UV
7.
7.1
CLINICAL STATEMENT
Inleiding
Dit hoofdstuk beschrijft de “Clinical Statement”. Voor deze tekst is de HL7 ballot van
januari 2007 gebruikt als bronmateriaal.Het Engelse woord clinical kan voor het
Nederlands het beste worden vertaald met zorginhoudelijk, dan wel primaire
zorgproces. Er wordt dus uitdrukkelijk bedoeld om ook buiten het ziekenhuis in
contacten met cliënten informatie vast te leggen en uit te wisselen, zoals in zorgketens.
De “clinical statement” vormt de kern van het CDA bericht en van het “Care Provision
D-MIM” en daarvan afgeleide “R-MIMs”.
Clinical Statement Pattern Domain
Het model dat in dit document beschreven wordt is een ”patroon” dat ontworpen is om
gebruikt te worden binnen verschillende HL7 Versie 3 domeinmodellen. Dit patroon
wordt bedoeld om het consistente ontwerp van communicatie te faciliteren die klinische
informatie overbrengen om specifieke “use cases” te verwezenlijken. Het is niet de
bedoeling dat het ”patroon” zelf ooit gebruikt wordt in een communicatie.
Dienovereenkomstig is de informatie in dit document op een hoog abstractieniveau
beschreven met een minimum aan beperkingen die toegepast worden. Het patroon
representeert niet een “Record Architecture” of een fysieke structur voor het opslaan
van data in een EPD database, hoewel het veel van de types van klinische informatie
beslaat die deel zouden uit moeten maken van een Electronisch Pateinten Dossier. De
“Clinical Statement” ballot zal ballot topics bevatten (met de tijd algemene patronen
zoals Lab, Allergie etc) waarin deze topics zo worden geschreven dat ze zoveel
mogelijk dezelfde structuur hebben als de domeinmodellen waarmee ze
corresponderen.
De formele definitie van ”Clinical Statement” voor de zorg van een patiënt is:
“Een expressie van een discreet object van klinische (of klinisch gerelateerde, waarbij
altijd wordt bedoel het primaire zorgproces) informatie die wordt vastgelegd vanwege
de relevantie voor de zorg voor een patiënt / cliënt. Klinische informatie kan in
verschillende mate van detail omschreven worden en daardoor kan de mate van detail
in een enkele “Clinical Statement” variëren”.
Om beschouwd te worden als een ”Clinical Statement” moet een concept geassocieerd
zijn met een patiënt op een manier die de volgende aspecten duidelijk maakt:
 zijn tijdsgebonden context;
 zijn relatie met de patiënt;
 in het geval van een observatie: zijn ”mood” en de aanwezigheid, afwezigheid, of de
waarde;
 in het geval van een procedure: zijn ”mood” status is;
Deze duidelijkheid kan worden verkregen door:
 expliciete representatie of;
 impliciete applicatie van ‘defaults’ ALLEEN waar expliciet gemodelleerde regels de
correcte ‘defaults’ definiëren.
achtergrond bronnen
121
Dit “Clinical Statement pattern” werd ontwikkeld door vele individuen uit vele landen,
inclusief, maar niet gelimiteerd tot de vertegenwoordigers van het UK National
Programme for Information Technology (NPfIT), het HL7 “Structured Documents
Technical Committee”.
De “Clinical Statement Task Force” erkent al deze individuen en organisaties en wil
hen bedanken voor hun waardevolle bijdrage. Deze standaard is echter niet bedoeld
een afgeleide te zijn van één van deze bronnen en deze bronnen zouden niet gebruikt
moeten worden om enige semantiek die in dit document gecommuniceerd wordt te
interpreteren.
gebruik van het model
Het “Clinical Statement Domein Patroon” representeert een standaard structuur voor
de inclusie van klinische informatie in communicatie met als doel specifieke
bedrijfsfuncties te ondersteunen. Hoewel het niet mogelijk is het te implementeren
zoals het is, kan het “Clinical Statement Domein Patroon” aangepast worden zodat aan
de eisen van vele specifieke communicaties van klinische informatie voldaan wordt.
Het proces van aanpassen zal of patroon beperking of uitbreiding (of soms beide) met
zich meebrengen om aan de behoeften van een bepaald domein te voldoen.
Mogelijkheden voor patroon beperking bevatten:
 de generieke 'Clinical Statement' klasse attributen kunnen beperkt zijn om de
precieze aard van de data die overgebracht moeten worden weer te geven.
Bijvoorbeeld:
 optionele attributen kunnen verwijderd worden wanneer deze niet van toepassing
zijn voor de business case;
 attributen kunnen zelf beperkt zijn:
 multipliciteiten kunnen beperkt worden naar meer beperkte sets; (0..*) kan
bijvoorbeeld beperkt worden tot (1..*);
 waardensets van attributen kunnen beperkt worden tot meer beperkte
waardensets; de “mood code” kan bijvoorbeeld gelimiteerd worden tot ”Event”;
 data typen voor een attribuut kunnen beperkt worden, bijvoorbeeld “ANY naar
CD”;
 associaties kunnen beperkt worden om de potentie voor complexiteit te verwijderen,
bijvoorbeeld: het beperken van een implementatie naar 3 nesting levels; het
verwijderen van “Episode Link” om een implementatie te definiëren naar de “lowest
common denominator” met betrekking tot systeem vermogen;
 klassen kunnen worden beperkt:
 klassen kunnen worden verwijderd als ze niet vereist zijn;
 klassen kunnen worden beperkt tot specifieke subklassen, bijvoorbeeld dat
“Observation Class” wordt beperkt tot “Concern Class”;
 klassen kunnen worden ”gekloond” om specifieke beperkingen voor attributen of
associaties te documenteren.
 klassen waarbij specifieke beperkingen van toepassing zijn, kunnen uitgerold
worden van de “Clinical Statement Keuzebox” om hun gebruik te beperken tot
een specifieke structuur (in dat geval kan niet langer worden aangenomen dat de
beperkte versie van de klasse aanwezig is in de gegeneraliseerde Clinical
Statement Keuzebox).
mogelijkheden voor patroon uitbreiding bevatten:
122
 aanvullingen van klassen, attributen en associaties toegestaan in het RIM
 vergroting van de waarden sets zoals ondersteund in door het RIM geaccepteerde
vocabulaires.
filosofie over uitbreidingen
De intentie van het ”patroon” is dat het de potentie zou moeten hebben om de breedst
mogelijke range van typen klinische informatie te bevatten in een ondubbelzinnige en
samenhangende representatie. In dat licht is er een mogelijkheid dat als in de toekomst
specifiekere eisen worden gesteld, enkele aanvullende klassen, attributen, associaties
en vocabulaire waardensets nodig kunnen zijn. Aanvullingen zouden alleen gemaakt
moeten worden wanneer het algemene model niet in staat is de vereiste informatie te
representeren en dat soort aanvullingen zullen afgeleid moeten worden van het HL7 v3
RIM waarbij de juiste methodologie gevolgd wordt. Deze zouden ingediend moeten
worden bij de “Clinical Statement Task Force” voor inclusie in het patroon. Dit kan
gedaan worden door een verzoek tot verandering aan de “Clinical Statement List” in te
dienen of aan de “Clinical Statement wiki”:
http://informatics.mayo.edu/wiki/index.php/Clinical_Statement_Change_Requests.
Echter, er is geen eis dat uitbreidingen goedgekeurd moeten worden door het “Clinical
Statement Committee” om in de ontwikkeling van domeinen gebruikt te worden. Als er,
na het consulteren van het ”Modeling and Methodology Technical Committee”, een eis
is waaraan niet voldaan kan worden door deze aanpak te volgen dan moet gezocht
worden naar de juiste aanvulling op het HL7 v3 RIM of op de methodologie.
patroon gebruik
Een “Act” buiten het “Clinical Statement Domain-Pattern” model moet als referentie
dienen voor dit patroon. Vaak levert deze externe “Act” het “Entry point” naar een
communicatie specificatie en representeert het de context waarin de “clinical
statement” informatie verzonden wordt. Bijvoorbeeld: de informatie met betrekking tot
wie deze informatie zendt wordt gevonden in een “Act” extern van het “Clinical
Statement Patroon”. De “Care Provision Act” in het “Care Provision Domein” is een
voorbeeld van een “Act” extern van het Patroon.
123
7.1
Clinical Statement Patroon (COCS_DM000000)
Beschrijving
model overzicht
Het model kan verdeeld worden in 3 gerelateerde onderdelen:
 Clinical Statement Act Keuzebox;
 participaties om de Acts heen;
 acts buiten de Keuzebox.
Elk van deze delen wordt hieronder beschreven.
clinical Statement Act Keuzebox
Dit deel van het model wordt gebruikt voor het overbrengen van de gedetailleerde
klinische informatie die verzonden wordt ter ondersteuning van de specifieke zakelijke
behoeften. Naast het leveren van een mechanisme voor het overbrengen van de
componenten van deze informatie, ondersteunt dit het groeperen van deze
124
componenten en levert het mechanismen om beweringen expliciet te verbinden daar
waar een specifieke relatie is.
Daar waar een “Clinical Statement” voorheen overgedragen is en hierdoor bekend is
binnen een informatiesysteem, kan de “Clinical Statement” toegevoegd worden door
middel van referentie of door het herhalen van de volledige bewering. Wanneer de
volledige bewering wordt herhaald moeten alle attributen en de context (hetzij expliciet
of geërfd) identiek zijn.
De “Clinical Statement” heeft de structuur van de keuzebox om het mogelijk te maken
elke klinisch relevante selectie, duplicatie, beperking en ordening van “Acts” in de
communicatie op te nemen.
Alle items in de klinische data zullen gecodeerd kunnen worden via of een HL7 code,
een extern geregistreerd code systeem, of een lokaal afgeleid/ontwikkeld code
systeem. Via de OID structuur zal het juiste code systeem geïdentificeerd worden.
observatie
De klasse observatie bevat informatie over de observatie inclusief de aard en, wanneer
van toepassing, en het resultaat of de bevinding van die observatie.
Dit omvat ook het verzoeken, aanbevelen, beloven, weigeren of het zetten van een
doel dat bereikt moet worden of een risico dat vermeden moet worden van een
observatie, evenals een specifieke instantiatie van een observatie met de resultaten.
Omvat elke soort Observatie subklasse.
De observatie in de “Clinical Statement” is een afgeleide (instantiatie) van de RIM
Observatie klasse, en wordt gebruikt voor het representeren van gecodeerde en
andere observaties.
De waardensets voor “Observation.moodCode (CNE)” zijn die volgens de definitie van
het RIM.
Zoals bij de “Act Klasse” hierboven beschreven, wordt gebruikt gemaakt van de
“Observation.negationInd”. Wanneer de “Observation.negationInd” “true” is, is dat een
positief verklaring dat de beschrijvende attributen van de Observatie als geheel worden
ontkend. Evenzo worden de inerte eigenschappen, zoals “Observation.id”,
“Observation.moodCode” en participaties niet ontkend.
Vooralsnog wordt de “negation indicator” niet gebruikt voor Nederlandse
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
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.
125
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 de frequentie 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” als geheel
worden ontkend.
Zoals hierboven bediscussieerd, worden de inerte eigenschappen, zoals
“SubstanceAdministration.id”, “SubstanceAdministration.moodCode” en participaties
niet ontkend. Deze inerte eigenschappen hebben altijd dezelfde betekenis, zo blijft de
auteur bijvoorbeeld de auteur van een negatieve “SubstanceAdministration”. Een
bewering van substantie toediening met “negationInd” is nog steeds een bewering over
het specifieke feit beschreven door de “SubstanceAdministration”. Bijvoorbeeld: een
ontkende "toediening van aspirine" betekent dat de auteur positief ontkent dat er
aspirine wordt toegediend en dat hij dezelfde verantwoordelijkheid neemt voor zo’n
126
bewering en dezelfde eis om bewijs te hebben voor zo’n bewering als wanneer hij de
ontkenning niet gebruikt had.
Het vastleggen van aan medicatie gerelateerde informatie omvat ook de interrelatie
van “SubstanceAdministration” met verscheidene andere klassen.
supply (levering)
Een afgeleide van de “RIM Supply klasse”, gebruikt voor het representeren van
levering van materiaal door één entiteit aan een ander.
Omvat het aanvragen, aanbevelen, beloven, verbieden of weigeren van zo’n levering,
als ook de daadwerkelijke gebeurtenis van levering.
Merk op dat een recept van een poliklinische patiënt over het algemeen een
aanbeveling voor “SubstanceAdministration” en een verzoek tot Levering bevat.
Dit gedeelte van het patroon zal verder worden geharmoniseerd met Farmacie.
De waardenset voor “Supply.moodCode (CNE)” is volgens het RIM.
De Supply (Levering) klasse representeert het distribueren, terwijl de
“SubstanceAdministration” klasse de toediening administreert. Prescripties zijn
complexe activiteiten die zowel een toedieningsaanvraag aan de patiënt (bijvoorbeeld
neem één maal per dag 0.125mg digoxin via de mond) als een leveringsverzoek aan
de apotheek (bijvoorbeeld: lever 30 tabletten met 5 navullingen) inhouden. Dit zou in
een CDA gepresenteerd moeten worden door een “SubstanceAdministration”
registratie dat een “Supply component” registratie heeft. De geneste “Supply
registratie” kan de “Supply.independentInd” op “false” hebben staan om aan te geven
dat de “Supply” niet op zichzelf kan staan, zonder zijn omsluitende
“SubstanceAdministration”.
procedure
Een afgeleide van de “RIM Procedure klasse”, gebruikt voor het representeren van
procedures.
Een “act” waarvan de directe en voornaamste uitkomst (postconditie) de wijziging is
van de fysieke conditie van het subject.
Omvat het aanvragen, aanbevelen, beloven, verbieden of weigeren van het uitvoeren
van een procedure, als ook de daadwerkelijke act van het aanvaarden van de
procedure.
De waardenset voor “Procedure.moodCode (CNE)” is volgens het RIM.
Wanneer de “Procedure.negationInd” “true” is, is dat een positief verklaring dat de
beschrijvende attributen van de Procedure as geheel worden ontkend. De inerte
eigenschappen, zoals “Procedure.id”, “Procedure.moodCode” en participaties worden
niet ontkend. Deze inerte eigenschappen hebben altijd dezelfde betekenis, zo blijft de
auteur bijvoorbeeld de auteur van een negatieve Procedure. Een procedure bewering
met “negationInd” is nog steeds een bewering over het specifieke feit beschreven door
de Procedure. Bijvoorbeeld: een ontkende "blindedarmoperatie uitgevoerd" betekent
dat de auteur positief ontkent dat er ooit een blindedarmoperatie is uitgevoerd en dat
hij dezelfde verantwoordelijkheid neemt voor zo’n statement en dezelfde eis om bewijs
te hebben voor zo’n statement als wanneer hij de ontkenning niet gebruikt had.
encounter (afspraak)
Een interactie tussen een patiënt en zorgverlener(s) met tot doel het leveren van
zorggerelateerde dienst(en). Zorgdiensten omvatten ook de zorg bepaling.
127
Merk op dat dit type bewering toelatingen, ontslagen en overdrachten van zorg omvat
als ook het meer gebruikelijke begrip van een afzonderlijk, discreet bezoek, consult of
visite.
Verder handelt het een plan af voor regelmatige bezoeken, zoals preventieve zorg
tijdens zwangerschap of het monitoren van chronisch zieke patiënten.
Omvat het aanvragen, voorstellen, beloven, verbieden of weigeren van een encounter,
als ook de daadwerkelijke encounter gebeurtenis.
Een afgeleide van de “RIM PatientEncounter klasse”, gebruikt voor het representeren
van gerelateerde “encounters”, zoals follow-up bezoeken of vorige encounters waaraan
gerefereerd wordt.
De waardenset voor “Encounter.moodCode (CNE)” is volgens het RIM.
organizer
Een afgeleide van de “RIM Act klasse”, welke gebruikt kan worden voor het creëren
van arbitraire groepen van andere “clinical statements” die een gemeenschappelijke
context delen. Een “Organizer” kan andere “Organizers” en/of ander klinische
beweringen bevatten, door het doorkruisen van een component relatie. Een
“Organizer” kan verwijzen naar “acts” via een referentie of via de component relatie.
Een “Organizer” kan niet de bron zijn van de “sourceOf1”, “sourceOf2”, Definitie of
conditie relaties.
“Organizer” van registraties. Dit is een “organizer” van registraties voor navigatie. Bevat
geen semantische inhoud. Kennis van de actiecode is niet vereist voor het
interpreteren van opgeslagen observaties. Representeert een titel in een hiërarchische
structuur of “organizer boom”.
De dossier registraties die gerelateerd zijn aan een alleenstaande klinische sessie
worden meestal gegroepeerd onder titels of rubrieken die fasen van de encounter
representeren of assisteren met lay-out en navigatie. Klinische titels reflecteren
meestal de klinische werkprocessen tijdens een zorgsessie en kunnen ook de
redeneringsprocessen van de auteur weergeven. Veel onderzoek heeft uitgewezen dat
titels verschillend worden gebruikt door verschillende groepen professionals en
specialisaties en dat titels niet consequent genoeg gebruikt worden om veilige
automatische verwerking van het Elektronisch Patiënten Dossier te ondersteunen.
Verscheidene specifieke typen van verzameling worden herkend (map, compositie,
onderwerp, categorie, cluster en batterij), hoewel individuele communicatie de typen
die gebruikt kunnen worden voor use cases van individuele communicatie zullen
beperken.
Een “Organizer” kan over het algemeen een SNOMED CT “concept identifier”
toegewezen worden die geschikt is voor zijn type (bijvoorbeeld: een categorie kan
geïdentificeerd worden als 'investigations' en een batterij kan geïdentificeerd worden
als ‘Full blood count’). Echter, alle soorten “concept identifiers” kunnen gebruikt
worden.
De “Organizer” kan gebruikt worden om “Clinical Statements” te harmoniseren met de
CEN/ISO 13606 standaard.
Merk op: “Clinical Statement ActChoice Acts” zoals “Organizers” kunnen ook andere
“ActChoice Acts” bevatten door de “sourceOf2” klasse te gebruiken. Er is geen eis dat
de registratie van de “Organizer” gebruikt moet worden om klinische beweringen te
groeperen. De waardenset voor “Organizer.moodCode (CNE)” is volgens het RIM.
act klasse
128
Een afgeleide van de “RIM Act klasse”, te gebruiken wanneer andere meer specifiek
klassen niet geschikt zijn.
Attributen van de “Act Klasse”:
“Act.negationInd”: wanneer deze ‘true’ is, is het een positieve bevestiging dat de
beschrijvende attributen van de “Act” als geheel worden ontkend. De inerte
eigenschappen zoals “Act.id”, “Act.moodCode” en de participaties worden niet ontkend.
Deze inerte eigenschappen hebben altijd dezelfde betekenis, zo blijft de auteur
bijvoorbeeld de auteur van een negatieve “Act”. Een “act statement” met “negationInd”
is nog steeds een bewering over het specifieke feit beschreven door de “Act”.
Bijvoorbeeld: een ontkende “bevinding van kortademigheid op 1 juli” betekent dat de
auteur positief ontkent dat er kortademigheid was op 1 juli en dat hij/zij dezelfde
verantwoordelijkheid voor zo’n bewering neemt en dezelfde eis om bewijs te hebben
voor zo’n statement als wanneer hij/zij de ontkenning niet gebruikt had.
De waardensets voor “Act.moodCode (CNE)” zijn gedefinieerd in het RIM.
“Clinical statement pattern” gebruikt het “Act.negationInd”” attribuut. Wanneer deze
”true” is, is het een positieve bevestiging dat de beschrijvende attributen van de “Act”
als geheel worden ontkend. De inerte eigenschappen zoals “Act.id”, “Act.moodCode”
en de participaties worden niet ontkend. Deze inerte eigenschappen hebben altijd
dezelfde betekenis, zo blijft de auteur bijvoorbeeld de auteur van een negatieve “Act”.
Een “act statement” met “negationInd” is nog steeds een bewering over het specifieke
feit beschreven door de “Act”. Bijvoorbeeld: een ontkende “bevinding van
kortademigheid op 1 juli” betekent dat de auteur positief ontkent dat er kortademigheid
was op 1 juli en dat hij/zij dezelfde verantwoordelijkheid voor zo’n statement neemt en
dezelfde eis om bewijs te hebben voor zo’n statement als wanneer hij/zij de ontkenning
niet gebruikt had.
attributen van Clinical Statements
Over het algemeen volgt het gebruik van attributen binnen klassen die de “Clinical
Statements” representeren de standaard HL7 v3 regels.
moodCode
De HL7 v3 modelleeraanpak volgend kunnen de meeste klassen binnen het
“ClinicalStatement” een “moodCode” toegewezen krijgen die aangeeft of er sprake is
van een daadwerkelijke gebeurtenis of van het uiten van een verzoek, voorstel, belofte,
afspraak of doel. De enige uitzondering is “Organizer.moodCode” welke altijd de
waarde “EVN”heeft.
Het gebruik van “moodCode” overlapt met SNOMED CT context attributen. De
SNOMED CT “concept identifiers” en “expressions” die gebruikt worden in het code
attribuut moeten de “moodCode” niet tegenspreken. Het “Terminfo project” levert
begeleiding bij de verbinding tussen “moodCode” en het SNOMED CT context model
voor de verschillende klassen in het “Clinical Statement” patroon.
id
Elke instantiatie van een “Clinical Statement” zou geïdentificeerd moeten worden door
middel van een id in de vorm van een “UUID (Universal Unique IDentifier)”. Dit
identificeert de specifieke “Clinical Statement” op een unieke manier, zodat wanneer
precies dezelfde informatie (statement en context) vereist wordt, gerefereerd aan of
dezelfde communicatie of in andere communicatie, dat dan dezelfde identifier waarde
129
gebruikt zal worden in een “ActReference” om aan de originele “Clinical Statement” te
refereren.
Omgekeerd, als niet alle attributen en context van een “Clinical Statement” klasse
identiek zijn, dan is er sprake van een andere “Clinical Statement” en dan zal een
nieuwe “UUID” toegewezen worden. Dit betekent:
 een subset van een “Clinical Statement” is een andere “Clinical Statement”, die een
andere “UUID” vereist;
 een “Organizer” waarvan één van de 'contained' statements wordt gemodificeerd is
een nieuwe statement die een nieuwe “UUID” vereist.
Het “clinical statement” patroon staat toe dat “Clinical Statements” meerdere identifiers
bevatten. Dit maakt het mogelijk dat “Clinical Statements” geïdentificeerd kunnen
worden door een ”human readable identifier” in aanvulling op de “UUID” en zal altijd
gerepresenteerd worden door een OID en code waarde. Het gebruik hiervan zou
identifiers kunnen bevatten als bestelnummer van de afdeling, nummer van de
episode, etc. wanneer dit vereist is door specifieke communicatie use cases.
code
Het code attribuut wordt gebruikt om de aard van de informatie, die overgedragen
wordt door een instantiatie van een “Clinical Statement Act”, vast te stellen. Code kan
in sommige specificaties optioneel zijn. De cardinaliteit en de conformatie van het code
attribuut in de Observatie in act is 1..1 vereist. Terwijl het attribuut aanwezig moet zijn
in alle instantiaties van de Observatie is het toegestaan om een null flavor te versturen
als legale waarde. Het HL7 v3 data type van het code attribuut is CD (Concept
Descriptor). Het CD data type staat de inclusie toe van:
 de tekst die door het coderingsschema toegewezen wordt aan de code (displayText)
en de tekst waarop de encodering gebaseerd was (originalText);
 “qualifiers” en het type, gebruikt in SNOMED CT (inclusief context attributen) om de
betekenis van een primaire code te verfijnen;
 elke “qualifier” is een naam + waarde paar waarbij de naam is uitgedrukt in een
code en de waarde als een andere instantiatie van het CD data type (met
toestemming voor nested qualifiers, wanneer nodig);
 vertalingen om de representatie van het concept toe te staan in het
coderingsschema waarin het ontstaan is als ook zoals vertaald in andere
geprefereerde terminologieën.
 merk op dat de originele code wordt uitgedrukt op het buitenste niveau met
daarbinnen de vereiste code (als deze anders is) uitgedrukt als een vertaling. De
mogelijkheid de originele codes te herkennen is van belang om toekomstige
vertalingen, gebaseerd op verbeterde mapping, mogelijk te maken. Dus, als de
data van origine gecodeerd was in een ander coderingssysteem, moet de
originele code toegevoegd zijn bij de vertaling die de SNOMED CT representatie
bevat.
Het CD data type ondersteunt het gebruik van pre en postcoördinatie van vocabulaire
uitdrukkingen en dit model stelt geen restricties aan hoe deze expressies worden
gepresenteerd, anders dan de beperkingen opgelegd door de respectieve
terminologieën.
value (waarde)
130
“Observation.value” is informatie die toegewezen of bepaald wordt door de observatie
actie.
De vraag is nu hoe “Observation.code” en “Observation.value” moeten worden
ingevuld. Terwijl dit kenmerkend rechtlijnig is voor laboratorium observaties, kan het
vaag worden voor andere typen observaties, zoals bevindingen en stoornissen en
familiegeschiedenis. Het HL7 Terminfo Project heeft principes gedefinieerd voor
verschillende manieren om deze twee attributen te gebruiken. De klinische
terminologie die wordt gebruikt als code attribuut is de SNOMED Clinical Terms (CT).
Het data type van het “Observation.value” attribuut varieert en waar de uitdrukking in
een “Observation.code” een waarde vereist, wordt de subset van toegestane data
typen beperkt door de code. Als de “PQ data type” wordt gebruikt, dan moeten de
“UCUM codes” worden gebruikt om de meetunits te representeren.
priorityCode
Het “priorityCode” attribuut heeft een potentiële overlap met sommige vocabulaires.
Het potentiële conflict kan als volgt opgelost worden:
 “priorityCode” zou alleen gebruikt moeten worden om de urgentie, waarmee de
ontvanger van het bericht zou moeten reageren op de informatie in de “Act”, aan te
geven. Bijvoorbeeld: het verzoek voor een procedure zou als dringend beschouwd
moeten worden. Daar uit voortvloeiend is het wenselijk dat het gebruik van
“priorityCode” gelimiteerd zou moeten worden tot “acts” die in de “Intent mood” zijn;
 “Act.code” vocabulaire expressies zouden gebruikt moeten worden om de klinische
urgentie van de expressie die in het code attribuut staat aan te geven. Bijvoorbeeld:
het concept ‘een nood blindendarmoperatie’ zou in z’n geheel binnen een “Act.code”
weergegeven worden.
Act.code afhankelijke attributen in het Clinical Statement model
Sommige gecodeerde attributen die opgenomen zijn in het HL7 v3 RIM zijn met opzet
optioneel gemaakt in “Act” klassen in dit model, omdat zij kwalificaties representeren
die binnen het terminologie model beter afgehandeld worden (bijvoorbeeld het
gebruiken van SNOMED CT beperkingen binnen het code attribuut, waar mogelijk).
Deze omvatten:
 “negationInd”;
 “uncertaintyCode”;
 “priorityCode”;
 “statusCode”;
 “observation.methodCode”;
 “observation.targetSiteCode”;
 “procedure.methodCode”
 “procedure.targetSiteCode”;
 “procedure.approachSiteCode”.
De basis voor het als optioneel beschouwen van deze attributen is dat flexibiliteit is
vereist bij domeinen om de gekozen vocabulaire te implementeren zonder
ambiguïteiten.
Zulke ambiguïteiten kunnen gerelateerd zijn aan het feit of een bepaald concept in een
“Act.code” expressie of in een andere “Act” klasse attribuut waarde wordt opgenomen.
Het terminfo project geeft aan hoe de attributen moeten worden gebruikt in de
modellen en berichten als SNOMED CT het gebruikte codesysteem is.
131
het linken van Statements
Het model reikt drie mechanismen aan die het mogelijk maken “Clinical Statements” te
linken door de “Act Relationship” Klasse:
 inhoud (Containment);
 directe relatie;
 referentie.
Dit zijn allemaal verfijningen van dezelfde algemene structuur en delen de volgende
faciliteiten:
 “inversionInd”; wanneer “true” verandert het de richting van de relatie, ‘Oorzaak van’
wordt bijvoorbeeld ‘Veroorzaakt door’ (zie Context en Overerving (Inheritance) voor
hoe dit werkt bij Context Overerving);
 “negationInd”; wanneer “true”staat dit de zender toe om specifiek aan te geven dat
de relatie niet van toepassing is. Bijvoorbeeld dat een observatie niet veroorzaakt
werd door een medicijn.
Er is enige overlap in het potentiële gebruik van deze 3 relatie mechanismen wat op de
volgende manier opgelost zal worden:
containment
Het groeperen van klassen van klinische/zorginhoudelijke data wordt bereikt door het
gebruiken van verzamelklassen zoals de “Organizer klasse” (een specialisatie van de
Observatie klasse code) geassocieerd met een “Component' Act Relatie” die terugkeer
van de “Clinical Statement”structuur ondersteunt.
Het groeperen kan voor verschillende doeleinden gebruikt worden, inclusief:
 beweringen
met
elkaar
in
verband
brengen.
Bijvoorbeeld:
een
zwangerschapscontrole kan individuele observaties bevatten van gewicht van de
moeder, bloeddruk van de moeder, grootte van de foetus, hartslag van de foetus,
etc.;
 beweringen die gerelateerd zijn aan een specifiek probleem, in het geval van een
“Concern”, met elkaar verbinden. (Zie hiervoor de specifieke uitwerking bij Care
Provision).
“Organizer”: Het toegestane type van groeperen wordt beperkt door de vocabulaire die
gebruikt wordt in het “Organizer.code attribuut”. Specifieke vocabulaire beperkingen
zullen in individuele communicatie ontwerpen toegepast worden, gebaseerd op de
communicatie eis die aangesproken wordt.
directe relatie
Dit verbinden wordt ondersteund door het terugkeren op het “Clinical Statement”, met
“ActRelationship.typeCode” die de aard van de link tussen de beweringen ondersteunt.
Het wordt gebruikt om een “Clinical Statement” toe te voegen aan een communicatie
die relateert aan een andere toegevoegde “Clinical Statement”, maar niet direct
relevant is voor de “Focal Act”, bron “Act” of doel van de communicatie.
Een voorbeeld is een vorige observatie die tijdens een contact (encounter) is gedaan
en die een huidige observatie verklaart. In dat geval wordt de vorige conditie alleen
toegevoegd aan de communicatie om de observatie te verklaren en niet omdat het
werd geïdentificeerd tijdens het contact (encounter).
132
Daar waar de ondersteunde “Clinical Statement” al beschikbaar is van een vorige
communicatie kan de link via referentie-aanpak gebruikt worden om dit type van linken
over te brengen.
referentie
Het linken van “Clinical Statements” door referentie wordt ondersteund door de
“sourceOf1” “Act Relatie” tussen de “Clinical Statement” en “ActReferentie”, weer met
“typeCode” die de aard van de link specificeert. Er zijn drie gevallen voor het gebruik:
 voor het handhaven van een link naar een “Clinical Statement” die al in een
communicatie-instantiatie aanwezig is voor een ander doel, waardoor onnodige
duplicatie voorkomen wordt;
 voor het handhaven van een link naar een “Clinical Statement” die direct gerelateerd
wordt aan het doel van de communicatie maar die gestuurd is als deel van een
eerdere notificatie;
 om een link naar een “Clinical Statement” die al beschikbaar is als een resultaat van
een niet-gerelateerde communicatie.
De “ActReference.classCode” en “ActReference.moodCode” zullen de waarden
aannemen van de doel “Act”, en “ActReference.id” is de “UUID” van het doel “Clinical
Statement”.
context en Overerving (Inheritance)
Hoewel potentieel complex, context overerving biedt een essentiële faciliteit die:
 de noodzaak elimineert om de volledige context van elke Clinical Statement expliciet
te specificeren, zoals in het algemene geval kan dit geërfd worden van de bron
statement;
 een mechanisme aanreikt dat toestaat dat specifieke items van context opgeheven
worden wanneer dit gepast is. Bijvoorbeeld: de 'auteur' van een resultaat van een
reeks (battery) wordt geacht de auteur te zijn van alle componenten, maar elke test
binnen de reeks zou door een andere persoon of apparaat uitgevoerd kunnen zijn.
Volgens de HL7 v3 afspraken specificeert de bron klasse (de klasse aan de botte kant
van de SourceOf pijl) altijd de context waarin de “SourceOf” van kracht was. Dus deze
bron klasse geeft de toekenning van de link aan (tijd, auteur, etc.). De semantische
richting van het relatietype (zoals aangegeven door SourceOf.typeCode) kan
omgekeerd worden door het gebruiken van de “inversionInd”. Omdat dit niet de
bijbehorende context omkeert staat het toe dat de volledige omvang van
richtingsrelaties uitgedrukt wordt van de context van één van de gerelateerde klassen.
De “seperatableInd” in een “Act Relatie” geeft aan of de auteur bereid is voor de inhoud
van de bron “Act” in te staan als het wordt gescheiden van de doel “Act”. Een waarde
”false” geeft aan dat het de bedoeling is dat de twee “acts” niet gescheiden worden
voor interpretatie. Dit kan duidelijk niet opgelegd worden, maar is bedoeld als een
waarschuwing voor de ontvanger van de bedoeling van de auteur. De waarde van de
“seperatableInd” wordt niet buiten de doel “Act” verspreid, ongeacht andere context
overerving.
Alleen als een “Act Relatie” specifiek het tegenovergestelde aangeeft (een waarde
“true” in de “contextConductionInd”), wordt de context niet overgeërfd van de bron naar
het doel.
Als de “contextConductionInd” in een “Act Relatie” op “false” wordt gezet dan wordt
niets van de context van de bron “Act” geërfd door de doel “Act”. Echter, als de waarde
133
op ”true” wordt gezet wordt alles van de context geërfd, behalve de Participaties in de
bron “Act”waar de “contextControlCode” op een ”non-propagating” waarde wordt gezet.
Waar een specifieke Participatie wordt meegegeven aan een “Act”, overschrijft dit elke
geërfde Participatie van hetzelfde type, behalve als de “contextControlCode” naar een
“additive” waarde wordt gezet wanneer de specifieke Participatie als een toevoeging
aan de geërfde waarde is (bijvoorbeeld: er zijn meerdere Participaties van hetzelfde
type). Context die op deze manier geërfd is, wordt beperkt tot Participatie in een “Act”.
Zie de RIM sectie van de HL7 v3 Standaard.
“Act Relaties” die een “ActReference” als hun doel hebben, voeren nooit de context
aan, omdat de context van de “Clinical Statement” waar aan gerefereerd wordt, wordt
gedefinieerd op basis zijn originele setting.
patiënten
De patiënt wordt gezien als het Subject van iedere “Clinical Statement” in de
communicatie behalve wanneer het expliciet wordt aangegeven dat dit niet het geval is
voor de gespecificeerde statement(s). Dit kan op één van de volgende manieren
aangegeven worden:
 de “Clinical Statement” heeft een subject participatie die details van de persoon aan
wie de statement gerelateerd is geeft;
 optioneel, in sommige domeinen, heeft het SNOMED CT concept in het code
attribuut een context die refereert aan iemand anders dan de patiënt, bijvoorbeeld:
Vader heeft een geschiedenis van Diabetes;
deelnemers (Participants)
“Clinical statements” kunnen verschillende deelnemers hebben. Deelnemers, verspreid
door de “focal” of bron “Act”, kunnen te niet gedaan worden binnen de “clinical
statement”. Deze participaties bevatten:
 “recordTarget”;
 subject;
 “authors“
 “performer”;
 “informant”;
 “dataEnterer”;
 “verifier”;
 “responsibleParty”;
 “consumable”;
 “product”;
 “location”.
“Clinical Statements” kunnen verschillende deelnemers hebben. Deelnemers, verspreid
door de “focal” of bron “Act”, kunnen te niet gedaan worden binnen de “clinical
statement”. De waardensets voor “typeCodes (CNE)” en “contextControlCodes (CNE)”
voor alle deelnemers zijn gedefinieerd in de RIM.
recordTarget
De record target is de entiteit waarvoor de “Clinical Statement” wordt vastgelegd. De
target entiteit informatie wordt opgenomen in de “R_Patient CMET”.
De
waardensets
voor
“recordTarget.typeCode
(CNE)”
en
“recordTarget.contextControlCode (CNE)” zijn gedefinieerd in de RIM.
134
auteur
Representeert de mensen en/of machines die het document geautoriseerd hebben.
Dat kan een toegewezen persoon/organisatie, zoals een zorgverlener of een familielid
zijn (R_AssignedEntity) of de patient zelf (R_Patient). De auteur kan worden
toegewezen aan een “clinical statement” die waarden vanuit de “focal or source act”
overschrijft en gevolgen heeft voor geneste “Acts”.
De waardensets voor “author.typeCode (CNE)” and “author.contextControlCode
(CNE)” zijn gedefinieerd in de RIM.
Een auteur is een persoon in de rol van een verzorger, patiënt of gerelateerde entiteit.
De auteur-participant is gerelateerd aan een clinical statement waar het de waarde(n)
vastlegt in een bron act.
consumable (het gebruikte)
De “consumable” participatie wordt gebruikt om de toegediende substantie te
beschrijven. Dat kan zijn een “R_Medication CMET” of “AdministerableMaterial”
entiteit. Het geproduceerde materiaal in de “R_Medication CMET” of de “Material
klasse”, identificeert het medicijn dat volgens de substance administratie is genomen.
De entiteit Materiaal wordt gebruikt voor het identificeren van toegediende substanties
die geen medicatie zijn, zoals vaccines en bloedproducten.
De set waarden voor “consumable.typeCode (CNE)”, “ManufacturedProduct.classCode
(CNE)”, “LabeledDrug.classCode (CNE)”, “Material.classCode (CNE)”,
en
“Material.determinerCode (CNE)” zijn gedefinieerd in de RIM.
informant
Een informant (of bron van informatie) is een persoon die relevante informatie levert,
zoals de ouder van een comateuze patiënt die het gedrag van de patiënt van voor de
coma beschrijft. Dit kan een aangewezen persoon of organisatie zijn
(R_AssignedEntity) zoals een verzorger, gerelateerde partij zoals een familielid of raad,
of de patiënt zelf (R_Patient). De “RelatedEntity” rol wordt gebruikt om een informant
zonder “rol.id” te representeren (bijvoorbeeld een ouder of een man op straat). In dat
geval heeft de informant enige formele of persoonlijke relatie met de patiënt.
“RelatedEntity.code” kan gebruikt worden om de aard van de relatie te specificeren.
De “R_AssignedEntity” rol wordt gebruikt voor een geïdentificeerde informant en wordt
bereikt (scoped) door een Organisatie.
De informant participant kan toegewezen worden aan een “clinical statement” waar het
de waarde(n) onderdrukt van de “focal” of bron “Act” en verspreidt aan geneste “Acts”.
De waardensets voor de “informant.typeCode (CNE)”, “informant.contextControlCode
(CNE)” en “RelatedEntity.classCode (CNE)” zijn gedefinieerd in de RIM.
uitvoerder (performer)
De performer is een persoon die een bepaalde “act”, of delen van een “act”, uitvoert of
uit zal voeren. De “performer” hoeft niet de voornaamste verantwoordelijke deelnemer
te zijn, bijvoorbeeld een arts-assistent die onder de verantwoordelijkheid van een
aanwezige chirurg valt is een “performer”. De waardenset voor “performer.typeCode
(CNE)” is gedefinieerd in de RIM.
product
Het uitgereikte product wordt geassocieerd met de “Supply act” via een product
participant, die aan de “ManufacturedProduct rol” verbonden is. Dit kan een
135
“LabeledDrug entity” of Materiaal zijn. De waardenset voor “product.typeCode (CNE)”
is gedefinieerd in de RIM.
component
De component relatie heeft “Organizer” als bron (zie Organizer, en een doel dat een
andere Clinical Statement is en wordt gebruikt om groepen clinical statements binnen
een Organizer te maken). De waardenset voor “component.typeCode (CNE)” is
gedefinieerd in de RIM.
condities
De preconditie klasse, afgeleid van de “ActRelatie klasse”, wordt gebruikt naast de
“Criterion klasse” om een conditie uit te drukken die waar moet zijn voordat enkele
over-activiteit “Clinical Provision” ontstaat.
referenceRange
De “referenceRange relatie” (zie de beschijving bij Observatie), heeft een Observatie
als bron en een doel dat een andere “CDA entry” is.
sourceOf2/targetOf
“Clinical Statement” heeft verschillende link scenario’s geïdentificeerd en
gemodelleerd. Deze scenario’s maken het mogelijk dat “ActChoice Acts” semantisch
gelinkt kunnen worden aan “Acts” die bestaan binnen hetzelfde document of bericht.
Merk op: Het “Clinical Statement” model staat toe dat elke “ActChoice Act” aan elke
“ActChoice Act” gerelateerd kan worden door één van de volgende relatietypen te
gebruiken. In veel gevallen zou dit resulteren in onzinnige relaties.
De “sourceOf2.inversionInd” kan op "true" gezet worden om aan te geven dat de relatie
geïnterpreteerd zou moeten worden alsof de rollen van de bron en het doel entries
omgekeerd waren. In het voorbeeld in de bovenstaande Tabel, "tredmolen test" RSON
(has reason) "pijn op de borst". Omgekeerd, zou deze "pijn op de borst " als de bron en
" tredmolen test " als het doel hebben: "pijn op de borst" RSON (inverted) "tredmolen
test". Omkeren kan nuttig zijn wanneer de huidige context het doel van een act relatie
beschrijft die teruggerelateerd moet zijn aan de bron.
De “actRelationship.contextConductionInd” verschilt van het anders zo algemene
gebruik van dit attribuut waarbij in alle gevallen waarin dit attribuut wordt gebruikt de
waarde vaststaat op "true", terwijl hier de default waarde op "true" staat en veranderd
kan worden naar "false" wanneer gerefereerd wordt aan een “entry” in hetzelfde
document. Het naar “false “zetten van de context wanneer gerefereerd wordt aan een
entry in hetzelfde document houdt het feit duidelijk dat het object waar aan gerefereerd
wordt zijn originele context behoudt.
sourceOf1
De “Clinical Statement” heeft diverse referentie scenario’s geïdentificeerd en
gemodelleerd. Deze scenario’s maken het mogelijk dat “ActChoice Acts” semantisch
kunnen worden verbonden aan “Acts by reference” die bestaan binnen hetzelfde
document/bericht of horen bij “external Acts”.
Elk object heeft een “identifier”.
Act Buiten de Clinical Entry Keuzebox
NOTE: Dit gedeelte moeten worden uitgebreid met statements over wanneer de
strategie wordt gebruikt, wat het betekent voor het Patroon, etc.
136
8.
Conclusie
In deze gids zijn de belangrijkste onderdelen voor Nederland opgenomen. De HL7 v3
Standaard Care Provision is uitgebreider dan hier is besproken. Voor Nederland zijn
die aanvullende items mogelijk van belang en die kunnen in de toekomst worden
opgepakt.
Naast deze generieke implementatiehandleiding is per project een nadere specificatie
noodzakelijk. Die wordt in een domein specifieke aanvulling per project uitgewerkt.
Concrete voorbeelden zijn voor PRN en de WMO.
137