Egde.Health.FhirIG
Implementation Guide for the Egde Health Gateway including platform and service implementations
This project is maintained by EgdeConsulting
Egde Health Platform - Gateway Implementation Guide
1 About the IG
Individual FHIR service IGs under this IG
- Egde Health Gateway (EHG) FHIR Facade Egde Health Gateway IG and profiles also in Simplifier.
- Tigeni FHIR Facade Tigeni FHIR facade IG
- Lifeness FHIR Facade Lifeness FHIR facade IG
- Godt Begynt (GB service) Godt begynt IG
- StaySafe (STS service) Staysafe IG
- Flåttsjekk-app (EM service) Flåttsjekk IG
- Evjeklinikken (VJ service) Evjeklinikken IG
1.1 Overview - Egde Health Gateway/Egde Health Platform
The Egde Health Gateway is a key component in Egde’s Health Platform architecture. It provides the following functionality:
- Connectors for
- FHIR REST;
- EDI messaging;
- other endpoints.
- A FHIR converter with the following functions:
- Convert;
- Map;
- Validate;
- Terminology referencing.
- Authentication
1.2 Scope
This IG covers the overall guide for the Egde Health Gateway.
We plan to develop IGs in English but they may contain references in Norwegian where we feel this is more appropriate to the use case.
The Egde Health Gateway is developed in compliance with the recommendations from “Målarkitektur for datadeling i helse- og omsorgssektoren fra Direktoratet for e-helse.” 
1.3 Purpose
Egde Health Gateway is a hybrid cloud based Software as a Service (SaaS) offering that includes a data converter to and from FHIR to other specified formats as well as a FHIR Server. The goal of the Egde Health Platform is to be a standards-based, cost effective and patient-centric platform for health services.
The Egde Health Gateway realises the following:
- Integration platform with national and private digital infrastructure;
- Backend for e-health applications that support centralised or decentraliseded storage;
- Authentication of patients, users, health personell in the public and private sectors.
The gateway is designed by the following principles:
- Compliance with FHIR and related standards;
- Compliance with the “Norm for informasjonssikkerhet og personvern I helse og omsorgssektoren (Normen)”;
- Compliance with HIPAA (Goal: 2023);
- Compliance with the recommendations from “Målarkitektur for datadeling i helse- og omsorgssektoren fra Direktoratet for e-helse”;
- Well-defined and documented APIs and Implementation Guides (this document).
For further details on security see section 8 Security
1.4 Intended audience
- Egde developers and testers;
- Partner developers and testers;
-
Customer developers and partners.
2 Use case(s)
2.1 Overview of systems and architecture
Use Case 1: Backend for e-health applications that support centralised or decentraliseded storage
This use case is for customers developing products, apps and solutions that are patient-facing and require a storage and backend API delivery to an application front-end. The Gateway provides a compliant and secure FHIR backend. The Gateway converts FHIR resources to DTO format fort API communication.
Example 1: Godt Begynt
The Egde Health Platform provides the backend for a control app and data integration between Checkware and the Municipality’s EPJ systems.
Godt Begynt (GB service) Godt begynt IG
Example 2: Zyberia
The Egde Health Platform provides the patient data backend, secure and compliant data storage and authentication for the service.
Example 3: StaySafe
The Egde Health Platform provides the backend for data integration between senors and EDI messages.
StaySafe (STS service) Staysafe IG
Example 4: Evjeklinikken
The Egde Health Platform provides the patient data backend, clinic admininstration, secure and compliant data storage and authentication for the service. Thjis project used Smile CDR, the commercial implementation of HAPI FHIR.
Evjeklinikken (VJ service) Evjeklinikken IG
Example 5: EM-app
The Egde Health Platform provides the backend for a service to citizens in Norway to submit a photo of a potential tick bite skin rash (Erythemia Migrans) for evaluation and response from a qualified doctor to help prevent lyme disease.
EM-app (EM service) EM IG
Use Case 2: Integration platform with national and private digital infrastructure
This use case is for customers requiring data integration with external data sources and sinks. This can be for legacy connection and conversion of EDI/XML interfaces, priorietary RESTful APIs or existing FHIR APIs.
Example 1: Zyberia
Example 2: Godt Begynt
Use Case 3: Authentication of patients, users, health personell in the public and private sectors
This use case covers the authentication of system users via required mechanisms, usually OIDC (OpenID Connect).
In the public sector for Norway this is usually via IDPorten .
In the provate sector for Norway this is usually BankID or VippsID and can be via the third-party service from Signicat AS.
Example: all customers
3 Module overview and roadmap
3.1 Modules
| Module | System | Status | Roadmap |
|---|---|---|---|
| FHIR Server | HAPI FHIR | Available | - |
| Private Cloud | NO & DE Kubernetes | Available | Continuous improvement |
| Monitoring | Azure devops & security | Available | Continuous improvement |
| Identity Provider IAM | Azure AD, Identity Server | Available | - |
| Admin portal | Azure deployments | Available | Q1 2021 |
| OIDC/OAuth2 | - | Available + solution customisation | Continuous improvement |
| SMART App Launch | - | Available | Continuous improvement |
| NoFHIR to FHIR Converter | FHIR Facade | Avaiable | Continuous improvement |
| FHIR to NoFHIR Converter | Egde | Available | Continuous improvement |
3.2 Public health components & services
| Connector | Format | Status | Roadmap |
|---|---|---|---|
| VKP | FHIR | Available | Operational |
| NHN Persontjenesten | EHG integration | Available | Operational |
| NHN Adresseregisteret | EHG integration | Available | Operational |
| NHN Adresseregisteret | service via proxy | In test | Operational |
| NHN ASP service | EHG qualified | Available | Operational |
| NHN Samsvartest | EHG integration | In development | 2023 |
| Pasientens prøvesvar (NILAR) | FHIR | Candidate | |
| Norsk helsenett - Journal | EDI XML | In development | Q3 2021 |
| Norsk helsenett - Sysvak | EDI XML | In development | Q3 2021 |
| Helsenorge | FHIR | Under consideration | Q4 2021 |
| Helseregistre | ? | Under consideration | ? |
| UiO TSD | CSV | In development | Q2 2021 |
| NAV Hjelpemidler | ? | Under consideration | 2022 |
3.3 Public & Private health systems
| Connector | Format | Status | Roadmap |
|---|---|---|---|
| Visma HsPro | EDI | Ready for test | Q4 2023 |
| Infodoc Helsestasjon | EDI | Planned | ? |
| Infodoc Fastlege | EDI | Ready for service | 2023 |
| CGM | EDI | Planned | 2023/2024 |
| Checkware | SOAP XML | In sevice | Operational |
| DIPS Arena | FHIR | In development | 2023/2024 |
| SSHF StaySafe | ? | In development | ? |
| Extensor integration | EDI | Ready for service | 2023 |
3.4 Authentication Systems
|Connector |System/Format |Status |Roadmap| |————|———–|———–|-| |Signicat |OIDC |Complete |Operational| |ID-Porten |OIDC |Complete |Operational| |NHN HelseID|EHG service & integration|Available|Continuous improvement| |BankID |OIDC |via Signicat |?| |Sykehuspartner federingstjeneste (IAM)| |In service |Operational| | | | | | n Guides (IG’s) <!– Examples - “There has to be a diabetes control document once every three months”.
- “Systems must have a consent on file for the patient to be allowed exchange patient data”
–> —4 Technical Implementation Guidance
Please refer to indivdual Implementation Guides (IG’s)
4.1 Per use case / transaction:
Each technical implementation guide will be published as a specifc set of artifacts.
- Actors involved
- Sender and receiver responsibilities (functional requirements)
- “Upon a POST of a new resource, the sender SHALL return a body with the newly stored resource”.
5 Profiles / Extensions
Egde aims to use International standards whereever possible. For National use Egde uses or bases all profiles on existing national profiles and is committed to working with the community to develop and qualify new profiles.
Refer to the overall Egde Health Gateway IG: Egde Health Gateway IG and profiles. <!– ### Usage
Official URL
Must support
Rendered data structure (diff/snapshot)
XML/JSON/Turtle
Mappings
Link to examples –>
6 Terminology
Terminology references can be found in individual IG’s.
ValueSets
ValueSets are provided in individual IG’s.
CodeSystems
The following code systems are currently in use:
- SNOMED-CT: http://snomed.info/sct
- ICD2
- IPCP2: http://terminology.hl7.org/CodeSystem/icpc2-icd10-THSRS
- ATC: http://hl7.org/fhir/uv/ips/ValueSet/whoatc-uv-ips
- FEST: https://fest-test.legemiddelverket.no/TestFest/FestService251.svc
- Volven https://volven.no/
7 Capability Statement
Please see indivdual IG’s.
8 Security
The Egde Health Gateway is designed to support the hightest levels of Norwegian, European and US security best practices as applied to patient and other health data.
This includes the following:
Normen
Compliance with the “Norm for informasjonssikkerhet og personvern I helse og omsorgssektoren (Normen)”.
For further details refer to: https://www.ehelse.no/normen
For an English version refer to:https://www.ehelse.no/normen/documents-in-english
HIPAA
Compliance with HIPAA (Goal: 2023)
Schrems II
The Schrems II Decision is a key ruling by the Court of Justice of the European Union (CJEU), in July 2020 they declared that Privacy Shield, the EU-US personal data transfer mechanism, was no longer lawful. This decision will have significant impacts on EU-US data transfers, and many organizations will need to update their programs to rely on alternative transfer mechanisms.
The following challenges arise that may impact Egde Health Platform customers:
- Uncertainty whether US-owned cloud operators can guarantee against personal data be handed out to US authorities through FISA 702 or E.O. 12333.
- There exists a concrete legal conflict between FISA 702 / E.O. 12333 and GDPR / EU Privacy Shield regarding storage of all kinds of personal data.
- Several Risk Assessments have identified public clouds like AWS, Google Cloud or Azure as unsafe platforms for cloud services
- One must assume that data stored or processed on a public cloud platform can be accessed beyond approved data processing area.
The Egde Health Platform & Gateway are built on the Microsoft Azure Stack technology. Development and test systems where there is no personal or health data used can be deployed to public Azure instances. Production systems for Norwegian customers are deployed to a private data centres in Norway and are therefore compliant with the Schrems II ruling.
(TODO: 2023 update needed here)
Norwegian Patient Journal law
The Egde Health Platform helps customer solutions to comply with the Norwegian Patient Journal law covering issues such as duty of confidentiality and security including logging and auditing requirements. Egde can provide technical advisory services and technical components to allow customers to comply with this law. Egde does provide legal advice. The full customer solution or service must be designed for compliance including those parts of the solution that lie outside of the remit of the Egde Health Platform and/or Gateway.
GDPR
GDPR covers privacy requirements for individuals including:
- Right to be forgotten
- Privacy by design•Explicit and informed consent
- Data portability
The full customer solution or service must be designed for GDPR but the Egde Health Platform & Gateway is designed to help customers confiorm to this requirement.
Egde Lupe - DevSecOps environment
Available - description to follow
9 General Help and Support
Communication - Contact
General help on this document: Andy Harrison Technical help: Jan Ivar Øyulvstad
FAQ
Tools
Downloads
Versioning info
- IG version 0.1.0 beta - ref. Guide to versioning
-
FHIR version 4.3.0
Key to published status of each section:
-
to be developed
-
draft started/chnges required
-
ready for review -
published