FHIR© Implementation Guide - DRAFT

Point of Care Diagnostics FHIR IG
- CI Build

Point of Care Diagnostics FHIR IG - Local Development build.

Detailed Specification

Introduction

The specification is outlined using specific interactions between the various point of care diagnostics systems. After the explanation of the interactions, protocols and payloads with examples, the conformance requirements for each of the systems is outlined. The specific interactions between the point of care diagnostic systems are

  • Registration and Discovery
  • Measurement Order Placement
  • Receiving Measurement Result

Registration and Discovery

Registration and Discovery process is used for each Subjective or Objective Measurement System to:

  • Identify the specific measurement that it can perform. (For example, measurement of oxygen saturation, glucose test, diagnostic questionnaire for Hepatitis)
  • Identify the specific results that will be sent back from the measurement

Protocols and Data Elements

For Phase 1, the registration process is manual and hence no specific communication protocol is prescribed. However the following minimum data is registered as part of the process.

Data Element Purpose Other Notes
Intent Information. Intent information is required for communication between MGD App and the Measurement App. Intent Information will include:
action
type (Mime Type)
component (Unique Name)
category (Launcher)
data (hl7.org.fhir.bundle)
extras
Test Detail Test Detail will specify the typee of subjective, objective measurement performed by the application. For Laboratory Tests, LOINC codes will be used.
For Vital Signs, LOINC codes will be used.
For Diagnosis, SNOMED-CT codes will be used.

Future: FHIR Resources and Profiles

For Phase 1, until the IG is piloted and the required FHIR resources mature, the registration and discovery process will be done manually. For future phases the following FHIR Resources and profiles will be used for registration and discovery.

FHIR Resource/Maturity Purpose Extensions
CatalogEntry/0 CatalogEntry will be used to declare the compendium of tests that are supported by a measurement system. For example, a specific device may support measurement of Oxygen saturation, Blood Pressure, HbA1C etc. None
ObservationDefintion/0 ObservationDefinition will be used to specify the meta data about the observation such as valid ranges, units, interpretation detail. None

Vocabulary (CodeSystems and ValueSets)

The following are the vocabulary and value set requirements for registration and discovery.

Data Element Vocabulary Specific ValueSet
Laboratory Test Name LOINC Laboratory Test Codes
Diagnosis Test Name SNOMED-CT Condition Codes

Examples of Registration

In Phase 1 of the project, registration is handled manually out of band and hence there are no specific examples.


Measurement Ordering

Measurement ordering process is used to initiate the measurement for a specific lab test, vital sign or an assessment. The diagram below shows the overall interaction of how the order is placed.


Figure 4: Measurement Ordering Interaction Diagram

Protocols and Data Elements

As shown in the above diagram, the ordering protocol used is "Intent" based app to app communication.

Data Element Purpose Other Notes
Intent extras. Communicates the FHIR Based Bundle containing Patient, Encounter and ServiceRequest profiles. Specifically following profiles will be used:
US Core Patient
US Core Encounter
New Service Request Profile

FHIR Resources and Profiles

The following are the FHIR resources and profiles that will be used for implementing the interaction.

FHIR Resource Purpose Extensions
Patient US Core Patient None
Encounter US Core Encounter None

Vocabulary (CodeSystems and ValueSets)

The following are the vocabulary and value set requirements for registration and discovery.

Data Element Vocabulary Specific ValueSet
ServiceRequest.code LOINC
SNOMED-CT
Laboratory Test Codes
Condition Codes

Examples of Orders

The following are examples of Order Payloads using FHIR per the specification. Add Link to Example.


Result Receiving

Result Receiving process is used to return the result from a specific objective or subjective measurement system. The diagram below shows the overall interaction of how the result is received.


Figure 5: Measurement Result Receiving Interaction Diagram

Protocols and Data Elements

As shown in the above diagram, the ordering protocol used is "Intent" based app to app communication.

Data Element Purpose Other Notes
Intent extras. Communicates the FHIR Based Bundle containing Patient, Encounter, Observation, Vital Signs, Condition, Medication Request profiles. Specifically following profiles will be used:
US Core Patient
US Core Encounter
US Core Lab Results profile
US Core Vital Signs profile
US Core Condition
US Core Medication Request

FHIR Resources and Profiles

The following are the FHIR resources and profiles that will be used for implementing the interaction.

FHIR Resource Purpose Extensions
Patient US Core Patient None
Encounter US Core Encounter None
Observation US Core Lab Results profile
None
Observation US Core Vital Signs profile
None
Condition US Core Condition profile
None
MedicationRequest US Core Medication Request profile
None

Vocabulary (CodeSystems and ValueSets)

The following are the vocabulary and value set requirements for registration and discovery.

Data Element Vocabulary Specific ValueSet
Observation.code LOINC
Laboratory Test Codes
Observation.value UCUM
None
Condition.value SNOMED-CT
US Core Condition Codes
MedicationRequest.medicationCodeableConcept RxNorm
US Core Medication Codes

Examples of Results

The following are examples of Result Payloads using FHIR per the specification. Add Link to Example.


Security Protocols

For Intent Based communication currently no security protocols are used as the applications are on the same mobile device and are assumed to be communicating with each other using standard mobile device protocols authorized by the user.
For FHIR API Based communication: In Phase 1 of the project, there are no specific FHIR APIs being used and hence there are no specific requirements for FHIR APIs. The FHIR payload will carry the necessary metadata about the actors, times and patients involved which SHALL be logged by the mobile apps interacting with each other.

Conformance Requirements

Conformance Requirements for MGD Mobile App

The following are conformance requirements for the MGD Mobile App

  • Registration:
  • The MGD Mobile App SHALL support registration of other mobile apps using Explicit Intents
  • The MGD Mobile App SHALL support registration of mobile apps supporting Laboratory Tests using LOINC codes
  • The MGD Mobile App SHALL support registration of mobile apps supporting Vital Sign Measurements using LOINC codes
  • The MGD Mobile App SHALL support registration of mobile apps supporting Subjective Assessment Tests using SNOMED-CT codes
  • The MGD Mobile App SHALL support registration of mobile apps supporting Subjective Assessment Tests using Test Names without any codes

  • Measurement Initiation:
  • The MGD Mobile App SHALL display all the supported tests to Healthcare workser
  • The MGD Mobile App SHALL support selection of supported tests by a Healthcare worker
  • The MGD Mobile App SHALL create a FHIR ServiceRequest when a subjective or objective measurement is initiated.
  • When a measurement is initiated, The MGD Mobile App SHALL create a FHIR Bundle payload containing Patient, Encounter and ServiceRequest.
  • The MGD Mobile App SHALL invoke the registered mobile app for a specific test using Intent and passing the FHIR Bundle payload.

  • Result Collection:
  • The MGD Mobile App SHALL respond to an Intent invocation from registered mobile apps passing results.
  • The MGD Mobile App SHALL receive a FHIR Bundle containing Patient, Encounter, Observation, Condition, MedicationRequest data from a subjective or objective measurement system.
  • The MGD Mobile App SHALL validate the received FHIR Bundle.
  • The MGD Mobile App SHOULD display the results received to the Healthcare Worker and the Patient.
  • The MGD Mobile App SHOULD submit the collected data to the MGD Cloud platform.

Conformance Requirements for Objective Measurement System

The following are conformance requirements for an Objective Measurement System

  • Registration:
  • The Objective Measurement System SHALL register an explicit Intent with the MGD Mobile App
  • The Objective Measurement System SHALL register laboratory objective tests with the MGD Mobile App using LOINC codes.
  • The Objective Measurement System SHALL register vital sign objective tests with the MGD Mobile App using LOINC codes.

  • Measurement Initiation:
  • The Objective Measurement System SHALL respond to an Intent invocation from MGD Mobile App.
  • The Objective Measurement System SHALL support Bluetooth protocols to collect data from external devices.
  • The Objective Measurement System SHALL process a FHIR Bundle containing Patient, Encounter and ServiceRequest for the objective measurement.
  • The Objective Measurement System SHOULD validate the FHIR Bundle according to the IG profiles.

  • Result Delivery:
  • The Objective Measurement System SHALL invoke an Intent corresponding to the Gats MGD Mobile App to deliver results.
  • The Objective Measurement System SHALL create a FHIR Bundle containing Patient, Encounter, Observation, data for the specific test initiated.
  • The Objective Measurement System MAY display the results received to the Healthcare Worker and the Patient.

Conformance Requirements for Subjective Measurement System

The following are conformance requirements for an Objective Measurement System

  • Registration:
  • The Subjective Measurement System SHALL register an explicit Intent with the MGD Mobile App
  • The Subjective Measurement System SHALL register subejctive tests/assessments with the MGD Mobile App using SNOMED-CT codes.

  • Measurement Initiation:
  • The Subjective Measurement System SHALL respond to an Intent invocation from MGD Mobile App.
  • The Subjective Measurement System SHOULD support Bluetooth protocols to collect data from external devices.
  • The Subjective Measurement System SHALL process a FHIR Bundle containing Patient, Encounter and ServiceRequest for the subjective measurement.
  • The Subjective Measurement System SHOULD validate the FHIR Bundle according to the IG profiles.

  • Result Delivery:
  • The Subjective Measurement System SHALL invoke an Intent corresponding to the MGD Mobile App to deliver results.
  • The Subjective Measurement System SHALL create a FHIR Bundle containing Patient, Encounter, Observation, Condition, MedicationRequest data for the specific test assessment.
  • The Subjective Measurement System MAY display the results received to the Healthcare Worker and the Patient.