Technical Documentation for Laboratories & Testing Facilities

Version: 12.02.20

CommonHealth connects users to their historical healthcare data, gives them complete control of how, when, and with whom to share, and focuses on consent management. The concepts related to taking control over personal data and deciding how and with whom to share those data are highly complex. The best policy and approach will be ineffective if the implementation does not work for all users of the platform. To that end, we are employing a participatory, iterative design process working with diverse groups of patients first to gain a better understanding of patients' conceptual views and beliefs about their health data and how it might be shared, then to design and assess user experiences that support people making informed personal decisions.

To foster innovation, we are inviting other healthcare apps and services in the digital health ecosystem so that we can strengthen our data sharing and privacy protection standards. Our objective is to fully support patient autonomy via personal data rights, level the developer playing field via interoperability standards, and support a vibrant and accountable developer community.  We acknowledge that to do so will require finding a middle ground in the false dichotomy of recklessly sharing all data on one hand and paternalistic data blocking on the other. 

The digital health app ecosystem will be invaluable to our design and development of data and privacy models. As you adopt our common standards, best practices, and code of conduct, we will solicit your input on how CommonHealth can further support your work. Combined with our participatory design process, your feedback will help CommonHealth to design new features and functions so that the app developer community can also benefit from our knowledge-base. 

The Commons Project is a strong believer in open source. The CommonHealth app and the CommonHealth Developer Toolkit are open source and made available according to the Apache 2.0 license. We will release all code for the core functioning of the CommonHealth app, developer tools, and health data interoperability. We may choose to hold back certain in-development code as well as code related to operations such as storage and deployment. We also may rely on certain third-party modules that are not open source. We do not require developers we work with or anyone leveraging our platform or code to be open-source, but we encourage them to do so.

CommonHealth generally follows the CARIN Alliance Code of Conduct, which in summary consists of: Asserting transparency in practice and use of data, not transacting data without explicit, informed consent, minimizing use and disclosure of data, providing individual access to data, using security best practices, maintaining data provenance, being accountable for our actions, taking the opportunity to educate users, and being an advocate for greater availability of standards-compliant health data. 

Connectivity via SMART on FHIR 

CommonHealth and the CommonHealth Data Service that supply CommonPass with test result data are designed to connect to as many data sources as possible. Connecting to these data sources is made scalable by the interoperability achieved through tight conformity to standards. 

In particular, CommonHealth relies on adoption a SMART on FHIR server following the HL7 International Patient Access Profile  (https://build.fhir.org/ig/grahamegrieve/ipa-candidate/) or, in the US, the HL7 Argonaut Implementation Guide (https://argonautwiki.hl7.org/Main_Page) for DSTU2 or the US Core Implementation Guide (http://hl7.org/fhir/us/core/) for R4.

Note that many aspects of these guides go beyond the scope of connecting CommonHealth and CommonPass. The primary implementation requirement centers on implementing the standalone patient profile aspect of a SMART on FHIR server (http://hl7.org/fhir/smart-app-launch/index.html).

Data encoding

When preparing FHIR objects for the patient access request, ensure that test data are encoded using LOINC codes and provisional LOINC codes for SARS-COV-2 (https://loinc.org/sars-cov-2-and-covid-19/).

Additional metadata are required beyond the basic test result. Specifically, append

  • The patient record object, also inclusive of Passport Information.

  • Test manufacturer and test model

  • Testing facility and test administrator

Verifiable Credentials

This implementation will ready your information system for the launch version of CommonPass. Our intent is to add support to CommonHealth and CommonPass for certified test results delivered via WC3 Verifiable Credentials (https://www.w3.org/TR/vc-data-model/). 

Specifically, we are using the SMART Health Cards (https://smarthealthit.org/health-cards/) platform to acquire FHIR data in Verifiable Credentials. Implement the Lab API (https://github.com/smart-on-fhir/health-cards/blob/main/docs/index.md#protocol-details, https://github.com/microsoft-healthcare-madison/health-wallet-demo) to issue certified lab results to CommonHealth and CommonPass.

DiagnosticReport

Each DiagnosticReport resource SHALL have:

  1. a status

  2. a category code of ‘LAB’

  3. a code (preferably a LOINC code) which tells you what is being measured

  4. Patient PII

  5. a time indicating when the measurement was taken

  6. a time indicating when the measurement was reported

  7. who issues the report

  8. references to the lab result Observation resources (either contained or standalone resources)

DSTU2

See here for the Argonaut DiagnosticReport resource definition

R4

See here for the IPA DiagnosticReport resource definition and here for the USCore resource definition.

The main distinction between the DSTU2 and R4 representations is that R4 allows for more than one reference in the performer field. 

Mapping

See the Argonaut DiagnosticReport profile for the basic requirements. Additionally, the following information is required:

  • Semantic property

  • FHIR DiagnosticReport property

  • Patient PII

  • Extension on subject reference. See Subject Info extension definition

  • Report issuer

Must be an Organization reference in the performer property referring to the organization issuing the report. The referenced Organization resource should be contained or the reference should contain the requisite information in an extension on the reference.

Each Observation resource SHALL have:

  1. a status

  2. a category code of ‘laboratory’

  3. a LOINC code which tells you what is being measured

  4. Patient PII (including passport information)

  5. a time indicating when the measurement was taken

  6. a result value and, if the result value is a numeric quantity, a standard UCUM unit

  7. an interpretation

  8. Test manufacturer and test model (and optionally, a unique identifier for the test instance)

  9. Testing facility and test administrator

DSTU2

See here for the Argonaut DiagnosticReport resource definition

R4

See here for the IPA DiagnosticReport resource definition and here for the USCore resource definition.

The main distinction between the DSTU2 and R4 representations is that R4 allows for more than one reference in the performer field. 

Mapping

See the Argonaut Observation Lab Result profile for the basic requirements. Additionally, the following information is required:

  • Semantic property

  • FHIR DiagnosticReport property

  • Patient PII

  • Extension on subject reference. See Subject Info extension definition

  • a time indicating when the measurement was taken

  • dateTime or Period in effective[x]property

  • an interpretation

  • CodeableConcept with binding to Observation Interpretation valueset in interpretation property

  • Test manufacturer and test model (and optionally, a unique identifier for the test instance)

  • CodeableConcept with binding to CommonPass Test Manufacturer / Model coding system (http://commonpass.org/fhir/StructureDefinition/test-manufacturer-model) in the method property. If including a unique test instance identifier, include this as an extension on the CodeableConcept. 

Test facility

Must be an Organization reference in the performer property referring to the organization that administered the test. The referenced Organization resource should be contained or the reference should contain the requisite information in an extension on the reference.

Test administrator

Must be a Practitioner reference in the performer property referring to the person that administered the test. The referenced Organization resource should be contained or the reference should contain the requisite information in an extension on the reference.

To facilitate positive identification of subjects at flight check-in, border crossings, and other key points during travel, we have created a subject info extension that is to be added to DiagnosticReport and Observation resources. This includes information like the subject’s name and passport number and may be extended to include additional fields in the future. An example of this extension can be found on the subject property in this resource. 

The CommonHealth Enterprise Implementation team will work closely with your organization to determine an appropriate launch date for the app. The definition of a launch date is when a user can find and connect to your organization through the CommonHealth app.

This date will be dependent on your organization providing the minimum required information.  A launch is not dependent on optional project tasks such as training and user distribution work.

We will continue to develop CommonHealth with feedback from our developer community. However, we request that you share your crucial feedback with us within thirty (30) days after starting your testing.

Technical Support: developers@commonhealth.org

Business Support: ops@thecommonsproject.org