Submitted by scarini on 2023-03-14
| Submitted By: Gora Datta / CAL2CAL | |
|---|---|
| Data Element Information | |
| 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. |
| Estimated number of stakeholders capturing, accessing using or exchanging | 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/cMHAFF+Project |
| Supporting Attachments |
Mobile Health App CA & Certification Guidance Concept Note - Gora Datta.pdf |
| Healthcare Aims |
|
| 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 |
| Number of organizations/individuals with which this data element has been electronically exchanged | 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. |
Submitted by goradatta on 2023-03-14
Error correction on of the links + new input
Hello: This message is regarding the Comment section Data element: Unique Mobile Health Application Identifier (UMHAI) under Medical Device We have a wrong link for the row: "Link to use case project page". The correct link is: https://confluence.hl7.org/display/MH/Unique+Mobile+Health+Application+Identifier+%28UMHAI%29+Project Kindly replace. In addition, wanted to update that HL7 Mobile Health Workgroup is now developing a new standard called "Unique Mobile Health Application Identifier (UMHAI)". The group meets virtually every Tuesday at 1pm ET.