Difference between revisions of "Best Practice in HealthCare"

From MgmtWiki
Jump to: navigation, search
(→‎References)
(→‎Smart App)
 
(19 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
−
Best Practice
+
Best Practice Use Cases in HealthCare
  
 
==Context==
 
==Context==
Line 9: Line 9:
  
 
==Solutions==
 
==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]] [[API]]s, but has not yet dealt with [[Federated Trust]].
 
[[FHIR]], pronounced 'fire' is working on [[Information Sharing]] [[API]]s, 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 [https://wiki.idesg.org/wiki/index.php/Emergency_Contact_Information_Use_Case 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 [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==
Line 16: Line 47:
 
*The [https://strategichie.com/ The Strategic Health Information Exchange Collaborative (SHIEC)] is the national collaborative representing health information exchanges (HIEs) and their strategic business and technology partners.
 
*The [https://strategichie.com/ The Strategic Health Information Exchange Collaborative (SHIEC)] is the national collaborative representing health information exchanges (HIEs) and their strategic business and technology partners.
 
*The [https://chimecentral.org/ College of Healthcare Information Management Executives (CHIME)] seems to be pushing back on greater integration in health care.
 
*The [https://chimecentral.org/ College of Healthcare Information Management Executives (CHIME)] seems to be pushing back on greater integration in health care.
−
*[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf#nameddest=3_19_Authenticate_Node__ITI_19_ Authenticate Node] section 19 of (2018-07-24) IHE IT Infrastructure Technical Framework  
+
*[http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf#nameddest=3_19_Authenticate_Node__ITI_19_ 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.
 +
*[https://wiki.idesg.org/wiki/index.php/Category:Health IDESG health wiki pages.]
  
 
[[Category:User Experience]]
 
[[Category:User Experience]]
 
[[Category:Best Practice]]
 
[[Category:Best Practice]]
 +
[[Category:Health]]

Latest revision as of 17:53, 25 January 2024

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

Emergency Contact Example

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

Building Solutions

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

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Best_Practice_in_HealthCare&oldid=19699"