Trustworthy Healthcare Provider: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
 
(52 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Full Title or Meme==
==Full Title or Meme==
There are two contexts where [[Trustworthy Healthcare Provider]] is defined and so there are two memes that it covers:
There are two contexts where [[Trustworthy Healthcare Provider]] is defined and so there are two memes that it covers (perhaps these two classes are isomorphic):
# Providers that share trust among themselves to know that [https://tcwiki.azurewebsites.net/index.php?title=PHI Protected Health Information (PHI)] can be shared as the correspondent is a recognized HIPAA-covered entity.
# Providers that share trust among themselves to know that [https://tcwiki.azurewebsites.net/index.php?title=PHI 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 with their [[UXC Dictionary|Consent]].
# Providers that may be trusted by patients (or other end users) with their PHI and their [[UXC Dictionary|Consent]] as to permitted use.
===Goals===
===Goals===
# [[IDEF Registry|Trust Registry]] of IDEF (Trusted Identifiers in Cyberspace) for healthcare industry in US.
# [[IDEF Registry|Trust Registry]] of IDEF (Trusted Identifiers in Cyberspace) for healthcare industry in US that is available to all inquiries at any time at low latency and at no cost to occasional users.


==Context==
==Context==
* The wiki page [[Health Care Profile]] establishes the context for this page.
* 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:
* 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 patient can know that their medical and other records are safe within any provider's Electronic Health Record (EHR) database.
Line 13: Line 15:
# 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.
# 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.
# 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.
* 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===
===Real World Members===
*The patient and the physical places where the patient goes are all legal entities and have legal obligations.
*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.
# 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. (See the section [[Trustworthy_Healthcare_Ecosystem#Use_of_Native_Apps_to_hold_the_patient.27s_PHI|Native Apps to hold the Patient PHI]] below for a discussion of some of these points.
# 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.
# Non-Covered Entities - Guardians, Delegated Authorities, Lawyers, etc. may act for the patient or just be others that the patient trusts to receive their medical records. The access can be conditional or date-time sensitive..
# 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.
# Covered Entities - 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. Some of these will perform [[Identity Proofing]]. The services that they provide are listed below.
 
===User Digital Devices===
This section deals with users which might be the patient or someone acting on behalf of the patient. The manner that a person gets the right to act on the patient's behalf is beyond the scope of this document and may vary from state to state.
* The user has the right to access the patient's Electronic Health Record (EHR) database from their digital device. (See TEFCA below)
* The exact form that the user can receive the data is not specified.
* The exact nature of "secure access" to the information is not not specified.
* There are multiple ways to provide the information and to secure access, none has been acceptable to all of the participants.  See solutions below.


===Digital Service Endpoints===
===Names use within the Ecosystem===
* These services may be combined on Web Sites in any way that works for the participants. These services all expose a common set of API's based on FHIR, but extended to allow online verification of trust and patient authentication information to be exchanged before data flows.
There are a variety of identifiers used by the real-world entities described above. These are the handles to which trust is assigned.
* While there may be distinct services that are available at each endpoint, there will (nearly) always be multiple endpoint at one particular domain named service. The domain named service is most often available as a result of a [https://tcwiki.azurewebsites.net/index.php?title=DNS DNS] entry for the host name such as https://example.com. Which must responds to requests for metadata that describes it in well-known protocols and semantics.
# Legal name in the jurisdiction(s) of interest. (eg 1- certificate of incorporation (Providence who owns several DBAs). 2- A DNS domain name.)
* These domain names and endpoints all belong to a single legal entity which is a member of the appropriate federation where the metadata may be examined.
# 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)
* The issue of [[Trustworthy Healthcare Provider]]s is important for flows not only among members of the federation, but also among their will participants. Please see that wiki page for more detains about the identification of [[Trustworthy Healthcare Provider]]s.
# Specific physical location where service was provided to a patient. (eg Pine Lake Office of Swedish Physicians) (aka POP - point of presence)
# Trust Registry - is an online Trust Anchor for information about medical providers that have met the appropriate operational criteria. All of the following endpoints will have trust certificates from a trust registry.
# 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)
# Credential Service Provider - is the glue between the user devices and the [[Covered Entities]] that perform identity proofing. It provides IAL2/AAL2 evidence that an App can act as the agent for the patient.
# Specific person providing the service.
# Trusted Third Parties authenticate the patient or others with legitimate access to patient medical records.
## The endpoints of particular interest to the user are the PHI records location and the place where appointments are made and calendars kept.
# EHR - the Electronic Health Record is required to respond to legitimate requests in a timely manner. It may also participate in patient matching. (See the [https://innovations.ahrq.gov/profiles/primary-care-patients-use-interactive-preventive-health-record-integrated-electronic-health 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.
# PHI processing entity (eg Epic)
# Payment Provider - can a part of both the patient proofing and patient authentication processes in most practices. At least one service will list covered solutions and indicate if the patient has co-pays that they need to make. This class of service endpoint also includes payment sources, like credit cards.
# 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==
==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?
* 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.
* 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. Where the full state includes all of the PHI and transaction includes only updates to the PHI.
* 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 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 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.
** When a patient creates information on their own, or with medical devices in the home they need a secure manner to share that data.
# '''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.
* 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.
# '''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.
* Patients have these needs that must be addressed by the ecosystem:
# '''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.
# 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.
# '''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.  
# 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.
# '''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.
# 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.


==Solutions==
==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===
===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 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 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 patients will be provided with proof of acceptance into a provider's practice.
* 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.
* All devices and user agent software will come with certifications of compliance.
Certifications today are found for:
* All providers that authenticate patients and authorize services will make their own determination as to the patient's identity.
* [https://www.healthit.gov/topic/certified-health-it-products-list-chpl Certified Health IT Products List (CHPL)] for software packages that can support EHR.


===Patient Consent===
===Patient Consent===
Line 77: Line 64:
** We need the ability to create a consent receipt for moving medical records from one provider to another provider.
** We need the ability to create a consent receipt for moving medical records from one provider to another provider.


===Bindings===
===Data Categorization===
* 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.
[https://www.hl7.org/fhir/v3/InformationSensitivityPolicy/vs.html FHIR v4] has 41 categories and 6 levels of sensitivity. We might start the six levels to see if they would be sufficient to handle the needs of the users.
* 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.
* The user agent will typically also create a binding between the subject and any service provider indicated the consent granted by the subject to the provider. In most cases the subject will have the ability to dissolve the binding and withdraw the consent. Contract law may override this ability to withdraw consent in some cases.
 
===Protection of the Patient Credentials===
These are the requirements from NIST SP 800-63-3.
 
* Identity Assurance Level 2 requires the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for identity proofing. Since many covered entities already perform identity proofing, the remaining problem is to move that proof from the covered entity into the patient credential on the smart phone.
* Authenticator Assurance Level 2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s) e.g. FIDO U2F (Web Authentication)or Client to Authentication Protocol (CTAP FIDO?) with the smart phone (with a trusted execution environment) itself.
 
The wiki page [[Phone as Health Care Credential]] describes how these requirements can be met in a patient-friendly manner.


===Use of [https://tcwiki.azurewebsites.net/index.php?title=Native_App Native Apps] to hold the patient's PHI===
{|border="1" padding="2" width="888px"
While there may be multiple ways to protect patient's PHI while in the user's possession, this paper explores two use cases.
| sev|| Name||  Definitions
#1 The app is considered to be a HIPAA covered entity and will only accept and disburse patient data to other covered entities. Exfiltration of data from this [Trusted Federation] is severely restricted, but still possible.
|-
#2 The app is not a HIPAA covered entity and is not bound by the federal regulations that apply to covered entities. Apps with little regard for the patient's information may be able to convince users to share data which is not covered.
| L ||low|| the information has been de-identified, and there are mitigating circumstances that prevent re-identification, which minimize risk of harm from unauthorized disclosure. The information requires protection to maintain low sensitivity.
The above addresses information that starts out covered by HIPAA. Other data that is not initially covered includes in-home telemetry data and user entered data include patient approved medical directives.
Examples: Includes anonymized, pseudonymized, or non-personally identifiable information such as HIPAA limited data sets.
====App as HIPAA covered entity====
Map: No clear map to ISO 13606-4 Sensitivity Level (1) Care Management: RECORD_COMPONENTs that might need to be accessed by a wide range of administrative staff to manage the subject of care's access to health services.
There are severe federal penalties for exposing covered data.
Usage Note: This metadata indicates the receiver may have an obligation to comply with a data use agreement.
* The app must be approved by a trusted authority to even open a communications channel to an EHR.
|-
* This applies to downloading data from the EHR, as well as uploading it to other sites.
| M||moderate||moderately sensitive information, which presents moderate risk of harm if disclosed without authorization.
* Potentially exfiltration of data from the domain of HIPAA covered entities could be down WITH EXPLICIT APPROVAL by the user of the app.
Examples: Includes allergies of non-sensitive nature used inform food service; health information a patient authorizes to be used for marketing, released to a bank for a health credit card or savings account; or information in personal health record systems that are not governed under health privacy laws.
* Rules of consent to release data could be rigorously enforced and violator could be thrown out of the federation. All federation access would be verfied for every connection to any other federated entity.
Map: Partial Map to ISO 13606-4 Sensitivity Level (2) Clinical Management: Less sensitive RECORD_COMPONENTs that might need to be accessed by a wider range of personnel not all of whom are actively caring for the patient (e.g. radiology staff).
 
Usage Note: This metadata indicates that the receiver may be obligated to comply with the receiver's terms of use or privacy policies.
====App is not protected by HIPAA====
|-
Only regular FTC protections for user private information apply.
| N||normal||  the information is typical, non-stigmatizing health information, which presents typical risk of harm if disclosed without authorization.
* There is an effort to create a "Code of Conduct" for apps that can acquire PHI from an EHR that is in development by the CARIN alliance.
Examples: In the US, this includes what HIPAA identifies as the minimum necessary protected health information (PHI) given a covered purpose of use (treatment, payment, or operations). Includes typical, non-stigmatizing health information disclosed in an application for health, workers compensation, disability, or life insurance.
* It is not clear that if a large company, like Apple, created a Health app, would then decide not to agree to the code of conduct. Could they be excluded from access PHI given the access rules of the ONC?
Map: Partial Map to ISO 13606-4 Sensitivity Level (3) Clinical Care: Default for normal clinical care access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR). Maps to normal confidentiality for treatment information but not to ancillary care, payment and operations.
 
Usage Note: This metadata indicates that the receiver may be obligated to comply with applicable jurisdictional privacy law or disclosure authorization.
===Recovery and Redress===
|-
# lost phone
| R|| restricted|| highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if disclosed without authorization. May be pre-empted by jurisdictional law, e.g., for public health reporting or emergency treatment.
# phone migration
Examples: Includes information that is additionally protected such as sensitive conditions mental health, HIV, substance abuse, domestic violence, child abuse, genetic disease, and reproductive health; or sensitive demographic information such as a patient's standing as an employee or a celebrity. May be used to indicate proprietary or classified information that is not related to an individual, e.g., secret ingredients in a therapeutic substance; or the name of a manufacturer.
# Phone hijacking
Map: Partial Map to ISO 13606-4 Sensitivity Level (3) Clinical Care: Default for normal clinical care access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR). Maps to normal confidentiality for treatment information but not to ancillary care, payment and operations..
 
Usage Note: This metadata indicates that the receiver may be obligated to comply with applicable, prevailing (default) jurisdictional privacy law or disclosure authorization..
===Access Codes===
|-
The access codes are created with the permission (consent) of the Patient or the Physician. Each grants access to a limited set of data.
|  U|| unrestricted|| the information is not classified as sensitive.
* Patient Credential access code provides access to the identify proofing evidence created by a Covered Entity.
Examples: Includes publicly available information, e.g., business name, phone, email or physical address.
* Medical Records ([https://tcwiki.azurewebsites.net/index.php?title=EHR EHR]) access code provides access to a particular patient EHR or a subset of the data in an EHR.
Usage Note: This metadata indicates that the receiver has no obligation to consider additional policies when making access control decisions. Note that in some jurisdictions, personally identifiable information must be protected as confidential, so it would not be appropriate to assign a confidentiality code of "unrestricted" to that information even if it is publicly available.
 
|-
===Biometric Factors===
| V ||very restricted || the information is extremely sensitive and likely stigmatizing health information that presents a very high risk if disclosed without authorization. This information must be kept in the highest confidence.
* Finger print
Examples: Includes information about a victim of abuse, patient requested information sensitivity, and taboo subjects relating to health status that must be discussed with the patient by an attending provider before sharing with the patient. May also include information held under 'legal lock' or attorney-client privilege. This metadata indicates that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject.
* 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.
*[[Trust Framework Membership Validation ]] describes the API to establish trust among covered entities and for the benefit of the patient.
*[https://github.com/TransparentHealth/poet Pre Oauth Entity Trust] describes a means to represent third-party application endorsement for health care applications. POET’s goal is to help consumers distinguish between applications that have an endorsement versus applications that have no pedigree (i.e untrusted and could be malicious).


===Record Matching===
===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.
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:PatientTrust.png]]


==Next Steps==
==Next Steps==
The order and extent of these items is currently arbitrary and pending review by industry experts.
The order and extent of these items is currently arbitrary and pending review by industry experts.
# Approve broad plan for proceeding.
# Approve broad plan for proceeding.
# Create a Patient experience set of use cases to be tested (as a part of a broader conformance verification)
# Collect sources of names in the US Healthcare industry today.
# Establish a specific plan for the sand box.
# Collect the best practices for names in other industries or standards groups.
# Build a trust registry that can hold configuration/manifest data and respond to API requests for:
# 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.
## Applications that are in conformance with Evolving CARIN best practices
# Fill the gaps
## 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.
# 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
# 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
# Create a trusted third party web site that can:
## Demonstrate how a patient can enter and manage their (e.g.) emergency contact information that is entirely under their own control.
## Demonstrate Identification and Attribute Provider (IAP) with IAL2 authentication capability


==References==
==References==
Line 172: Line 127:
*[[Trust Framework Membership Validation ]] describes the API to establish trust
*[[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]]
*[[Consent to Create Binding]] describes the api message to be sent by the user device to the [[Credential Service Provider]]
*[[Trustworthy Healthcare Ecosystem]] (this document)
*[[Trustworthy Healthcare Ecosystem]] (Describes the scope of this document)


===External References===
===External References===
Line 187: Line 142:
*[https://tcwiki.azurewebsites.net/index.php?title=Medical_Records_Identifier Medical Records Identifier]
*[https://tcwiki.azurewebsites.net/index.php?title=Medical_Records_Identifier Medical Records Identifier]
*[https://tcwiki.azurewebsites.net/index.php?title=Patient_Experience Patient Experience]
*[https://tcwiki.azurewebsites.net/index.php?title=Patient_Experience Patient Experience]
*[https://tcwiki.azurewebsites.net/index.php?title=PHI Patient Health Information - PHI]
*[https://tcwiki.azurewebsites.net/index.php?title=PHI Patient (or Protected) Health Information - PHI]
*[https://tcwiki.azurewebsites.net/index.php?title=TEFCA TEFCA], Trusted Exchange Framework and Common Agreement for an FHIR interaction with the transfer of PHI between Secure Nodes
*[https://digital.nhs.uk/services/health-and-social-care-network The UK HSCN Internet Access Form] In the UK only known sites are permitted to handle health information.<blockquote>The HSCN Internet Access Form has replaced the Data Security Centre (DSC) HSCN ANME Firewall Change Request Form. The form can be used if your CNSP has advised you are trying to access something that has been blacklisted, the port you are trying to access is not an allowed any/any port or you had access to a site on the Transition Network (previously N3) however you do not have the same access on HSCN.</blockquote>
<blockquote>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.</blockquote>
*[https://tcwiki.azurewebsites.net/index.php?title=TEFCA TEFCA], Trusted Exchange Framework and Common Agreement for an FHIR interaction with the transfer of PHI between Secure Nodes<blockquote>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.</blockquote>
 
* Public Health Service Act (42 U.S.C. 300jj) Health Care Provider Definition<blockquote>The term “health care provider” includes a hospital, skilled nursing facility, nursing facility, home health entity or other long term care facility, health care clinic, community mental health center (as defined in section 300x–2(b)(1) of this title), renal dialysis facility, blood center, ambulatory surgical center described in section 1395l(i) of this title, emergency medical services provider, Federally qualified health center, group practice, a pharmacist, a pharmacy, a laboratory, a physician (as defined in section 1395x(r) of this title), a practitioner (as described in section 1395u(b)(18)(C) of this title), a provider operated by, or under contract with, the Indian Health Service or by an Indian tribe (as defined in the Indian Self-Determination and Education Assistance Act [25 U.S.C. 450 et seq.]), tribal organization, or urban Indian organization (as defined in section 1603 of title 25), a rural health clinic, a covered entity under section 256b of this title, an ambulatory surgical center described in section 1395l(i) of this title, a therapist (as defined in section 1395w–4(k)(3)(B)(iii) of this title), and any other category of health care facility, entity, practitioner, or clinician determined appropriate by the Secretary</blockquote>
* [https://www.healthit.gov/sites/default/files/page/2019-04/ONCCuresActNPRMIBWebinar031919.pdf type of Health Care Providers from onc] (interestingly does not include the Electronic Health Repository (EHR) itself)
# a hospital
# skilled nursing facility
# nursing facility
# home health entity or other long term care facility
# health care clinic
# community mental health center
# renal dialysis facility
# blood center
# ambulatory surgical
# emergency medical services provider
# federally qualified health center
# group practice
# a pharmacist
# a pharmacy
# a laboratory
# a physician
# a practitioner
# a provider operated by, or under contract with, the Indian Health Service or by an Indian tribe, tribal organization, or urban Indian organization
# a rural health clinic
# a “covered entity” under certain statutory provisions
# an ambulatory surgical center
# a therapist
# any other category of health care facility, entity, practitioner, or clinician determined appropriate by the Secretary
# ONC is considering adjusting the [[Information Blocking]] definition of “health care provider” to cover all individuals and entities covered by the HIPAA “health care provider” definition.


[[Category:Profile]]
[[Category:Profile]]

Latest revision as of 01:34, 18 February 2021

Full Title or Meme

There are two contexts where Trustworthy Healthcare Provider is defined and so there are two memes that it covers (perhaps these two classes are isomorphic):

  1. 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.
  2. Providers that may be trusted by patients (or other end users) with their PHI and their Consent as to permitted use.

Goals

  1. Trust Registry of IDEF (Trusted Identifiers in Cyberspace) for healthcare industry in US that is available to all inquiries at any time at low latency and at no cost to occasional users.

Context

  • 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:
  1. The patient can know that their medical and other records are safe within any 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 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.
  1. 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.)
  2. 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.
  3. 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.

  1. Legal name in the jurisdiction(s) of interest. (eg 1- certificate of incorporation (Providence who owns several DBAs). 2- A DNS domain name.)
  2. 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)
  3. Specific physical location where service was provided to a patient. (eg Pine Lake Office of Swedish Physicians) (aka POP - point of presence)
  4. 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)
  5. Specific person providing the service.
    1. The endpoints of particular interest to the user are the PHI records location and the place where appointments are made and calendars kept.
  6. PHI processing entity (eg Epic)

Problems

  • 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:
  1. 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.
  2. 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.
  3. 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.

Solutions

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 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.

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.

Data Categorization

FHIR v4 has 41 categories and 6 levels of sensitivity. We might start the six levels to see if they would be sufficient to handle the needs of the users.

sev Name Definitions
L low the information has been de-identified, and there are mitigating circumstances that prevent re-identification, which minimize risk of harm from unauthorized disclosure. The information requires protection to maintain low sensitivity.

Examples: Includes anonymized, pseudonymized, or non-personally identifiable information such as HIPAA limited data sets. Map: No clear map to ISO 13606-4 Sensitivity Level (1) Care Management: RECORD_COMPONENTs that might need to be accessed by a wide range of administrative staff to manage the subject of care's access to health services. Usage Note: This metadata indicates the receiver may have an obligation to comply with a data use agreement.

M moderate moderately sensitive information, which presents moderate risk of harm if disclosed without authorization.

Examples: Includes allergies of non-sensitive nature used inform food service; health information a patient authorizes to be used for marketing, released to a bank for a health credit card or savings account; or information in personal health record systems that are not governed under health privacy laws. Map: Partial Map to ISO 13606-4 Sensitivity Level (2) Clinical Management: Less sensitive RECORD_COMPONENTs that might need to be accessed by a wider range of personnel not all of whom are actively caring for the patient (e.g. radiology staff). Usage Note: This metadata indicates that the receiver may be obligated to comply with the receiver's terms of use or privacy policies.

N normal the information is typical, non-stigmatizing health information, which presents typical risk of harm if disclosed without authorization.

Examples: In the US, this includes what HIPAA identifies as the minimum necessary protected health information (PHI) given a covered purpose of use (treatment, payment, or operations). Includes typical, non-stigmatizing health information disclosed in an application for health, workers compensation, disability, or life insurance. Map: Partial Map to ISO 13606-4 Sensitivity Level (3) Clinical Care: Default for normal clinical care access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR). Maps to normal confidentiality for treatment information but not to ancillary care, payment and operations. Usage Note: This metadata indicates that the receiver may be obligated to comply with applicable jurisdictional privacy law or disclosure authorization.

R restricted highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if disclosed without authorization. May be pre-empted by jurisdictional law, e.g., for public health reporting or emergency treatment.

Examples: Includes information that is additionally protected such as sensitive conditions mental health, HIV, substance abuse, domestic violence, child abuse, genetic disease, and reproductive health; or sensitive demographic information such as a patient's standing as an employee or a celebrity. May be used to indicate proprietary or classified information that is not related to an individual, e.g., secret ingredients in a therapeutic substance; or the name of a manufacturer. Map: Partial Map to ISO 13606-4 Sensitivity Level (3) Clinical Care: Default for normal clinical care access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR). Maps to normal confidentiality for treatment information but not to ancillary care, payment and operations.. Usage Note: This metadata indicates that the receiver may be obligated to comply with applicable, prevailing (default) jurisdictional privacy law or disclosure authorization..

U unrestricted the information is not classified as sensitive.

Examples: Includes publicly available information, e.g., business name, phone, email or physical address. Usage Note: This metadata indicates that the receiver has no obligation to consider additional policies when making access control decisions. Note that in some jurisdictions, personally identifiable information must be protected as confidential, so it would not be appropriate to assign a confidentiality code of "unrestricted" to that information even if it is publicly available.

V very restricted the information is extremely sensitive and likely stigmatizing health information that presents a very high risk if disclosed without authorization. This information must be kept in the highest confidence.

Examples: Includes information about a victim of abuse, patient requested information sensitivity, and taboo subjects relating to health status that must be discussed with the patient by an attending provider before sharing with the patient. May also include information held under 'legal lock' or attorney-client privilege. This metadata indicates that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject.

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.

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. Collect sources of names in the US Healthcare industry today.
  3. Collect the best practices for names in other industries or standards groups.
  4. 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.
  5. Fill the gaps

References

Internal References

On Kantara wiki pages.

External References

  • 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
  • FHIR
  • FirstNet
  • Health Care Digital Identity
  • Health Care Identity Management
  • Health Care Native App Example
  • Medical Records Identifier
  • Patient Experience
  • Patient (or Protected) Health Information - PHI
  • The UK HSCN Internet Access Form In the UK only known sites are permitted to handle health information.

    The HSCN Internet Access Form has replaced the Data Security Centre (DSC) HSCN ANME Firewall Change Request Form. The form can be used if your CNSP has advised you are trying to access something that has been blacklisted, the port you are trying to access is not an allowed any/any port or you had access to a site on the Transition Network (previously N3) however you do not have the same access on HSCN.

  • 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.

  • Public Health Service Act (42 U.S.C. 300jj) Health Care Provider Definition

    The term “health care provider” includes a hospital, skilled nursing facility, nursing facility, home health entity or other long term care facility, health care clinic, community mental health center (as defined in section 300x–2(b)(1) of this title), renal dialysis facility, blood center, ambulatory surgical center described in section 1395l(i) of this title, emergency medical services provider, Federally qualified health center, group practice, a pharmacist, a pharmacy, a laboratory, a physician (as defined in section 1395x(r) of this title), a practitioner (as described in section 1395u(b)(18)(C) of this title), a provider operated by, or under contract with, the Indian Health Service or by an Indian tribe (as defined in the Indian Self-Determination and Education Assistance Act [25 U.S.C. 450 et seq.]), tribal organization, or urban Indian organization (as defined in section 1603 of title 25), a rural health clinic, a covered entity under section 256b of this title, an ambulatory surgical center described in section 1395l(i) of this title, a therapist (as defined in section 1395w–4(k)(3)(B)(iii) of this title), and any other category of health care facility, entity, practitioner, or clinician determined appropriate by the Secretary

  • type of Health Care Providers from onc (interestingly does not include the Electronic Health Repository (EHR) itself)
  1. a hospital
  2. skilled nursing facility
  3. nursing facility
  4. home health entity or other long term care facility
  5. health care clinic
  6. community mental health center
  7. renal dialysis facility
  8. blood center
  9. ambulatory surgical
  10. emergency medical services provider
  11. federally qualified health center
  12. group practice
  13. a pharmacist
  14. a pharmacy
  15. a laboratory
  16. a physician
  17. a practitioner
  18. a provider operated by, or under contract with, the Indian Health Service or by an Indian tribe, tribal organization, or urban Indian organization
  19. a rural health clinic
  20. a “covered entity” under certain statutory provisions
  21. an ambulatory surgical center
  22. a therapist
  23. any other category of health care facility, entity, practitioner, or clinician determined appropriate by the Secretary
  24. ONC is considering adjusting the Information Blocking definition of “health care provider” to cover all individuals and entities covered by the HIPAA “health care provider” definition.