Facility Registry Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Sri Lanka Facility Registry Implementation Guide

This is the Implementation Guide for the Sir Lanka (LK) Facility Registry (FR).

A Facility is composed of Organizations that offer Services at a Location. Each Facility is run by employees (doctors, nurses, administrative, janitors, etc) and some of the healthcare Provider employees fulfill Client requests for Services. A Nurse may draw blood, a technician may use equipment to create a digital image, a doctor may create a diagnosis and an administrative employee may register a Client when they present at a hospital or clinic.

A Location is a point on a map, a building, where Services are offered.

An Organization is a formal or informal group of people that fulfill Client Services in a healthcare system. An Organization may have a parent Organization or children Organizations' a hierarchical structure.

This guide focuses on Organizations, Services and Locations as a single Registry — the Facility Registry. Healthcare Providers, such as Nurses or Doctors, are included as FHIR References from the Provider Registry. At this time the concept of mobile Facilities, like an ambulance is not considered.

Consideration 🔎 The above statements imply that the Facility Registry will store Organizations, Locations and HealthcareServices. This is a design decision, which as seen in the Specification page, makes searching for combinations of Services, Organizations and Locations much simpler (as one can use _include and _revinclude). An alternate design places Organization, Service and Location in separate independent repositories. This alternate design complicates queries as a single query may need to be orchestrated across many systems and depending on design, may force each Registry to make outbound connections to other Registries to fulfill queries. Separation of concerns is a guiding principal of architecture and design and an argument can be made that even with complications, separate and independent registries has advantages. The interfaces in this guide are described such that one could split the interfaces across several Registries if that is desired. In one or two cases the separate Registry queries are also described.

                                              ┌─────────────────────┐      
                                              │Organization Registry│      
                                              └─────────────────────┘      
                                                                              
  ┌─────────────────┐                         ┌─────────────────┐          
  │Facility Registry│ ◄─────  Alternate  ───► │Location Registry│          
  └─────────────────┘                         └─────────────────┘          
                                                                              
                                              ┌──────────────────────────┐ 
                                              │HealthcareService Registry│ 
                                              └──────────────────────────┘ 

Some conventions are defined below, an overview is provided which describes some of the design decisions and data structures used for the Facility Registry. A detailed specification follows interface descriptions.

Relationships To Other Guides

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 LKLocation and LKOrganization profiles use LKAddress from Client Registry.

Conventions for Usage of Organization, Location and HealthcareService

When referring to FHIR Resources the guide will use the term Organization. When referring specifically to a record within the Registry, Organization record will be used. The same convention will be used for Location and Location record. HealthcareService is referring to a FHIR Resource and Services represents a record in the repository.

Data Absent Reason

Use of data absent reason extension SHALL be permitted on mandatory elements. As scenarios arise, and experience is gained, this will be refined.

Must Support

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.

Data Masking

Using the data absent reason extension to mask data SHALL be permitted. As scenarios arise, and experience is gained, this will be refined.

Synchronous Interfaces

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.

Security, Privacy and Consent

The FR 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.

Conformance and Conformance Language

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.

Licensing

This guide is licensed under the CC0-1.0 license.