National Electronic Health Record Implementation Guide
0.1.0 - ci-build
National Electronic Health Record Implementation Guide
0.1.0 - ci-build
National Electronic Health Record Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
| Official URL: http://ig.hiu.lk/fhir/nehr/ImplementationGuide/fhir.lk.nehr | Version: 0.1.0 | |||
| Draft as of 2025-10-23 | Computable Name: Sri_Lanka_NEHR_ImplemenationGuide | |||
The NEHR is a core component of the national Digital Health Platform (DHP) that serves as a centralized, secure database for storing and managing patient health records in a longitudinal format. It provides standardized APIs for submission, query, and lookup of patient health data, enabling authorized healthcare providers to access comprehensive patient information across the continuum of care.
Some conventions are defined below, an overview is provided which describes some of the design decisions and data structures used for the NEHR. A detailed specification follows interface descriptions.
This guide is part of a suite of guides that build on one another so that complex Message exchanges can be designed and useful Resource profiles created in the advanced guides.
Base Guides
FHIR R4
Foundational Guides
Client Registry
Provider Registry
Facility Registry
Advanced Guides
Document Repository
National Electronic Health Record Repository
Electronic Referrals
The LKEncounter profile (and several others) use LKPatient from Client Registry. LKPractitioner from Provider Registry is also used.
Improvement 🔎 There are several other profiles that the NEHR could include such as LKLocation, LKOrganization and LKHealthcareService. At this time it isn't clear which elements would benefit from using the Sri Lanka profiles, but this should be considered in the future.
Use of data absent reason extension SHALL be permitted on mandatory elements. As scenarios arise, and experience is gained, this will be refined.
The Producer (sender) SHALL populate if known and allowed. The Consumer (receiver) SHALL process (store and return in response). Both of these obligations use the term allowed which is referencing the data masking section just below.
Using the data absent reason extension to mask data SHALL be permitted. As scenarios arise, and experience is gained, this will be refined.
All interfaces are synchronous.
Consideration 🔎 At times when the network is unreliable the responsibility to retry and queue messages lies with the connecting system.
The NEHR will follow Sir Lanka's policies on protecting client demographic information; allowing only authorized systems and individuals access. Those polices described at a high level in the Digital Health Blueprint document, section "2.5.5 Security and Privacy by Design" and section "4.2.7 Security & Privacy". See also the "National eHealth Guidelines and Standards" (version 2.0) document.
The specification of security, privacy and consent is beyond the scope of this guide.
Unless otherwise specified base FHIR R4 conformance standards are assumed by this guide.
This guide follows standard FHIR R4 definitions for conformance language. Follow this link for more details.
This guide is licensed under the CC0-1.0 license.