Trustworthy Healthcare Application

Full Title or Meme

There are two models where Trustworthy Healthcare Application guidelines are needed and so there are two levels of protection that are prescribed:

1. Applications that are designed specifically to meet the Cures act requirements for access to download patient information (aka a read-only app.)
2. Applications that are designed to work with a patient's health plan and provide information back to the health care provider (called write-back by the ONC.)
3. Applications that are designated as medical devices by the FDC are currently out-of-scope, but may be addressed at a future time.

Goals

1. The Trust Registry of Kantara (Trusted Identifiers in Cyberspace) for healthcare industry makes application authentication assurance statements available at all times for Trustworthy Healthcare Providers to interact with patients on their smartphones and other devices.
2. This page is a guideline that bridges between the HIPAA and Cures Act regulations and the Software Assessment Criteria so that this guideline can be used by application developers to assure compliance.

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 Participants

• 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.
4. Electronic Health Record (EHR) is where the patient records are accessible. It is a Covered Entity, but is not alway the provider. For example the EHR can be on HIE.

Identifers 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. User ID = the identifier used by the patient or guardian when the sign into the provider or IHE portal.
2. Patient ID = this is an identifier that is known to the Patient. The goal is that the patient ID is created by the patient and is self-sovereign, that is owned by the patient.
3. eID = an electronic ID issued by a sovereign state. This may not apply to all jurisdictions or interactions. (Sometime call a mobile id (MID) which can be confusing in healthcare.)
4. WebID = a name of the website (or EHR) than can be recognized by the application when connecting (aka an EHR URL). This is not always the provider when an EHR covers several providers.)
5. Medical Record Locater = this is a combination of the EHR locator and the Medical ID (MID) that they EHR creates for the patient.

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 providers that authenticate patients and authorize services will make their own determination as to the patient's identity.
• User Identity proofing needs to be portable among healthcare providers.
• All devices and user agent software will come with certifications of compliance.
• The Kantara Trust Registry will make a Mobile Authentication Assurance Statement available for all apps that access private health information (PHI).

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.

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

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.