A Facility Registry (FR) acts as the tool for an authority to collect, store and distribute up to date and standardized facility data.  The resulting dataset stored in the registry is sometimes called a master facility list

The FR Helps To:

  • Bring All Important Facility Data Into 1 Location

  • Keep Data Current

  • Provide APIs and Easy Downloads to Users

  • Support Interoperability Profiles and Standards

  • Make Management Simple and Straightforward


Ability to Manage and administer the registry 

Must Have:

    • Create, define, and evolve the attributes & associated data dictionary for a registry.

      • Field types: Hierarchies, categorical, numeric, location, contact, pictures, etc.

    • Setup and manage users, permissions

      • Read, write, admin

    • Non-functional Requirement

      • Define what is a facility?   SOP for managing the FR, Curating  

Good to Have:

    • Host in the cloud vs. locally

    • Bulk Import

A map-based interface to easily interact with data.

Recommended - Good to Have

    • See sites on a map

    • Search

    • Filter / group

    • See data for individual sites

    • Download the data to a csv

Nice to have:

    • **Branded Facility Finder for Public Data

    • Dashboard/Visualization

Data curation capabilities

Must Have

      • Way to edit, create facilities

      • Permission edit vs. read

**non-functional requirement - - SOP

Good to Have:

      • Pull updates from other sources (federated, single direction integration)

      • Regions / Districts: Specific regional permissions

      • Advanced approval workflows

      • De-duplicate and clean data.

Activity monitoring to easily track or audit changes that happen over time.

Recommended - Good to Have

      • Simple Activity Feed - Changes being made

      • Who made changes when

Nice to Have

      • Update API, RSS Feed

APIs to support data diverse types of dates use 

Must Have

      • CRUD API or ability to pull data to other system (.csv)

Good to Have

      • Standard / Convention for sharing facility data (i.e., FRED, GeoJSON, FHIR, CSD)

      • Flexible APIs for different kinds of use cases

Full List of stories: Link to Matrix

Support of OpenHIE Non-functional Requirements 

An OpenHIE component should consider the following OpenHIE Non-Functional Requirements - Draft

  • No labels


  1. I think we need to add mCSD and CSD under 'Must Haves'.   Not sure that FRED is being maintained anymore and it doesnt have wide adoption so we may want to remove it to not cause confusion.

  2. I'm with Carl on this. The requirement expressed in our OpenHIE workflow is that the ILR has source-of-truth facility content in it. There is a separate workflow defined in the CSD or mCSD Profiles that describes how this ILR content is refreshed from one or more underlying directories. In my view, OpenHIE doesn't need to be normative regarding the CRUD transactions on these underlying directories – but does need to be normative on how they sync up to the ILR.