Provider Registry Requirements: Difference between revisions

From IHRIS Wiki
No edit summary
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
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]].
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]].




==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]


===Key Requirements===
===Key Requirements===
*The system must provide user restricted security to its configuration.
*KR1 The system must provide user restricted security to its configuration. [[Use Case:PR-UI-5]]
*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.
*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.
*The system must allow new provider records to be inserted by a privileged user.
*KR3 The system must allow new provider records to be inserted by a privileged user. See [[Use Case:PR-UI-1]]
*The system must allow searching of existing provider records.
*KR4 The system must allow searching of existing provider records. See [[Use Case:PR-UI-3]]
*The system must allow provider records to be edited by a privileged user.
*KR5 The system must allow provider records to be edited by a privileged user. See [[Use Case:PR-UI-2]]
*The system must allow provider record to be deactivated/soft deleted by a privileged user.
*KR6 The system must allow provider record to be deactivated/soft deleted by a privileged user. See [[Use Case:PR-UI-4]]
*The system must allow a provider's record to be viewed.
*KR7 The system must allow a provider's record to be viewed.See [[Use Case:PR-UI-3]]
*The system must expose a web service endpoint to fetch a provider’s enterprise ID given another unique ID of that provider.
*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===
===Provider Attributes===
Line 23: 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 34: 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
 
 
===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. 


===Rwamagana===
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


*The system must expose a web service endpoint to fetch a provider’s enterprise ID given another unique ID of that provider.
Notes:
**Managing provider IDs:
*the EPID that is returned on subsequent look-up should be of the authoritative record
***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.
*duplicative EPID should be queryable from the authoritative record
***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.
*if a provider attribute is present in both the authoritative and duplicate record, then:
**Who constitutes the central management team that will administer provider IDs? 
**querying a provider by the value of either the authoritative of duplicate provider attribute is permissible
***What functions will they be allowed to perform:
**the attribute value from the authoritative records is considered "primary"
****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?
***#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)?
*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..===
==Background Information==
*Interoperability layer functionality:
===Integrating the Healthcare Enterprise (IHE)===
*http://wiki.ihe.net/index.php?title=Personnel_White_Pages
*http://wiki.hitsp.org/docs/T64/T64-3.html
*http://www.ihe.net/Technical_Framework/
*http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol2a_FT_2011-08-19.pdf  -- has Provider Data in LDAP and discusses mapping provider data to HL7 starting page 189

Latest revision as of 08:00, 7 June 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. 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"