Mobile Health Work Group
Point of Contact Name and Email:
Project Lead: Christopher Doss ()
URL to download document:
http://wiki.hl7.org/index.php?title=MHWG_Projects_FHIRframe
Project Name and ID
FHIRframe Open LibraryAPI Specification / Project ID:
TSC Notification Informative/DSTU to Normative Date :
1. Sponsoring Group(s) / Project Team
Click here to go to Appendix A for more information regarding this section.
Primary Sponsor/Work Group (1 Mandatory) / Mobile Health Work GroupCo-Sponsor Work Group(s) / None
Co-Sponsor Group Approval Date / N/A
Indicate the level of involvement that the co-sponsor will have for this project:
Request formal content review prior to ballot
Request periodic project updates. Specify period:
Other Involvement. Specify details here:
Project Team:
Project facilitator (1 Mandatory) / Christopher Doss (; Mohd Anwar (); Paul Petronelli () Gora Datta ()
Other interested parties and their roles
Multi-disciplinary project team (recommended)
Software architect / Paul Petronelli ()
Modeling facilitator
Publishing facilitator / Harry Rhodes ()
Vocabulary facilitator
Domain expert rep / Nathan Botts ()
Business requirement analyst / Igor Yuabov ()
Conformance facilitator (for IG projects)
Other facilitators (SOA, etc) / Hans Anderson ()
Implementers (2 Mandatory for DSTU projects)
FHIR Project Note: The implementer requirement will be handled by the “balloting” project. Therefore work groups do not fill out the above section. However, feel free to list implementers specific to your work group’s resources if you know of any.
1) North Carolina A&T State University
2) PALM Associates, Inc.
3) CAL2CAL Corporation
4) Health e-Services LLC
2. Project Definition
2.a. Project Scope
Click here to go to Appendix A for more information regarding this section and FHIR project instructions.
FHIRframe Open API SpecificationThe short term objective for phase 1 will be to produce the following deliverables:
A. Survey of the current state of the art in frameworks and API families dealing with exchange of healthcare information. This survey will concentrate on understanding the lessons learned from recent interoperability demonstrations, the impact of mobile devices on the usability of these frameworks and the critical data elements to be exchanged. Security and privacy issues will be itemized for use in later phases of this project. A FHIRframe whitepaper will be prepared and made available on the HL7 Mobile Health Wiki (including the surveyed information).
B. High level specification of a family of APIs which can be effectively used for implementing interfaces between mobile devices as well as healthcare repositories. Security and privacy impacts and requirements will be identified. A short report will be prepared for peer-comments and the resulting specification will be posted on the HL7 Mobile Health Wiki.
· Implementation of a subset of the mobile API family for a proof of concept demonstration. A subset will be selected and incorporated into a mobile device. A proof of concept demonstrating interoperability between mobile devices and Healthcare Repositories will be carried out. A short report will be prepared and posted to the HL7 Mobile Healthcare Wiki.
The phase 2 objective is to develop a set of standardized Application Programming Interface (API) libraries, validated through companion Software Development Kits (SDKs), which would facilitate the implementation of platform agnostic mobile health applications that leverage HL7 FHIR (Fast Healthcare Interoperability Resources) standards.
These APIs will provide platform-independent, real-time, standardized means to:
1. access health information using a gamut of mobile devices,
2. facilitate the use of diverse mobile devices as an aggregator for transmitting health information from different medical devices to Electronic Health Record repositories,
3. share health information across applications and devices.
Validation:
The class librariesAPI specification will be validated to ensure created that support for a variety of mobile/portable platforms, including iOS, Android, .NET, and Arduino. These class libraries will containThis validation will be based on the APIs thatability to: ease the incorporation of FHIR resources into their corresponding application interfaces; facilitate interaction with EHR systems; manage workflows and use cases set forth by IHE. The FHIRframe SDK will ease the development of mHealth applications by providing sample reusable code and documentation.
The primary focus of these libraries will be to promote interoperability and allow interfacing to mobile devices through the use of FHIR. This interoperability approach differs from that used in the SMART Platform in the following ways:
1. FHIRframe will be catered to developing native applications on mobile devices, while SMART is catered towards developing web applications
2. FHIRframe will be catered to allowing the capture of data from medical devices, while SMART is catered towards accessing data within various EHRs.
3. FHIRframe will incorporate methods for enforcing various workflows for submitting data to an EHR, while SMART does not (currently) allow for submission of data.
These contrasts could allow FHIRframe and SMART to be utilized in a complementary manner.
2.b. Project Need
Click here to go to Appendix A for more information regarding this section and FHIR project instructions.
There is a need for APIs that provide a platform-independent, real-time, standardized means to:4. access health information using a gamut of mobile devices,
5. facilitate the use of diverse mobile devices as an aggregator for transmitting health information from different medical devices to Electronic Health Record repositories,
6. share health information across applications and devices.
The past few years have witnessed a proliferation of mobile and portable devices with increased computing capabilities. These devices range from smartphones and tablets to smart devices such as the Kinect and Google Glass. Medical devices have also benefited from these advances, often supporting wireless connectivity to smart devices. Thus, they facilitate the development of mHealth applications.
However, these applications are not designed with interoperability in mind. For example, nutrition applications are not necessarily designed to be interoperable with an app that reads from a glucose meter. Apps that keep track of your exercise routine are not interoperable with apps that read from a blood pressure monitor. A further drawback is that although these various devices allow for constant monitoring of vital signs, their corresponding apps are not designed with Meaningful Use in mind.
Figure 1 FHIRframe Architecture
Figure 1 shows the architecture of the proposed API LibrarySpecification. This architecture consists of several layers. The device translation layer will consist of software APIs for interfacing between various medical devices and mobile platforms. The IHE domain workflow layer will contain software APIs that ensures IHE standardized workflows are followed, while also accommodating future and/or null workflows. The enterprise translation layer will consist of software APIs that interfaces to EHRs. The security layer will provide software APIs that ensures secure transmissions. In addition, each layer may have multiple sublayers.
Figure 2 FHIRframe Operational Context
Figure 2 shows the operational context of FHIRframe. As can be seen in the diagram, FHIRframe facilitates interactions between mobile health devices and electronic health record systems.
There are numerous business benefits to the FHIRframe approach. The most immediate benefit is guaranteed interoperability. This will allow for faster and lower cost development of applications. Also, there is a reduced cost for adoption, since much of the APIs will be tested to meet IHE and HL7 standards. Meaningful Use Stages 3 and beyond will likely incorporate the use of mHealth devices. This SDK API will allow for faster implementation of MU, allowing quick transfer of information and the ability for decision-making from the various data sources.
2.c. Success Criteria
Click here to go to Appendix A for more information regarding this section and FHIR project instructions.
Phase 1 of tThis project will be considered successful by the delivery of:1. Survey of state of APIs and frameworks in use today
2. Specifications of Mobile Library API Classes
3. Proof of concept implementation of a subset of classesDelivery of report used to validate the API.
Phase 2 of this project will be considered successful with the delivery of a working prototype which will be developed to demonstrate:
1. Usability, robustness, and effectiveness of the APIs for facilitating cross-platform transactions of health information.
2. Usefulness of SDKs (with reusable code, automated building tools, and documentation) in easily creating cross-platform mHealth applications.
3. The creation of the specifications for a library of APIs, an SDK, and associated documentation, as well as their utilization in the development of mobile health applications.
2.d. Project Risks
Click here to go to Appendix A for more information regarding this section.
Risk Description: / The HL7 FHIR project may change significantly during the early implementation stages.Impact: / Critical / Serious / Significant / Low
Likelihood: / High / Med / Low
Risk Type: / Requirements / Resources / Social-Political / Technology
Risk To HL7: / Internal to HL7 / External to HL7
Mitigation Plan: / Close monitoring of the HL7 FHIR project is necessary to provide early notification of changes which may affect the mobile framework definitions. API definitions will be crafted to be extensible in order to accommodate a moving end target.
2.e. Security Risks
Click here to go to Appendix A for more information regarding this section.
Will this project produce executable(s), for example, schemas, transforms, stylesheets, executable program, etc. If so the project must review and document security risks. / Yes / No / Unknown2.f. External Drivers
Click here to go to Appendix A for more information regarding this section.
None2.g. Project Objectives / Deliverables / Target Dates
Within each row, enter the explicit work product(s) / objective(s). Indicate their target date at the right in WGM/Ballot Cycle format. Include the project end date as the last objective (for standards projects, the end date will be the projected ANSI approval date).Click here for further information, FHIR project instructions, and an EXAMPLE / Target Date (in WGM or ballot cycle format, e.g.
‘2010 Sept WGM’ or
‘2010 Jan Ballot’)
FHIRframe Whitepaper / 2015 October WGM
Submit for Comment Only Ballot / 2016 May WGM
Submit FHIRframe API Specification for DSTU Ballot #1 (First Ballot Cycle) / 2017 Jan WGM
Project End Date (all objectives have been met) / 2017 May WGM
2.h. Common Names / Keywords / Aliases
Click here to go to Appendix A for more information regarding this section.
SDK: software development kitAPI: application programmer’s interface
2.i. Lineage
Click here to go to Appendix A for more information regarding this section.
None2.j. Project Requirements
Click here to go to Appendix A for more information regarding this section.
http://wiki.hl7.org/index.php?title=MHWG_Projects_FHIRframe,2.k. Project Dependencies
Click here to go to Appendix A for more information regarding this section.
http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?ref=commonhttp://wiki.hl7.org/index.php?title=MHWG_Projects_FHIRframe,
2.l. Project Document Repository Location
Click here to go to Appendix A for more information regarding this section.
http://wiki.hl7.org/index.php?title=MHWG_Projects_FHIRframe,2.m. Backwards Compatibility
Are the items being produced by this project backward compatible? / Yes / No / Unknown / N/AFor V3, are you using the current data types?
(Refer to TSC position statement on new projects using R2B for more information on the current V3 data types) / Yes / No
If you check 'No' please explain the reason:
2.n. External Vocabularies
Will this project include/reference external vocabularies? / Yes / No / Unknown / N/AIf yes, please list the vocabularies:
3. Products
Click here to go to Appendix A for more information regarding this section
Non Product Project- (Educ. Marketing, Elec. Services, etc.)/ V3 Domain Information Model (DIM / DMIM)
Arden Syntax
/ V3 Documents – Administrative (e.g. SPL)
Clinical Context Object Workgroup (CCOW)
/ V3 Documents – Clinical (e.g. CDA)
Domain Analysis Model (DAM)
/ V3 Documents - Knowledge
Electronic Health Record (EHR) Functional Profile
/ V3 Foundation – RIM
Logical Model
/ V3 Foundation – Vocab Domains & Value Sets
V2 Messages – Administrative
/ V3 Messages - Administrative
V2 Messages - Clinical
/ V3 Messages - Clinical
V2 Messages - Departmental
/ V3 Messages - Departmental
V2 Messages – Infrastructure
/ V3 Messages - Infrastructure
FHIR Resources
/ V3 Rules - GELLO
FHIR Profiles
/ V3 Services – Java Services (ITS Work Group)
New/Modified/HL7 Policy/Procedure/Process
/ V3 Services – Web Services (SOA)
New Product Definition
New Product Family
Implementation tool for mobile health application development.
4. Project Intent (check all that apply)
Click here to go to Appendix A for more information regarding this section and FHIR project instructions.
Create new standardRevise current standard (see text box below)
Reaffirmation of a standard
New/Modified HL7 Policy/Procedure/Process
Withdraw an Informative Document
N/A (Project not directly related to an HL7 Standard)
/ Supplement to a current standard
Implementation Guide (IG) will be created/modified
Project is adopting/endorsing an externally developed IG: Specify external organization in Sec. 6 below;
Externally developed IG is to be (select one):
Adopted - OR - / Endorsed
4.a. Ballot Type (check all that apply)
Click here to go to Appendix A for more information regarding this section and FHIR project instructions.
Comment OnlyInformative
DSTU to Normative
/ Normative (no DSTU)
Joint Ballot (with other SDOs or HL7 Work Groups)
N/A (project won’t go through ballot)
4.b. Joint Copyright
Click here to go to Appendix A for more information regarding this section
Check this box if you will be pursuing a joint copyright. Note that when this box is checked, a Joint Copyright Letter of Agreement must be submitted to the TSC in order for the PSS to receive TSC approval.