FHIR to the Patient Use Case

From IDESG Wiki
Jump to navigation Jump to search

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 Electronic Health Record (EHR) to the computing device, typically a laptop or smartphone.
  • The ONC has asserted that any app that is from a "certified" developer should be able to down load data from and EHR to the patient. The primary use case will focus on that decision by the EHR to allow downloads.

Goal

Release of patient's health information (PHI) is only permitted if the Electronic Health Record (EHR) holder has trust that it can (1) accurately identify the requester, (2) validate the request itself, and (3) certification requirements for the app developer (which have not yet been determined.)

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 to the patient's computing device. The receiver is acting as the patient's agent.
  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. Data or transactions generated by the provider are sent to the data source, the EHR.
  5. Patient = A person who is the subject of health records, or an authorized representative acting on such a person’s behalf (aka guardian). The term user refers to either party.
  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, but are not likely in a patient device. The transaction is a message that is created by the user but then has a life of its own until it completes. At that point a notification should be created to be directed to the user's agent.

Preconditions

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

Threats

  • The EHR has a duty under several laws to protect the patient's health information (PHI) from release. Release to unauthorized source can create a large financial liability to the EHR.
  • The user has a legal right to load the data to a device and app of their own choosing, but that app must be from a certified developer as specified in the 2020-05-01 final rule.
  • This puts the EHR between a rock and a hard place with little guidance of how to make the choice of whether to release PHI to a request received from the internet.
  • The following is one use case that the EHR could navigate in making that choice.

Scenarios

Primary Scenario (Patient uses a smartphone app):

  1. Patient wants to participate in their own care plan.
  2. Patient searches for an appropriate app to load onto their computing device (for this purposes of this scenario).
  3. Patient queries the he Medical Record Locator Service (MRLS) to see what sites have his data online and accessible. (Always optional and may not be complete in the early years of the Cures Act.)
  4. Patient uses the medical record locator, either from the website of the provider, or from the MRLS, to request data.

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.
  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 MRLS.
  4. The patient is always informed when such a scan occurs and what the results were found.

A different path using a simple cell phone or a public app in a library.


Failed Paths:

  1. Patient not found in MRLS.
  2. Wrong record returned from MRLS
  3. App is not recognized as meeting the requirements of the EHR to protect patient's data from unauthorized release.

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.

What's Missing

  1. Requirements for the app developer certification.
  2. Trust Authority where the EHR can validate the certifications of the app trying to access PHI.
  3. While there are many protocols for stating user identifiers there is as yet on single, unified format for stating the:
    1. Identifier of the user and level of identifier proofing of that identifier.
    2. certifications of the app developer
    3. proof of the authentication and presence of the user at the computing device.
  4. Trust Authority that can tell the user whether the health sites that they visit are certified to hold the PHI.

Workflow Diagram

TK

References

Retrieved from "https://wiki.idesg.org/index.php?title=FHIR_to_the_Patient_Use_Case&oldid=14637"