Overview
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
Requirements
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
2 Comments
Carl Leitner
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.
Derek Ritz (ecGroup)
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.