Clinical Connectathon Netwerkzorg Track

Uit dhealth

Test

Justification and Objectives

De zorgcomplexiteit neemt toe, waardoor ziekenhuizen zich steeds meer gaan specialiseren. Om deze verschuiving te ondersteunen worden regionale zorgpaden opgesteld, verdeeld over meerdere regio zorgaanbieders. Het is daarom belangrijk dat relevante patiëntinformatie uit het gehele zorgpad bij de verschillende zorgaanbieders beschikbaar is. Dit verbetert de kwaliteit van de zorg, voorkomt fouten en dubbele diagnostiek. De zorgaanbieder waarnaar wordt doorverwezen moet kunnen voortbouwen op de informatie die in de voortgaande stappen zijn vergaard. Hierdoor hoeft diagnostiek niet weer uitgevoerd te worden, zoals beeldvorming of laboratoriumonderzoeken. Door het beschikbaar maken van alle informatie voor alle betrokken zorginstellingen kan de 2e lijn de patiënt volgen in de 3e lijn en omgekeerd.

Hoe zorgen we ervoor dat alle behandelaars in de HartNet zorgpaden over de juiste informatie beschikken zodat ze optimaal in staat zijn de patiënt de juiste behandeling te geven en inefficiënties (zoals dubbele diagnostiek en onnodige behandelingen) en/of onjuiste informatie, niet meer voorkomen?

Een succesvolle Clinical Connectathon levert de volgende resultaten op:

  • Een webbased prototype van de Patient Viewer op basis van de input van de medische experts;
  • Ervaring, draagvlak en enthousiasme over de gekozen oplossing;
  • Steun voor de gekozen Zorg IT-standaarden standaarden (FHIR en MedMij);
  • Een draaiboek voor de herhaling van de Clinical Connectathon aanpak voor andere zorgpaden;
  • Kennis voor het laten bouwen (of configureren) van een Patient Viewer.

Track Lead

  • Michael van der Zel (UMCG)
  • Frank Ploeg (UMCG)

Expected participants

De teams (ondersteund door o.a. Klinisch Informatici):

  1. UMCG & MZH - scenario/viewpoint 3,2 - resultaat: ClinicalConnectathon1Team1
  2. Hinq / Stichting Gerrit - scenario/Viewpoint 1,2 - resultaat: ClinicalConnectathon1Team2
  3. Ziuz - scenario/viewpoint 2,3 - resultaat: ClinicalConnectathon1Team3
  4. Wildsea - scenario/viewpoint 3,1 - resultaat: ClinicalConnectathon1Team4
  5. ATOS - scenario/viewpoint 2,3 - resultaat: ClinicalConnectathon1Team5

Clinical Scenario

TAVI Netwerkzorgpad TAVI netwerkzorgpad

  • TAVI proces [1] (zie ook bovenstaande afbeelding)
    • Aanmelding 2e lijn naar 3e lijn;
    • 3e lijn kijkt naar informatie 2e lijn;
    • 2e lijns specialist kijkt naar informatie van de 3e lijn over de behandeling en Quality of Life (QoL) vragenlijst en omgekeerd.
  • TestDataSet (Synthea) HartNet TestDataSet
    • Patiëntdata wordt getest voorafgaande de start van de Clinical Connectathon.

System Roles

  • Patiënt Dossier
    • één voor elke lijn, namelijk 1e lijn, 2e lijn en 3e lijn (HartNet Glossary)
    • FHIR STU3 server die de betreffende test data levert voor de betreffende lijn.
  • Patient Index
    • Een FHIR STU3 “server” die op basis van een patiënt identificatie (BSN) de EndPoints levert waar data van die patiënt beschikbaar is indien consent is gegeven.
- "Server" kan ook een Service zijn
  • Patient Viewer
    • Een SMART-on-FHIR app die middels de Patient Index alle gegevens aggregeert van een patiënt en de juiste view toont zodat de persona’s hun processtap kunnen uitvoeren. Deze app wordt embedded in het EPD van de lijn.
  • Mock EPD
    • Een app die de SMART-on-FHIR Patient Viewer kan opstarten met meegeven van context, o.a. rol.

Technical Scenario

Sequence Diagram

  • Pre condities
    • Single-Sign-On (SSO) van EPD naar Patient Viewer valt buiten de scope;
    • Patiënt is in alle zorginstellingen aangemeld (Patient Resource is aangemaakt in elk patiënt dossier);
    • Patiënt heeft consent gegeven (Consent Resource optional) voor delen gegevens en dit is ook in de Patient Index geregistreerd, alsook bij welke zorginstelling de Patient bekend is (Endpoint Resource);
    • Test DataSet is ingelezen in de Patient Dossiers;
    • In elke zorginstelling is een werklijst (List Resource list-mode=working) beschikbaar waar Patient op komt of er is een query mogelijk waarmee dat overzicht kan worden gegenereerd (Bundle);
    • Patiënt is al aangemeld door de huisarts (1e lijn) bij de 2e lijn. De medisch secretaresse heeft de patiënt al gepland / geplaatst op de werklijst van de cardioloog of verpleegkundig specialist van de 2e lijn;
    • Overname van gegevens uit de viewer naar eigen EPD is niet in scope.
  • (A) Patient selectie gebeurt in een van de Patient Dossiers
    • Dit simuleren we nu via de SMART-on-FHIR launcher in een van de Patient Dossier omgevingen (MARTINI 2de lijn of UMCG 3de lijn)
  • (B) Opstarten van de Patient Viewer gebeurt door (A) middels SMART-on-FHIR
  • (C) De Browser gaat nu de Patient Viewer "starten" en geeft patientid mee
  • (D) Patient Index bevragen adhv patientid
  • (E) Opvragen losse (of bundle) gegevens van de patient bij iedere endpoint
  • (F) Integreren van de losse setjes in de views zoals in de Design Sessie gepaald

Onderliggende ViewPoints

ViewPoint 1: aanmelding 2e lijn naar 3e lijn

TAVIHartNetScenario1.png

  • Cardioloog of Verpleegkundig Specialist/Physician Assistant werkzaam in de 2e lijn heeft een werklijst van geplande patiënten in eigen EPD. De patiënt wordt geopend vanaf de werklijst. Hiermee opent de Patient Viewer.
  • Op dat moment raadpleegt de Patient Viewer de Patient Index voor EndPoints en haalt daarmee relevante gegevens op.
  • De zorgverleners in de 2e lijn hebben op dat moment een View op de data van de patiënt. Gezien de patiënt op de werklijst staat (is gepland) bij de cardiologie, biedt de Patient Viewer een View op cardiologisch relevante data, vooraf gedefinieerd door de cardiologie.
  • De zorgverleners vullen zelf informatie toe aan het dossier, zoals radiologisch onderzoek, labonderzoek of observaties. Vervolgens meldt de zorgverlener aan de medische secretaresse dat de patiënt zijn/haar gegevens ter bespreking moet in de 3e lijn, ook wel MDO Hartteam genoemd.
  • Medische secretaresse meldt de patiënt aan bij de 3e lijn.

Wat wil men zien in ViewPoint 1

Belangrijk dat er informatie beschikbaar is betreffend:

  • Patiëntgegevens, zoals adres, telefoonnr, contactpersoon bij nood
  • Waarom is de patiënt aangemeld (bv voor MDO Hartteam)
  • Checklist van de onderzoeken die gedaan hadden moeten worden, namelijk:
    • Lab (ASAT, ALAT, Hb, Ht, NT Pro-BNP
    • Echo onderzoek
    • X-thorax onderzoek
    • CAG onderzoek
    • Informed Consent

ViewPoint 2: 3e lijn kijkt naar informatie 2e lijn

TAVIHartNetScenario2.png

1. beschrijft de eerste overdracht van het patiëntendossier; 2. beschrijft de tweede overdracht van het patiëntendossier.
  • De medische secretaresse accepteert de aanmelding, controleert op volledigheid van gegevens en plant de patiënt voor de eerstvolgende hartbespreking in het EPD;
  • Cardioloog of Verpleegkundig Specialist/Physician Assistant werkzaam in de 3e lijn heeft een werklijst van geplande patiënten in eigen EPD. De patiënt wordt geopend vanaf de werklijst. Hiermee opent de Patient Viewer. Hetzelfde proces volgt in de 3e lijn, zoals eerder beschreven in de 2e lijn (zie Aanmelding 2e lijn naar 3e lijn).

Wat wil men zien in ViewPoint 2

Belangrijk is dat de cardioloog, verpleegkundig specialist en Physician Assistant kan kijken naar de diagnostiek:

  • lab waarden, zoals ASAT, ALAT, Hb, Ht, NT Pro-BNP
  • beeldvormend onderzoek: CAG, TTE, X-thorax, CT
  • Aanvullende documenten: Informed Consent

ViewPoint 3: 2e lijns specialist kijkt naar informatie van de 3e lijn

TAVIHartNetScenario3.png

  • Patiënt komt voor vervolgafspraak bij de 2e lijn.
  • Cardioloog selecteert patiënt vanuit de werklijst (vergelijkbaar met Aanmelding 2e lijn naar 3e lijn).
  • Op dat moment raadpleegt de Patient Viewer de Patient Index voor EndPoints en haalt daarmee relevante gegevens op.
  • De cardioloog van de 2e lijn kan zien welke behandeling is uitgevoerd, hoe dit is verlopen en heeft informatie over de vervolgafspraak die nog heeft plaatsgevonden in de 3e lijn in eigen EPD, door de Patient Viewer.

ViewPoint 3:Quality of Life (QoL) antwoorden zijn beschikbaar

TAVIHartNetScenario4.png

  • Patiënt vult een QoL vragenlijst in voorafgaande de behandeling (3e lijn). Vervolgens vult de patiënt dezelfde QoL vragenlijst in na de behandeling (2e lijn). Deze vragenlijst wordt door de patiënt zelf ingevuld. Op dit moment gebruiken de verschillende lijnen eigen tooling om deze vragenlijst beschikbaar te maken richting de patiënt.
  • Inzage in QoL vragenlijst is nuttig voor zowel 2e als 3e lijn.
  • De (QoL vragenlijst, genaamd SF-12[[2]]) is ook onderdeel van de Nederlandse Hart Registratie (NHR[[3]]) en moet aangeleverd worden door 2e / 3e lijn.

Nederlandse HartRegistratie (NHR) data

De data benodigd voor de aanlevering richting NHR voor het TAVI (lees: THI) proces komt met name uit het primaire proces. Echter, het EPD van de ziekenhuizen is nu ingericht dat de cardioloog achteraf een formulier invult met NHR context.

In de TAVI dataset[[4]] staat de data benodigd voor de NHR dataset.

De NHR dataset wordt gevuld door informatie vanuit de 3e lijn (de daadwerkelijke TAVI procedure) en vanuit de 2e lijn (follow-up documentatie). Onderdeel van de NHR dataset is de Quality of Life Short Form Health Survey SF-12 vragenlijst[[5]], zoals benoemd bij ViewPoint 3.


Verantwoordelijk voor aanlevering

Het organisatiebeleid is aangepast dat het UMCG verantwoordelijk is voor de aanlevering van de NHR dataset. UMCG is ook het enige huis, van de HartNet huizen, die datamanagers in dienst heeft. Het is dus van belang dat de informatie vanuit de follow-up in de 2e lijn (na één jaar) terug komt naar het UMCG. Het is nu nog onduidelijk hoe men deze informatie juist terug krijgt in het UMCG. Gezien de leeftijd van HartNet zijn de eerste patiënten rond april 2020 volledig door het HartNet zorgpad gelopen inclusief de follow-up na één jaar.

Clinical Connectathon ontwikkeldagen

Primair doel:

  • Ontwikkel een Patient Viewer die voor de 2e en 3e lijn cardiologen een view toont met de relevante informatie nodig op dat moment (processtap) met eventueel een drill down mogelijkheid.
  • Drill down = verder in detail kunnen gaan met betrekking tot verzamelde gegevens.
  • NIET het toevoegen of wijzigen van gegevens (wordt uitgevoerd in eigen EPD).

Test FHIR Servers

N.B. dHealthLab Dev platform

ALTERNATIEF

HartNet Glossary

Eerstelijnszorg
(1e lijn) 		In het Nederlandse stelsel komt doorgaans een hulpvraag in eerste instantie aan bij de eerste lijn. Via algemene zorg proberen huisartsen, eerstelijnspsychologen, fysiotherapeuten, tandartsen of verloskundigen de klachten van de hulpvraag te verhelpen.  Deze zorg is direct toegankelijk voor alle zorgverzekerden.
Tweedelijnszorg
(2e lijn) 		Als de zorg in de eerste lijn ontoereikend is en meer specialistische zorg noodzakelijk is, verwijzen zorgverleners door naar de tweede lijn. Voor behandeling in de tweede lijn is een verwijzing uit de eerste lijn noodzakelijk. Onder de tweedelijnszorg vallen bijvoorbeeld ziekenhuiszorg, geestelijke gezondheidszorg en gespecialiseerde jeugdzorg
Derdelijnszorg
(3e lijn) 		Op het moment dat er hoog specialistische zorg nodig is, zowel voor geestelijke als somatische gezondheidsproblemen, volgt doorverwijzing naar instellingen voor topklinische zorg. Dit noemen wij derdelijnszorg.
Medisch dossier / Patiënt Dossier De hulpverlener (…) richt een dossier in met betrekking tot de behandeling van de patiënt. Hij houdt in het dossier aantekening van de gegevens over de gezondheid van de patiënt en de te diens aanzien uitgevoerde verrichtingen en neemt andere stukken, bevattende zodanige gegevens, daarin op, een en ander voor zover dit voor een goede hulpverlening noodzakelijk is.
Patient Index Een FHIR STU3 “server” die op basis van een patiënt identificatie (BSN) de EndPoints levert waar data van die patiënt beschikbaar is indien consent is gegeven.
Patient Viewer Een SMART-on-FHIR app die middels de Patient Index alle gegevens aggregeert van een patiënt en de juiste view toont zodat de persona’s hun processtap kunnen uitvoeren. Deze app wordt embedded in het EPD van de lijn.
System Roles IHE: Actors are information systems or components of information systems that produce, manage, or act on information associated with operational activities in the enterprise.
Single-Sign-On (SSO) Single Sign-On (SSO) is een vorm van authenticatie waarbij een gebruiker maar één keer hoeft in te loggen om toegang te krijgen tot meerdere applicaties. Organisaties gebruiken SSO meestal om de toegang tot de diverse applicaties die ze gebruiken (web, on-premise en cloud) te vereenvoudigen en daardoor de gebruikerservaring te verbeteren.
Overgenomen van "https://wiki-dhealth.web.rug.nl/index.php?title=Clinical_Connectathon_Netwerkzorg_Track&oldid=218"