0.1.7 - ci-build
EgdeEHG_IG - Local Development build (v0.1.7). See the Directory of published versions
Official URL: http://www.egde.no/ImplementationGuide/fhir.egdeehg | Version: 0.1.7 | |||
Draft as of 2023-03-24 | Computable Name: EgdeEHG_IG |
This document is a FHIR IG for the Egde Health Gateway (EHG) defining the FHIR facade for standard data interchange. This IG is the generic product level implementation. It is typically customised where necessary for customer implementations.
The API is for a Patient app where the patient context is set using the Smart App Launch framework.
The FHIR Facade API exposes the following resources and operations:
The following profiels are usually used directly by customer implementations of the Egde Health Gateway.
SMART Apps Launch Framework is used as an authentication method for allowing other healthcare systems access to your health data through a web API. It’s based on OIDC and requires the support for a launch context that defines the scope of access to resources.
The following launch context will be used:
ehg-address-no is used for Norwegian addresses confiorming to the no-basis profile for Organization and its derivatives.
Consent resource (ehg-consent-no) for Opt-in and Opt-out are available. The only consent type supported is LOINC code #59284-0 “Patient Consent”. The policy refers to Normen (norm for informasjonssikkerhet og personvern i helse- og omsorgssektoren) for the provacy policy.
ehg-DocumentReference-Norway and ehg-Attachment are used for Norwegian documents that are categorised by the Norwegian document reference types. It refers to Volven 9602 Dokumenttyper.
ehg-Goal defines must support fields for implementations using Goals.
A customised example of this can be found in the Tigeni IG.
The ehg-specimen defines only key fields that must be supported by EHG implementations containing Specimen.
A customised example of this can be found in the Tigeni IG.
Observations are generally not defined in the Egde Health Gateway general level since they are usually specific to a customer implementation. The EHG Observation (ehg-observation) definition defines what elements should be supported by an API connecting to it.