1c. Is Your Project an Investigative Project (aka PSS-Lite)?
Yes
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
Modeling & Methodology
2d. Project Facilitator
Keith Boone
2e. Other Interested Parties (and roles)
US Office of the National Coordinator for Health IT (AllOfUs Health IT standards research sponsor)
US National Institutes of Health, All of Us Research Project
Open mHealth
Audacious Inquiry
2f. Modeling Facilitator
2g. Publishing Facilitator
2h. Vocabulary Facilitator
2i. Domain Expert Representative
2j. Business Requirements Analyst
2k. Conformance Facilitator
2l. Other Facilitators
2m. Implementers
3a. Project Scope
The initial scope of this project is to analyze variation in FHIR data exchanged from mobile health apps and devices for personal health information. Because mobile health apps and devices can convey a wide variety of data including hundreds of different kinds of measurements, this project will first look at a limited scope of data, including vital signs, physical activity, sleep and blood sugar.
These data elements are readily accessible in many mobile health apps and devices. Similar data is often used during treatment of disease affecting cardiovascular, cereberovascular, lower respiratory, and endocryne systems. These diseases are five of the top ten leading causes of death in the US (https://www.cdc.gov/nchs/fastats/leading-causes-of-death.htm) and four out of ten in the world (https://ourworldindata.org/causes-of-death). Thus, they are high priority items to address in this project.
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.
There are multiple pathways to obtain personal health data from mobile apps and devices in FHIR. Some of these pathways are shown in the attached Powerpoint diagram and include:
* Proprietary API to FHIR Conversion (via cloud, mobile platform, or direct to device APIs).
* Proprietary to FHIR Conversion via an Intermediate Format (e.g., Open mHealth)
* Direct output in FHIR from a Device Gateway
* Exchange to EHR w/ Output in FHIR generated from an EHR
Each of these pathways can introduce variation due to the encoding of sematic codes describing the measurement, or variations in the way that units are expressed, or in the precision of data exchanged.
Because of the increasing use of personal health devices to augment care, this is of concern because it can introduce variation in personal health data that may be used for diagnosis, treatment and research.
The goal of this project is to determine the degree of semantic and precision variation in these pathways and determine what steps are needed to address this challenge to enable healthcare providers to use personal health device data for diagnosis, treatment and research.
3c. Security Risk
3d. External Drivers
3e. Objectives/Deliverables and Target Dates
1. Promote a FHIR Connectathon track (see https://confluence.hl7.org/display/FHIR/2019-09+Mobile+Health+Data+Exchange) to compare variations in pathways for getting FHIR Data. September and possibly January WGM.
2. Analyze variation and develop a plan to address sources of variation. Such a plan might include development of functional requirements or an implementation guide, but those details are not yet determined.
3. Implement action plan.
3k. Additional Backwards Compatibility Information (if applicable)
3l. Using Current V3 Data Types?
3l. Reason for not using current V3 data types?
3m. External Vocabularies
3n. List of Vocabularies
3o. Earliest prior release and/or version to which the compatibility applies
4a. Products
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
4c. FHIR Profiles Version
4d. Please define your New Product Definition
4d. Please define your New Product Family
5a. Project Intent
5a. White Paper Type
5a. Is the project adopting/endorsing an externally developed IG?
5a. Externally developed IG is to be (select one)
5a. Specify external organization
5a. Revising Current Standard Info
5b. Project Ballot Type
5c. Additional Ballot Info
5d. Joint Copyright
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
6b. Content Already Developed
6c. Content externally developed?
6d. List Developers of Externally Developed Content
6e. Is this a hosted (externally funded) project?
6f. Stakeholders
6f. Other Stakeholders
6g. Vendors
6g. Other Vendors
6h. Providers
6h. Other Providers
6i. Realm
Universal
7d. US Realm Approval Date
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Aug 02, 2019
7c. Co-Sponsor Approval Date
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
Aug 14, 2019
7g. V2 MG Approval Date
7h. Architecture Review Board Approval Date
7i. Steering Division Approval Date
Sep 16, 2019
7j. TSC Approval Date
Show Changes
Version
3
Modifier
Keith W. Boone
Modify Date
Nov 01, 2019 18:20
1a. Project Name
Mobile Health App Data Exchange
1b. Project ID
1551
1c. Is Your Project an Investigative Project (aka PSS-Lite)?
Yes
1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?
No
2a. Primary/Sponsor WG
Modeling & Methodology
2d. Project Facilitator
Keith Boone
2e. Other Interested Parties (and roles)
US Office of the National Coordinator for Health IT (AllOfUs Health IT standards research sponsor)
US National Institutes of Health, All of Us Research Project
Open mHealth
Audacious Inquiry
3a. Project Scope
The initial scope of this project is to analyze variation in FHIR data exchanged from mobile health apps and devices for personal health information. Because mobile health apps and devices can convey a wide variety of data including hundreds of different kinds of measurements, this project will first look at a limited scope of data, including vital signs, physical activity, sleep and blood sugar.
These data elements are readily accessible in many mobile health apps and devices. Similar data is often used during treatment of disease affecting cardiovascular, cereberovascular, lower respiratory, and endocryne systems. These diseases are five of the top ten leading causes of death in the US (https://www.cdc.gov/nchs/fastats/leading-causes-of-death.htm) and four out of ten in the world (https://ourworldindata.org/causes-of-death). Thus, they are high priority items to address in this project.
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.
There are multiple pathways to obtain personal health data from mobile apps and devices in FHIR. Some of these pathways are shown in the attached Powerpoint diagram and include:
* Proprietary API to FHIR Conversion (via cloud, mobile platform, or direct to device APIs).
* Proprietary to FHIR Conversion via an Intermediate Format (e.g., Open mHealth)
* Direct output in FHIR from a Device Gateway
* Exchange to EHR w/ Output in FHIR generated from an EHR
Each of these pathways can introduce variation due to the encoding of sematic codes describing the measurement, or variations in the way that units are expressed, or in the precision of data exchanged.
Because of the increasing use of personal health devices to augment care, this is of concern because it can introduce variation in personal health data that may be used for diagnosis, treatment and research.
The goal of this project is to determine the degree of semantic and precision variation in these pathways and determine what steps are needed to address this challenge to enable healthcare providers to use personal health device data for diagnosis, treatment and research.
3e. Objectives/Deliverables and Target Dates
1. Promote a FHIR Connectathon track (see https://confluence.hl7.org/display/FHIR/2019-09+Mobile+Health+Data+Exchange) to compare variations in pathways for getting FHIR Data. September and possibly January WGM.
2. Analyze variation and develop a plan to address sources of variation. Such a plan might include development of functional requirements or an implementation guide, but those details are not yet determined.
3. Implement action plan.
1c. Is Your Project an Investigative Project (aka PSS-Lite)?
Yes
1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?
No
2a. Primary/Sponsor WG
Modeling & Methodology
2d. Project Facilitator
Keith Boone
2e. Other Interested Parties (and roles)
US Office of the National Coordinator for Health IT (AllOfUs Health IT standards research sponsor)
US National Institutes of Health, All of Us Research Project
Open mHealth
Audacious Inquiry
3a. Project Scope
The initial scope of this project is to analyze variation in FHIR data exchanged from mobile health apps and devices for personal health information. Because mobile health apps and devices can convey a wide variety of data including hundreds of different kinds of measurements, this project will first look at a limited scope of data, including vital signs, physical activity, sleep and blood sugar.
These data elements are readily accessible in many mobile health apps and devices. Similar data is often used during treatment of disease affecting cardiovascular, cereberovascular, lower respiratory, and endocryne systems. These diseases are five of the top ten leading causes of death in the US (https://www.cdc.gov/nchs/fastats/leading-causes-of-death.htm) and four out of ten in the world (https://ourworldindata.org/causes-of-death). Thus, they are high priority items to address in this project.
There are multiple pathways to obtain personal health data from mobile apps and devices in FHIR. Some of these pathways are shown in the attached Powerpoint diagram and include:
* Proprietary API to FHIR Conversion (via cloud, mobile platform, or direct to device APIs).
* Proprietary to FHIR Conversion via an Intermediate Format (e.g., Open mHealth)
* Direct output in FHIR from a Device Gateway
* Exchange to EHR w/ Output in FHIR generated from an EHR
Each of these pathways can introduce variation due to the encoding of sematic codes describing the measurement, or variations in the way that units are expressed, or in the precision of data exchanged.
Because of the increasing use of personal health devices to augment care, this is of concern because it can introduce variation in personal health data that may be used for diagnosis, treatment and research.
The goal of this project is to determine the degree of semantic and precision variation in these pathways and determine what steps are needed to address this challenge to enable healthcare providers to use personal health device data for diagnosis, treatment and research.
3e. Objectives/Deliverables and Target Dates
1. Promote a FHIR Connectathon track (see https://confluence.hl7.org/display/FHIR/2019-09+Mobile+Health+Data+Exchange) to compare variations in pathways for getting FHIR Data. September and possibly January WGM.
2. Analyze variation and develop a plan to address sources of variation. Such a plan might include development of functional requirements or an implementation guide, but those details are not yet determined.
3. Implement action plan.
1c. Is Your Project an Investigative Project (aka PSS-Lite)?
Yes
1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?
No
2a. Primary/Sponsor WG
Modeling & Methodology
2d. Project Facilitator
Keith Boone
2e. Other Interested Parties (and roles)
US Office of the National Coordinator for Health IT (AllOfUs Health IT standards research sponsor)
US National Institutes of Health, All of Us Research Project
Open mHealth
Audacious Inquiry
3a. Project Scope
The initial scope of this project is to analyze variation in FHIR data exchanged from mobile health apps and devices for personal health information. Because mobile health apps and devices can convey a wide variety of data including hundreds of different kinds of measurements, this project will first look at a limited scope of data, including vital signs, physical activity, sleep and blood sugar.
These data elements are readily accessible in many mobile health apps and devices. Similar data is often used during treatment of disease affecting cardiovascular, cereberovascular, lower respiratory, and endocryne systems. These diseases are five of the top ten leading causes of death in the US (https://www.cdc.gov/nchs/fastats/leading-causes-of-death.htm) and four out of ten in the world (https://ourworldindata.org/causes-of-death). Thus, they are high priority items to address in this project.
There are multiple pathways to obtain personal health data from mobile apps and devices in FHIR. Some of these pathways are shown in the attached Powerpoint diagram and include:
* Proprietary API to FHIR Conversion (via cloud, mobile platform, or direct to device APIs).
* Proprietary to FHIR Conversion via an Intermediate Format (e.g., Open mHealth)
* Direct output in FHIR from a Device Gateway
* Exchange to EHR w/ Output in FHIR generated from an EHR
Each of these pathways can introduce variation due to the encoding of sematic codes describing the measurement, or variations in the way that units are expressed, or in the precision of data exchanged.
Because of the increasing use of personal health devices to augment care, this is of concern because it can introduce variation in personal health data that may be used for diagnosis, treatment and research.
The goal of this project is to determine the degree of semantic and precision variation in these pathways and determine what steps are needed to address this challenge to enable healthcare providers to use personal health device data for diagnosis, treatment and research.
3e. Objectives/Deliverables and Target Dates
1. Promote a FHIR Connectathon track (see https://confluence.hl7.org/display/FHIR/2019-09+Mobile+Health+Data+Exchange) to compare variations in pathways for getting FHIR Data. September and possibly January WGM.
2. Analyze variation and develop a plan to address sources of variation. Such a plan might include development of functional requirements or an implementation guide, but those details are not yet determined.
3. Implement action plan.
Keith W. Boone Hi Keith! Initial review of this PSS revealed the following:
I updated the sponsor to be Mobile Health. The PSS had Learning Health Systems listed. My apologies if that was the intention.
Section 3.i: Please add a link to the HL7-managed project document repository
This must be reviewed by the FHIR Management Group. I can add to their next call on 2019-08-14 at 4pm Eastern. It is preferred that a representative of the project attend the call to answer any questions. Please let me know who can attend and I will send a calendar invite.
Following FMG approval, the PSS should be sent to the Infrastructure Steering Division for approval.
Keith W. BooneRob McClure Greetings! Before I can send this to TSC, it still needs a link to an HL7-managed project document repository in section 3.i. Once we've got that, I can send it for approval. Thank you!
8 Comments
Anne Wizauer
Keith W. Boone Hi Keith! Initial review of this PSS revealed the following:
Rob McClure
Anne Wizauer
Keith W. Boone Rob McClure Greetings! Before I can send this to TSC, it still needs a link to an HL7-managed project document repository in section 3.i. Once we've got that, I can send it for approval. Thank you!
Nathan Botts
I've added a link to the repository in 3i now.
Paul Knapp
Anne Wizauer Looks like this is ready for TSC.
Ulrike Merrick
https://confluence.hl7.org/download/attachments/55939942/DataFunnel.pptx?version=1&modificationDate=1563362788913&api=v2 - link gets file not found message
Nathan Botts
I just tried the link you posted, Ulrike and it worked for me. Maybe try again?
Ulrike Merrick
thanks - it worked this time