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
An OpenHIE component should consider the following OpenHIE Non-Functional Requirements - Draft