Architectuur en Use Cases
Interoperabiliteit Telemonitoring Hartfalen
Datum 30 mei 2011
Auteurs Nictiz – Arina Burghouts Nictiz – Gé Klein Wolterink
Versie v1.0
© Nictiz
www.nictiz.nl
Samenvatting
In dit document wordt de basis gelegd voor het oplossen van een aantal interoperabiliteitsvraagstukken op het gebied van telemonitoring bij chronisch hartfalen (CHF). Daarvoor is een proces gestart waarbij partijen betrokken zijn, met name zorgverleners en leveranciers (zie Bijlage 1), die concrete praktijkervaring hebben met telemonitoring bij CHF. Door het uitwerken van de systeemrollen (hoofdstuk 2) wordt inzicht gegeven in de verschillende actoren die een rol kunnen spelen in het telemonitoringproces. Ook wordt beschreven welke partijen welke rol kunnen invullen in de praktijk. Een systeembeschrijving (hoofdstuk 3) laat zien hoe een telemonitoringsysteem (TMS) er in de praktijk uit ziet en geeft een indruk van de verschillende varianten die in de markt beschikbaar zijn. In een architectuurmodel (hoofdstuk 4) worden de verschillende systeeminterfaces gedefinieerd. Een aantal daarvan zijn en blijven (voorlopig) leveranciersspecifiek. Voor een drietal interfaces zijn betrokken partijen het erover eens dat het wenselijk is om daar gezamenlijke afspraken over te maken zodat het standaardinterfaces kunnen zijn. Die drie standaardinterfaces zijn: An En Pn
Meetapparaat - Gateway Backoffice TMS - Informatiesystemen zorgaanbieders (XIS) Backoffice TMS - PGD-systemen
De prioriteit voor het vinden van oplossingen ligt bij interface En. Vanuit de betrokken partijen zijn een aantal gewenste functies m.b.t. interoperabiliteit benoemd. Deze zijn uitgewerkt in use cases. Twee bedrijfsprocessen, het logistiek proces en het medisch proces, zijn uitgewerkt. Het logistiek proces (hoofdstuk 5) heeft te maken met het bestellen, installeren en onderhouden van het TMS. Het medisch proces (hoofdstuk 6) beschrijft het feitelijke gebruik, het meten van vitale waarden, het vastleggen van vragen en antwoorden en de actie die volgt. Beide processen worden beschreven aan de hand van een algemene use case die de actoren en de verschillende acties beschrijft. Vervolgens zijn door de betrokken partijen, op basis van hun praktische ervaringen, een aantal meer gedetailleerde use cases gedefinieerd die concrete interoperabiliteitsvraagstukken beschrijven die zich in de praktijk voordoen. Die gedetailleerde use cases m.b.t. interoperabiliteit zijn: LP1 LP2a LP2b MP1 MP2 MP3 MP4 MP5 MP6
Bestellen van een telemonitoringdienst via het XIS met automatische gegevensoverdracht. Wijzigen van patiëntgegevens en zorgverleneridentiteit via het XIS Wijzigen van systeemconfiguratie en –instellingen via het XIS (incl. beëindiging van dienst) Openen van het juiste dossier in het XIS vanuit het TMS met één klik (SSO) Openen van het juiste dossier in het TMS vanuit het XIS met één klik (SSO) Realtime monitoren van de vitale waarden van de patiënt in het XIS Rapportage van de vitale waarden van de patiënt in het XIS Monitoren van symptomen en leefstijl van de patiënt in het XIS Bekijken van medische informatie uit het XIS in het TMS
De volgende stap is het uitwerken van de interoperabiliteitsvraagstukken die zijn beschreven in de genoemde use cases voor het interface En in de vorm van interoperabiliteitsprofielen. Daarbij is het belangrijk om alle niveaus van interoperabiliteit mee te nemen: organisatie en proces, informatie, applicaties, techniek en infrastructuur (hoofdstuk 7). De resultaten zoals beschreven in dit document (interoperabiliteitsvraagstukken, use cases, interfacedefinitie) vormen de basis voor die volgende stap. Die resultaten sluiten aan bij concrete issues zoals die spelen in de praktijk en worden ondersteund door de partijen die bij het proces betrokken zijn.
Mei 2011
3
Tijdens een workshop op 12 mei 2011 is besloten dat in fase 2 de volgende interoperabiliteitsprofielen zullen worden uitgewerkt: -
het interoperabiliteitsprofiel Gegevensoverdracht, met daarin de functionaliteit zoals beschreven in use cases MP3, MP4 en MP5,
-
het interoperabiliteitsprofiel Logistiek, met daarin de functionaliteit zoals beschreven in use cases LP1, LP2a, LP2b en MP6.
Er is besloten de functionaliteit van MP1 en MP2 voorlopig niet uit te werken in een interoperabiliteitsprofiel.
4
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
Inhoud
H-1
Inleiding
6
1.1. 1.2. 1.3. 1.4.
Achtergrond Project Proces Dit document
6 6 7 7
H-2
Rollen
9
2.1. 2.2.
Systeemrollen Marktpartijen
9 10
H-3
Systeembeschrijving
13
3.1. 3.2. 3.3. 3.4. 3.5.
Algemeen Omgeving patiënt Backoffice aanbieder telemonitoringdiensten Omgeving zorgverlener Omgeving aanbieder PGD
13 14 14 15 15
H-4
Architectuurmodel
16
4.1. 4.2.
Systeeminterfaces Referentiearchitectuur
16 18
H-5
Logistiek proces en use cases
19
5.1. 5.2.
Procesbeschrijving Interoperabiliteitsaspecten en use cases
19 20
H-6
Medisch proces en use cases
23
6.1. 6.2.
Procesbeschrijving Interoperabiliteitsaspecten en use cases
23 25
H-7
Interoperabiliteit
29
7.1. 7.2.
Interoperabiliteitsniveaus Interoperabiliteitsprofielen
29 30
Bijlage I.
Deelnemers
31
Bijlage II.
Use case format
32
Bijlage III. Definities en afkortingen
Mei 2011
33
5
H-1 Inleiding
1.1.
Achtergrond
Er zijn verschillende redenen waarom in de praktijk opschaling van eHealth-producten en -diensten minder snel plaatsvindt dan gewenst. Zo heeft het eHealthNu initiatief een zevental barrières benoemd waarvan het gebrek aan uniformering en standaardisatie er één is (zie: http://www.ehealthnu.nl/barrieres). In de periode 2009-2010 is er vanuit eHealthNu een werkgroep Chronisch Hartfalen gevormd om deze barrières te adresseren met betrokkenheid van experts uit het veld. De resultaten en conclusies van deze werkzaamheden en de bijbehorende rapportage vormen de uitgangspunten voor concrete initiatieven rond inkoopvoorwaarden en financiering door ZN (Zorgverzekeraars Nederland) en interoperabiliteit zoals in dit document beschreven. Nictiz heeft met een aantal (industriële) partners het initiatief genomen tot het eHForum (eHealth Forum), een onafhankelijk platform voor het bevorderen van de interoperabiliteit van eHealth-producten en -diensten. Het platform is de basis voor samenwerking van de verschillende eHealth-stakeholders in Nederland om tot concrete interoperabiliteitsoplossingen te komen op basis van een gezamenlijk afgesproken proces. Tot die stakeholders behoren zorginstellingen, zorgprofessionals, patiëntenvertegenwoordigers, bedrijfsleven, koepels, zorgverzekeraars, regionale samenwerkingsverbanden, overheden en kennisinstituten. Uitgangspunt bij de gekozen aanpak zijn in alle gevallen concrete use cases uit het veld.
1.2.
Project
Dit document is onderdeel van een project om te komen tot interoperabiliteitsprofielen in het kader van telemonitoring bij chronisch hartfalen. Het is een gezamenlijk initiatief van een aantal marktpartijen om op het gebied van chronisch hartfalen te komen tot afspraken (in de vorm van interoperabiliteitsprofielen) tussen marktpartijen die interoperabiliteit en daarmee uniformering en standaardisatie bevorderen. De hoofddoelstelling van het project is: Het ontwikkelen van concrete interoperabiliteitsoplossingen in het kader van telemonitoring bij chronisch hartfalen (CHF) die aansluiten bij praktische vraagstukken en prioriteiten uit het veld worden ondersteund door relevante en betrokken partijen uit het veld Belangrijke uitgangspunten voor het project zijn: Aansluiten bij praktische problemen en vragen in het veld rond telemonitoring bij hartfalen Zo breed mogelijk draagvlak bij alle stakeholders Zoveel mogelijk aansluiten bij en gebruik maken van de resultaten van initiatieven als Continua Health Alliance en IHE Gestructureerde en procesmatige aanpak Iteratieve benadering om snelle resultaten te boeken en daar verder op te bouwen Elke stakeholder (bedrijf, zorgaanbieder, etc..) die zich daarvoor meldt kan deelnemen aan het proces Alle resultaten zijn publiek beschikbaar
6
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
1.3.
Proces
De aanpak van het project bestaat uit 3 fases (zie Figuur 1): 1. Vaststellen business requirements, gedetailleerde use cases en identificeren van de interoperabiliteitsvraagstukken 2. Uitwerken en toetsen interoperabiliteitprofielen 3. Communicatie en demonstratie
Figuur 1 - Projectfasering
Tijdens fase 1 ligt de focus op de volgende punten: Wat zijn belangen en randvoorwaarden van stakeholders om te Business requirements komen tot afspraken op het gebied van interoperabiliteit? Hoe ziet de telemonitoringomgeving, de samenhang van systemen, Architectuur producten en diensten er uit? Wat zijn de concrete use cases die we mogelijk willen maken? Use cases Welke interoperabiliteitsproblemen moeten opgelost worden? Interoperabiliteitsproblemen Er vindt bilateraal overleg plaats met verschillende stakeholders over de punten die in de tabel hierboven benoemd worden. Fase 2 is gericht op het uitwerken en toetsen van de noodzakelijke interoperabiliteitsprofielen. De details worden uitgewerkt door een expertteam. De resultaten van fase 2 worden geconsolideerd in een gezamenlijke workshop. Fase 3 is gericht op disseminatie van de resultaten door een combinatie van communiceren en demonstreren. Tegelijkertijd start een nieuwe iteratie met fase 1 en nieuwe use cases (en functionaliteit).
1.4.
Dit document
Dit document is een deliverable van fase 1 van het project. In dit document worden de use cases en de architectuuraspecten beschreven die horen bij de eHealth-dienst ‘telemonitoring voor hartfalen’. De focus ligt op de interoperabiliteitsaspecten. Het document is tot stand gekomen tijdens bilateraal overleg met verschillende marktpartijen gedurende de periode februari – april 2011 en is met een aantal aanpassingen vastgesteld in een gezamenlijke workshop op donderdag 12 mei 2011. De deelnemende partijen zijn weergegeven in Bijlage I van dit document. De andere deliverable van fase 1 is het document: Business Requirements – Interoperabiliteit Telemonitoring Hartfalen
Mei 2011
7
De twee documenten vormen de basis voor het overleg met de stakeholders om: De actuele interoperabiliteitsvraagstukken op het vlak van telemonitoring voor hartfalen op transparante wijze te definiëren De prioriteiten vast te stellen Daarvoor draagvlak te creëren Het is niet de intentie om in dit document de architectuur te beschrijven die hoort bij concrete implementaties voor telemonitoring voor hartfalen. In de markt bestaan diverse oplossingen voor telemonitoring die op meerdere gebieden kunnen verschillen: Meer of minder functionaliteit Wel of niet een Medisch Service Center Al of niet directe toegang tot de gemeten informatie voor de zorgverlener etc.. Het gaat met name om de interoperabiliteit van de verschillende onderdelen van de oplossing. Interoperabiliteit is relevant op de "raakvlakken" tussen verschillende entiteiten in de telemonitoringoplossingen. Het gaat erom die raakvlakken te definiëren en daarover afspraken te maken. Achtereenvolgens wordt in dit document ingegaan op: Hoofdstuk
8
Titel
Beschrijving
2
Rollen
- Welke systeemrollen zijn er te onderscheiden? - Welke marktpartijen zijn er en welke rol spelen zij?
3
Systeembeschrijving
- Hoe ziet een telemonitoringsysteem er uit?
4
Architectuurmodel
- Welke systeeminterfaces of koppelvlakken zijn er? - Referentiearchitectuur - Relatie met Continua-architectuur
5
Logistiek proces en use cases
- Hoe ziet het logistieke proces er uit? - Welke interoperabiliteitsaspecten spelen er? - Use cases m.b.t. de interoperabiliteitsaspecten
6
Medisch proces en use cases
- Hoe ziet het medische proces er uit? - Welke interoperabiliteitsaspecten spelen er? - Use cases m.b.t. de interoperabiliteitsaspecten
7
Interoperabiliteit
- De verschillende interoperabiliteitsaspecten die beschreven moeten worden voor de standaard interfaces - Welke interoperabiliteitsprofielen met daarin welke use cases zullen worden uitgewerkt?
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
H-2 Rollen
2.1.
Systeemrollen
In Figuur 2 worden de systeemrollen weergegeven die onderdeel kunnen zijn van het telemonitoring proces bij chronisch hartfalen.
Figuur 2 - Mogelijke systeemrollen
In voorkomende telemonitoringoplossingen spelen de volgende partijen in het algemeen een rol: Patiënt Eerstelijnszorgverlener; in eerste instantie de huisarts als verwijzer naar de tweede lijn Specialistische zorgverlener in de tweede lijn: specialist / verpleegkundige in de hartfalenpoli of het ziekenhuis die de telemonitoringdiensten aanvraagt Aanbieder van telemonitoringdiensten Ook een persoonlijk gezondheidsdossier (PGD) kan onderdeel zijn van de totaaloplossing. De resultaten van de telemonitoringdiensten (vitale waarden en/of vragen en antwoorden) moeten worden geëvalueerd, ook wel de medische triage genoemd. De triage is gebaseerd op afspraken die zijn vastgelegd in een zorgprotocol dat onder verantwoordelijkheid van de verantwoordelijke specialist is gemaakt.
Mei 2011
9
De rol van de medische triage kan op een drietal manieren worden ingevuld, zoals in Figuur 3 is geïllustreerd: 1. Door verpleegkundigen en/of specialisten werkzaam bij een Medisch Service Center (MSC), als onderdeel van het dienstenportfolio van de aanbieder van telemonitoringdiensten of als aparte dienst 2. Door verpleegkundigen en/of specialisten in het ziekenhuis of de poli of in de eerstelijnszorg. 3. Geautomatiseerd, als onderdeel van de diensten van het telemonitoringsysteem (TMS).
Figuur 3 - Uitvoerende partijen medische triage
2.2.
Marktpartijen
De volgende marktpartijen worden onderscheiden: Patiënt Aanbieder telemonitoringdiensten Medisch Service Center (MSC) Hartfalenpoli / ziekenhuis Huisarts Aanbieder persoonlijk gezondheidsdossier Deze partijen worden hieronder kort beschreven. Patiënt De hartfalenpatiënt die met zijn/haar zorgverlener afspraken heeft gemaakt over telemonitoring van zijn/haar gezondheidstoestand.
10
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
Telemonitoring vindt extramuraal (buiten de zorginstelling) plaats. Dat kan bv. zijn: bij de patiënt thuis op het werk onderweg (bv. op vakantie). Er zijn verschillende mogelijkheden zoals: De patiënt meet een aantal van zijn/haar eigen vitale parameters, bv. gewicht, bloeddruk, ECGwaarden De patiënt vult vragenlijsten in of reageert op vragen die worden gegenereerd door het TMS. De patiënt heeft contact met zijn/haar zorgverlener bv. via telefoon, email, sms De patiënt heeft toegang heeft tot een persoonlijk gezondheidsdossier (PGD). Het PGD kan onderdeel zijn van de aangeboden telemonitoringoplossing of een op zichzelf staande voorziening. Praktische telemonitoringoplossingen voorzien in één of meer van genoemde mogelijkheden, maar kunnen ook andere diensten bieden. Aanbieder telemonitoringdiensten De aanbieder van telemonitoringdiensten is een leverancier die daarover in het algemeen afspraken heeft gemaakt met het ziekenhuis c.q. de hartfalenpoli en de betrokken specialist (cardioloog). De aangeboden oplossingen zijn divers. De aanbieder levert i.h.a. een pakket aan telemonitoringdiensten en bijbehorende apparatuur, het telemonitoringsysteem (TMS). Het TMS houdt vaak in apparatuur voor thuis of onderweg, één of meer meetapparaten (zoals weegschaal, bloeddrukmeter, ECG recorder) en een apparaat, de gateway, dat de communicatie tussen die meetapparaten en de buitenwereld verzorgt. De gateway heeft in sommige telemonitoringoplossingen ook een user interface voor communicatie met de patiënt. In dat geval kan de gateway ook zonder meetapparaten aangeboden c.q. gebruikt worden. De aanbieder van telemonitoringdiensten heeft i.h.a. een backoffice die o.a. functioneert als datacenter. Bij sommige aanbieders is het MSC dat hierna beschreven wordt een integraal onderdeel van het aangeboden dienstenpakket. Medisch Service Center (MSC) In het MSC zijn zorgprofessionals (specialisten, verpleegkundigen) aanwezig die in staat zijn meetwaarden en/of antwoorden op vragenlijsten te interpreteren in de gegeven context en daarop actie te nemen, de zogenaamde medische triage. Een MSC vormt niet altijd onderdeel van de aangeboden telemonitoringoplossing. Een MSC kan een integraal onderdeel zijn van de door de leverancier aangeboden telemonitoringoplossing (en diens organisatie), maar kan ook een aparte rechtspersoon zijn en/of uitbesteed worden aan een andere partij. Hartfalenpoli / ziekenhuis Een kliniek die is gespecialiseerd in hartfalenzorg of een ziekenhuis met een hartfalenafdeling. De zorgverleners in de poli/ het ziekenhuis zijn bijvoorbeeld cardiologen en hartfalenverpleegkundigen. De hartfalenpoli / het ziekenhuis heeft in het algemeen een eigen EPD of ziekenhuisinformatiesysteem (ZIS) of soms ook een disease management systeem. Deze informatiesystemen vatten we in dit document onder de term zorgverlenerinformatiesysteem, kortweg XIS. Zorgverleners in de poli / het ziekenhuis bestellen i.h.a. de telemonitoringdienst nemen in bepaalde gevallen de medische triage op zich (NB. dit kan ook door een externe partij als een Medisch Service Center en/of door intelligentie in het telemonitoring systeem gebeuren) handelen op basis van de resultaten van de medische triage
Mei 2011
11
Huisarts De eigen huisarts van de patiënt. De huisarts heeft de beschikking over een huisartseninformatiesysteem (HIS). De huisarts doet i.h.a. de verwijzing naar de specialist kan (in overleg met de specialist) ook de partij zijn die telemonitoringdiensten bestelt en handelt op basis van de resultaten van de medische triage Aanbieder persoonlijk gezondheidsdossier Een partij die een PGD aanbiedt waarin de patiënt zijn/haar waarden kan (laten) opslaan en kan inkijken. De aanbieder van het PGD en de aanbieder van de telemonitoringdienst kan dezelfde organisatie zijn, maar ook een andere.
12
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
H-3 Systeembeschrijving
Een aanbieder van telemonitoringdiensten kan verschillende oplossingen aanbieden. Een aantal voorbeelden wordt hier beschreven. In Figuur 4 hieronder de meest uitgebreide vorm. Niet alle onderdelen die hier te zien zijn komen dus terug in de concrete oplossingen die er op de markt zijn.
Figuur 4 - Een telemonitoringsysteem (TMS)
3.1.
Algemeen
Leveranciers bieden een grote diversiteit aan producten en diensten aan. Binnen die diversiteit positioneren leveranciers zich op verschillende manieren en met verschillende proposities naar hun klanten. De diversiteit kan onder andere als volgt terugkomen: In de activiteiten die de patiënt thuis doet o Voorbeeld 1: de patiënt meet vitale waarden (zoals gewicht) en stuurt die door o Voorbeeld 2: de patiënt vult vragenlijsten in c.q. reageert op vragen die gesteld worden n.a.v. actuele ontwikkelingen o Voorbeeld 3: een combinatie van 1 en 2 In de functionaliteit die de backoffice c.q. het telemonitoringsysteem invult. o Voorbeeld 1: het systeem is m.n. een doorgeefluik van de gegevens die in de patiënt omgeving worden gegenereerd naar de achterliggende systemen o Voorbeeld 2: het systeem biedt allerlei aanvullende diensten op basis van de opgeslagen informatie uit de patiëntomgeving, zoals evaluatie en interpretatie van de gegevens, het genereren van alarmen bij het overschrijden van drempelwaardes, etc. Daarbij kan ook andere informatie zoals contextinformatie (bv. medicatie-informatie) gebruikt worden die op andere manieren beschikbaar is gemaakt in het telemonitoringsysteem.
Mei 2011
13
3.2.
De manier waarop de patiënt toegang krijgt tot de informatie o Voorbeeld 1: de patiënt krijgt toegang tot de informatie in het telemonitoringsysteem via een portal op het systeem o Voorbeeld 2: de patiëntgegevens worden geëxporteerd naar een extern dossier, het persoonlijk gezondheidsdossier (PGD) o Voorbeeld 3: de patiënt heeft geen toegang tot de informatie De manier waarop zorgverleners toegang krijgen tot de informatie o Voorbeeld 1: de belangrijkste toegang voor zorgverleners wordt geboden door een portal van het telemonitoringsysteem. Alle functionaliteit is beschikbaar via die interface. o Voorbeeld 2: de toegang voor de zorgverlener loopt via het “eigen” systeem, het XIS. De evaluatie en interpretatie van de gegevens gebeurt in het informatiesysteem van de zorgverlener o Voorbeeld 3: een combinatie van 1 en 2
Omgeving patiënt
Met de patiëntomgeving wordt bedoeld bij de patiënt thuis, op het werk, elders, onderweg etc. Daarbij kan gebruik gemaakt worden van: Meetapparaten zoals bloeddrukmeter, weegschaal, ECG monitor, .. Een apparaat met een user interface (vaak gecombineerd met de gateway, zie hierna) waarop bv. vragen gesteld kunnen worden en antwoorden gegeven, maar ook bv. videocontact mogelijk is. Een gateway die de verbinding verzorgt tussen de meetapparaten en de buitenwereld. De gateway kan verschillende uitvoeringsvormen hebben zoals: Een settopbox met TV en een afstandsbediening Een computer zoals een PC of laptop Een enkel intelligent apparaat met een ingebouwd display (bv. een touchschreen) Een apparaat zonder user interface en alleen een gateway functie Een iPhone Etc.…. Mogelijk kan de patiënt via een portal toegang krijgen tot de informatie in het datacenter . Deze functionaliteit kan ook onderdeel zijn van de functionaliteit van de gateway.
3.3.
Backoffice aanbieder telemonitoringdiensten
In het algemeen fungeert de backoffice van de aanbieder van telemonitoringdiensten als een datacenter waarbinnen twee functies te onderscheiden zijn: De serverfunctie waarin een belangrijk deel van de functionaliteit van de aangeboden diensten is opgenomen. De gateway in het huis van de patiënt fungeert dan als client. De datacenterfunctie voor dataopslag, o.a. van de meetwaarden van de patiënt. Afhankelijk van het dienstenpakket van de aanbieder (van het doorgeven van de vitale data tot diensten gebaseerd op evaluatie en interpretatie van de beschikbare informatie) is er meer of minder functionaliteit aanwezig in het systeem. Bij sommige telemonitoringsystemen die worden aangeboden is geen backofficefunctie aanwezig maar is een directe koppeling met de systemen van de zorgaanbieder mogelijk.
14
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
3.4.
Omgeving zorgverlener
In de context van telemonitoring bij hartfalen zijn er meerdere "zorgverleneromgevingen" te onderscheiden zoals: De hartfalenpoli en/of het ziekenhuis De huisartsenpraktijk Het Medisch Service Center (indien aanwezig) In de hartfalenpoli of het ziekenhuis wordt i.h.a. gebruik gemaakt van een informatiesysteem als een ZIS, een disease management systeem of een andere vorm van een EPD. In de huisartsenpraktijk wordt i.h.a. gebruik gemaakt van een HIS. Een Medisch Service Center kan ook de beschikking hebben over een eigen informatiesysteem bv. in de vorm van een Disease Management systeem. Alle aanbieders van telemonitoringdiensten bieden de zorgverlener toegang tot informatie in het telemonitoringsysteem via een eigen portal. De informatie en functionaliteit die worden geboden via de zorgverlenerportaal verschillen sterk voor de verschillende oplossingen. Sommige aanbieders van telemonitoringdiensten bieden additionele functionaliteit die vanaf een computer bij de zorgaanbieder te benaderen is: Toegang tot de informatie in de backoffice, de mogelijkheid om alarmeringsniveaus in te stellen, alarmen te laten genereren etc. Dit kan beschikbaar gesteld worden aan een cardioloog of hartfalen verpleegkundige in ziekenhuis of hartfalenpoli maar ook aan een Medisch Service Center (MSC). Toegang tot onderhoud en beheer van het telemonitoringsysteem. Verder bieden telemonitoringsystemen in verschillende mate de mogelijkheid om te koppelen met andere systemen zoals een HIS (huisartsen informatie systeem), een ZIS (ziekenhuis informatie systeem), een disease management systeem, een andere vorm van een EPD of bijvoorbeeld een informatiesysteem dat in het MSC gebruikt wordt. Welke informatie wanneer en op welke wijze uitgewisseld wordt of kan worden, is verschillend voor de diverse oplossingen en niet gestandaardiseerd.
3.5.
Omgeving aanbieder PGD
Toegang tot een PGD wordt gedefinieerd als een aparte dienst. Sommige leveranciers van telemonitoringdiensten bieden PGD-achtige diensten als onderdeel van hun portfolio. Daarnaast valt te denken aan externe oplossingen van specifieke leveranciers (bv. volgens het concept van Microsoft Health Vault of Google Health, of Mijnhartenvaten.nl) of andere aanbieders als een ziekenhuis of een regionale samenwerkingsorganisatie van zorginstellingen die PGD-diensten aanbieden.
Mei 2011
15
H-4 Architectuurmodel
4.1.
Systeeminterfaces
Op basis van de systeembeschrijving in hoofdstuk 3 kunnen verschillende interfaces gedefinieerd worden voor een telemonitoringsysteem.
Figuur 5 - Systeeminterfaces voor een TMS
In de tabel op de volgende pagina worden de interfaces kort beschreven. In de kolom ‘type’ wordt aangegeven of het gaat om een standaard interface - marktpartijen zijn het er over eens dat het wenselijk is om gebruik te maken van standaard oplossingen een proprietary interface - interfaces zijn leveranciersspecifiek De indeling standaard/leveranciersspecifiek is in overleg met de betrokken leveranciers vastgesteld.
16
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
Interface ECG-monitor gateway Bloeddrukmeter gateway Weegschaal - gateway
Opmerking In de meeste systemen een open interface zodat meetapparaten van verschillende leveranciers gebruikt kunnen worden.
B
Gateway - backoffice TMS
C
Server - datacenter
T.z.t. kan overwogen worden of dit een open interface kan zijn maar op dit moment is het in alle beschikbare systemen een leveranciersspecifieke interface Intern interface in de backoffice. T.z.t. kan worden overwogen of dit een open interface zou kunnen zijn. Leveranciersspecifieke interface
A1 A2 A3
D1
Type Standaard interface Standaard interface Standaard interface Proprietary interface Interne interface Proprietary interface Proprietary interface Proprietary interface Standaard interface
Toegangsapplicatie backoffice TMS D2 Toegangsapplicatie Leveranciersspecifieke interface backoffice TMS D3 Beheersapplicatie Leveranciersspecifieke interface backoffice TMS En Backoffice TMS Koppeling van de backoffice met informatiesystemen van informatiesystemen zorgaanbieders. Standaardisatie gewenst. zorgaanbieders Pn Backoffice TMS Koppeling van de backoffice met externe PGD-systemen. Standaard PGD-systemen Standaardisatie gewenst. interface Let wel: niet alle interfaces zijn aanwezig in alle systemen die in de markt aangeboden worden.
Voor de volgende koppelvlakken geldt volgens betrokken marktpartijen dat het wenselijk om uit te gaan van standaardoplossingen: Aanduiding An
Koppelvlak Meetapparaat - gateway
En
Backoffice TMS informatiesystemen zorgaanbieders Backoffice TMS PGD-systemen
Pn
Status In de praktijk worden hiervoor al standaard oplossingen gebruikt (in lijn met de Continua Design Guidelines) Er zijn individuele leveranciersspecifieke implementaties Er zijn individuele leveranciersspecifieke implementaties
De eerste prioriteit ligt bij het maken van afspraken voor koppelvlak En.
Mei 2011
17
4.2.
Referentiearchitectuur
De beschreven systeemopzet is teruggebracht naar een referentiearchitectuur zoals in Figuur 6.
Figuur 6 - Referentiearchitectuur TMS
Het meetapparaat is bv. een ECG-monitor, bloeddrukmeter of weegschaal die via interface An gekoppeld is aan de gateway. Meetapparaat, gateway en het backoffice-systeem vormen samen het telemonitoringsysteem. Interfaces B, C en D - voor zover aanwezig - zijn leveranciersspecifieke en deels interne interfaces. Via interface D is het mogelijk via leveranciersspecifieke toepassingen toegang te krijgen tot het backoffice-systeem. Het telemonitoringsysteem is via interface En gekoppeld aan een EPD systeem of XIS van de zorgverlener en via interface Pn aan een PGD systeem dat wordt gebruikt door de patiënt. De Continua referentiearchitectuur is weergegeven in Figuur 7. Daarbij komt het An-interface uit het telemonitoringsysteem overeen met het PAN IF/LAN IF. Het En- en Pn-interface komen overeen met het xHRN IF.
Figuur 7 - Referentiearchitectuur Continua
18
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
H-5 Logistiek proces en use cases
In hoofdstukken 5 en 6 wordt verder ingegaan op een tweetal processen die gerelateerd zijn aan het TMS: - het logistiek proces (hoofdstuk 5) - het medisch proces (hoofdstuk 6) Het logistiek proces heeft te maken met het bestellen, installeren en onderhouden van het TMS. Het medisch proces beschrijft het feitelijke gebruik, het meten van vitale waarden, het vastleggen van vragen en antwoorden en de actie die volgt. Voor beide processen zijn een aantal interoperabiliteitsaspecten vastgesteld die worden beschreven aan de hand van use cases. Deze interoperabiliteitsaspecten bevinden zich allen op interface En, die in hoofdstuk 4 gedefinieerd is. Voor de use cases wordt gebruikt gemaakt van een standaard formaat dat is weergegeven en beschreven in Bijlage II.
5.1.
Procesbeschrijving
Het logistieke proces is in grote lijnen weergegeven in Figuur 8 en wordt op hoog niveau beschreven in de use case hieronder (use case LP).
Figuur 8 - Het logistiek proces
Mei 2011
19
Use case LP
Bestellen en installeren telemonitoringsysteem
Primaire actor
Cardioloog, hartfalenverpleegkundige of ondersteunend personeel, aanbieder TMS
Beschrijving
Als een patiënt in aanmerking komt voor behandeling met telemonitoring, zal voor deze patiënt een telemonitoringsysteem moeten worden besteld en geïnstalleerd.
Scope
Telemonitoringsysteem, informatiesysteem van de zorgverlener (XIS)
Level
Summary
Preconditie
Er is bepaald dat de patiënt gebruik gaat maken van telemonitoring
Postconditie
De patiënt heeft alle apparatuur tot zijn beschikking en is in het telemonitoringsysteem opgenomen.
Successcenario
1. De zorgverlener (of ondersteunend personeel) plaatst een bestelling bij de leverancier, via telefoon, e-mail, TMS of XIS 2. De zorgverlener geeft alle benodigde (identiteits-, demografische en order-) gegevens door (zie use case LP1) 3. De leverancier configureert de apparatuur op basis van de gegevens van de bestelling 4. De leverancier zorgt voor de levering en installatie van het systeem, eventueel gebeurt installatie door de patiënt zelf 5. De patiënt neemt het systeem en de bijbehorende diensten in gebruik 6. In geval van problemen met de werking van het systeem neemt de patiënt contact op met de technische helpdesk 7. De technische helpdesk lost in overleg met de gebruiker technische problemen op 8. Bij veranderingen in patiëntgegevens of drempelwaarden wijzigt de zorgverlener dit en geeft dit door (zie use case LP2a/b)
5.2.
Interoperabiliteitsaspecten en use cases
Tijdens het overleg met de verschillende stakeholders zijn ten aanzien van het logistieke proces een tweetal situaties naar voren gekomen waarin interoperabiliteitsaspecten spelen: UC LP1 LP2a LP2b
Beschrijving - Het bestellen van een telemonitoringdienst via het informatiesysteem van de zorgverlener (XIS) met automatische gegevensoverdracht. - Wijzigen van patiëntgegevens en zorgverleneridentiteit via het XIS - Wijzigen van systeemconfiguratie en –instellingen via het XIS (incl. beëindiging van dienst)
Deze situaties worden achtereenvolgens beschreven in use case LP1 en use cases LP2a en LP2b. De relevantie van deze use cases en de interoperabiliteitsprofielen die hierop volgen zijn beschreven in hoofdstuk 7.
20
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
5.2.1. Use case LP1 Use case LP1
Bestellen telemonitoringdienst met automatische gegevensinvoer (via XIS)
Primaire actor
Cardioloog, hartfalenverpleegkundige of ondersteunend personeel, aanbieder TMS
Beschrijving
Als een patiënt in aanmerking komt voor behandeling met telemonitoring, zal deze patiënt als nieuwe patiënt moeten worden aangemaakt in het telemonitoring systeem. Hierbij gaat het enerzijds om het doorgeven van de identiteits- en demografische gegevens van de patiënt en anderzijds om het plaatsen van een bestelling voor de apparatuur, inclusief de benodigde instellingen. In sommige systemen zal slechts één van de functies worden gebruikt. De gegevens worden voor zover beschikbaar rechtstreeks uit het informatiesysteem van de zorgverlener gehaald.
Scope
XIS → TMS
Level
User goal
Preconditie
De benodigde gegevens van de patiënt zijn bekend, maar nog niet aanwezig in het telemonitoringsysteem. Het TMS en het informatiesysteem van de zorgverlener moeten met elkaar kunnen communiceren (evt. via ander systeem).
Postconditie
De patiënt is opgenomen in het TMS en de bestelling is doorgegeven
Successcenario
1. De zorgverlener opent het XIS en maakt een nieuwe bestelling voor een TMS aan voor de patiënt 2. De benodigde (identiteits-, demografische en order-) gegevens worden automatisch uit het XIS overgenomen en waar nodig aangevuld door de zorgverlener 3. De gegevens van de patiënt worden bij verzenden vanuit het XIS naar de back office (server/datacenter) van het TMS gestuurd.
5.2.2. Use case LP2a Use case LP2a
Wijzigen van patiëntgegevens en zorgverleneridentiteit via het XIS
Primaire actor
Cardioloog, hartfalenverpleegkundige of ondersteunend personeel, aanbieder TMS
Beschrijving
Als de gegevens van de patiënt wijzigen of als (de contactgegevens van) zorgverleners wijzigen, kan dit vanuit het XIS worden gedaan.
Scope
XIS → TMS
Level
User goal
Preconditie
De benodigde gegevens van de patiënt of zorgverlener zijn bekend, maar nog niet juist aanwezig in het TMS. Het TMS en het XIS moeten met elkaar kunnen communiceren (evt. via ander systeem).
Postconditie
De gegevens van de patiënt of de zorgverlener in het TMS zijn gewijzigd
Successcenario
1. De zorgverlener opent het dossier van de patiënt in het XIS en geeft aan dat hij de patiënt- of zorgverlenergegevens wil wijzigen 2. De benodigde (identiteits- en demografische) gegevens worden automatisch uit het XIS overgenomen of ingevuld door de zorgverlener 3. De gegevens van de patiënt of de zorgverlener worden bij verzenden vanuit het XIS naar de back office (server/datacenter) van het TMS gestuurd.
Mei 2011
21
5.2.3. Use case LP2b Use case LP2b
Wijzigen van systeemconfiguratie en –instellingen via het XIS (incl. beëindiging van dienst)
Primaire actor
Cardioloog, hartfalenverpleegkundige of ondersteunend personeel, aanbieder TMS
Beschrijving
Als de drempelwaarden opnieuw worden ingesteld of andere systeeminstellingen wijzigen, kan dit vanuit het XIS worden gedaan. Dit geldt ook voor het beëindigen van de dienst.
Scope
XIS → TMS
Level
User goal
Preconditie
De benodigde gegevens zijn bekend, maar nog niet juist aanwezig in het TMS. Het TMS en het XIS moeten met elkaar kunnen communiceren (evt. via ander systeem).
Postconditie
De drempelwaarden of andere instellingen in het TMS zijn gewijzigd
Successcenario
1. De zorgverlener opent het dossier van de patiënt in het XIS en geeft aan dat hij de drempelwaarden of andere systeeminstellingen wil wijzigen 2. De benodigde (order-) gegevens worden automatisch uit het XIS overgenomen of ingevuld door de zorgverlener 3. De nieuwe drempelwaarden en andere instellingen worden bij verzenden vanuit het XIS naar de back office (server/datacenter) van het TMS gestuurd. 4. De TMS gateway wordt opnieuw ingesteld volgens de nieuwe instellingen.
22
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
H-6 Medisch proces en use cases
6.1.
Procesbeschrijving
Het medisch proces is in grote lijnen weergegeven in Figuur 9 en wordt op hoog niveau beschreven in de use case hieronder (use case MP).
Figuur 9 - Het medisch proces
Mei 2011
23
Use case MP
Telemonitoring bij hartfalenpatiënten
Primaire actor
Patiënt, cardioloog en hartfalenverpleegkundige
Beschrijving
De patiënt meet dagelijks zijn gewicht, bloeddruk en zo nodig overige meetwaarden. Deze waarden zijn in te zien door de patiënt en door de zorgverleners, zodat deze hun beleid hierop kunnen aanpassen.
Scope
Meetapparatuur, telemonitoringssysteem, informatiesysteem van de zorgverlener (XIS), persoonlijk gezondheidsdossier
Level
Summary
Preconditie
De verschillende systemen en producten van de zorgverleners en de patiënten moeten met elkaar kunnen communiceren.
Postconditie
De zorgverlener heeft de gezondheid van de patiënt bijgehouden en gecontroleerd en heeft geanticipeerd op afwijkingen.
Successcenario
1. De patiënt meet dagelijks zijn gewicht, bloeddruk en zo nodig overige meetwaarden en/of beantwoordt een aantal vragen over voorkomende symptomen (monitorgerichte interventie) 2. De patiënt beantwoordt eventueel ook een aantal vragen over de kennis over hartfalen 3. De gegevens worden in het TMS ingevoerd en doorgestuurd naar de database van het TMS 4. De database van het TMS slaat de gegevens op 5. Het systeem geeft zo nodig & zo mogelijk schriftelijke educatie over hartfalen in de vorm van tekst of filmpjes (educatiegerichte en gedragsgerichte interventie) 6. De telemonitoringinformatie wordt aangeboden aan de medische triage (door MSC, TMS of zorgverlener) 7. De medische triage evalueert de aangeboden telemonitoringgegevens ten opzichte van vooraf afgesproken regels en zorgproces 8. De medische triage geeft na afloop een trigger om de gegevens beschikbaar te maken voor de zorgverlener 9. Het TMS geeft eventueel feedback aan de gebruiker, op basis van de medische triage 10. Het TMS maakt de telemonitoringinformatie beschikbaar voor de zorgverlener 11. Bij afwijkende waarden wordt de hartfalenverpleegkundige of de cardioloog gewaarschuwd, via e-mail, sms, telefoon of als melding in het TMS. 12. De zorgverlener bekijkt de meetwaarden en overige gegevens van de patiënt in de applicatie van het telemonitoringsysteem of in zijn eigen informatiesysteem 13. De zorgverlener neemt zo nodig contact op met de patiënt en/of past het beleid aan 14. De patiënt houdt eventueel zijn eigen gezondheid bij, door de meetwaarden en overige gegevens te controleren in zijn PGD.
24
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
6.2.
Interoperabiliteitsaspecten en use cases
Het koppelen van het informatiesysteem van de zorgverlener (XIS) en het TMS kan op verschillende manieren, afhankelijk van de wensen van de zorgverleners en de leveranciers. Ten eerste kan er een koppeling worden gelegd op inlogniveau. Hierdoor kan vanuit het ene systeem het andere systeem worden geopend, zonder dat opnieuw hoeft te worden ingelogd en het juiste dossier gezocht hoeft te worden. Deze koppeling kan beide kanten op worden gemaakt en wordt vaak aangeduid met Single Sign On (SSO). Daarnaast kan de koppeling van de twee systemen inhouden dat er gegevens van het ene systeem in het andere systeem worden overgenomen. Dit kan voor verschillende functies worden gedaan. Ook dit kan beide kanten op plaatsvinden. Tijdens het overleg met de verschillende stakeholders zijn ten aanzien van het medische proces de volgende use cases gedefinieerd waarin interoperabiliteitsaspecten spelen: UC MP1 MP2 MP3 MP4 MP5 MP6
Beschrijving - Openen van het juiste dossier in het XIS vanuit het TMS met één klik (SSO) - Openen van het juiste dossier in het TMS vanuit het XIS met één klik (SSO) - Realtime monitoren van de vitale waarden van de patiënt in het XIS - Rapportage van de vitale waarden van de patiënt in het XIS - Monitoren van symptomen en leefstijl van de patiënt in het XIS - Bekijken van medische informatie uit het XIS in het TMS
Deze situaties worden achtereenvolgens beschreven in use case MP1 tot en met use case MP6. De relevantie van deze use cases en de interoperabiliteitsprofielen die hierop volgen zijn beschreven in hoofdstuk 7.
6.2.1. Use case MP1 Use case MP1
Openen van het juiste dossier in het XIS vanuit het TMS met één klik (SSO)
Primaire actor
Cardioloog, hartfalenverpleegkundige
Beschrijving
Vanuit TMS wordt de zorgverlener in één keer doorgelinkt naar het juiste dossier in het informatiesysteem van de zorgverlener (XIS), de gebruiker hoeft hierbij niet nogmaals in te loggen (single sign-on). Er worden verder geen gegevens overgezet.
Scope
TMS → XIS
Level
User goal
Preconditie
De meetapparatuur en de informatiesystemen van de zorgverleners moeten met elkaar kunnen communiceren
Postconditie
Het juiste dossier is geopend in het XIS vanuit het TMS zonder dat de zorgverlener opnieuw heeft moeten inloggen. Er zijn verder geen gegevens overgezet.
Successcenario
1. De zorgverlener heeft het dossier van de patiënt geopend in de applicatie van het TMS. 2. De zorgverlener klikt op de knop om het dossier van de patiënt in het XIS te openen 3. Het XIS wordt opgestart, als dit nog niet het geval was, en het dossier van de juiste patiënt wordt geopend, zonder dat opnieuw hoeft worden ingelogd.
Mei 2011
25
6.2.2. Use case MP2 Use case MP2
Openen van het juiste dossier in het TMS vanuit het XIS met één klik (SSO)
Primaire actor
Cardioloog, hartfalenverpleegkundige
Beschrijving
Vanuit het informatiesysteem van de zorgverlener (XIS ) wordt de zorgverlener in één keer doorgelinkt naar het juiste dossier in het TMS, de gebruiker hoeft hierbij niet nogmaals in te loggen (single sign-on). Er worden verder geen gegevens overgezet.
Scope
XIS → TMS
Level
User goal
Preconditie
De meetapparatuur en de informatiesystemen van de zorgverleners moeten met elkaar kunnen communiceren.
Postconditie
Het juiste dossier is geopend in het TMS vanuit het XIS zonder dat de zorgverlener opnieuw heeft moeten inloggen. Er zijn verder geen gegevens overgezet.
Successcenario
1. De zorgverlener heeft het dossier van de patiënt geopend in het XIS. 2. De zorgverlener klikt op de knop om het dossier van de patiënt in de applicatie van het TMS te openen 3. Het TMS wordt opgestart, als dit nog niet het geval was, en het dossier van de juiste patiënt wordt geopend, zonder dat opnieuw hoeft worden ingelogd. .
6.2.3. Use case MP3 Use case MP3
Realtime monitoren van de vitale waarden van de patiënt in het XIS
Primaire actor
Cardioloog, hartfalenverpleegkundige
Beschrijving
De patiënt meet dagelijks zijn gewicht, bloeddruk en zo nodig overige meetwaarden. Deze waarden zijn in te zien door de cardioloog en de hartfalenverpleegkundige, zodat deze kunnen ingrijpen bij afwijkende waarden.
Scope
Meetapparatuur → TMS → XIS
Level
User goal
Preconditie
De patiënt heeft zijn vitale levensfuncties opgemeten. De meetapparatuur en de informatiesystemen van de zorgverleners moeten met elkaar kunnen communiceren.
Postconditie
De zorgverlener is in geval van afwijkende meetwaarden gewaarschuwd en heeft contact opgenomen met de patiënt.
Successcenario
1. De vitale waarden worden realtime vanuit de meetapparatuur, via de gateway naar de back office (server/datacenter) verstuurd 2. (Een selectie van) de meetwaarden worden realtime vanuit de back office (server/datacenter) toegankelijk gemaakt voor (het datacenter van) het XIS, eventueel alleen na alarmtrigger 3. Bij afwijkende of zorgwekkende waarden wordt de cardioloog/HFverpleegkundige (automatisch of door de MSC-verpleegkundige) gewaarschuwd 4. De hartfalenverpleegkundige of cardioloog opent het XIS en logt in 5. De hartfalenverpleegkundige of cardioloog bekijkt de meetwaarden, de gezondheidsstatus en eventuele meldingen over de patiënt. 6. De zorgverlener past eventueel het therapiebeleid aan 7. De zorgverlener neemt contact op met de patiënt als dit nodig is
26
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
6.2.4. Use case MP4 Use case MP4
Rapportage van de vitale waarden van de patiënt in het XIS
Primaire actor
Cardioloog, hartfalenverpleegkundige
Beschrijving
De patiënt meet dagelijks zijn gewicht, bloeddruk en zo nodig overige meetwaarden. Een samenvatting van deze waarden worden in het XIS van de zorgverlener beschikbaar gemaakt, zodat deze tijdens consulten en dergelijke in te zien zijn.
Scope
Meetapparatuur → TMS → XIS
Level
User goal
Preconditie
De patiënt heeft zijn vitale levensfuncties opgemeten. De meetapparatuur en de informatiesystemen van de zorgverleners moeten met elkaar kunnen communiceren (evt. via ander systeem).
Postconditie
De zorgverlener heeft een rapportage van de vitale waarden bekeken in zijn eigen informatiesysteem.
Successcenario
1. De vitale waarden worden vanuit de meetapparatuur, via de gateway naar de back office (server/datacenter) verstuurd 2. De vitale waarden worden vanuit de back office (server/datacenter) naar het XIS gestuurd 3. De hartfalenverpleegkundige of cardioloog opent het XIS en logt in 4. De hartfalenverpleegkundige of cardioloog bekijkt de vitale waarden, bijvoorbeeld als voorbereiding voor een consult.
6.2.5. Use case MP5 Use case MP5
Monitoren van symptomen en leefstijl van de patiënt in het XIS
Primaire actor
Cardioloog, hartfalenverpleegkundige
Beschrijving
De patiënt beantwoordt regelmatig een aantal vragen over zijn gezondheid, voorkomende symptomen en leefstijl. Deze antwoorden zijn in te zien door de cardioloog en de hartfalenverpleegkundige, zodat zij hun therapiebeleid hierop kunnen aanpassen.
Scope
TMS → XIS
Level
User goal
Preconditie
De patiënt heeft de relevante vragen beantwoord. Het telemonitoringsysteem en de informatiesystemen van de zorgverleners moeten met elkaar kunnen communiceren.
Postconditie
De zorgverlener is in geval van afwijkende waarden gewaarschuwd en heeft contact opgenomen met de patiënt.
Successcenario
1. De antwoorden van de patiënt worden door de gateway naar de backoffice (server/datacenter) van het telemonitoringsysteem gestuurd. 2. Bij afwijkende of zorgwekkende antwoorden wordt een melding naar de zorgverlener gestuurd. 3. De antwoorden worden realtime vanuit de back office (server/datacenter) toegankelijk gemaakt voor (het datacenter van) het XIS (via push of pull) 4. De hartfalenverpleegkundige of cardioloog opent het XIS en logt in 5. De hartfalenverpleegkundige of cardioloog bekijkt de gezondheidsstatus, de
Mei 2011
27
antwoorden over symptomen en leefstijl en eventuele meldingen over de patiënt. 6. De zorgverlener past eventueel de educatie-/gedragsgerichte interventie van het telemonitoringsysteem of het therapiebeleid aan 7. De zorgverlener neemt contact op met de patiënt als dit nodig is
6.2.6. Use case MP6 Use case MP6
Bekijken van medische informatie uit het XIS in het TMS
Primaire actor
Cardioloog, hartfalenverpleegkundige
Beschrijving
Voor de medische triage is in sommige gevallen medische informatie uit het ziekenhuis, zoals een medicatieoverzicht, nodig. Deze informatie wordt overgezet uit het XIS naar het TMS
Scope
XIS → TMS
Level
User goal
Preconditie
De informatie is bekend in het XIS. Het TMS en het XIS moeten met elkaar kunnen communiceren.
Postconditie
De zorgverlener heeft de medische informatie kunnen bekijken in combinatie met de telemonitoringinformatie, of de medische triage heeft plaatsgevonden op basis van de medische informatie in combinatie met de telemonitoringinformatie.
Successcenario
1. De medische informatie van de patiënt wordt realtime of met enige regelmaat vanuit het XIS naar de backoffice van het telemonitoringsysteem gestuurd. 2. De medische informatie is inzichtelijk in de applicatie van het TMS 3. Eventueel vindt medische triage automatisch plaats door het TMS of door een zorgverlener op het MSC, op basis van de telemonitoringgegevens in combinatie met de toegankelijk gemaakte medische informatie 4. De zorgverlener logt in in het TMS en opent het dossier van de patiënt. 5. De zorgverlener bekijkt de medische informatie in combinatie met de telemonitoringinformatie van de patiënt.
28
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
H-7 Interoperabiliteit
Zoals in hoofdstuk 4, 5 en 6 beschreven zal de focus in eerste instantie liggen op het maken van afspraken rond interface En. Bij een volgende iteratie komt koppeling Pn met de PGD-omgeving aan de beurt. In de praktijk maken de meeste leveranciers al gebruik van standaardoplossingen voor An-interfaces.
7.1.
Interoperabiliteitsniveaus
Bij de uitwerking van koppeling En is het belangrijk om alle niveaus van interoperabiliteit mee te nemen zoals aangegeven in onderstaande figuur en de bijbehorende tabel.
Figuur 10 - Interoperabiliteitsniveaus
In onderstaande tabel zijn die niveaus verder uitgewerkt. Organisatie, proces Welke actoren zijn er? Hoe wordt er samengewerkt? Wie doet wat? Is er een zorgstandaard? Zo niet, welke afspraken, protocollen, richtlijnen, uitgangspunten worden er gehanteerd? Informatie Welke informatie wordt er, door wie, op welk moment uitgewisseld? Wat is het datamodel? Wat is de minimale dataset? Welke codestelsels worden gebruikt? Applicatie, functionaliteit Welke systeemrollen zijn er en wat is de interactie? Welke functionaliteit wordt waar en wanneer geleverd? Techniek, infrastructuur Hoe vindt de gegevensuitwisseling plaats? Welke berichten worden er gebruikt? Wat is de verbindende techniek? Hoe ziet de infrastructuur eruit?
Mei 2011
29
In de interoperabiliteitsprofielen die worden ontwikkeld zullen deze verschillende interoperabiliteitsniveaus worden uitgewerkt voor de use cases die zijn geïdentificeerd voor het logistiek proces en het medisch proces, in respectievelijk de paragrafen 5.2 en 6.2. UC
Beschrijving
LP1 LP2a
Het bestellen van een telemonitoringdienst via het informatiesysteem van de zorgverlener (XIS) met automatische gegevensoverdracht. Wijzigen van patiëntgegevens en zorgverleneridentiteit via het XIS
LP2b
Wijzigen van systeemconfiguratie en –instellingen via het XIS (incl. beëindiging van dienst)
MP1
Openen van het juiste dossier in het XIS vanuit het TMS met één klik (SSO)
MP2
Openen van het juiste dossier in het TMS vanuit het XIS met één klik (SSO)
MP3
Realtime monitoren van de vitale waarden van de patiënt in het XIS
MP4
Rapportage van de vitale waarden van de patiënt in het XIS
MP5
Monitoren van symptomen en leefstijl van de patiënt in het XIS
MP6
Bekijken van medische informatie uit het XIS in het TMS
7.2.
Interoperabiliteitsprofielen
Tijdens de workshop die plaatsvond op 12 mei 2011 is besloten dat de eerste prioriteit ligt in het ontwikkelen van interoperabiliteitsprofielen voor de functionaliteit zoals beschreven in use cases MP3, LP1 en LP2. Bij de uitwerking van het profiel voor MP3 zullen ook MP4 en MP5 meegenomen worden, aangezien deze als varianten van MP3 gezien worden. Use cases MP1 en MP2 zullen voorlopig niet worden uitgewerkt in een interoperabiliteitsprofiel. Use case MP6 is de medische variant van het logistieke proces, van use cases LP1 en LP2. De uitwerking van MP6 zal dan ook volgen op de eerste realisatie van het logistieke interoperabiliteitsprofiel met daarin de uitwerking voor LP1 en LP2. De uitwerking van de interoperabiliteitsprofielen zal plaatsvinden door een expertteam tijdens fase 2.
Figuur 11 - De uit te werken interoperabiliteitsprofielen
30
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
Bijlage I.
Deelnemers
De volgende organisaties en personen hebben deelgenomen in het proces van het tot stand komen van dit document.
Organisatie
Naam
Rol/functie
Dr. René van Dijk
Cardioloog
Wendy de Valk
Verpleegkundig specialist
x
Josiane Boyne
Verpleegkundig specialist
x
Dr. Schroeder - Tanka
Cardioloog
Jan Ebing
Verpleegkundig specialist
Wietse Veenstra
Verpleegkundig specialist
Dr. Wajon
Cardioloog
8
Martini Ziekenhuis, Groningen Martini Ziekenhuis, Groningen MUMC+, Maastricht St. Lucas. Andreas Ziekenhuis, Amsterdam St. Lucas. Andreas Ziekenhuis, Amsterdam Scheper Ziekenhuis, Emmen Medisch Spectrum Twente, Enschede IZIT
Monique Nijkamp
9
De Hart&Vaatgroep
Inge van den Broek
10
NPCF
Marcel Heldoorn
11
Zorgverzekeraars Nederland
Sytske de Vries
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Sananet Sananet Curit Curit Curit IPT Medical Services KPN Tunstall Philips Philips Fujitsu (Intel/Care Innovations) Fujitsu (Intel/Care Innovations) TNO TNO Nictiz Nictiz Nictiz
Thom Hoedemakers Jan Ramaekers Ellen Zonder Albert-Jan Nijburg Eltjo Kraai Joop Wallenburg Sacha Gramberg Jelle van der Weijde Patrick van Deursen Johan Muskens Mike Dunn Ron Klaas Ronald Mooij Ton Rövekamp Arina Burghouts Gé Klein Wolterink Johan Bruin
Projectleider telemonitoring bij het MST Patiëntenorganisatie, adviseur Patiëntenorganisatie, adviseur Programmamanager eHealth Leverancier Leverancier Leverancier Leverancier Leverancier Leverancier Leverancier Leverancier Leverancier Leverancier Leverancier Leverancier
1 2 3 4 5 6 7
Mei 2011
Aanwezig bij workshop x
x
x
x x
x x x x x x x
x x x x x x
31
Bijlage II.
Use case format
Een use case beschrijft het gedrag van het systeem en de interacties onder verschillende condities als het systeem reageert op de vraag van de gebruiker. Een gebruiker gebruikt een systeem met een bepaald doel. In de use case worden de scenario’s beschreven die gerelateerd zijn aan het halen of niet halen van het doel van de gebruiker. De use case beschrijft de verschillende kenmerken van de functie die het systeem gaat uitvoeren voor de gebruiker. Voor de beschrijving van use case wordt gebruik gemaakt van een standaard format dat hieronder is weergegeven. Use case # Primaire actor
Naam; beschrijft het doel van de gebruiker De gebruiker die het systeem gebruikt voor bovengenoemd doel
Beschrijving
Korte beschrijving van de use case
Scope
Dit is het systeem dat van toepassing is in deze use case. Dit kan een software applicatie zijn of een onderdeel van de software applicatie. Het kan ook een organisatie of proces zijn.
Level
Beschrijft het abstractieniveau van de use case. Er zijn drie niveaus te onderscheiden: - User goal: in dit geval gaat de use case over het doel waarvoor de gebruiker het systeem gaat gebruiken. Meestal gaat dit over één gebruiker in één zitting. - Sub function goal: een niveau lager dan het user goal level. Het beschrijft een onderdeel van een user goal met iets meer detail. - Summary level: een niveau hoger dan het user goal level. Het omvat meestal meerdere user goals en omschrijft de context waarin een gebruiker en het systeem functioneren. Het kan uren, dagen, weken of zelfs jaren omvatten.
Preconditie
Hier staan alle condities beschreven die waar moeten zijn om de use case te kunnen starten.
Postconditie
Hier staat het resultaat beschreven dat behaalt is als het scenario succesvol is doorlopen.
Successcenario
Beschrijft de verschillende stappen in het geval waarin niets verkeerd gaat. De reeks van acties en interacties wordt beschreven.
32
Architectuur en Use Cases – Interoperabiliteit Telemonitoring Hartfalen v1.0
Bijlage III. Definities en afkortingen
Term
Omschrijving
CHF
Chronisch hartfalen
Continua
Continua Health Alliance www.continuaalliance.org
EPD
Elektronisch patiëntendossier
HIS
Huisartsinformatiesysteem.
IHE
Integrating the Healthcare Enterprise www.ihe.net www.ihe-nl.org
Interoperabiliteit
De mogelijkheid van verschillende autonome, heterogene eenheden, systemen, partijen, organisaties of individuen om met elkaar te communiceren en interactie te hebben
Interoperabiliteitsprofiel
Een set van afspraken tussen betrokken partijen die een concreet interoperabiliteitsprobleem adresseren. Het profiel documenteert actoren, systeem rollen, standaarden en ontwerp details om organisaties of processen te ontwerpen, informatie of functionaliteit te definiëren en/of systemen te ontwikkelen die samen werken om het specifiek probleem te adresseren. In het interoperabiliteitsprofiel wordt een duidelijke relatie gelegd met de use case. Er wordt zoveel mogelijk gebruik gemaakt van bestaande (open) standaarden. Een interoperabiliteitsprofiel is geen nieuwe standaard maar kan o.a. beschrijven hoe bestaande standaarden geïmplementeerd kunnen worden.
MSC
Medisch Service Center
PGD
Persoonlijk gezondheidsdossier (Engels: PHR)
TMS
Telemonitoringsysteem
Triage / Medische Triage
In geval van telemonitoring: evaluatie van de resultaten van de telemonitoringdiensten zoals gemeten, vitale waarden of antwoorden op vragen
XIS
Zorgverlenerinformatiesysteem, generieke, overkoepelende term voor ZIS, HIS, EPD, disease management systeem, etc.
ZIS
Ziekenhuisinformatiesysteem
Mei 2011
33