View source for Health Care Native App Example

==Full Title==
Best Practice example of a [[Native App]]lication 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<ref> 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</ref> sponsored a collaboration with the Rand corporation and reported this conclusion about an '''opportunity for a Patient-empowered solution''':<blockquote>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.</blockquote>

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

===HL7 FHIR Smart Application===
*A [https://hl7.org/fhir/smart-app-launch/index.html SMART App Launch Frame] is in development within the HL7 FHIR standardization group. That document describes four use cases which are here annotated.
{| class="wikitable"
|-
| Patient Apps || launch standalone|| [[Native App]] || This example
|-
| Patient Apps || launch from a portal || [[Progressive Web App]]
|-
| Provider apps || launch standalone|| [[Native App]]
|-
| Provider apps || launch from a portal|| [[Progressive Web App]]
|}

==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:
# 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.
# The CARIN Alliance has published a code of ethics for health care information that moves beyond the control of HIPAA covered entities.
# The [[Smart_Phone#Smart_Phone_role_in_Authentication|role of Smart Phones in Authentication]] has been expanding (see that wiki page for specific examples.) See section below on Patient Rights.
# Microsoft has just introduced<ref>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/</ref> 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.
**  ([https://krebsonsecurity.com/2021/03/can-we-stop-pretending-sms-is-secure-now/ SMS is easy to hijack] and should not be used for security purposes.)

*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/
* [https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Forange.hosting.lsoft.com%2Ftrk%2Fclick%3Fref%3Dznwrbbrs9_6-2be2bx32c520x081583%26&data=04%7C01%7C%7C1b0cfc8a7db9484bb50308d946e0a1e9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637618752869025374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PaRyaYQadjyHbH5wP%2FruYlnD0B5rftISxc8a9dfAJeQ%3D&reserved=0 WHO Releases AI Guidelines for Health Government Technology] 2021-07-12 <blockquote>A new report from the World Health Organization (WHO) offers guidance for the ethical use of artificial intelligence (AI) in the health sector. The six primary principles for the use of AI as set forth in the report are to protect autonomy; promote human well-being, safety, and the public interest; ensure transparency, explainability, and intelligibility; foster responsibility and accountability; ensure inclusiveness and equity; and promote responsive and sustainable AI. These principles are intended as a foundation for AI stakeholders, including governments, developers, and society. The report, Ethics and Governance of Artificial Intelligence for Health, finds public- and private-sector collaboration necessary to ensure AI’s accountability.<blockquote>

===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 [[User Tracking|tracking]] medications or other health plan conformance.

===Threat Models===
Organizations should develop system threat models for mobile devices and the resources that are accessed through the mobile devices. Selections that apply to [[Smart Phone]]s in the hands of patients from the [https://csrc.nist.rip/library/alt-SP800-124r1.pdf NIST Guidelines for Managing the Security of Mobile Devices in the Enterprise]
<blockquote>Mobile devices often need additional protection because their nature generally places them at higher exposure to threats than other client devices (for example, desktop and laptop devices only used within the organization’s facilities and on the organization’s networks). Before designing and deploying mobile device solutions, organizations should develop system threat models. Threat modeling helps organizations
to identify security requirements and to design the mobile device solution to incorporate the controls needed to meet the security requirements. Threat modeling involves identifying resources of interest and  the feasible threats, vulnerabilities, and security controls related to these resources, then quantifying the likelihood of successful attacks and their impacts, and finally analyzing this information to determine where security controls need to be improved or added.</blockquote>

And these additional recommendations from that report:
#User and device authentication: requiring device authentication and/or other authentication before accessing organization resources, resetting forgotten passwords remotely, automatically locking idle devices, and remotely locking devices suspected of being left unlocked in an unsecured location.
#Applications: restricting which app stores may be used and which applications may be installed, restricting the permissions assigned to each application, installing and updating applications, restricting the use of synchronization services and verifying digital signatures on applications.
Additional recommendations on limiting distribution of apps can be handeled by only allowing apps that are controlled by the licensing capabilities of the manufactures' app stores.

===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

===Compatibility with FHIR Smart App===
The FHIR specs are part of an overall FHIR ecosystem. This app is designed, first and foremost, to be of assistance to the patient or guardian and so will offer other services, like [[Authentication]], which might require some additional standardization to be broadly useful.
*FHIR published a [http://hl7.org/fhir/smart-app-launch/index.html SMART App Launch Framework] which includes some details described below that will be tracked as best as possible given that the patient experience will always take precedence.
*App launch is not fully determined at this point but will likely have several entry points. If launched from a FHIR EHR session it will set up the "launch session" via a redirect to:
 https://[app launch uri]?launch=[number]&iss=https://[fhir base url]
*When the app decides to get FHIR data it will first ask for metadata on the server to be used for the "launched instance":
 GET https://[base url]/metadata
 or alternately will use the <link data to get the information> if present.
*It is not completely clear what will be returned, but the only thing of interest is the "name" of the server.
*The first time the app communicates with the server it will use the metadata "name" to acquire trust information 
*The app will then seek to get authorization to access the data, which may require an [[OpenID Connect]] [[Authentication]] step first.
*The "launch" ID will be generated by a FHIR server if it is the first to initiate the session. Otherwise the app will create a sid or Session ID.

===Protected Data Store===

*There are a variety of data stores associated with a native app. This store contains the user personal information that binds the user to the various [[Web Site]]s where the user has an account and is not for any [[PHI]]. Note that the private key is NOT stored in the data store, but in the [[Trusted Execution Environment]] where it can be used for signing, but is not exposed to the [[Native App]].
*Microsoft [https://docs.microsoft.com/en-us/dotnet/standard/io/types-of-isolation types of isolation] for UWP apps.

===Deployed Apps===
There are a [https://apps.smarthealthit.org/apps/featured/page/2 fair number of apps deployed] that support [[FHIR]] formatted data on smart phones, nearly 50 at the end of 2023. Usage data is not available, but assumed to be low accept for the case of Smart Health Cards (SHC:) which includes wallet apps like Apple and the LA state driver's license app. There was a spurt of support during the COVID pandemic as evidence for vaccination peaked and then died out.

==Details of Implementation==
*Code for the [[Health Care Native App Example]] is written is Xamarin Forms using C# and XAML.
* [https://xamarinhelp.com/entity-framework-core-xamarin-forms/ Install NuGet package] for [https://www.nuget.org/packages/Microsoft.EntityFrameworkCore.Sqlite/ Microsoft.EntityFrameworkCore.Sqlite] in every package of the solution. Click [https://www.youtube.com/watch?v=cZ1PmKeIzL4 here for a good podcast on installing SQLite.]
*The SDK is [https://docs.microsoft.com/en-us/dotnet/api/?view=netstandard-2.0 NETSTANDARD 2.0] which works on Windows UWP, Google Android and Apple iOS.
*The Crypto is [https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsa?view=netstandard-2.0 RSA class] using the [https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsacryptoserviceprovider?view=netstandard-2.0 RSACryptoServiceProvider]. There is an issue setting the key size as described [https://github.com/dotnet/corefx/issues/12388 here] for keys other than the default 1024.

==Next Steps==
#Create pilot test code for validation of ideas with all participants in a live setting.
#Test APIs for getting data (like [[Blue Button]])
#Start a directed pilot test with a specific health care provider to get real-world feedback.
#Test APIs for transmitting data to [[EHR]]s.
#Look at value add features, like tracking patient conformance with drug or other treatment options.

==References==
<references />
===Other References===
*[https://www.hl7.org/fhir/http.html#capabilities MetaData] or capabilities from FHIR - might not survive till next versions.
*The [https://nhisac.org/ 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.
*[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 IDEF health wiki pages.]

[[Category:Profile]]
[[Category:User Experience]]
[[Category:Best Practice]]
[[Category: Health]]