Trustworthy Healthcare Ecosystem

From IDESG Wiki
Jump to navigation Jump to search

Full Title

Examine the healthcare ecosystem from the perspective of a patient of that system.

Context

  • The wiki page Health Care Profile establishes the context for this page.
  • For a healthcare trust ecosystem to have value for a patient, these criteria are important:
  1. The patient can know that their medical and other records are safe within the provider's Electronic Health Record (EHR) database.
  2. The user can determine the trustworthiness of other providers that are seeking access to their medical and other records.
  3. Trust begins when a doctor sees a patient for the first time with a current complaint. The patient provides some identification and subjective information about their history and health problem and then the doctor does an objective (clinical ) exam which may or may not validate the initial complaint. That is the start of a trust relationship.
  4. After the patient visited multiple times and become an established patient they are then "known to the practice" and the level of trust has grown in both directions.
  • TEFCA says that if the patient has a trusted identity the patient should be able to view any episode of medical care, as reflected in their medical record, online and be able to download it and and share it with others. In those cases trust must be established and shared within the ecosystem by digital means.

Real World Entities

  • The first two actors are human beings that interact with the system during Identity Proofing or through User Agents.
  1. Patient - is the person receiving care and the one that "owns" the rights to the information.
  2. Non-Covered Entities - Guardians, Delegated Authorities, Lawyers, etc. - Although not called out specifically below, a guardian may legally (or by patient consent) be authorized to view or even modify patient records. They are acting as an agent.
  3. Patient Support - is source of the user devices and the code running on the user's phone or computer. It is trusted to protect the patient's credentials from disclosure.
  4. Covered Entities - Any entities that is covered by HIPAA rules - is the place that a patient typically goes for general sustaining medical care. It will always have access to an EHR that it maintains for the patient. This is where Identity Proofing is performed.

Digital Service Endpoints

  • The other actors are roles that may be combined on Web Sites in any way that works for the participants. These roles all expose a common set of API's based on FHIR, but extended to allow trust and authentication information to flow before data flows.
  1. Credential Service Provider - is the glue between the user devices and the Covered Entities. It provides IAL2 evidence that an App can act as the user agent for the patient.
  2. EHR - the Electronic Health Record has become an actor in the sense that is is required to respond to legitimate requests in a timely manner. It may also participate in patient matching. (See the HHS Primary Care Patients Use Interactive Preventive Health Record Integrated With Electronic Health Record, Leading to Enhanced Provision of Preventive Services) The EHR must release information to the patient with proper IAL2 authentication.
  3. Specialist Practice - is separate from the PCP and for the purposes of this document maintains a separate EHR for the patient. (This may be a Private Care Practice so sometimes might be referred to as a PCP.)
  4. Payment Provider - is a part of both the patient proofing and patient authentication processes in most practices.
  5. Trust Registry - is an online Trust Anchor for information about medical providers that have met the appropriate operational criteria.
  6. Medical Record Locator Service - is a source for the patient or trusted providers to search for records about the patient. It has yet to be fully specified, but is assumed to exist.

Problems

  • If a PCP (Private Care Practice) is the source of Identity Proofing to be used with other providers, can we provide the standards that would relieve them of liability for misuse?
  • For IAL2 some means of protecting the patient authentication credentials must be available, e.g. FIDO U2F (Web Authentication) or the smart phone (with a trusted execution environment) itself.
  • Medical records can apply to both state and transaction records.
    • When the patient asks for records they have the right to get everything that is permitted by law.
    • When a physician makes a referral they typical send the relevant information relating to that condition (with patient consent).
  • The following problem areas were identified at the CARIN Health Care Digital ID Summit 2019-06-04. In order to best proceed the definitions have been amended slightly to make the terms into distinct entries in a Trustworthy Healthcare Ecosystem taxonomy of Identification.
  1. Identity - is the matching of the real live biological human to the records necessary for billing and patient care. The level of identity proofing that occurs here will be situationally determined as would be the case (e.g.) for new versus returning patients. It will only be established by patient-present use cases, except in some low volume use cases.
  2. Authentication - is the matching of the user of a digital computer system to the patient identified in problem 1. Our scope in this ecosystem is limited to the digital exchange of credentials and trust statements over the web.
  3. Trust and Federation - is the trust between different organizations in different federations as well as trust of the patient for the web sites that they visit.
  4. Consent - is required for all information-sharing events. In some cases blanket consent has been provided. In some venues consent has a limited life time.
  5. Matching of the Patient - to their electronic health records can occur in both patient-present and remote access use cases. Prior to the time of patient matching, Identity (problem 1) and Authentication (problem 2) must have been completed. (But note that matching an incoming patient to the medical records may be included as a part of the Identity and Authentication solutions.) The most severe matching problems, when the patient is non-responsive, are out of scope here. The most common use case is presumed to be the passing of medical records from the PCP to some other provider and back again as modified.

Solutions

Relational Trust

The definition of (relational) trust is to believe in the honesty and reliability of someone or an entity you have known over time, made a good faith effort to live up to an agreement to fulfill their commitment, be it a contract or handshake agreement. ‘Trust’ is a transnational catalyst, the chemistry that initiates an interaction and reaction if not abused. (So that the trust expressed as "known to the practice" can be transmitted to other participants.)

Online Trust

  • All online service endpoints shall be equipped with capability metadata that informs communications partners as to the services offered.
  • All online service endpoints shall supply certificates that can be verified to prove compliance with minimal health industry standards.
  • All compliant services that authenticate patients with IAL2/AAL2 will supply patient credentials as requested by other compliant medical providers.
  • All services that authenticate patients will make their own determination as to the patient's identity. Patient credentials are just one component of that trust process.

Patient Consent

  • We need to be able to capture the patient consent in a digital message and transfer that to another provider.
    • A taxonomy for how to represent the information requirements and risks to the patient must be in use by all providers.
    • Existing taxonomies of data types in the EHR is too technical to allow patients to make informed decisions.
  • The Patient must understands what information they have consented to share and what the risks to the patient are.
    • Also why the information is required to provide that care. (Transparency)
  • When medical records come from the patient that consent would also be captured and given to the new provider.
    • We need the ability to create a consent receipt for moving medical records from one provider to another provider.

Bindings

  • In a digital world binding are formalized with a cryptographic key signing a document that associates one entity with a collection of keys and attributes. For example the X.509 certificate.
  • For the organization the trust anchor (described in federation below) works.
  • For the patient some sort of private credentials are required for a formalized binding process. If the patient's credentials are well protected they can be used with an authentication protocol to prove that the patient is present for an on-line interaction.
  • The binding is then between the patient and the protected key pair. The public part of the key pair is, in effect, an identifier of the patient.
  • Bindings can be used to assure that any part of the system remains in the state that was known to be secure. For example, software should have a way to let any communicating party know who is controlling the interaction. Devices should all be able to make a secure statement about itself. It is also desirable for an instance of an app on a device to have a unique and secure identifier. This instance represents the life-cycle of that software on that device, not just the running instance at a moment in time. Even more trivially, each communication session should be conducted over HTTPS which will also be bound to the key that was used in interchanging secure messages.
  • Note that the patient may be considered to be bound to their medical records, but that is an organizational relationship that is core to the patient matching problem. While it is not feasible for a medical record to have an identifier (index key) that is itself cryptographically bound to the patient given current US law, it is possible to include cryptographically bound identifiers in the medical record.

Protection of the Patient Credentials

This is a requirement for IAL2/AAL2.

  • eg U2F or FIDO (W3C Web Authentication) or TEE or Client to Authentication Protocol (CTAP FIDO?)

Biometric Factors

  • Finger print
  • Palm print
  • Iris scan
  • Face scan - particularly dynamic scans where the patient must rotate the head in response to commands from the authenticator.
  • Behavior

Knowledge Authentication Factors (from KBA)

  • Medical records have information that can be used to assure that the patient is correctly identified and that the patient is matched to the correct record. Clearly there are privacy concerns that must be met if this method is to be acceptable to the patient.

Federated Trust

  • In a federated system there will be at least one trust anchor that provide trust certificates to the members of the federation.

Record Matching

No patient is fully trusted when approaching the receptionist or any health care provider beyond the personal physician. The essential problem is that mistakes happen in health care and the wrong records get attached to the wrong human being. This can cause disastrous consequences. Ensuring that the provider that is immediately attending to the patient have relevant information about the patient is essential to good outcomes.

PatientTrust.png

Next Steps

The order and extent of these items is currently arbitrary and pending review by industry experts.

  1. Approve broad plan for proceeding.
  2. Create a Patient experience set of use cases to be tested (as a part of a broader conformance verification)
  3. Establish a specific plan for the sand box.
  4. Build a trust registry that can hold configuration/manifest data and respond to API requests for:
    1. Applications that are in conformance with Evolving CARIN best practices
    2. Trusted Provider sites with EHR - deploy at least two for the sandbox to allow a sender (e.g. a PCP) and a receiver (e.g. a specialist) for testing.
  5. Build a demo native app that can show how how a patient can acquire and use an app of their own choosing with authorization code generated by PCP
  6. Enlist an existing medical software vendor to build a demo app that can show how a patient can acquire and use an app from a PCP
  7. Create a trusted third party web site that can:
    1. Demonstrate how a patient can enter and manage their (e.g.) emergency contact information that is entirely under their own control.
    2. Demonstrate Identification and Attribute Provider (IAP) with IAL2 authentication capability

References

<references />

Internal References

On Kantara wiki pages.

External References

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