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
FRWF-1	Query health worker and/or facility records workflow.	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