Health Care Profile

From IDESG Wiki
Revision as of 19:36, 15 September 2019 by Tomjones (talk | contribs) (→‎References)
Jump to navigation Jump to search

Full Title or Meme

This Health Care 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.

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

    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.

Stakeholders

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

References

  • 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

    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.

  • Kantara Healthcare Identity Assurance Work Group

    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.

  • OpenID HEART WG

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

  • HIE of one

    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.

Retrieved from "https://wiki.idesg.org/index.php?title=Health_Care_Profile&oldid=13357"