FHIR Ingest Service

This page is to document some of the thoughts about how we can support ingesting data in FHIR into a Streams application.

We will provide the microservices to support the most important FHIR resources for Streams applications:

IngestFhirObservationService

This service ingests Observation data from a FHIR server. The service will:

• Subscribe to the streams.monitor.patients topic. The topic provides list of patients that the service should monitor.
• Given a list of patients from the incoming stream, the service will construct the following query:
  • For each patient on the list
  • Get a list of observations updated since the last time we query the server for that patient
  • For each observation, construct the Streams Observation obect
  • Publish observation data for downstream applications to consume
  • The service queries for observation records on each tuple it receives

Mapping FHIR Observation to Streams Type

FHIR Observation Specification

Streams Observation Data Type

type Observation = Device device, rstring patientId, 
    ReadingSource readingSource, Reading reading;

type Reading = int64 ts, rstring readingType, float64 value, rstring uom;

type Device = rstring id, rstring locationId;	

type ReadingSource = rstring id, rstring sourceType, rstring deviceId;

type Patient = rstring id, rstring name, rstring gender, rstring DOB, 
    rstring status ;	

type Location = rstring id, rstring name, rstring locationType;	

Mapping

Streams Observation Type Attributes	FHIR Observation Type Attributes	Comments
o.reading.ts	o.EffectiveDateTime
o.reading.readingType	o.code / o.component[x].code	ReadingType should rename to code? Missing system information
o.reading.value	o.valueQuantity.value / o.component[x].value	The value field supports data type other than numeric values. It can be string, datetime, or attachments. Current Streams framework cannot support other data types
o.reading.uom	o.valueQuantity.unit / o.component[x].value.unit	UOM also has a system associated with it. Current Streams framework does not support passing on that information
o.readingSource.id	o.deviceMetric.identifier	deviceMetric describes the physical channel on the device
o.readingSource.sourceType	o.deviceMetric.type.code
o.readingSource.deviceId	o.device.id
o.device.id	o.device.id	Why do we need this twice?
o.device.locationId	o.device.location.id
o.patientId	o.subject.id