Skip to end of metadata
Go to start of metadata

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

Standards and Workflows

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

  • No labels