Provider Registry Requirements: Difference between revisions

From IHRIS Wiki
No edit summary
Line 2: Line 2:




==Initial RHEA Requirements==
==Rwamagana RHEA Requirements==
Also see [http://jira.jembi.org/wiki/display/RHEAPILOT/Home;jsessionid=7D50DADAD732DC5D465AC07CCB1AD604 RHEA]
Also see [http://jira.jembi.org/wiki/display/RHEAPILOT/Home;jsessionid=7D50DADAD732DC5D465AC07CCB1AD604 RHEA]


Line 22: Line 22:
**Passport Number - With country
**Passport Number - With country
**Mutuelle Number
**Mutuelle Number
**Social Security Number
**Social Security Number (OSR)
*Last Name
*Last Name
*Other names
*Other names
Line 33: Line 33:




==Requirements and HR Data Flow Questions==
===HL7 Provider Registry Validation===
The aim of this section is to refine and the categorize requirements of the provider registry for both immediate and future use.


*An HL7 message from a POC application is sent with a national (or other) ID for the provider
*#message arrives to interop layer
*#interoperability layer queries PR for Enterprise ID (EID), also called Enterprise Provider ID (EPID), via web services [[Web Service:PR-WS-2 | 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


===Rwamagana===


*Managing provider IDs:
===Security and Access Level===
**Paul B.:  What are your plans to keep track of unique codes and identities for  healthcare providers in Rwanda? 
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:
***(KR3-6) Is your vision to manage that  centrally, or in a more distributed fashion? 
*Paid Public Sector (e.g. iHRIS)
***(KR2) 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.
*Community Health Workers
**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.
*Private Sector
*Central Management Team (KR3-6):
*Students
**Who constitutes the central management team that will administer provider IDs? 
*Volunteers
**Will the central management team have access to each provider's data equally regardless of the sector (paid public, CHW, informal?)


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


*(KR1) Who will manage (presumably role-based) permissions to access the provider registry?  What security method?
===Data Population===
**the interoperability layer
For purposes of Rwamagana in September, it is assumed that the Provider Registry is to be populated from:
**Point-of-Care (POC) applications:
*iHRIS for paid public sector
***openMRS
*Spreadsheet from Liz for CHWs
***RapidSMS
This is to be a one-time data load with no synchronization or HR transactions.
***any others?
**by provider sectors:
***iHRIS Rwanda (paid public sector)
***CHWs
***non-public sector formal health workers
***informal health workers (volunteers, students, etc.)
***other provider data source
*(KR8) What authentication will exist between PR and the intero player? something like oAuth?
*(KR2,KR4,R8) How will POC applications access data in PR?  Will it have direct access (thereby breaking ESB model) or will it access through interoperability layer only?
**How does provider data get populated in the POC application?
**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?
**#message arrives to interop layer and 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
**#*(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
**How does POC app know that the message has been modified (or does it not care)?
*(KR2)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?
*(KR2)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:

Revision as of 17:34, 22 May 2012

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.
  • 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.

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