- Uniquely Identifies Mobile Health App Instance as installed on a Mobile "Device" and used by a specific person.
- Potential data elements
- Application name
- App Builder
- build number
- hosting device
- unique identifier(s)
- Unique Device Identifier(s)for a Patient’s Implantable Device(s) - A unique numeric or alphanumeric code that consists of a device identifier (DI) and a production identifier (PI) -FDA approved device
- Does UMHAI change when new data generating devices are added to MH App linkage? Yes
- Need to define MH App State Diagram.
- Single User (keep it simple) - App has a point of access for a single user
- Differentiate but be able to consolidate data from same user using different app versions
- Multiple User/Single device - Single device is used by two or more users
- MH App Prescription is linked to UMHAI Identifier
- Screening Device - Anonymous Subjects need to have UMHAI defined even without subject information.
- Cardiac Screening EKG/ECG
- add Notes from meeting
- Data Retention Policy
- Subject/User Data
- UMHAI ID Authority (Does not exist today)
- ID Authority (Credentials/ Certificate/ App Store)
|Static (one time)||Sporadic Changes (infrequent changes)||Dynamic (frequent changes)||Comment:||UMHAI APIs|
|App Version||Manufacture Provided||Get current UMHAI ID|
|App Category||Needs Ontology for Mobile Health App categories , possibly realm specific|
Linked Devices (Context)?
App may need to be updated when OS Version is updated.
Do we need to know about wearable or smart devices used by the app?
User may not subject/ Clinical Use/ Public Health or Subject for healthcare
Direct/ Indirect Use ( Parent/ Child/ Guardian/ Care Provider/ Custodian)
|Context of use||Context of use|
needs more discussion with use cases for Static or Dynamic
linked devices are supported or not supported
|No PHI||No PHI||User will need some form of authentication (Biometric, Pin)|
UML Deployment Resources: