Difference between revisions of "Healthcare Profile"

Latest revision as of 12:36, 16 May 2023

This Healthcare Profile is one of the Framework Profiles that will allow developers of code and user experience to determine if their systems are compliant with the framework.

Goals

1. Creation of a profile for the use of the UXC NSTIC Principles in the US Healthcare community.
2. Improve Patient Choice in acquiring and releasing of their Personal Healthcare Information (PHI).
3. Solution to the TEFCA requirement for Level 2 identifier assurance based on NIST 800-63-3 (A) for IAL2 and (B) for AAL2.
4. That a patient oriented solution must provide a corresponding level of trust in the covered health care providers (aka the Electronic Health Record service).

Assumptions

1. Consumer acceptance of level 2 assurance has been rejected in most cases where it has been tried. (It has only worked where some enterprise required its use.)
2. Banking institutions are required to support Anti-money Laundering legislation and do a credible job of assuring customer identity.
3. Individual Private Care Practices (PCPs) have a good record of requiring strong identity proofing at registration and authentication.
4. The US CARES act administered by the HHS ONC will provide sufficient incentive to propel US healthcare to level 2 assurance of identity.

Context

• This profile is oriented to federated health systems like that in the United States. Still the privacy considerations should apply to all, especially to cross boarder access.
• As a part of the creation of a set of Identity Ecosystems this profile is targeted to apply to any framework that handles user Protected Health Information (PHI).
• The wiki page Trustworthy Healthcare Ecosystem contains details on how identity is used in healthcare.
• The effort to standardize PHI transfers has been steadily progressing for years under pressure from the ONH, but many health providers view user's PHI as their proprietary asset.
• Now Apple has entered the equations with their health app which has gone directly to the health providers to acquire PHI as well as generating it on their own from the Apple watch. Now they are a PHI provider themselves, and presumably subject to all the regulation that entails.

Identifiers for Patients

Several countries have started an effort to create a central registry of all citizens or, in some cases, all residents. The US has determined that the social security number (SSN) is not a secure means of identification and has mandated that many agencies will need to create their own Identifiers. This has not yet impacted medicare nor the providers' database keys which are still base on the SSN. (Note that in some cases guardians may also be qualified to act as a agent for the patient.)

• The Center for Medicare Services recently deployed a new Identifier for users of Medicare that is not tied to the user's social security number.
• Pew research report Enhanced Patient Matching Is Critical to Achieving Full Promise of Digital Health Records, and to prevent harm through faulty health history information. This is defiantly not patient oriented (and that is not a typo.) When they did ask patients what they wanted it was consistently shown that patients want all of the benefit of matching, with none of the downside of loss of privacy. They also found that Republican voters didn't want the government involved at all.

1. System oriented solution needs unique patient identifiers - but what they really mean is mandatory patient IDs for life.
2. Patient oriented solutions, like Smart Phones and QR codes, fit in better with the goal to give patients access and control of their private information, personal as well as medical.
3. Demographic matching, bio-metrics, disease history, whatever (maybe even the old standard, the social security number).
4. Referential from other sites, like social services agencies or similar.

• The Department of Homeland security will be enforcing Real ID by October 2020 for travel as well as border crossings.
• The Federal Emergency Management Agency (FEMA) has created a SID.
• The US Treasury (for the IRS) is planning for a tax payer ID.
• The Department of Defense has issued PIV cards for access to national defense information (and has propagated that system to NATO).

All of these should result in the user's Identity being separated for the various uses. This appears to be an example of the sort of Distributed ID that many organizations are now promoting. Obviously all the law enforcement agencies will ask for the unfettered ability to cross reference these Identifiers from any source what-so-ever. Hopefully the API that allows access to that tracking functionality will be well protected.

Assurance for Patient Identifiers

TECA requires "that all QHIN (Qualified Health Information Network) shall require that any staff or users at the QHIN, Participants, or Individual Users who request EHI or request to send EHI shall be authenticated at a minimum of AAL2 and, if not an Individual User, also provide support for at least FAL2. Each QHIN shall also require each of its Participants to authenticate any Participant Members or Individuals Users that request EHI or request to send EHI at a minimum of AAL2 and, if not an Individual User, also provide support for at least FAL2." And also " Prior to the issuance of access credentials, each QHIN shall identity proof any staff or users at the QHIN who may initiate a QHIN Query or QHIN Message Delivery at a minimum of IAL2." As a general rule it appears that this criteria is met by any patient of a medical practice that has been accepted by the practice as a patient. It is less clear how this is to be applied to any QHIN that is not affiliated with the patient's primary care practice (PCP).

• TEFCA, Trusted Exchange Framework and Common Agreement for an FHIR interaction with the transfer of PHI between Secure Nodes
• Phone as Health Care Credential describes one way that NIST 800-63-3 level 2 assurance can be obtained with minimal impact to existing healthcare systems.

Identifiers for Providers

• CMS Advances Interoperability & Patient Access to Health Data through New Proposals which are defiantly not patient oriented in any way.<blockquote>Today, February 11, 2019, the Centers for Medicare & Medicaid Services (CMS) proposed policy changes supporting its MyHealthEData initiative to improve patient access and advance electronic data exchange and care coordination throughout the healthcare system. The Interoperability and Patient Access Proposed Rule outlines opportunities to make patient data more useful and transferable through open, secure, standardized, and machine-readable formats while reducing restrictive burdens on healthcare providers.<blockquote>

Stakeholders

• Integrating the Healthcare Enterprise (IHE) has international participation. Of particular interest here might be the Privacy and Consents page. A description of the use of Consent in a Healthcare Exchange was create by John Moehrke,

Problems

• Some of the stakeholders are reluctant to share patient information that they consider to be proprietary.
• Different organizations of providers (regions, VA, etc.) have created their own taxa and procedures that are not cross-compatible.
• While privacy of patient information is consider, the User Experience of the patient is not part of any health care proposals.
• Health care offers a variety of critical functions during any emergency, like the ER itself. Access to medical records and public health were part of the enumeration of the National Critical Functions Set reported by the Cybersecurity and Infrastructure Security Agency (CISA) in NATIONAL CRITICAL FUNCTIONS AN EVOLVED LENS FOR CRITICAL INFRASTRUCTURE SECURITY AND RESILIENCE.

Solutions

UX Ecosystem https://blog.prototypr.io/ux-ecosystems-in-healthcare-4c244c386253

Use Cases

• Emergency Contact Information Use Case - How users construct a collection of contact information that can be access by First Responders.
• Patient with Lab and Referral Use Case - Normal patient at a normal doctors' offices with lab work for sensitive disease (say hepatitis) and referral to a specialist in a different practice.
• Patient under 13 and Homeless Use Case - Homeless child under the age of 13 being registered by a school nurse and subsequent diagnosis with a public health issue - say measles. (Not yet started)
• The page Health IT Record Location Service (Data Aggregation) contains a use case for locating user PHI.
• Alice consents to safely receive and share her health information with any user of her choice that uses modern, patient-centric security and respects her privacy preferences
• Patient Experience wiki page.
• Controlling Access to Health Data from the UMA use cases.
• Coordinated chronic disease management for a patient having several modalities using telemedicine and 3rd party business associates vendors as part of the remote monitoring solution. (Not yet started)
• Mobile Driver's License in Healthcare how it can be used to register a patient in telemedicine.
• Trustworthy Healthcare Ecosystem contains the patient trust experience in a healthcare ecosystem.
• Patient from US travels to Northern Ireland where she contracts salmonella. She is diagnosed in the Republic of Ireland that tries to track the source of infrection.
• FHIR Use Case

References

• Trusted Exchange Framework and Common Agreement (TEFCA) Draft 2 (2019-04-19) See the basic identity issues under the section #Assurance for Patient Identifiers above.
• Health ISAC, IDENTITY FOR THE CISO NOT YET PAYING ATTENTION TO IDENTITY (2019-09)
• Association for Advancement of Medical Instrumentation (AAMI) Technical Information Report 57, Principles for medical device security–Risk management
• Department of Health and Human Services (HHS), “The HIPAA Privacy Rule,” https://www.hhs.gov/hipaa/for-professionals/privacy/index.html
• HHS, “The HIPAA Security Rule,” https://www.hhs.gov/hipaa/forprofessionals/security/index.html
• NIST SP 800-66 Revision 1, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-66r1.pdf
• A User’s Guide to Understanding to TEFCA Draft 2 A slide deck that introduces some erroneous simplifications. (like credential)
• The page Health Care Profile Sandbox details a test suite that will allow developers of code and user experience to assure the compliance of their products to the framework.
• The US Health and Human Services (HHS) announced a yearlong effort to foster innovation on 2018-11-21.
• European Federation of Nurses working on user centric health data.
• Summary of the European Commission’s eHealth Strategy
• European Health ePolicy
• ISO 22600-1:2014 Health informatics -- Privilege management and access control -- Part 1: Overview and policy management
• HIPPA - Legislation - § 164.414(b) Burden of proof. In the event of a use or disclosure in violation of subpart E, the covered entity or business associate, as applicable, shall have the burden of demonstrating that all notifications were made as required by this subpart or that the use or disclosure did not constitute a breach, as defined at § 164.402.
• Direct Trust<blockquote>DirectTrust is a collaborative non-profit association of 121 health IT and health care provider organizations to support secure, interoperable health information exchange via the Direct message protocols. DirectTrust has created a “trust framework” that extends use of Direct exchange to over 106,000 health care organizations and 1,582,373 Direct addresses/accounts. Over 300 EHR and PHR vendors’ products, and over 50 HIEs, participate in the DirectTrust network, ensuring interoperability and security via Direct for exchange of health information to more than half the professionals in the U.S. health care system.</blockquote>
• The Sequoia Project ONC selects nonprofit Sequoia Project to coordinate TEFCA (2019-09-06) <blockquote>The government’s health IT agency has selected nonprofit Sequoia Project to serve as the recognized coordinating entity (RCE) overseeing the implementation of the Trusted Exchange Framework and Common Agreement (TEFCA). The Sequoia Project, a public-private partnership that advocates for nationwide health IT exchange, will start work on its responsibilities this week. The RCE is mostly responsible for developing and implementing the Common Agreement portion of the interoperability guidelines: creating baseline technical and legal requirements for different health IT systems, companies and groups to communicate with each another and share electronic information. In its new role, the Sequoia Project will also choose and monitor qualified health information networks (QHINs). The four-year agreement with the Office of the National Coordinator for Health IT is funded for $900,000 for the first year.</blockquote>
• Kantara Healthcare Identity Assurance Work Group <blockquote>The Kantara Healthcare Identity Assurance WG (HIAWG) exists to be the primary source of Healthcare Industry expert input into the Kantara IAF; to promote the use of Trust Frameworks in the Healthcare Industry for meeting the Trusted Identity interoperability requirements of the industry; and, to foster collaboration with regional, national and international Healthcare IT organizations.</blockquote>
• Kantara Identity Assurance Work Group<blockquote>The IAWG is an active discussion forum that maintains the Kantara Identity Assurance Framework (IAF) and supports Kantara Initiative Inc. governance and assurance programs. The IAF includes the standards, processes, practices, guidance and methods by which participants in identity federations gain assurance of the reliability, security, thoroughness and degree of assurance of each others’ processes for identity and credential information verification, validation and exchange.</blockquote>
• OpenID HEART WG<blockquote>HEART (Health Relationship Trust) is a set of profiles that enables patients to control how, when, and with whom their clinical data is shared. The HEART model builds on existing state-of-the-art security and adds additional components to ensure that patient clinical data is securely exchanged. In addition to giving patients control over how their own data is shared, HEART defines the interoperable process for systems to exchange patient-authorized healthcare data consistent with open standards, specifically FHIR (Fast Healthcare Interoperability Resources), OAuth, OpenID Connect, and UMA (User-Managed Access).</blockquote>
• The Strategic Health Information Exchange Collaborative (SHIEC) is the national collaborative representing health information exchanges (HIEs) and their strategic business and technology partners.<blockquote>SHIEC strives to enable the secure exchange of patient information to improve the quality, coordination, and cost-effectiveness of healthcare locally, regionally and nationally. We are the largest consortium of its kind in the country, representing 70+ member HIE organizations that together cover more than 200 million people across the United States—well over half of the American population. We advocate on behalf of our member organizations to ensure their needs are represented in nationwide conversations about critical healthcare issues, including health IT, health data sharing and stewardship.</blockquote>
• HIE of one is an open source cooperative based on blockchain and W3C Verifiable Claims. <blockquote>Our solution is a patient-centered approach to privacy protection in cloud computing and information based on digital consent standards, blockchain identity, and blockchain audit. This enables each patient and each licensed practitioner to own and completely control their open source connected health records within a secure environment. </blockquote>