Health Care Native App Example

From MgmtWiki
Revision as of 17:11, 26 May 2019 by Tom (talk | contribs) (Next Steps)

Jump to: navigation, search

Full Title

Best Practice example of a Native Application designed for patients with a modern Smart Phone.

Context

Matching patient health care records and interoperability among EHR have been hard problems to address. Much of the focus has been on the health care providers rather than the patient. But now the patient has guaranteed access to their medical records, they might be able to overcome some of the resistance to sharing seen today. Patient control of the distribution of medical records would give patients both the appearance and the reality of limited access to private health care information. This example of a patient-oriented Native App for them to host on their personal Smart Phone is designed to show how patients might be the best answer to health care sharing in any case.

The Pew Trust report[1] sponsored a collaboration with the Rand corporation and reported this conclusion about an opportunity for a Patient-empowered solution:
In a report released in August 2018, RAND recommended a patient-empowered approach for matching involving two main components: validating patient information and a smartphone application, which would then be used together once developed.

Parties to any Transaction

  • The patient with the Smart Phone and the app is always a part of the transaction.
    • In some cases the phone is simply for Authentication, or records matching, but that is not the primary purpose.
    • The phone can be the source of information to be passed to the relying party from either medical or personal sources.
  • The Relying Party is a catchall term for the party seeking the information or validation, including:
    • A PCP - private care provide where the patient appears in person with the phone in hand.
    • Any site with PHI - patient health information in an EHR - Electronic Health Record - either in person on on the web.

Problems

  • Smart phone apps have been generated by some large practices, often with support of their IT service providers. These apps do not provide patients with any choice other than "take it or leave it".
  • There has been no sound business case to support the development of patient-oriented apps in the marketplace.
  • Covered entities have HIPAA regulations to control how they handle the patient's medical records; but there is no such rules in place when medical records are under the control of the patient (or guardian).

Solutions

Several trends have been seen that can enable such a Patient-empowered solution:

  1. Matching of patient records to the patient is a recognized problem that requires some solution to prevent unwanted patient outcomes. Efforts at a universal health care identifier for patients seems to be as far in the future as ever and no other solution has appeared on the horizon.
  2. The CARIN Alliance has published a code of ethics for health care information that moves beyond the control of HIPAA covered entities.
  3. The role of Smart Phones in Authentication has been expanding (see that wiki page for specific examples.)
  4. Microsoft has just introduced[2] a open-source protocol to address performance issues with Blockchain. ION, or Identify Overlay Network, is based on an earlier blockchain project built by Microsoft and others called Sidetree.

Information Sharing

It is generally agreed that it is better for doctors to have a full set of patient health histories to enable adequate care, especially in life-or-death emergency cases. This sample shows a way for the patient to both acquire and distribut health care information. Since the progress on giving patients access to their own health records may be more likely than cooperation among competing health care enterprises, a Smart Phone app is one way to overcome the blockage to information sharing. This path also gives the patient more control on exactly what information is shared. While patient choice may result in some critical information being with-held, more choice will give the patients greater confidence in sharing, which could have beneficial effects on health outcomes.

Authentication

  • The app will act as an authencator to other medical records providers.
  • It can provide local access with bluetooth, NFC or QR code displayed on the scree.
  • It will support remote authentication with a variety of Web Authentication methods inlcude FIDO U2F.
  • It is likely that a single anchor for a country's health ecosystem is required where any patient or provider can learn the status of any Web Site by providing metadata about the entity that operates the Web Site from a Federation Trust Registry.
  • It is likely that the entity operating the Web Site will not be the health service Provider, and so a "On-behalf-of" Identifier is likely to be required as well.

Verified Information

  • A Smart Phone can verify in very simple ways, such as receiving an SMS message with a code to provide to the Relying Party, but the app is not required for that.
  • Verification of the phone number would help maintain contact information the the patient as well as providing verification.
  • The app as a wider range of value types it can display for verification by the Relying Party.
  • The app can simply ask the patient for a gesture or finger swipe to approve an transaction or simple identity.
  • The app can even respond to update requests from the Relying Party.

Patient's Rights

Deborah C. Peel, MD Founder and President Patient Privacy Rights

www.patientprivacyrights.org

https://patientprivacyrights.org/health-privacy-summit/

Patient Experience

  • The best Patient Experience is likely to be enabled by giving the patients the choice of which app to host on their phone based on their own experience with phone apps.
  • The patient experience could easily continue to tracking medications or other health plan conformance.

Emergency Contact Example

. See an evolving example of this use case at http://controls.azurewebsites.net

Next Steps

  1. Create pilot test code for validation of ideas with all participants in a live setting.
  2. Test APIs for getting data (like Blue Button)
  3. Start a directed pilot test with a specific health care provider to get real-world feedback.
  4. Test APIs for transmitting data to EHRs.
  5. Look at value add features, like tracking patient conformance with drug or other treatment options.

References

  1. Pew Charitable Trust, Enhanced Patient Matching Is Critical to Achieving Full Promise of Digital Health Records. https://www.pewtrusts.org/-/media/assets/2018/09/healthit_enhancedpatientmatching_report_final.pdf
  2. Microsoft, Microsoft unveils decentralized identity protocol that works atop the Bitcoin blockchain. (2019-05-13) https://www.geekwire.com/2019/microsoft-unveils-decentralized-identity-protocol-works-atop-bitcoin-blockchain/

Other References

  • The H-ISAC Healthcare Information Sharing and Analysis Center provides a forum for coordinating, collaborating and sharing vital Physical and Cyber Threat Intelligence and best practices with each other.
  • Authenticate Node section 19 of (2018-07-24) IHE IT Infrastructure Technical Framework primarily relies on mutual authentication with no specific trust anchor other than X.509 certificate chains.
  • IDEF health wiki pages.