Provider Registry Requirements

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 connect them with the Provider Registry Use Cases.

Initial RHEA Requirements

Also see RHEA

Key Requirements

• The system must provide user restricted security to its configuration.
• 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.
• The system must allow new provider records to be inserted by a privileged user.
• The system must allow searching of existing provider records.
• The system must allow provider records to be edited by a privileged user.
• The system must allow provider record to be deactivated/soft deleted by a privileged user.
• The system must allow a provider's record to be viewed.
• The system must expose a web service endpoint to fetch a provider’s enterprise ID given another unique ID of that provider.

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
• Last Name
• Other names
• Phone number
• Date of Birth
• Country of Birth
• Place of Work - FOSAID (could be multiple)
• Professional Category
• Current Employment

Requirements and HR Data Flow Questions

The aim of this section is to refine and the categorize requirements of the provider registry for both immediate and future use.

Rwamagana

• The system must expose a web service endpoint to fetch a provider’s enterprise ID given another unique ID of that provider.
  • Managing provider IDs:
    • Paul B.: What are your plans to keep track of unique codes and identities for healthcare providers in Rwanda? Is your vision to manage that centrally, or in a more distributed fashion? Do you want to keep track of *every* individual that generates health data within the country (including CHWs, volunteers, students, etc), or are there designate signatories in some cases (i.e., an attending for a student). We need to understand the business rules for how you want to attribute provider information to clinical care scenarios, at least in the case of maternal health provision in Rwamagana.
    • Richard G.: The codes and unique identities of providers will be managed centrally. I still haven't figured out how students (who are not registered in the medical council) can be assigned identifiers but volunteers can be since they have to register with the relevant councils. CHWs also provide some care as mentioned above and since we have included them in the RHEA project we shall keep track of the health data that they generate....this may stop at maternal health data (at least for now) since the rest of their clinical work is dealing with acute cases like malaria and diarrhea, that doesn't have strong relevancy to the long-term medical record of an individual.
  • Who constitutes the central management team that will administer provider IDs?
    • What functions will they be allowed to perform:
      • Create a provider record
      • Read/query for a provider record
      • Update/modify an existing provider record (e.g. change facility/facilities, id #'s, demographic information)
      • Delete/disable an existing provider record
    • Will the central management team have access to each provider's data equally regardless of the sector (paid public, CHW, informal?)
  • How will this central body manage permissions of applications to access and write to the provider registry across multiple systems including:
    • Point-of-Care applications:
      • openMRS
      • RapidSMS
      • any others?
    • Sources of HR data
      • iHRIS Rwanda (paid public sector)
      • CHWs
      • non-public sector formal health workers
      • informal health workers (volunteers, students, etc.)
• Interoperability layer functionality:
  • What authentication will exist between PR and the intero player? something like oAuth?
  • POC application sends a HL7 message referencing provider.
    • When does the POC query against the provider registry to lookup a provider id?
      • When an HL7 message is sent?
      • When an HL7 message is created?
      • When a user is created (and associated with a provider EID)?
    • If an HL7 message from the POC is sent without Enterprise ID (EID) for the provider what happens?
      1. message arrives to interop layer and fails validation
      2. message goes into exception queue
      3. user in the central manager team views the message in the exception queue
      4. user tries to find the correct provider in PR
         • (on failure) either add a new provider into PR or remove message from queue and stop
      5. user modifies the HL7 message to contain the correct provider
    • How does POC app know that the message has been modified (or does it not care)?
• The system must be able to load paid public sector data from iHRIS Rwanda
  • Is this one time or does there need to be routine synchronization?
  • Should anyone outside of HR managers be able to modify this data? If so what?
• The system must be able to load community health worker data from ?spreadsheet?
  • Assumption: this is one time data import.
  • Data comes from RapidSMS installation(s). What is process for adding new providers?
• Do we need facility data in the provider registry? Alternatively we can access this via Shared Health Record

Rwanda

• How should provider registry be updated? Some mechanisms may include:
  • Add HR Transactions (deployment, firing) to interoperability layer which all systems providing HR data are expected to communicate in?
    • Does this need to be HL7 or can it be other format (HR-XML, etc?)
    • Should changes be approved by central management team?
• Should PR have facility to manage roles across many instances of POC application? Example: Nurse Bill Smith has the same set of functions in OpenMRS which he can perform no matter which facility he is at
• Should POC applications to have a local (read-only) copy of provider registry data for offline use?
  • If so, for what purpose will the the POC be accessing the offline copy of the PR?

And Beyond..

• Interoperability layer functionality:
  • POC applications in PR?