OpenHIE Facility Registry (FR)

The purpose of a health facility registry is to act as the central authority to collect, store, and distribute an up to date and standardized set of facility data. The resulting standardized and current facility dataset stored in the registry is called the Master Facility List (MFL). While these concepts are closely related, a facility registry can be understood as the technology that manages and shares facility data and an MFL is the standardized data stored in the tool.

See also Non-Functional Requirements.

OpenHIE FR Workflow Requirements

#

FR Workflows (Described in detail in the later part of this document)

Recommendation/ Requirement

Required

OpenHIE FR Functional Requirements

#

FR Functional Requirement

Recommendation/ Requirement

FRF-1

The system shall support the ability to create, define, and evolve the attributes & associated data dictionary for a registry.

Required

FRF-2

The system shall support the ability to create, define, and maintain multi-organizational hierarchies of facilities and related geo-objects.

Required

FRF-3

A system should support the collection of data for the following minimum facility attributes dataset: (Refer to WHO, USAID MFL resource package - Guidelines for countries)

Signature Domain

  • Facility name

  • Facility type (e.g., hospital, clinic, mobile clinic, lab, pharmacy)

  • Facility ownership/managing authority

  • Facility physical address

  • Facility contact information

  • Record date

  • Operational status

  • Administrative level/areas

  • Geographic coordinates

  • Facility unique identifier

Service domain

  • Type of Services offered - Lab, HIV, TB, etc.

  • Human resource for health, numbers by cadre

  • Opening and closing times

  • Common and Mapped Identifiers per Location

  • Details on Infrastructure - Power, Water, etc.

Recommended

FRF-4

The system shall support the ability to set up and manage users, permissions for reading data, writing data (posting, validation, publishing), viewing data and system administration.

Required

FRF-5

At minimum an FR should support the ability to create roles and assign permissions to the roles. Example roles would be the Master Administrator, Data curator, Health Officer.

Recommended

FRF-6

The system should have flexible standards-based APIs, preferably RESTful API.

Recommended

FRF-7

The system should have the ability to pull and/or push data to other systems (.csv) based on defined criteria.

Recommended

FRF-8

The system shall support the ability to do bulk imports.

Required

FRF-9

The system should support the ability to search for facilities by attribute.

Recommended

FRF-10

The system should support the ability to see the facility located on a map.

Recommended

FRF-11

The system should allow public access to view data that is relevant to the public (e.g. services provided by a facility)

Recommended

FRF-12

The system should support facility data curation to manage site status changes (closures, openings, service changes)

Recommended

FR-13

The system should generate standard and customizable reports inline with the core FR attributes.

Recommended

FR-14

The facility registry should align with the primary Master Facility List at minimum, or influence its update.

Recommended

Last updated