Provider Registry Implementation Guide
0.1.0 - ci-build
Provider Registry Implementation Guide
0.1.0 - ci-build
Provider Registry 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/providerregistry/ImplementationGuide/fhir.lk.providerregistry | Version: 0.1.0 | |||
| Draft as of 2025-10-23 | Computable Name: Sri_Lanka_ProviderRegistry_ImplemenationGuide | |||
This is the Implementation Guide for the Sir Lankan (LK) Provider Registry (PR). The primary purpose of the LK Provider Registry (PR) is to consistently manage health care Provider identities.
Some conventions are defined below, an overview is provided which describes some of the design decisions and data structures used for the Provider Registry. 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 LKPractitionerRoleServices profile uses LKService from Facility Registry. The LKPractitioner uses LKAddress from Client Registry. These are common profiles shared between Registries.
When referring to FHIR Resources the guide will use the term Practitioner. When referring to a record within the Provider Registry (PR), Provider will be used. FHIR Resources such as Practitioner are used to transport information to the PR, while Providers are records within the PR data repository.
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, including operations.
At times when the network is unreliable the responsibility to retry and queue messages lies with the connecting system.
The PR 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.