RIVO Noord Zorgviewer MVP2 Implementation Guide - Local Development build (v0.2.1). See the Directory of published versions

Conformance

Uitgangspunten

1. De architectuur moet generiek zijn en voor verschillende zorgpaden en specialismen toepasbaar zijn.
2. Alle actoren in het zorgpad hebben inzage in dezelfde informatie, op basis van de gegeven toestemming van de patiënt.
3. Informatie blijft primair bij de bron en wordt zo min mogelijk gerepliceerd
   • Registratie aan de Bron - zorg voor juiste bron registratie, ontsluit wat er is
   • Aanpassen aan de bron, mappings in de bron en bron corrigeren als mogelijk
4. De Zorgviewer wordt opgestart vanuit de eigen informatieomgeving
5. TOEKOMST Informatie kan worden overgenomen in het eigen informatiesysteem wanneer daaraan behoefte is
6. De informatie wordt gefilterd op basis van de specifieke informatiebehoefte, bijvoorbeeld:
   • actief zorgpad
   • alle zorgepisodes van de afgelopen 2 jaar
   • alle benodigde informatie voor een gedefinieerd specifiek zorgpad
   • alle labuitslagen van de afgelopen 4 maanden
7. De architectuur gaat uit van een haalbare eerste versie vanuit bestaande werkwijzen en technische mogelijkheden.
8. De architectuur voldoet aan wet- en regelgeving en maakt compliancy op het gebied van privacy en security mogelijk.
9. De architectuur rust op de verleende toestemming door de patiënt. De patiënt bepaalt of gegevens worden gedeeld, en heeft inzicht in wie de gegevens raadpleegt of overneemt.
10. De architectuur is gebaseerd op open standaarden
11. Taal en transport zijn gescheiden, zodat vendor-lock-in wordt voorkomen
    • Internet-first transport - geen besloten netwerken

Requirements

Zorgviewer Host

Synoniemen:

1. Hostsysteem
2. Informatieomgeving

Definitie: Informatieomgeving (EPD, ECD, Portal) van de gebruiker van waaruit de Zorgviewer opstart wordt.

Requirements:

1. De zorgviewer host draagt zorg voor (lokale) authenticatie van de gebruiker.
2. De zorgviewer host voorziet in patient selectie en toets behandelrelatie.
3. De zorgviewer host kan de zorgviewer opstarten met context (huidige gebruiker en patient).
4. De zorgviewer host ondersteund patient context wissels.
5. De zorgviewer host ondersteund gebruiker context wissels.
6. De zorgviewer host biedt mogelijkeid aan de zorgviewer om volledige huidige gebruiker en patient gegevens op te vragen.

Keuze:

1. Conform SMART-on-FHIR 1.0.0 EHR launch

Solutions:

1. Epic
2. Chipsoft
3. Topicus
4. TOEKOMST Zorgviewer Launcher - Los voor gebruikers zonder EPD/ECD

Zorgviewer

Definitie: De Zorgviewer toont data uit de aangesloten bronsystemen, ordent deze, en biedt de gebruiker de mogelijkheid van filtering van de data op basis van het zorgpad of persoonlijke instellingen.

Requirements:

1. De zorgviewer bevat zelf geen patiëntgebonden data, en wijzigt geen data in de bronsystemen.
2. De zorgviewer integreert in de informatieomgeving van de gebruiker.
   1. Keuze: Conform SMART-on-FHIR 1.0.0 EHR launch
3. Het moet mogelijk zijn om aan te geven dat het een spoedsituatie betreft.
4. Conflicten, ontdubbelen en duplicaatdetectie volgens BgZ MSZ Informatistandaard
   1. De zorgviewer attendeert de gebruiker op belangrijke lacunes in het eigen informatiesysteem: specificeren wat en welke dat zijn. Centraal vastleggen en dat alerten.
   2. De zorgviewer attendeert de gebruiker op conflicten in het tonen van data van verschillende bronnen waar ze niet overeenkomen.
   3. De zorgviewer faciliteert in ontdubbelen
5. De zorgviewer logt gebruikersacties (clicks). Dit ten behoeve van optimalisatie gebruikersinterface en trends van gebruik.
6. De zorgviewer biedt de mogelijkheid om informatie te tonen op basis van de plek van de patiënt in het zorgpad.
7. De zorgviewer biedt de mogelijkheid om persoonlijke filters toe te passen.

Toestemming

Definitie: De expliciete specifieke, vrijgegeven toestemming tot het beschikbaar stellen van zorginformatie door de patiënt (bron: AVG)

Kandidaat solutions:

1. INITIEEL: Regionale service
   1. Invulling: FHIR server met vulling volgens FHIR API van MITZ “Open autorisatievraag”
2. Connect4Care Topicus
3. MITZ OTV TOEKOMST

Identiteit

Definitie: Identiteit wordt gebruikt voor:

• Vastleggen van logging
• Bepalen van gerechtigde dataset
• Basis voor authenticatie

Requirements:

1. Gebruik van reeds in organisatie in gebruik zijnde ID’s gekoppeld aan een extern erkende identiteit, zoals AGB of BIG voor zorgveleners en zorgaanbieders.
   1. Lokale identitie MOET AGB-Z of BIG-Nummer als attribuut hebben, zodat we via de Zorgverlener Directory de specialismen en rollen kunnen opvragen
2. Vektis AGB-medische specialismen

Zorgverlener Directory

Synoniemem:

1. Zorgverlener Registry
2. Zorgaanbieder Registry of Directory
3. Provider Directory (IHE)
4. Adressering
5. White pages

Definitie: Register met Identiteiten en attributen van zorgaanbieders en zorgverleners. Voorbeelden zijn volledige naam, maar ook technische endpoints.

Volledige naam: “F. Heuvel (Cardiologie (cardioloog)) in het UMCG” FHIR Base voor UMCG: https://prd.epic.umcg.nl/fhir/STU3

Kandidaat solutions:

1. Regionale FHIR server met vulling volgens FHIR API van ZORG-AB
   1. ZORG-AB Implementatiehandeleiding
   2. FHIR Interface definitie ZORG-AB: Simplifier Project
2. ONDERZOCHT: Het BIG-Register - Handleiding webservice BIG-register - deze biedt geen FHIR interface, bovendien zit de content ook in het ZORG-AB.

Authenticatie

Definitie: Het bouwblok authenticatie stelt de identiteit van de gebruiker onomstotelijk vast volgens de wettelijke kaders. Is onderdeel van de Zorgviewer Host.

Requirements:

1. ..

Keuze:

1. Compliant met SMART-on-FHIR 1.0.0

Invulling Epic:

1. Zorgviewer Epic OAuth2
2. Ontsluiting bronsysteem Epic Backend Authentication

Autorisatie

Definitie: Rechten die een identiteit (zorgverlener, client / patient) heeft voor toegang tot cliëntgegevens (bron: NEN 7510).

Logging

Definitie: Stelselmatige geautomatiseerde registratie van gegevens rond de toegang tot het patiëntdossier, die controle van de rechtmatigheid ervan mogelijk maakt (NEN 7513).

Requirements:

1. Bij opvragen van gegevens dient een gebruikersnaam en extern id mee gestuurd te worden door de aanroepende instelling zodat dit bij het bronsysteem kan worden gelogd.
2. Logging dient te gebeuren in het bronsysteem.
3. Logging dient te gebeuren op inzage van de gegevens.
4. De Zorgviewer logt voor audit log naar een regionale log service.
5. Logging volgens NEN 7513 en IHE ATNA

Solutions:

1. Regionale FHIR Server met AuditEvents conform NEN 7513 gevuld.

Ontsluiting bronsysteem

Definitie: Het bouwblok ‘Ontsluiting bronsystemen’ draagt zorg voor het aanleveren van de informatie uit de bronsystemen in een formaat dat door de zorgviewer kan worden verwerkt (Zibs/FHIR).

Requirements:

1. Ontsluit minimaal de volgende gegevens:
   1. de 28 BGZ-Zibs
   2. de correspondentie (radiologie brieven, specialisten brieven, notities, ontslag brief)
      • N.B. de zibs kunnen heel veel gegevens ondersteunen, maar als er geen schermen voor zijn om de gegevens in te voeren of geen workflow is waar die schermen zichtbaar worden, zullen die gegevens nooit beschikbaar zijn.
2. Zorginformatiebouwstenen conform NICTIZ publicatie 2017, de 28 BGZ-Zibs, Zibs 2017 FHIR Profiles en BgZ 2017 obv HL7 FHIR STU3
3. Individuele ZIBS moeten kunnen worden aangeleverd
4. Alleen identiteiten zoals gedefinieerd door het Identiteit bouwblok mogen geaccepteerd worden.
5. TOEKOMST Bronsysteem ZOU MOETEN checken bij Mitz

Kandidaat solutions:

• Epic Interconnect via Intersystems Iris Healthshare
• Chipsoft Zorgplatform
• Topicus
• XDS-NN met een FHIR API volgens de IG (e.g. Documenten)
• Een “Docker” voor een bron die geheel of gedeeltelijk nog niet conform zorgviewer-ig kan ontsluiten
• Nexus via Founda

Behandelplan

Definitie: De stappen die je als patiënt of cliënt kan doorlopen in het zorgpad. In de zorgviewer zie je een digitale weergave van het -regionaal of per specialisme overeengekomen- zorgpad. Aan de gestructureerde stappen ‘hangen’ informatiecomponenten (de zibs of codes) vast, waarmee de relevante gegevens hoger getoond kunnen worden.

Requirements:

1. ..

Solutions:

• FHIR server met PlanDefinitions, focus op data-requirements tbv queries en filters
  • in lijn met FHIR Clinical Guidelines
  • in lijn met Problem List Maps

Technische Requirements

1. Alle implementaties dienen zich te houden aan Postel’s law, Robustness principle
2. Niet valideren tegen de profiles at-runtime, alleen bij aansluit (zelf) certificeren aan de hand van de CapabilityStatements in deze IG.

Dependencies

Package nictiz.fhir.nl.stu3.zib2017#2.2.8 Nictiz NL package of FHIR STU3 conformance resources for HCIM Release 2017. Includes MedMij and HL7 NL. HCIMs: https://zibs.nl/wiki/HCIMRelease2017(EN)

Globals

There are no Global profiles defined

EHR-S FM Requirements Mapping

Het EHR-S FM is …

• Bronsysteem Ontsluiting
  • Alles onder TI.5 Standards-Based Interoperability
  • TI.5.1.1 Application Interchange Standards
• Logging TI.2 Audit
• Authenticatie
  • TI.1.1 Entity Authentication
  • TI.1.11 Trusted Information Exchange Environment
• Autorisatie TI.1.2 Entity Authorization
• Terminology TI.4.1 Standard Terminology and Terminology Models
• Toestemming Privacy AVG TI.1.8 Patient Privacy and Confidentiality
• Behandelplan CPS.3.3 Support for Standard Care Plans, Guidelines, Protocols
• Zorgviewer CPS.3.4 Support for Context-Sensitive Care Plans, Guidelines, Protocols