Difference between revisions of "Best Practice in HealthCare"
(→=Smart App) |
(→Smart App) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 38: | Line 38: | ||
===Smart App=== | ===Smart App=== | ||
| − | The HL7 FHIR team created a [https://hl7.org/fhir/smart-app-launch/ spec for | + | The HL7 FHIR team created a [https://hl7.org/fhir/smart-app-launch/ spec for the smart app.] The [https://hl7.org/fhir/smart-app-launch/app-launch.html Authorization via SMART App Launch] describes how this is based on [[OpenID Connect]]. That copies most of the requirements of the OpenID spec, including a requirement for POSTing to the Authorization Server, which has become an issue as thrid party cookies are blocked by most browsers.<blockquote>The SMART App Launch Framework connects third-party applications to Electronic Health Record data, allowing apps to launch from inside or outside the user interface of an EHR system. The framework supports apps for use by clinicians, patients, and others via a PHR or Patient Portal or any FHIR system where a user can launch an app. It provides a reliable, secure authorization protocol for a variety of app architectures, including apps that run on an end-user’s device as well as apps that run on a secure server.</blockquote> |
| + | |||
| + | Documentation can be found at [https://docs.smarthealthit.org/ this site.] | ||
==References== | ==References== | ||
Latest revision as of 17:53, 25 January 2024
Contents
Full Title or Meme
Best Practice Use Cases in HealthCare
Context
healthcare interoperability has been a great pain point to date with one of the primary barriers being the lack of a true business incentive to compel providers and EHR developers to be “open” with this ever-so-important data. To this end, in recent proposed regulations, federal health leaders have clamped down, perhaps harder than ever before, in their ongoing effort to guide stakeholders to a world in which seamless health data exchange is the norm, rather than a rarity.
Problems
In the absence of a single payer health care network, the US is blessed with a plethora of solutions, but plagued with the resultant lack of interoperability.
Solutions
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.
FHIR, pronounced 'fire' is working on Information Sharing APIs, but has not yet dealt with Federated Trust.
Federated Trust Anchor
- 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.
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 will not be delivered by focusing on Patient's legal rights, but rather focusing on the Patient User Experience.
- For a good example of a User Experience see the wiki page Health Care Native App Example.
Emergency Contact Example
- Kantara sample with first demo of a Emergency Contact Information Use Case
. See an evolving example of this use case at http://controls.azurewebsites.net
Building Solutions
- The wiki page on Health Credentials shows how they can be built.
Smart App
The HL7 FHIR team created a spec for the smart app. The Authorization via SMART App Launch describes how this is based on OpenID Connect. That copies most of the requirements of the OpenID spec, including a requirement for POSTing to the Authorization Server, which has become an issue as thrid party cookies are blocked by most browsers.The SMART App Launch Framework connects third-party applications to Electronic Health Record data, allowing apps to launch from inside or outside the user interface of an EHR system. The framework supports apps for use by clinicians, patients, and others via a PHR or Patient Portal or any FHIR system where a user can launch an app. It provides a reliable, secure authorization protocol for a variety of app architectures, including apps that run on an end-user’s device as well as apps that run on a secure server.
Documentation can be found at this site.
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.
- Healthcare Informatics is an on-line magazine.
- The The Strategic Health Information Exchange Collaborative (SHIEC) is the national collaborative representing health information exchanges (HIEs) and their strategic business and technology partners.
- The College of Healthcare Information Management Executives (CHIME) seems to be pushing back on greater integration in health care.
- 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.
- IDESG health wiki pages.
