Skip to end of metadata
Go to start of metadata




1a. Project Name

Application Data Exchange Assessment Framework and Functional Requirements for Mobile Health

1b. Project ID

1599

1c. Is Your Project an Investigative Project (aka PSS-Lite)?

No

1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU?

No

1e. Today's Date

1f. Name of standard being reaffirmed

1g. Project Artifact Information

1h. ISO/IEC Standard to Adopt

1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption?

1j. Unit of Measure

2a. Primary/Sponsor WG

Mobile Health

2b. Co-Sponsor WG

Electronic Health Record

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2c. Co-Sponsor Update Periods

Review prior to publication and at WGMs

2b. Co-Sponsor WG 2

Orders & Observations

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2c. Co-Sponsor 2 Update Periods

Review prior to publication and at WGMs

2b. Co-Sponsor WG 3

Clinical Information Modeling Initiative

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballotRequest periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2d. Project Facilitator

Christina Caraballo

2e. Other Interested Parties (and roles)

US Office of the National Coordinator for Health IT
US National Institutes of Health, All of Us Research Project
Open mHealth

2f. Modeling Facilitator

Keith Boone

2g. Publishing Facilitator

Keith Boone

2h. Vocabulary Facilitator

2i. Domain Expert Representative

Nathan Botts

2j. Business Requirements Analyst

2k. Conformance Facilitator

Keith Boone

2l. Other Facilitators

2m. Implementers

Reliant Medical
Open mHealth
Audacious Inquiry
Health eServices

3a. Project Scope

The scope of this project is to develop the assessment framework and functional requirements for consumer medical devices and applications required to support the exchange of observations and other data in support of consumer health monitoring. We will focus ensuring that devices, apps and infrastructure can support reporting of vital signs (height, weight, blood pressure, O2 saturation, respiration and heart rate), and physical activity based on requirements of implementation guidelines and specifications from HL7 and other sources.

The scope of this project is Universal even though current leadership of the project is US based. We have had participation in project efforts from individuals in the US, Europe and Asia, and who serve markets internationally. We welcome greater international participation in this project.

This project will produce a FHIR Implementation Guide containing:
1. A framework for assessing conformance to the function requirements. (Normative)
2. Functional requirements for Mobile Health Devices and Apps and Supporting infrastructure exchanging health data. (Normative)
3. FHIR resource constraints necessary to support functional requirements in this guide. (Informative)

Out of scope items include:
* Non-functional requirements are covered in other specifications (e.g., CMHAFF) and will referenced by this document but are otherwise out of scope.
* Development of new profiles for the purposes of exchange for the above mentioned content. The profiles included in this guide will be for the purposes of automation of assessments, not for the purposes of exchange.

Attachments

3b. Project Need

Mobile health devices and apps provide their own APIs and methods for collecting device data that can be communicated to EHR, PHR and research endpoints. Much of this data can (and has been) readily converted to FHIR resources.
However, some limits have been encountered which demonstrate that essential data needed to generate, interpret and use the FHIR resources is sometimes missing.

The purpose of this project is to develop functional requirements and a framework that can be used to assess mobile health devices, apps and FHIR profiles to ensure that the essential data needed for clinical, patient and research uses is present in communications between applications.

3c. Security Risk

No

3d. External Drivers

All of Us Research program

3e. Objectives/Deliverables and Target Dates

Initial Ballot May 2020
Additional Ballot September 2020

3f. Common Names / Keywords / Aliases:

mHealth ADE Assessment Framework

3g. Lineage

mHealth App Data Exchange investigative project

3h. Project Dependencies

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/MH/Mobile+Health+App+Data+Exchange+Project

3j. Backwards Compatibility

No

3k. Additional Backwards Compatibility Information (if applicable)

3l. Using Current V3 Data Types?

N/A

3l. Reason for not using current V3 data types?

3m. External Vocabularies

Yes

3n. List of Vocabularies

LOINC
SNOMED CT
IEEE 11073

3o. Earliest prior release and/or version to which the compatibility applies

4a. Products

FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

4c. FHIR Profiles Version

R4

4d. Please define your New Product Definition

4d. Please define your New Product Family

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. White Paper Type

5a. Is the project adopting/endorsing an externally developed IG?

No

5a. Externally developed IG is to be (select one)

5a. Specify external organization

5a. Revising Current Standard Info

5b. Project Ballot Type

STU to Normative

5c. Additional Ballot Info

There are compatibility concerns, given that this specification could be used to assess existing FHIR and other implementation guides (e.g., US Core, Healthcare Devices FHIR IG specifications). However, these concerns are not material to the development of this guide.

5d. Joint Copyright

No

5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval.

no

6a. External Project Collaboration

Open mHealth
IHE Mobile Health App Workgroup

6b. Content Already Developed

5-10%

6c. Content externally developed?

No

6d. List Developers of Externally Developed Content

6e. Is this a hosted (externally funded) project?

No

6f. Stakeholders

Regulatory Agency, Standards Development Organizations (SDOs)

6f. Other Stakeholders

6g. Vendors

EHR, PHR, Equipment, Health Care IT

6g. Other Vendors

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6h. Other Providers

6i. Realm

Universal

7d. US Realm Approval Date

7a. Management Group(s) to Review PSS

FHIR

7b. Sponsoring WG Approval Date

Dec 20, 2019

7c. Co-Sponsor Approval Date

Dec 17, 2019

7c. Co-Sponsor 2 Approval Date

7c. Co-Sponsor 3 Approval Date

7c. Co-Sponsor 4 Approval Date

7c. Co-Sponsor 5 Approval Date

7c. Co-Sponsor 6 Approval Date

7c. Co-Sponsor 7 Approval Date

7c. Co-Sponsor 8 Approval Date

7c. Co-Sponsor 9 Approval Date

7c. Co-Sponsor 10 Approval Date

7e. CDA MG Approval Date

7f. FMG Approval Date

Jan 22, 2020

7g. V2 MG Approval Date

7h. Architecture Review Board Approval Date

7i. Steering Division Approval Date

Mar 08, 2020

7j. TSC Approval Date

Mar 16, 2020


























5 Comments

  1. Shouldn't there be some Privacy and Security by design as well as Provenance components to this project?

    1. Those belong in a specification that addresses non-functional requirements, like cMHaff, which the draft guide refers readers to, and are not addressed other than as preconditions or assumptions in a functional requirements specification.  So essentially, you are requesting that something be put into scope that has specifically been stated as being out of scope for this PSS.  

  2. Added O&O and CIMI as possible cosponsors and reached out to workgroups for discussion.

    Clarified that FHIR Profiles in the guide are to be Informative, not Normative.  They exist for the purposes of automating assessments of IGs or outputs of apps, infrastructure, et cetera, not for other reasons (e.g., exchange).

  3. Hi Keith - where does the PSS state that functional capabilities supporting adherence to privacy and security policies is out of scope?  Certainly aren't out of scope for other HL7 Functional Models.  Seems to me that assessing IGs our Apps should include assessment of privacy, security, and provenance capabilities.

    1. Added to clarify: Non-functional requirements are covered in other specifications (e.g., CMHAFF) and will referenced by this document but are otherwise out of scope.