Trustworthy Healthcare Provider
Full Title or Meme
There are two contexts where Trustworthy Healthcare Provider is defined and so there are two memes that it covers:
- Providers that share trust among themselves to know that Protected Health Information (PHI) can be shared as the correspondent is a recognized HIPAA-covered entity.
- Providers that may be trusted by patients (or other end users) with their PHI and their Consent as to permitted use.
- Trust Registry of IDEF (Trusted Identifiers in Cyberspace) for healthcare industry in US.
- The wiki page Health Care Profile establishes the context for this page.
- Details of the Trustworthy Healthcare Ecosystem explores the full ramifications to every aspect of information exchange in the ecosystem.
- For a healthcare trust ecosystem to have value for a provider those providers must agree among themselves as to the criteria for entry into the registry of that ecosystem.
- For a healthcare trust ecosystem to have value for a patient, these criteria are important:
- The patient can know that their medical and other records are safe within any provider's Electronic Health Record (EHR) database.
- The user can determine the trustworthiness of other providers that are seeking access to their medical and other records.
- 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.
- After the patient has visited a PCP (Primary Care Physician) they are entitled to acquire their medical records. Where the records are stored digitally, the patient must be give online access.
Real World Members
- The patient and the physical places where the patient goes are all legal entities and have legal obligations.
- Patient - is the person receiving care and the one that "owns" the rights to the information. (In some cases the patient allows other users access to their PHI.)
- Patient Support - is source of the user phone or computer and the code running on the user's phone or computer. It is trusted to protect the patient's credentials and medical records from disclosure.
- Covered Entities (called providers below) - Any entities that is covered by HIPAA rules including the places that a patient goes for medical care. They will all be recognized as such in the digital world by virtue of trust certificates. Many of these will perform Identity Proofing. All will provide evidence that a user is accepted as a patient at the entity to any other registered covered entity. (For the record locator service.) The services that they provide are listed below.
Names use within the Ecosystem
There are a variety of identifiers used by the real-world entities described above. These are the handles to which trust is assigned.
- Legal name in the jurisdiction(s) of interest. (eg 1- certificate of incorporation (Providence who owns several DBAs). 2- A DNS domain name.)
- Doing Business As (DBA) for the practice. ( eg Swedish Physicians) Note that this may or may not have a legal or DNS name - not sure if that is important)
- Specific physical location where service was provided to a patient. (eg Pine Lake Office of Swedish Physicians) (aka POP - point of presence)
- Endpoint were a specified digital service is provided. (eg A url consisting of: DNS scheme: host name: port number / service name # information provided by user)
- Specific person providing the service.
- The endpoints of particular interest to the user are the PHI records location and the place where appointments are made and calendars kept.
- PHI processing entity (eg Epic)
- If a PCP (Private Care Practice) is the source of Identity Proofing to be used with other providers we need to create an identifier for the user with level 2 assurance.
- Medical records can apply to both state and transaction records. Where the full state includes all of the PHI and transaction includes only updates to the PHI.
- 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).
- When a patient creates information on their own, or with medical devices in the home they need a secure manner to share that data.
- It is hard to describe the scope of data in a manner that can be understood by most patients. It is expected that such a list should have between 5 and 12 entries ONLY.
- Patients have these needs that must be addressed by the ecosystem:
- Redress of grievances - usually data that is incorrect, mislabeled (as to severity) - It must be clear to the patient where to go for redress of any data in the EHR.
- Recovery of access - usually loss of access to one or more EHR - access to the record locator service might be the best place to address.
- Determining current state of consent grants and changing them.
Several of the above items might be distributed across a range of providers. That will mean, for example, that the place to go for redress might well depend on the data source. While consent grants might be tracked in the user agent. Altho the problem with tracking in the user agent may not agree with the understanding of the provider.
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.)
- 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 patients will be provided with proof of acceptance into a provider's practice.
- All devices and user agent software will come with certifications of compliance.
- All providers that authenticate patients and authorize services will make their own determination as to the patient's identity.
- 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.
FHIR v4 has 41 categories and 5 levels of sensitivity. We might start the the four levels to see if they would be sufficient to handle the needs of the users.
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.
The order and extent of these items is currently arbitrary and pending review by industry experts.
- Approve broad plan for proceeding.
- Collect sources of names in the US Healthcare industry today.
- Collect the best practices for names in other industries or standards groups.
- Identify gaps, one specific one is the lack of any taxonomy of data types for the user, as opposed to the ones used by the providers and payers.
- Fill the gaps
On Kantara wiki pages.
- The charter of the Kantara work group effort
- The wiki page Health Care Profile establishes the context for this page.
- Phone as Health Care Credential
- Emergency Contact Information Use Case
- Health Care Profile Sandbox
- Health IT Record Location Service (Data Aggregation)
- Patient authenticates to EHR to access their lab results
- Patient pull of information
- Patient Registration with Distributed Attributes
- Patient uses Trusted Third Party to authenticate and move EHR
- Patient with Lab and Referral Use Case
- Trust Framework Membership Validation describes the API to establish trust
- Consent to Create Binding describes the api message to be sent by the user device to the Credential Service Provider
- Trustworthy Healthcare Ecosystem (Describes the scope of this document)
- A comprehensive report on OpenID HEART which uses Kantara UMA and federated authorization.
- Heart Specs at the OpenID foundation.
- Best Practice in HealthCare
- Compliant Implementation of Trust Registry
- Electronic Health Records - EHR
- Health Care Digital Identity
- Health Care Identity Management
- Health Care Native App Example
- Medical Records Identifier
- Patient Experience
- Patient Health Information - PHI
- TEFCA, Trusted Exchange Framework and Common Agreement for an FHIR interaction with the transfer of PHI between Secure Nodes
The TEF Draft 2 supports the Cures Act’s goal of advancing nationwide interoperability and is a key component of HHS’ and the Administration’s broader strategy to facilitate nationwide interoperability. HINs must agree on a minimum set of principles that enable trust in order to facilitate interoperability and the exchange of EHI necessary to support the entire care continuum. The TEF Draft 2 establishes a uniform set of principles that all HINs should adhere to allow for the trusted and secure electronic exchange of health information. Adherence to these principles will help improve the flow of EHI, providing patients with secure access to their information when and where they need it most.