DRAFT

Request for Proposal

Continua Design Guidelines Implementation Software

Services Interface: FHIR Observation Upload Capability -

Personal Health Gateway

January 2018

This is a DRAFT RFP being circulated solely for the purpose of seeking sponsors to fund the development work described herein.

It is not a solicitation to respond.

This Request for Proposal (RFP) contains proprietary and confidential information of the Personal Connected Health Alliance, which is provided for the sole purpose of permitting the recipient to respond to this RFP.

Version 20180117 DRAFT

Executive Summary

The Personal Connected Health Alliance (PCHAlliance) works collaboratively with health, technology and life sciences, public policy, research and advocacy groups to support a new norm of personal health engagement, positive behavior change and improved wellbeing and health outcomes. The PCHAlliance is working to accelerate commercial adoption of products that employ the Continua Design Guidelines in order to support ubiquitous delivery of Continua device data and patient information into health systems. Proposals are currently being accepted to develop commercial ready source code that implements a part of the Continua Design Guidelines while providing documentation and tools to help expedite regulatory approval. The requirements outlined herein are for a component of an overall system called Continua Open Development Environment (CODE) for Healthcare, and the supplied component(s) must be designed to integrate in a consistent manner with the existing CODE for Healthcare system.

Suppliers planning to bid shall report their intent by 11:59 PM Eastern Time Zone on 15 January 2018. Proposals will be accepted by 11:59 PM Eastern Time Zone 15 April 2018. Proposals will be held in confidence by PCHAlliance Officers and Staff on a need-to-know basis. Procurement is expected to begin no later than the third quarter of calendar year 2018.

The CODE for Healthcare project operates under a Project Quality Plan that is based off requirements specified in the Quality Management System designed in accordance with the IEC 62304 specification. All software that is to be developed shall be developed in accordance with this Project Quality Plan.

The goal of the project is to accelerate commercial adoption of products that employ the Continua Interfaces by developing and providing commercial ready source code that implements the Continua Design Guidelines. The architecture employed strikes an effective balance between a turn-key system and software components that can be used in other systems. Personal Health Gateway software shall run on both Android and iOS devices.

The primary deliverable of this project is source code, along with the associated build, validation, and regulatory artifacts, that when used can create software services for the current commercial release of both the iOS and Android platforms. Key functionality includes IEEE 11073 mapping to a FHIR data model, supporting capability exchange, OAuth service and FHIR-based observation uploads. Tests shall be created for the existing CODE for Healthcare testing framework.

The payment schedule is based on 50% of the total cost being invoiced over the expected duration of the project, and the balance being invoiced upon final acceptance of the deliverables. The supplier shall submit a fixed price contract that covers all costs of delivering products and services as defined in this RFP. All software developed and delivered shall be compliant with FreeBSD open source software license.

PCHA Confidential 1 DRAFT

Table of Contents 1 Project Overview ...... 1 2 Administration ...... 1 3 Quality System Requirements ...... 3 4 Technical Requirements ...... 4

4.1 Continua Architecture Overview ...... 4

4.2 Commercial Ready Software Architecture Overview ...... 5

4.3 PHG architecture guiding principles ...... 5

4.4 PHG architecture overview ...... 7

4.5 Goals and Deliverables for this Project ...... 8

4.6 Software Requirements ...... 10 5 Management Requirements ...... 10 6 Supplier Qualifications ...... 11 7 Suppliers’ Section ...... 11 8 Contracts and Licenses ...... 12 9 Appendices ...... 12

9.1 Acronyms & Abbreviations ...... 12

PCHA Confidential 1 DRAFT

1 Project Overview

The Personal Connected Health Alliance (PCHAlliance) works collaboratively with health, technology and life sciences, public policy, research and advocacy groups to support a new norm of personal health engagement, positive behavior change and improved wellbeing and health outcomes. The PCHAlliance is focused on driving the agenda, creating an evidence base and mobilizing collective action to achieve personal connected health for all. For more information, please visit http://www.pchalliance.org/.

The PCHAlliance publishes and promotes the global adoption of the Continua Design Guidelines, the only secure end-to-end ICT framework for personal connected health and care using open standards, to create a secure and interoperable health data exchange in personal connected health. The CDG provide a set of clearly defined interfaces that enable the secure flow of medical data among sensors, gateways, and end services, removing ambiguity in underlying standards to ensure a consistent and interoperable ecosystem of personal connected health devices. To enable reliable interoperability it also contains additional implementation guidelines that further clarify these standards and specifications by reducing options in the underlying standard or specification or by adding a feature missing in the underlying standard or specification.

The PCHAlliance is working to accelerate commercial adoption of products that employ the Continua interfaces in order to support ubiquitous delivery of Continua device data into health systems. Proposals are currently being accepted to develop commercial ready source code that implements the Continua Design Guidelines while providing documentation and tools to help expedite regulatory approvals. This Request for Proposal (RFP) will be used to solicit written proposals from various candidate organizations to develop and deliver specific functional blocks of source code software per the qualifications and requirements defined herein.

2 Administration

Proposals will be accepted on or before 11:59 PM Eastern Time Zone 15 April 2018. Procurement is expected to begin no later than the third quarter of calendar year 2018. Failure to comply these requirements may be grounds for disqualification. Instructions are mandatory requirements and should be treated as such.

Suppliers planning to bid shall report their intent by 11:59 PM on 15 January 2018 Eastern Time Zone.

All proposals submitted shall conform to the following format requirements. A transmittal letter signed by a person authorized to engage your company in a contract shall accompany your proposal.

PCHA Confidential 1 DRAFT Volume 1: Technical Proposal • Section 1: Cover letter or letter of transmittal • Section 2: Proposal executive summary • Section 3: Response to Administrative Requirements • Section 4: Response to Quality System Requirements • Section 5: Response to Technical Requirements • Section 6: Response to Test Requirements • Section 7: Response to Management Requirements • Section 8: Response to Supplier Qualifications • Appendix A: Additional supporting information

Volume 2: Price Proposal • Section 1: Pricing Response • Section 2: Contract

The PCHAlliance is interested in obtaining a complete solution to the stated requirements. Proposals will be evaluated using a number of factors as described below.

Technical Solution – Primary consideration will be given to meeting the mandatory functional requirements listed in this RFP. Key factors include: • Fulfillment of requirements stated in this RFP. • Demonstrated understanding of the work to be performed. • Technical approach to accomplish the work. • Completeness and competence in addressing the scope of work.

Project Management – Key factors include: • Completeness and responsiveness of project management plans and project team • Demonstration of adequate experience in developing, commercializing, and supporting similar products • Proposals containing detailed project plan that demonstrates understanding of the project.

Cost – will be used as a final indicator for determining award when all other criteria have been normalized.

All questions and submissions will be directed to: Thomas Erickson Michael Kirwan Director, Technical Operations Vice President, Continua Personal Connected Health Alliance Personal Connected Health Alliance 33 West Monroe St. Suite 1700 33 West Monroe St. Suite 1700 Chicago, IL 60603 Chicago, IL 60603

Email: [email protected] [email protected]

Responses to all questions will be held and periodically released to all bidders. The supplier submitting the question will not be disclosed.

PCHA Confidential 2 DRAFT 3 Quality System Requirements

The CODE for Healthcare project operates under a Project Quality Plan that can be found here: (https://lnijira.atlassian.net/wiki/spaces/CFH/pages/202082/Project+Quality+Plan)

The project quality plan is itself based off requirements specified in the Quality Management System of a contracted project maintainer, which, in turn, has been designed in accordance with the IEC 62304 specification.

All software that is to be developed shall be developed in accordance with the Project Quality Plan. The resulting documentation shall be integrated with the existing documentation which is maintained under Atlassian’s Confluence and can be found here: (https://lnijira.atlassian.net/wiki/spaces/CFH/overview).

The core elements of the Project Quality Project Plan require that:

• All customer specifications shall be identified and validated by the customer • All requirements are managed and tracked, such that: o The source of the requirement is identified o The resulting test that validates proper implementation of the requirement is documented, and that documentation specifically identifies each requirement that is validated. o The requirement is associated with a JIRA epic or story which must be implemented (or waiver accepted). o The test implementation that validates the requirement and its associated development history is tracked in JIRA o The implemented tests that validates the requirement is integrated into the continuous build system o Test results have links back to the test documents describing their implementations, which identify the exact requirements validated. o Note: Units tests may not be required to have the associated documentation if there are not specifically identified requirements above the detailed software design level. • Risk assessments are made relative to patient safety and health with associated mitigations (which may include additional requirements for the software that are then tracked) • Software of unknown pedigree (SOUP) is properly managed • High level design and architecture documents are maintained and updated including associated testing requirements

The following software tooling is used in CODE for Healthcare and the winner of this project must be able to integrate with this tooling. If the CODE for Healthcare tools are not used during development, documentation must be provided that explains how the new material will be integrated and still meet the underlying requirements of the Quality System Plan.

• Source Code Control System - Git (Git repositories are maintained in Bitbucket) • Software Development – Agile workflow process – JIRA

PCHA Confidential 3 DRAFT • Issue Tracking – JIRA • Regulatory documentation management system – Confluence • Continuous Integration Server - Jenkins

4 Technical Requirements

The goal of the project is to accelerate commercial adoption of products that employ the Continua Interfaces through development of commercial ready source code that implements the Continua Design Guidelines.

The following sections offer an overview of the Continua end-to-end architecture followed by the envisioned overall architecture of the commercial ready source code. Software developed in response to this proposal should be compatible with the Personal Health Gateway (PHG) software architecture concepts outlined in sections 4.3 and 4.4 below. 4.1 Continua Architecture Overview

Figure 4-1 The Continua end-to-end architecture

The Personal Health Device (PHD) Interface communicates IEEE 11073 data from a sensor to a Personal Health Gateway (PHG). The IEEE 11073 family of standards ensures that the user of the data knows exactly what was measured where and how, and that this critical information is not lost as it is transported from the sensor, to the gateway, and ultimately to the electronic health record system.

The Services Interface provides for uploading device observations, exchange of questionnaires and responses, consent management, capabilities exchange, and authenticated persistent session over a wide area network between the PHG and the Health & Fitness Server (HFS).

The Health Information System (HIS) Interface provides for the electronic exchange of health records between the HFS and the Health Information System (HIS).

PCHA Confidential 4 DRAFT For more detailed description of these interfaces, read “Fundamentals of Data Exchange” available at http://www.pchalliance.org/sites/pchalliance/files/ctools/Fundamentals_Data_Exchange_20171001.pdf. 4.2 Commercial Ready Software Architecture Overview

Figure 4-2 Scope of the commercial ready source code

The primary objectives of the CODE for Healthcare project are twofold:

• Provide software capabilities that implement specific functions defined in the Continua Design Guidelines in the form of extractable, portable modules that can be easily integrated into development projects that require this functionality. In particular, the modules provide the interfaces developers of applications for PHG and HFS systems are expected to need, as illustrated on Figure 4-2 • Provide complete operational systems that could be extended and customized to quickly bring a Continua Design Guidelines compliant PHG, or HFS to market.

The primary objective of this RFP is to provide the customer specifications for the component of functionality needed in the Personal Health Gateway that uploads a device observation in accordance with H.812.5 (H.812.5 FHIR Observation Upload Continua Design Guidelines Trial Implementation). In the figure above the software provided will implement a subset of the yellow PHG box and its green padlock, and the RPF response for the software component will be evaluated with respect to how it will fit into the architecture outlined below – which is still in development – in order to align with other components anticipated in the future. 4.3 PHG Architecture Guiding Principles

The customer specifications contained herein describe a component of a PHG. The responder to this RFP is not being asked to provide a complete PHG solution, only the component that translates the arriving sensor measurement into FHIR resources, and uploads the FHIR resources to the HFS. The overall PHG solution, and hence the requested component need to be “commercial-ready”. For the FHIR upload component of the PHG commercial-ready implies that the protocol translation process must function correctly in the many special case conditions that arise with different sensors. Thus the responder to the RFP should outline

PCHA Confidential 5 DRAFT how that validation process is going to take place, and account for development work that may be needed to generate the input conditions that validation will require.

In addition to proper protocol operation, the term commercial-ready requires that:

• The response to this proposal clearly addresses as many regulatory demands in the best way practically possible for an untargeted (the specific application use case is not known) software component that is intended to be used in medical devices – see clause on Quality Systems Requirements and IEC 62304 for additional guidance. • The response to this proposal clearly addresses how the component will fit into the anticipated architecture which is expected to incorporate the following concepts: o Self-contained modules that communicate in the context of a micro services framework. o Isolation from a specific communications bus architecture o Operation on cell phone hardware platforms running either iOS or Android. o Independence (or clear isolation) from OS specific services. o Language portability between iOS/Android (support builds in XCODE or Android Studio) o Minimal number of languages and associated dependencies. • The component is robust in terms of failed communications; not losing or duplicating messages • The component can be audited, or have clear mechanisms that support auditing. Here auditing implies the ability to identify and know the outcome of all messages such that message loss or duplication could be traced to root cause.

4.3.1 Self Contained Modules

The PHG library is comprised of modules independently developed and maintained. Modules only interact with other modules through well-defined (and versioned) interfaces. Changes to one module only affect the applications that use this particular module, and can be safely ignored by all other applications (using other modules from the library).

4.3.2 Micro Services Framework

APIs are based on message passing, based on the availability of a common message bus. This architectural style resembles a micro-service architecture with a lightweight message bus for resource constrained platforms (may not use http), optimized for intra-process communication (between modules of a single or a few processes).

4.3.3 Portability / Low Platform Dependence

The hardware technology underlying cell phone platforms is rapidly changing (resulting in short product lifespans), so the software components on the PHG should be isolated from hardware dependencies.

The envisioned PHG architecture is expected to support hardware independence by a platform abstraction layer (PAL) that will expose platform-specific services in a generalized manner. The bidder should include in the RFP response appropriate interface(s) that the FHIR

PCHA Confidential 6 DRAFT component will need from the PAL layer with respect to underlying OS services. For validation purposes, the software component to be provided should provide stub logic for the proposed PAL interfaces as these will not be available.

The provided software component must not depend on the use of external cross-platform application frameworks (such as Cordova, Qt, Xamarin). The application developer must be free to choose such a framework.

4.3.4 Loose Coupling / Single Responsibility Principle

Functionality is broken down into reusable modules according to the Single Responsibility Principle, which states that a software module should have one and only one reason to change. (https://8thlight.com/blog/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html)

4.3.5 Minimal Number of Languages and Dependencies

Languages that can be compiled by GCC and a commonly available LLVM frontend are acceptable. The recommended approach is to use one language; one that can be compiled for both the Android and iOS platforms. The reason for having this recommendation is, that for each new language added to the software component, standard libraries and compiler runtime libraries for that language are also added to the code-base as SOUP, which the application developer will have to deal with when the PHG library is used in a (software as) medical device.

There is a trade-off between the utility and time savings associated with external libraries, and their management as SOUP. The responder to the RFP should identify the external libraries that will be involved, and seek to optimize the proposed solution such that the number of external libraries is minimized while keeping the overall scope of work reasonable.

Libraries and dependencies used for platform-independent modules must be available on all chosen platforms. Open source libraries compatible with FreeBSD open source software license shall be used. 4.4 PHG Architecture Overview

Modules located in the platform abstraction layer (boxes on blue background in Figure 4-3) are implemented once for each platform they are used on, and they all have a platform- specific responsibility – e.g. adapting to Android’s Bluetooth stack, or sending and receiving text messages on iOS.

The platform-independent modules (boxes on yellow background) are implemented once, and must work on all platforms.

The green coloured elements in the figure represent the functionality that the winning bidder is to provide in terms of its architecture. The figure is not intended to constrain actual detailed software design relative to the number of components within the proposed solution.

The white boxes represent functionality expected to be provided by the underlying platform, or by future work.

PCHA Confidential 7 DRAFT Micro services Framework

Capability Exchange

FHIR Observation Upload Component

HTTP client

Message API Message API Message API Platform Device Abstraction OAuth PHG Persistent Observation Network Services Layer (PAL) Services (stub) Store (stub) Source (stub)

Platform’s Native APIs and 3rd party library APIs

Figure 4-3 PHG architecture overview. The green elements represent the architectural components to be provided for this RFP 4.5 Goals and Deliverables for this Project

The goal of this project will be to develop commercial ready software source code to implement the FHIR Observation Upload capability for the Personal Health Gateway as defined in the H.812.5 FHIR Observation Upload Trial Implementation Continua Design Guidelines.

The primary deliverable of this project is source code, along with the associated build, validation, and regulatory artifacts. The provided artifacts shall include sufficient validation infrastructure that the claimed functionality can be validated by a third party. At a minimum the validation infrastructure, in conjunction with the existing CODE for Healthcare system, will be able to simulate observations from a Weight Scale, a Blood Pressure Cuff, and a Blood Glucometer that can be uploaded to the CODE for Healthcare FHIR Observation Server without error.

4.5.1 IEEE 11073 Mapping and Data Model Requirements

The most technically significant part of this work is the development of a representational model for the IEEE 11073 information that will be delivered either via Bluetooth Low Energy or by ISO/IEEE 11073-20601. This representational model will be used in the interface to the FHIR Observation Upload Component as well as in other Upload components that will map it to other representations. The representation must be able to properly handle all the IEEE

PCHA Confidential 8 DRAFT 11073 structures defined in ISO/IEEE 11073-20601 and the associated device specializations supported by Continua.

Although not technically an IEEE 11073-20601 mapping, the representation must be able to handle patient information, as well as provide for proper communication of time and time synchronization as outlined is H.812.1.

4.5.2 Capability Exchange

The implementation shall provide an API that accepts a URL pointing to a Continua Capability Exchange endpoint, and other appropriate information. The implementation shall be able to process the root.xml file, and download the OAuthResource in accordance with H.812.3 and H.812.5. Based on this information the implementation shall only attempt to authorize using the OAuth mechanisms supported by the OAuth authorization server, and shall optimize its upload based on the Continua Certified Capability Class the HFS supports. The implementation may ignore other services in the root.xml that it is not aware of.

4.5.3 OAuth Requirements

The responder to this RFP shall document a proposed interface to an OAuth service that shall enable it to obtain the information required to perform the observation upload. The FHIR Observation Upload Service is not required to perform OAuth negotiation.

For testing purposes, it may be necessary for an OAuth stub to be put in place that will be able to authorize with the CODE for Healthcare HFS. If this is required the responder must provide this as part of the testing infrastructure.

4.5.4 FHIR Observation Upload Requirements

The implementation that results from this work, shall be compliant with the FHIR Observation Client as defined in H.812.5, and further, shall be able to communicate with either a FHIR Observation Server or a FHIR Observation Reporting Server. The RFP response shall include a proposed approach as to how it will upload an observation to a FHIR Observation Server in an optimal way. It should also address how it will handle and filter duplicate observations.

4.5.5 Messaging Requirements

The micro service communication framework will not be in place for this work. Hence the RFP responder shall use TCP/IP as the bus protocol. An abstraction layer shall be provided above the socket calls that will allow the TCP/IP interface to be replaced by a TBD message exchange mechanism. The messaging system can assume static assignment of modules and does not have to manage a registration process.

4.5.6 Test Framework

Tests shall be created for the existing CODE for Healthcare testing framework and be documented as required by the Quality System Plan. All requirement tracking and regulatory documentation associated with the tests shall be integrated appropriately into Confluence in a

PCHA Confidential 9 DRAFT manner analogous to what exists for the HFS. Tests must be setup to run under Jenkins, and be able to report results in a manner consistent with other tests. 4.6 Software Requirements

The Personal Health Gateway Services Interface FHIR Observation Upload shall utilize a micro services inspired architecture employing self-contained modules, common message bus, portability / low platform dependence, loose coupling / single responsibilities principles, and minimum number of languages and dependencies as outlined in sections 4.3 – 4.4 above. The objective is to use a language and environment allowing for write-once-run-everywhere to the maximum extent practical. International standards shall be used for communication and content formats. GUI functionality is outside the scope of this RFP.

The PHG Services Interface shall support the FHIR Observation Reporting Client and the FHIR Observation Client Capability Classes as specified in “Section 9.2 Requirements Common to both PHG FHIR Capability Classes” of the “H.812.5 FHIR Observation Upload Continua Design Guidelines Trial Implementation”.

The PHG Services Interface shall also support the FHIR Observation Client Capability Class as specified in “Section 9.5 Requirements Specific to the FHIR Observation Client” of the “H.812.5 FHIR Observation Upload Continua Design Guidelines Trial Implementation”.

The PHG Services Interface shall also support the FHIR Observation Reporting Client Capability Class as specified in “Section 9.6 Requirements Specific to the FHIR Observation Reporting Client” of the “H.812.5 FHIR Observation Upload Continua Design Guidelines Trial Implementation”.

5 Management Requirements

Commercially available project planning tools shall be used to itemize, track, and manage major tasks, responsibilities, and schedules. Each task shall include a start and stop date, estimated number of hours required to complete the task, and a person responsible for completing the task. There shall be an agreed upon mechanism to demonstrate completion of the task (e.g. testing, analysis, review). Task dependencies shall be clearly noted.

The proposed management structure shall be described and key personnel assigned to the project identified (and resumes provided). Primary and secondary very responsive points of contact will be identified.

Release notes shall be provided highlighting the features of the delivered source code and where to access software elements / services.

The supplier shall include user and developer documentation. The user documentation shall include system requirements and guide the downloading, installation, and use of the software. The developer documentation shall enable a clear understanding of the functional elements of the source code to facilitate evolution of the source code in an open source software project environment.

PCHA Confidential 10 DRAFT Upon availability of the initial deliverable (beta), the PCHAlliance may elect to perform internal testing and submit a punch list to the supplier for resolution. This list must be provided within 60 days of receipt of acceptance testing report from the supplier. The supplier will resolve issues identified in the punch list without additional charges.

6 Supplier Qualifications

The supplier will provide an overview of their firm including a brief history of experience demonstrating the necessary qualifications to perform the work outlined in this RFP. In particular, the supplier should demonstrate evidence of having the technical skills, financial resources, relevant product experience (list of current products), and names of customers who can provide references. Any subcontracting relationships shall be listed in the proposal.

7 Suppliers’ Section

The supplier is invited and encouraged to provide any additional information in succinct fashion that may be helpful in differentiating themselves from other bidders.

PCHA Confidential 11 DRAFT 8 Contracts and Licenses

The supplier shall submit a fixed price contract that covers all costs of delivering products and services as defined in the RFP. Contract shall structure payment as follows:

The payment schedule is based on 50% of the total cost being invoiced over the expected duration of the project, and the balance being invoiced upon availability of initial (beta) and final (gold) deliverables. The final deliverable shall include resolution of punch list items from the initial deliverable and shall be 10% of the total project cost. Payment Trigger for Invoice Amount Notes #1 PO received by supplier US$ #2 Project start plus 4 weeks #3 Project start plus 8 weeks #N Availability of initial deliverable (beta) #N+1 Availability of final deliverable (gold)

All software developed and delivered shall be compliant with FreeBSD open source software license. 9 Appendices 9.1 Acronyms & Abbreviations API Application Programming Interface BSD Berkley Software Distribution CDA Clinical Document Architecture CDG Continua Design Guidelines FHIR Fast Healthcare Interoperable Resources HFS Health & Fitness Server HIS Health Information System HL7 Health Level 7 International IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IHE Integrating the Healthcare Enterprise ISO International Organization for Standardization MQTT Message Queue Telemetry Transport PC Personal Computer PCD Patient Care Device PCHAlliance Personal Connected Health Alliance PHD Personal Health Device PHG Personal Health Gateway PO Purchase Order QFD Questionnaire Form Definition QRD Questionnaire Response Document REST Representational State Transfer RFP Request for Proposal SOUP Software Of Unknown Pedigree UI User Interface URL Uniform Resource Locator

PCHA Confidential 12