Provider Registry Requirements

From IHRIS Wiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This is a list of gathered potential requirements for the provider registry. The aim of this page is to refine requirements, record key discussion points and decisions, and use the results to refine the Provider Registry Use Cases.


Rwamagana RHEA Requirements

Also see RHEA

Key Requirements

  • KR1 The system must provide user restricted security to its configuration. Use Case:PR-UI-5
  • KR2 The system must store a provider's record with a single enterprise ID as its primary identifier. The record will include multiple other ID’s along with a number of provider demographic attributes.
  • KR3 The system must allow new provider records to be inserted by a privileged user. See Use Case:PR-UI-1
  • KR4 The system must allow searching of existing provider records. See Use Case:PR-UI-3
  • KR5 The system must allow provider records to be edited by a privileged user. See Use Case:PR-UI-2
  • KR6 The system must allow provider record to be deactivated/soft deleted by a privileged user. See Use Case:PR-UI-4
  • KR7 The system must allow a provider's record to be viewed.See Use Case:PR-UI-3
  • KR8 The system must expose a web service endpoint to fetch a provider’s enterprise ID given another unique ID of that provider. See Use Case:PR-WS-1

Provider Attributes

The Provider Registry must be able to store the following attributes about a provider:

  • EPID - Enterprise Provider ID
  • Other ID’s
    • NID
    • Passport Number - With country
    • Mutuelle Number
    • Social Security Number (OSR)
  • Last Name
  • Other names
  • Phone number
  • Date of Birth
  • Country of Birth
  • Place of Work - FOSAID (could be multiple)
  • Professional Category
  • Current Employment


HL7 Provider Registry Validation

  • An HL7 message from a POC application is sent with a national (or other) ID for the provider
    1. message arrives to interop layer
    2. interoperability layer queries PR for Enterprise ID (EID), also called Enterprise Provider ID (EPID), via web services PR-WS-2
      • If EPID is found, the message is considered valid w.r.t. PR
      • It EPID is not found, HL7 message fails validation
        • message goes into exception queue
        • user in the central manager team views the message in the exception queue
        • user tries to find the correct provider in PR (this is a manual process at this point) by looking up on other provider attributes found in the HL7 message
          • (on failure) either add a new provider into PR or remove message from queue and stop
        • user modifies the HL7 message to contain the correct provider

Note. there is no communication of EPIDs to POC applications


Security and Access Level

As of yet, not definite determination of access levels to PR based on "domain" of HWs has been determined (KR1,KR3-7). Possible domains include:

  • Paid Public Sector (e.g. iHRIS)
  • Community Health Workers
  • Private Sector
  • Students
  • Volunteers

Note (KR8) also that the Provider registry is assumed to be behind a firewall and as such there is no need for any authentication/restricted access to web services

Data Population

For purposes of Rwamagana in September, it is assumed that the Provider Registry is to be populated from:

  • iHRIS for paid public sector
  • Spreadsheet from Liz for CHWs

This is to be a one-time data load with no synchronization or HR transactions.

Duplicate Information

No requirements defined for what happens when a duplicate provider is identified in the system.

Possible workflow:

  • One provider records is determined to be authoritative. The other is referred to as the duplicate information
  • All data fields from duplicate record are added to authoritative record including the EPID
  • Duplicate provider record is deleted from the system

Notes:

  • the EPID that is returned on subsequent look-up should be of the authoritative record
  • duplicative EPID should be queryable from the authoritative record
  • if a provider attribute is present in both the authoritative and duplicate record, then:
    • querying a provider by the value of either the authoritative of duplicate provider attribute is permissible
    • the attribute value from the authoritative records is considered "primary"


Background Information

Integrating the Healthcare Enterprise (IHE)

Retrieved from "https://wiki.ihris.org/mediawiki/index.php?title=Provider_Registry_Requirements&oldid=44379"