View source for Health IT Record Location Service (Data Aggregation)

==Full Title==
Health IT Record Location Service Use Case

==Use Case Description==
A relationship location service (RLS) that allows patients to control discovery of encounters aggregated across a system.  This patient may authenticate to the system with a trusted identity, authenticate to the system with pseudonymous identity, segment encounters using multiple personas within the system and/or verify attributes with privacy protection. (RLS has also been used to indicate a record locator service on the assumption that relationship discovery will typically be associated with a record at that location. Although often true, this need not be the case since discovery of actual records may be subject to additional constraints and authorizations by the record holder. For clarity, this Use Case adopts the Relationship Locator Service definition.) The RLS is intended for use by authorized Healthcare stakeholders.

A brief discussion of multiple IDs in healthcare is here: [[User:Thomas_Sullivan|https://www.idecosystem. Unverified IDs in Healthcare]]

<br />
'''Use Case Category''': 

<br />
'''Contributor''': Heathcare WG

<br />
=== Use Case Details ===
'''Actors''': 
* Provider
* Patient
* Electronic Health Record Service (EHR)
* [[Record Locator Service]] (RLS)
* Authorized Healthcare stakeholders


<br />
'''Goals''': 
Patient managed control of access to aggregated data
<br />
<br />
'''Assumptions''': 
* Backend system information is out of scope.
* All touch points between RLS and Providers available via accessible APIs
* There is an existing Particpation and/or Federation agreement between Provider and RLS
* RLS may support a Master Person Index (MPI) with one or many personas for each identity contained within the MPI
* RLS provides optional identity audit service so patient can manage relationships reported for different personas 



<br />
'''Requirements''': 

* [[Patient Consent]] for Provider to send relationship information to RLS
* Patient portal or other means for patient to audit and submit corrected information in the RLS
* Digital, real-time fulfillment of HIPAA Accounting of Disclosures and related public disclosure laws

<br />
'''Process Flow''': 
* Insert Record

: * Patient has an encounter with Provider
: * Provider requests consent to add and/or search for encounters in the RLS 
: * Patient is offered the option to provide a Persona/Identity
: * Provider logs on to the EHR that has a relationship with the RLS
: * Provider generates a record that includes the following information:
:: * EHR location (scope of EHR patient ID uniqueness)
:: * Patient ID in the EHR
:: * Date of encounter
:: * Consent (this may be implied in the transfer of encounter info to the RLS)
:: * Persona ID (if provided)
:: * Name (optional)
:: * Birthdate (optional)
:: * DL info for (optional)
*Query RLS
: * Provider authenticates to RLS
: * Provider queries RLS using Persona and evidence of consent provided by Patient
: * RLS returns a list of encounters which the Provider uses to query actual sources for information (additional Provider authentication and authorization may be required by the data holders)
: * Query Results may include the following:
:: * EHR location information
:: * EHR patient ID  
:: * Date of encounter 
:: * Persona ID (if available)
:: * Name (optional) 
:: * Birthdate (optional) 
* Patient Access
: * Patient authenticates to RLS (choose one of the 4 methods)
:: * Patient first registers in-person with RLS by providing acceptable credentials that match the credentials and Persona presented to EHR Provider (assumes Provider can get adequately strong credentials prior to sending info to RLS)
:: * Patient first self-registers with RLS and RLS uses knowledge-based authentication to issue Patient credentials (assumes Provider has communicated sufficient Patient attributes to enable reliable KBA)
:: * Patient signs-in to Provider who authenticates patient based on trust relationship between Provider and RLS
:: * Provider and RLS both accept third-party IDP linked to Patient's Persona
: * Patient queries RLS to review encounter history and who has requested access to personal data
: * Query Results may include the following:
:: * Persona (if specified, may be modified by Patient)
:: * Date of encounter 
:: * Provider Location
:: * Provider name (may be encoded to protect Provider's privacy)
:: * Current consent status (may be modified by Patient)

<br />
'''Success Scenario''': 
* Physician is able to see a subset listing of patient encounters based on patient consent
* Patient can log into the RLS and view an Accounting of Disclosures
* Potential for privacy preserving Pseudonoymous Login 
* Authorized Users are able to log in with a federated Login
* Potential ability for patient segmentation of data via Persona
* Compatibility of Idenity Managment with Data Exchange Participation agreements
* Enables Delegation of access as allowed by law

<br />
'''Barriers''': 
* Data holders unwilling to share data - often directed against competitors
* Dependent on State and Local policies
* Difficulty in patients understanding their privacy rights to restrict release and determine how their PHI is managed
* Difficulty in patients understanding how to access the RLS
* The willingness of data holders (as opposed to individual providers) to adopt federated identity management
* Multiple credentials required to access information



<br />
'''Error Conditions''': 
* Patient unable to access data
* Inadvertant and/or intentional merging or spliting of data contrary to patient wishes
* Entire, unrestricted, record history available to all who are authorized to search the RLS


<br />

=== Relationships ===
* Extended by:
** 
**
* Extension of: 
** Authentication Person
** Authentication Service
** Secure Anonymous Digital Credential

==References and Citations==
* HIPAA
* Omnibus HIPAA Rule ...January 2013..http://www.hhs.gov/ocr/privacy/hipaa/administrative/omnibus/
* NIST SP-800-63-2 ....August 2013  ..http://csrc.nist.gov/publications/PubsSPs.html
* NIST SP-800-53-4  ...April 2013  ..http://csrc.nist.gov/publications/PubsSPs.html
* Recommendations to [[ONC]] re: accounting of Disclosures [http://www.healthit.gov/buzz-blog/health-innovation/seeking-input-transparency-implementation-hitech-accounting-disclosures/ healthit.gov/buzz-blog/ Disclosure Goals and comments from 9/23/13 to present]
* Introducing Blue Button + .. [http://bluebuttonplus.org/index.html] [http://bluebuttonplus.org/privacy.html] [http://blue-button.github.io/blue-button-plus-pull/] 
* RHEX OAUTH and OpenID profiles...[http://wiki.siframework.org/RHEx+Approach RHEx+Approach]
* Office of Civil Rights FAQ ....http://www.hhs.gov/ocr/privacy/hipaa/faq/index.html
* Meaningful Use - View, Download and Transmit...[http://www.healthit.gov/providers-professionals/achieve-meaningful-use/core-measures-2/patient-ability-electronically-view-download-transmit-vdt-health-information http://www.healthit.gov/providers-professionals/achieve-meaningful-use..]
* Direct Applicability Statement..See original/revisions..[http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport http://wiki.directproject.org]
* Restful approach recommendations to [[ONC]] ...See August 30, 2013 PDF [http://www.healthit.gov/facas/health-it-standards-committee/health-it-standards-committee-recommendations-national-coordinator]
* Stage 3 Recommendations [http://www.healthit.gov/facas/sites/.../IEWG_RecommendationTransmittal.pdf‎]
* [http://www.healthit.gov www.healthit.gov]
* Federal Health Architecture [http://www.connectopensource.org/fha-directed-exchange-workgroup-survey]
* Related BB+ Pull IDESG Use Case [https://www.idecosystem.org/wiki/BB%2B_Direct_PULL]

<br />

[[Category:Use Cases]]
[[Category:Health]]