Trustworthy Healthcare Ecosystem: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 20: Line 20:
# '''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.
# '''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.
# '''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.  
# '''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.  
# '''Matching of the Patient''' - to their electronic health records can occur in both patient-present and remote access use cases. It is assumed that problems 1 and 2 have been successfully dealt with. 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.
# '''Matching of the Patient''' - to their electronic health records can occur in both patient-present and remote access use cases. It is assumed that problems 1 and 2 have been successfully dealt with. But note that matching an incoming patient to the medical records may be included as part of solution to problem 1 or 2. 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==
==Solutions==

Revision as of 02:12, 26 June 2019

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. what a doctor sees a patient for the first time with a chief complaint, there is no trust. The patient provides subjective information about his/her complaint and then the doctor does an objective (clinical ) exam which may or may not validate the initial complaint.. that is the start of a relational trust. If she/he has been a patient for a year + they become an established patient for coding purposes but I would not classify them as a trusted patient in being compliant in following through with a care plan that address their complain.
  • TEFCA says that if the patient has a trusted identity the patient should be able to view that episode of medical care, as reflected in their medical record, online and be able to download it and and share it with others .... the latter is a trust as to who the person/patient says they are and is not the relational trust between a physician and patient.

Problems

  • If a PCP (Private Care Practice) is the source of IAL2 authentication credentials 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 situationaly 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. There are some patient-present authentication protocols at care providers that are out-of-scope here.
  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. It is assumed that problems 1 and 2 have been successfully dealt with. But note that matching an incoming patient to the medical records may be included as part of solution to problem 1 or 2. 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. (aka "known to the practice")

Online Trust

  • Create standards that would leverage the IAL2 authentication with the PCP to build IAL2 authentication for use by other medical providers.
  • In a digital economy, where online transactions are spontaneous, there is no trust in knowing who a user or entity is, so a measurable level of confidence must be determined instantly. This is a must if parties are to perform as expected in a digital exchange; an implied contractual agreement. This digital trust process underpins every digital interaction by evaluating a user’s digital identity attributes, with expectations of who that user or entity claims to be and if they will behave in an expected manner that represents their trustworthiness

Patient Consent

  • Create a consent receipt for moving medical records from one provider to another provider.
  • Patient 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.
    • Clearly a taxonomy for how to represent the information requirements and risks to the patient.
  • When medical records come from the patient that consent would also be captured and given to the new provider.
  • How to capture the patient consent in digital format and transfer that to another provider.

Protection of the Patient Credentials

This is a requirement for IAL2.

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

Biometric Factors

  • Finger print
  • Palm print
  • Iris scan
  • Behavior

Knowledge Authentication Factors (from KBA)

  • Medical records

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.

File:PatentTrust.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 conformance testing)
  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 - build at least two to allow a sender (e.g. a PCP) and a receiver (e.g. a specialist)
  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