Instrument, apparatus, machine, equipment, implant, software, hardware, or related component or accessory intended to diagnose, treat, cure, mitigate, or prevent disease, or to affect the structure or function of the body.
Data Element
|
|
Unique Mobile Health Application Identifier (UMHAI)
|
| Submitted By: Gora Datta
/ CAL2CAL
|
| Data Element Information |
| Data Element Description |
This is a unique identifier that uniquely identifies mobile health application instance as installed on a mobile device.
Related data elements would include Application name, App Builder, version, build number, hosting device, unique identifiers [similar to a Vehicle Identification Number (VIN) used to track and identify individual vehicle]. Unique Mobile Health Application Identifier enables identification of application instance to facilitate recall, maintenance, transparency and traceability.
|
| Rationale for Separate Consideration |
Proposed data element UMHAI is similar to UDI but has more complexity and additional details that are not available in UDI.
For example: Host Device where App resides, Device Manufacture, OS Build, ability to support multiple users.
It is recognized that App Store may have their own proprietary mechanism for tracking Application installs. UMHAI standards development process will factor-in these existing methods as HL7 Mobile Health Workgroup develops UMHAI standard.
|
| Use Case Description(s) |
| Use Case Description |
Consumer use of Mobile Health Apps for Health and Fitness Tracking
Mobile Health Apps are used on mobile devices to collect and aggregate Patient Generated Health Data (PGHD). Mobile Health Apps can utilize mobile device components (GPS, accelerometers, audio data, visual data) to improve health and support independent living. Integration with Wearable and Smart Devices facilitate remote monitor and track longitudinal data trends to improve patient health or quality of life.
Prescription of Mobile Health Apps for Care Management
Mobile Health Apps and wearable device are moving toward prescribe healthcare solutions. It is becoming increasing important to understand the context and provenance of the mobile health app and devices used to acquire and manage PGHD/PRO/PRE/SDOH and meta data collected by these apps and devices. Also, for safety and privacy it will be beneficial to track Apps and the context of their deployment to facilitate timely updates and possible recall of defect in implementation and deployment.
Patient Safety and Data Privacy
Safety and Data Privacy concerns are factors driving the need for tracking of Unique Mobile Health Application Identifier (UMHAI), many nations are looking to provide safeguards and guidance to Mobile Health App Developers to ensure patient safety and consumer privacy measures comply to local or national standards. How will Mobile Health App assert conformance? If a defect is discovered in App Build affecting safety or privacy how will the user receive update build or disable App usage?
Data Interoperability Compliance
What standards for data interoperability are support for a given application instance by the mobile health app.
|
| Estimate the breadth of applicability of the use case(s) for this data element
|
As of 2019, there are between 400,000 to 500,000[1] health, wellness and fitness apps that run on smartphones, watches, tablets, and other mobile devices, available for download from platform-specific application stores such as the Apple App Store (iOS) and Google Play (Android). This number has rapidly grown from 325,000 [2] apps in 2017.
[1] https://www.fda.gov/medical-devices/digital-health
[2] https://research2guidance.com/hipaa-gdpr-and-connected-health-interview-with-jovan-stevovic-ceo-of-chino-io/
|
| Link to use case project page |
https://confluence.hl7.org/display/MH/Unique+Mobile+Health+Application+Identifier+%28UMHAI%29+Project |
| Supporting Attachments |
Mobile Health App CA & Certification Guidance Concept Note - Gora Datta.pdf
|
| Healthcare Aims |
- Improving patient experience of care (quality and/or satisfaction)
- Improving the health of populations
- Reducing the cost of care
- Improving provider experience of care
|
| Maturity of Use and Technical Specifications for Data Element |
| Applicable Standard(s) |
N/A |
| Additional Specifications |
N/A |
| Current Use |
Not currently captured or accessed with an organization |
| Extent of exchange
|
N/A |
| Potential Challenges |
| Restrictions on Standardization (e.g. proprietary code) |
This is a green field not many requirement or constraints have been developed at this time. |
| Restrictions on Use (e.g. licensing, user fees) |
It is envisaged that there may be registry fee associated with obtaining an identifier. |
| Privacy and Security Concerns |
Possible unique privacy and/or security concerns must be addressed here. These concerns may invoke existing privacy and security regulations or restrictions such as HIPAA or 42 CFR Part 2. If a new data class/element is not specifically covered by these, this would need to be stated clearly, not assumed to be not applicable. |
| Estimate of Overall Burden |
How hard is it to access and provide the data?
Is it only available in an outside system, such as a lab reporting system?
Does it need to be calculated by the patient or provider, or can it be automatically retrieved or calculated by the system in a production environment?
Does it require significant time on the part of patient or provider to access or record or does it require an interuption in normal workflow to capture?
Does it require significant developer time to implement in EHR systems?
This may be unknown to the submitter and additional information would be needed from industry or may be determined as part of the ONC consideration process.
|
| Other Implementation Challenges |
This can include concepts such as regulatory impact analysis, development burden/cost, cultural barriers, etc. Again, it may not be fully known to the submitter. |
ASTP Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
|
Criterion #1 Maturity - Current Standards |
Level 0
- Data element is not represented by a terminology standard or SDO-balloted technical specification or implementation guide.
|
Criterion #2 Maturity - Current Use
|
Level 0
- Data element is captured, stored, or accessed in limited settings such as a pilot or proof of concept demonstration.
|
Criterion #3 Maturity - Current Exchange |
Level 0
- Data element is electronically exchanged in limited environments, such as connectathons or pilots.
|
Criterion #4 Use Case(s) - Breadth of Applicability |
Level 0
- Use cases apply to a limited number of care settings or specialties, or data element represents a specialization of other, more general data elements.
|
|
Submitted by jiahweing on
Important data element for data safety and privacy
Given the rise of mobile health app development, there is an important need to track if these mobile apps are following proper data safety and privacy measures. Having this data element is important to make sure that the mobile apps can be tracked and followed up longitudinally.