Most of the information on the CDC and ATSDR websites is not subject to copyright, is in the public domain, and may be freely used or reproduced without obtaining copyright permission. For information and exceptions regarding use of CDC material please see https://www.cdc.gov/other/agencymaterials.html
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed
or info@snomed.org
.
RIVO-Noord Zorgviewer Implementation Guide - Local Development build (v1.14.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions ( src
)
There are examples where a medication request may include the option of an oral dose or an Intravenous or Intramuscular dose. For example, "Ondansetron 8mg orally or IV twice a day as needed for nausea" or "Compazine® (prochlorperazine) 5-10mg PO or 25mg PR bid prn nausea or vomiting". In these cases, two medication requests would be created that could be grouped together. The decision on which dose and route of administration to use is based on the patient's condition at the time the dose is needed. ( src
)
Mimetype to send. If not specified, the content could be anything (including no payload, if the connectionType defined this) Binding: mimetypes
( required
): The mime type of an attachment. Any valid mime type is allowed.
Also note that there is the additional profile zib-LaboratoryTestResult-DiagnosticReport
, which is used for (textual) reports on individual (panels of) observations, like conclusions. The DiagnosticReport contains references to instances of this profile and can be used in all three the situations described above.
Stap 1 Aanmaken Apps in Epic: Zorgviewer FrontEnd en Zorgviewer Backend
De frontend is een SMART-on-FHIR integratie, waarbij de standaard Epic sequence er zo uit ziet
.
3.2 Moet nog aangevuld worden…
- FHIR endpoint (interconnect) > client id koppelen aan emp (epic manual)
Er moet een backend EMP worden aangemaakt, zie hiervoor de Epic Galaxy documentatie Backend System Integration
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
HartNet is een regionaal samenwerkingsverband tussen de ziekenhuizen in Groningen en Drenthe
. Het doel is om de juiste hartzorg op de juiste plek aan te bieden voor de bewoners in Noord-Nederland. HartNet heeft daarom vijf verschillende zorgpaden volledig uitgeschreven en geoptimaliseerd. Eén van deze zorgpaden is het TAVI zorgpad en staat voor Transcatheter Aortic Valve Implantation. Bij TAVI wordt een hartklep vervangen, wanneer deze niet optimaal werkt. Denk aan aandoeningen zoals aortaklepstenose; een aandoening waarbij de hartklep onvoldoende sluit.
Hier passen we de request access token flow toe van de Bulk Data Access Backend authenticatie specificaties.
Daarnaast ivm NEN 7513 logging requirement moet het bronsysteem de vragende organisatie weten. De vragende organisatie is de organisatie van de geauthenticeerde gebruiker van de Zorgviewer. De IHE IUA standaard
beschrijft de attribuut naam die hiervoor gebruikt dient te worden in de authentication JWT die mee gaat naar de access token request. Dit is ook zoals LSP/VZVZ dit doet.
Tbv het correleren van de Zorgviewer logging met de logging van een Bronsysteem dient een X-Correlation-Id
HTTP Header (per sessie) en een X-Request-Id
HTTP Header (per request) te worden toegevoegd aan ieder request aan het Bronsysteem. Deze kan dan door het Bronsysteem gelogd worden, zodat de logging in de Zorgviewer kan worden gekoppeld aan de logging in het Bronsysteem.
Epic ondersteunt dit nu d.m.v. key-value pairs in de AORTA-ID
HTTP-Header, zie Epic Nova
.
Voorbeeld voor Epic HTTP-Header van "L. Arts uit Tjongerschans": AORTA-ID: rid:1b9d6bCd-bBf;cid:yA8UM8fHmhde;usr:larts;rol:62247001;org:2.16.528.1.1007.3.3.15123
. N.B. maximale lengte is 128 characters.
Voor de Request- en Correlation-ID's kan de NaN0-1D-12
12 tekens gebruikt.
De overige velden worden op twee manieren meegestuurd: individueel als HTTP header en verpakt in een
JWT, tevens als HTTP header.
De JWT variant is de veiligere optie, omdat de JWT ondertekend is en de waarden daarmee niet aangepast
kunnen worden. Het is echter niet perse gegarandeerd dat deze constructie door een bronsysteem
ondersteund wordt. Daarom worden ze ook individueel als HTTP header meegestuurd.
Voor de naamgeving is gekozen voor een prefix X-ZV-
(Zorgviewer) gevolgd door de naam van het veld,
die weer gebaseerd zijn op IHE IUA
.
De JWT wordt ondertekend met de private key waarmee ook de JWT voor het request voor access tokens
wordt ondertekend. Hiervoor is al een route ingericht om het publieke deel van de key op te vragen ( JWKS
).
Vervolgens wordt de JWT in een custom HTTP header geplaatst:
Zorgaanbieder eigen systeemZorgviewer NetwerkZorgviewerAndere zorgaanbieder bronsysteem(meerdere)ZorgverlenerZorgverlener?html-link??html-link?ZorgviewerZorgviewer?html-link??html-link?EigenEigenAuthenticatieAuthenticatie?html-link?Zorgviewer?html-link?ZorgviewerZorgviewer?html-link?ToestemmingToestemmingAdresseringAdresseringOntsluitenOntsluiten?html-link?BronsysteemBronsysteem?html-link?ZorgverlenerEigenbronsysteemAuthenticatieZorgviewerBackendToestemming~MITZAdresseringOntsluitenbronsysteemBronsysteemCHECK: Zorgaanbieder is deelnermer RIVO-NoordCHECK: Zorgaanbieder staat inNEN 7510 registerStart Zorgviewer HostZorgviewerHost1start EPD2inloggen met lokale identiteit34CHECK: authenticatie5selecteer patient6CHECK: behandelrelatieStart Zorgviewer7start Zorgviewer8PRE-CONDITIE: op basis van security context"knop" wel of niet beschikbaarZorgviewerFrontend(in Browser)9start met context10CHECK: whitelistCHECK: token validatie11authenticatie handshakeOAuth2/ClientIDCHECK: applicatieHuidige patient en gebruiker(OPTIONEEL) als niet al in context12(OPTIONEEL) opvragen huidige gebruikeren patient detailsCHECK: access token13toon gebruiker en patientidentiteit detailsPatient dossier14opvragen gegevens15vraag patient toestemmingen opWordt MITZ Open autorisatievraag\nals dit in de regio in productie is16vraag endpoints (lokaties) op van organizatiesobv de toestemmingenbinnen besloten Zorgviewer netwerkloop[Voor ieder endpoint]17opvragen gegevens18CHECK: ip/ACL19opvragen gegevens20CHECK: ip/ACLCHECK: backend tokenCHECK: client certificateCheck toestemming OPTIESAls MITZ in productie is in de regio wordt dit de Gesloten autorisatie vraagvanuit bron (b) of vanuit ontsluiten bronsysteem (b) als de bron dit niet zelf kan.21(a) Check locale toestemming22(b) Check toestemming23CHECK: vraag gesteld zonder MITZ toestemming24gegevens25gegevens26toon geaggregeerde gegevens
In de gezondheidszorg wordt gebruik gemaakt van de Informed Consent
. Middels de informed consent geeft de patiënt toestemming voor het uitvoeren van het medisch beleid door de zorgverlener. Het wordt 'informed' genoemd, omdat je de patiënt voorafgaand informeert over de mogelijke behandeling en de consequenties van behandelen. Bij behandelen worden ook de onderzoeken verstaan, zoals bloedafname of de röntgen foto.
Mitz-toestemming
Om problemen rondom toestemming en gegevensuitwisseling tegen te gaan is er landelijk Mitz gekozen als dé oplossing voor de toestemmingsvoorziening. In Mitz kan de patiënt op één plek zijn/haar toestemmingen beheren. Alle uitwisselingssystemen (US) worden aangesloten op Mitz, zodat ook de US'en op de hoogte zijn van de toestemming van de patiënt. De toestemming wordt op een categorie van zorgaanbieders geregistreerd.
Als een zorgaanbieder de toestemming van een patiënt wil raadplegen, dan wordt er een vraag gesteld aan het US. Het US vraagt dan de toestemming op bij Mitz. Eerst wordt er gevraagd of er toestemming is voor het delen van gegevens: de gesloten autorisatievraag
.
Met de Zorgviewer MVP2 zullen we een toestemming realiseren volgens de afspraken tussen de RIVO-Noord instellingen. Zie het beleid hier
. Deze zal zoveel mogelijk volgens de MITZ specificatie zijn. MITZ zal zich laten inspireren door de Zorgviewer specificaties.
OpvragerZorgaanbieder eigen systeemZorgviewerAndere zorgaanbieder bronsysteem(meerdere)Bronhouder ontsluitingZorgverlenerZorgverlener?html-link??html-link?ZorgviewerZorgviewer?html-link??html-link?AuthenticatieAuthenticatie?html-link?EigenEigenZorgviewerZorgviewer?html-link?ZorgviewerZorgviewer?html-link?Zorgviewer Nuts NodeZorgviewer Nuts Node?html-link?Mitz LocalisatieMitz LocalisatieAdresseringAdresseringToestemmingToestemmingAPI SecurityAPI Security?html-link?Bronsysteem Nuts NodeBronsysteem Nuts NodeBronsysteemBronsysteem?html-link?ZorgverlenerZorgviewerHostAuthenticatieEigenbronsysteemZorgviewerFrontendZorgviewerBackendZorgviewer Nuts NodeMitz LocalisatieAdresseringToestemming~MITZAPI SecurityBronsysteem Nuts NodeBronsysteemCHECK: Zorgaanbieder is deelnermer RIVO-NoordCHECK: Zorgaanbieder staat inNEN 7510 registerAddresering wordt nuvoorzien door de Nuts nodesStart Zorgviewer Host1start EPD2inloggen met lokale identiteit34CHECK: authenticatie5selecteer patient6CHECK: behandelrelatieStart Zorgviewer7start Zorgviewer8CHECK: op basis van security context"knop" wel of niet tonen9start met context10CHECK: whitelistCHECK: token validatie11authenticatie handshakeCHECK: applicatieHuidige patient en gebruiker(OPT) als niet al in context12opvragen huidige gebruikeren patient details13(OPT) opvragen gebruikeren patient detailsCHECK: access tokenCHECK: client certificate14toon gebruiker en patientidentiteit detailsNetwerk identieit aanmaken15signing session starten16Render EmployeeIdentityZorginstelling verklaard de identiteit van de gebruikerDe gebruik bevestigt deze.17bevestigen identiteit18ophalen EmployeeIdentityPatient dossier19vraag bronhouders voor patient op~MITZ Open autorisatievraag20vraag endpoints op van organizatiesobv de toestemmingenEndpoints uit Nuts nodeloop[Voor ieder endpoint]21verkrijg access_token mbv EmployeeIdentity22opvragen gegevens23CHECK: ip/ACL24valideer access_tokenCHECK: access tokenCHECK: opvrager identiteitCHECK: EmployeeIdentity25opvragen gegevens26CHECK: ip/ACLCHECK: backend tokenCHECK: client certificate27~MITZ Gesloten autorisatie vraag28CHECK: vraag gesteld zonder MITZ toestemming29gegevens30gegevens31toon geaggregeerde gegevens
Welkom op de implementatiegids van de Zorgviewer. In deze implementatiegids wordt ingegaan op de use-cases en de functionele en technische invulling hiervan. Op de website van het Regionaal InformatieVoorzieningsOverleg Noord Nederland
kun je meer informatie vinden over de organisatie rondom de Zorgviewer. Op deze website kun je ook meer achtergrond informatie vinden over de Zorgviewer
.
Welkom op de implementatiegids van de Zorgviewer. In deze implementatiegids wordt ingegaan op de use-cases en de functionele en technische invulling hiervan. Op de website van het Regionaal InformatieVoorzieningsOverleg Noord Nederland
kun je meer informatie vinden over de organisatie rondom de Zorgviewer. Op deze website kun je ook meer achtergrond informatie vinden over de Zorgviewer
.
Samen met het RIVO en de regionale architecten (RAO) is er in 2020 een netwerkzorgarchitectuur
opgeleverd, waar men spreekt over het neerzetten van een 360 graden beeld van de patiënt. In eerdere programma's rondom Registratie aan de Bron, VIPP, MedMij/PGO is het de bedoeling geweest om de registratie (aan de bron) recht te trekken.
Op basis van bronsysteem voorbeeld berichten conform de zibs wordt bekeken wat de minimale overlappende vulling is.
Dat weer aangevuld met de FMS Handreiking Adequate registratie
resulteert in de must-support en mandatory (min=1) van elementen.
De FMS Handreiking en Fit-Gap analyse laat de overeenkomstige elementen zien voor de bronsystemen Epic, Chipsoft en Nexus.
Van mandatory elementen (min=1) wordt er altijd vulling verwacht.
De Zorgviewer FHIR Profilen zijn constraints van de generieke zib2017 FHIR STU3 Profielen.
In tegenstelling tot wat het zib2017 profiel zegt is het wel degelijk toegestaan om Condition.onsetPeriod te gebruiken als ProbleemBeginDatum. Dit wordt o.a. door Epic gebruikt als een begin datum een "vage" datum is, zoals ergens in het jaar 2020. Dan is het begin 20200101 en eind 20201231.
Dit is afgestemd met Nictiz zie BITS ticket MM-4077
.
Vanaf de volgende versie (zibs2020) is Nictiz sowieso open-world bezig.
Op deze pagine beschrijven we de conformiteit met de verschillende NEN normen als gevolg van de Wet EGIZ
en bijbehorende NEN-Normen
van toepassing op de Zorgviewer.
Op deze pagine beschrijven we de conformiteit met de verschillende NEN normen als gevolg van de Wet EGIZ
en bijbehorende NEN-Normen
van toepassing op de Zorgviewer.
Als basis voor deze non functional requirements is Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24
uit de Nationale Bibliotheek gebruikt.
Deze zijn herschreven vanuit het Zorgviewer perspectief.
… in principe zijn deze non functionals niet specifiek voor de gegevensset (BgZ) en zelfs niet voor de rollen (MSZ), ze zijn generiek voor al de beoogte rollen (ziekenhuis, huisarts, verpleegkundig, paramedisch) van de RIVO.
De zorgviewer attendeert de gebruiker op belangrijke lacunes in het eigen informatiesysteem: specificeren wat en welke dat zijn. Centraal vastleggen en dat alerten.
De zorgviewer attendeert de gebruiker op conflicten in het tonen van data van verschillende bronnen waar ze niet overeenkomen.
