FHIR to the Patient Use Case: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 12: Line 12:
===Actors===
===Actors===
#Data Source = data goes from the EHR to the Patient. The source is where the data is coming from.
#Data Source = data goes from the EHR to the Patient. The source is where the data is coming from.
#Data Receiver =data goes from point A to point B. The receiver is where the data is going to.
#Data Receiver = data goes from the EHR to the patient's computing device. The receiver is where the data is going to.
#[[Record Locator Service]](RLS) = provides the ability to identify where records are located based upon criteria such as a Person ID and/or record data type, as well as providing functionality for the ongoing maintenance of this location information.
#[[Record Locator Service]](RLS) = provides the ability to identify where records are located based upon criteria such as a Person ID and/or record data type, as well as providing functionality for the ongoing maintenance of this location information.
#Provider =  A clinician or organization that is directly engaged in treatment services.
#Provider =  A clinician or organization that is directly engaged in treatment services.

Revision as of 23:22, 14 May 2020

Full Title

The healthcare patient in the US has the legal capability to download their data in a Machine-readable format like FHIR.

Context

  • This use case was written as the 21th Century Cures act was approved in 2020-05-01 for roll-out starting on 2021-01-01 (delayed due to COVID-19).
  • This case is directed specifically at the patient that wants to download data from their EHR to the computing device, typically a laptop or smartphone.
  • The

Goal

Release of PHI can only occur if the record holder has trust not only that it can accurately identify the requester, but that the request itself, and the requester’s policies and practices around the information once it is released, are appropriate. Such trust is straightforward to establish for an individual connection between two partner organizations, by relying on new or existing contractual relationships bolstered by negotiation of security and other technical details. Such an approach is not scalable, however, as the healthcare industry discovered in the context of document exchange via SOAP-based web services. Carequality’s governance framework can provide a “single on ramp” that allows an organization to sign one contract, implement one technical platform, and connect universally to a broad ecosystem of other participants.

Actors

  1. Data Source = data goes from the EHR to the Patient. The source is where the data is coming from.
  2. Data Receiver = data goes from the EHR to the patient's computing device. The receiver is where the data is going to.
  3. Record Locator Service(RLS) = provides the ability to identify where records are located based upon criteria such as a Person ID and/or record data type, as well as providing functionality for the ongoing maintenance of this location information.
  4. Provider = A clinician or organization that is directly engaged in treatment services.
  5. Patient = A person who is the subject of health records, or an authorized representative acting on such a person’s behalf.
  6. Transaction = Per the HL7 website; an interaction that submits a set of actions to perform on a server as a single atomic action. Multiple actions on multiple resources of the same or different types may be submitted, and they may be a mix of other operations (e.g. read, search, create, update, delete, etc.)
  7. Research = Work done to improve healthcare costs, outcomes, quality, safety, and innovation via systematic investigation and structured data analysis.

Preconditions

  • The patient has a primary care provider with up-to-date medical conditions, prescriptions and allergies.
  • The PCP uses an EHR which is part of the US Healthcare Assurance Framework.

Scenarios

Primary Scenario:

  1. Patient is traveling, has a shoulder injury and seeks care at local rural care facility.
  2. Physician examines patient and wants to provide a pain medicine, patient cannot provide exact medicines or allergies.
  3. Phisician queries patient Medical Record Locator Service and determines appropriate prescription.

Alternative Paths:

  1. The Primary Care Physician has placed the patient records in an EHR that regularly performs scans of all patients in the EHR for health conditions.
  2. The patient is informed that health concerns are indicated and requests consent from the user to scan other health care records. (This step was missing from the original.)
  3. When indications from the scan show possible areas of concern, the EHR reaches out to all providers of care to the patient using the Medical Record Locator Service
  4. The patient is always informed when such a scan occurs and what the results were found. (This step was less informative in the original.)

A different path using biometrics:


Failed Paths:

  1. Patient not found in MRLS.
  2. Wrong record returned from MRLS
  3. Data is not sufficient to allow doctor confidence in prescribing.

Results

Accepted Risks:

  1. The patient data is incorrect and unknowingly creates more harm that would have occured without the extra (erroneous) data.

Post Condition:

  1. I Patient outcomes are improved and dangerous conditions are avoided.

Examples:

Dependencies::

  1. Web Sites must be trusted before any user information is released.
  2. Trust federations can be used to help users make informed decisions.
  3. User consent and trust must begin before any user information is transferred.
  4. Standards exist to collect needed attributes where-ever they may be.

Workflow Diagram

TK

References