FHIR Device, DeviceComponent, and DeviceMetric resources

Question

I am trying to map the properties of a medical device as described by a sequence of OBX segments in a PCD-01 message to FHIR resources. The properties described in the PCD-01 message are

• the device type (such as a blood pressure cuff) (found in FHIR Device resource)
• the manufacturer name and model number (found in the FHIR Device resource)
• the production specifications (found in the FHIR DeviceComponent resource)
• properties such as time capabilities (found in the FHIR DeviceMetric)

I would expect that the logical way to do this would be to populate each of these resources with the data from the said OBX segments and then "link" them together by making the DeviceMetric a contained resource of the DeviceComponent which is a contained resource of the Device. However, a contained resource cannot contain further contained resources so I need to include two contained resources in the Device resource.

However, the example for the DeviceComponent at

http://www.hl7.org/fhir/2015May/devicecomponent-example-prodspec.json.html

shows the Device a contained resource of the DeviceComponent, exactly backwards of what I would expect. How are these resources supposed to be used? I cannot use any single one of these resources to describe all the properties of the actual device, the real difficulty being that the manufacturer and model names are not in the same resource as the production specification information.

Also, if the Device type identifies that the device is a blood pressure cuff, what does the DeviceComponent type indicate? There really is no 'component' in this case, the device is a stand-alone BP cuff and nothing else, I am just forced to use the DeviceComponent resource in order to describe the production specification values.

Any help on this would be greatly appreciated!

Answer 1

Thanks Ewout for your very well explanation.

To Brian: As you mentioned IEEE 11073-20601 in one of your comments, may I make an assumption that you are only dealing with MDS and Metric as the DIM model for your blood pressure cuff?

Thus, to describe the blood pressure cuff observation (PCD-01 message), your resource of interest are the following:

Device: to describe the device type (preferably using nomenclature as defined in IEEE 11073-10101), manufacture and model number, udi, etc. This resource is created once, and will live through the lifetime of the device unless there is a change with location/organization/patient.

DeviceComponent: to describe the MDS where you can populate production specification, operational status of the device, etc. This resource would have the same lifetime as the device resource unless there is a change with software version, hardware version, or operational status for example.

DeviceMetric (x3): to describe each metric (systolic, diastolic, pulse) including type (preferably using nomenclature as defined in IEEE 11073-10101), unit (preferably using nomenclature as defined in IEEE 11073-10101, but UCUM is fine), identifier (metric unique identification that is assigned by the device, for example, handle ID), and measurementPeriod (if the device happens to repetitively taking measurement at a specified period time, for example, every hour). Same lifetime like DeviceComponent unless there is the change in unit or measurement period.

Observation (DeviceMetricObservation profile): to describe the actual measurement. (In PCD-01, we used OBX-4 to describe the c-tree path that link the observation to the actual metric in the tree. For FHIR, we use device element to describe the external reference to the DeviceMetric)

I would not recommend to use contained resource. I think we should probably create all Device/DeviceComponent, and DeviceMetric resources ahead of time, cache their links and used those as external references. For example, Device resource will be created first, then DeviceComponent whose source element contains the external reference to the Device resource, then DeviceMetric resource whose parent element contains the external reference to DeviceComponent and source element contains the external reference to Device. Now that we have a somewhat well-organized containment tree setup using those resources and links, whenever the device produces a new measurement, we only to create the observation resource, setup the link to DeviceMetric, and that should be it.

Please let me know if you have further questions. Thanks

Answer 2

"the Device a contained resource of the DeviceComponent, exactly backwards of what I would expect"

This is the way that the resources are defined - DeviceComponent refers to Device as a source, rather than Device listing it's components. I'm not sure why they are defined that way - I'll ask the committees (Orders/Obs and Devices) to comment.

I would think that if the Device is a blood pressure cuff, it has a single component that carries the values. That's not the most obvious solution, but it's certainly how things have developed over the years in the PCD space.

Answer 3

The physical composition of a Device is done by the DeviceComponents pointing to their "parent" component using DeviceComponent.parent, e.g. channel to VMD and VMD to the MDS. All components point to the "logical" Device they belong to, using DeviceComponent.source.

In this model, the "Device" is the "administrative" resource for the device (it does not change much and has manufacturer information etc.), where as the DeviceComponent models the physical part, including operation status and is much more volatile.

If you want to express which logical device your observation came from, you can just use Device, if you need to be more specific observation can point to DeviceMetric (which is really a kind of DeviceComponent).