Motivation
In our last blog post about Service-Oriented Device Connectivity (SDC) we gave an introduction and overview about this collection of standards. In this post we will have a closer look into the standard IEEE 11073:10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication (BICEPS).
CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/legalcode
The BICEPS (Basic Integrated Clinical Environment Protocol Specifications) standard is the one of the core standards to start with. It is crucial to understand the main idea and fundamental functionality. It does offer all the necessary nomenclature and semantics to get the whole picture.
BICEPS is divided into different aspects.
- Participant Model: Describes a medical device which does take part into a SDC enabled system
- Communication Model: Describes what services a device provides and what message are exchanged between devices
- Discovery Model: Describes how devices get detect each other in the network and what happens when a device is entering or leaving the network
- Non-functional requirements: Describes quality goals like special security and safety treatments
Let’s have look into each of them.
Its All About Content – The Participant Model
BICEPS defines with the participants model a representation a specific participant in the distributed SDC system. A participant can be a medical device or pure software as well. The definition of such a device is named as MDIB (Medical Device Information Base). MDIB is a XML structure and can be exchanged between devices. This XML structure itself is defined by a XML schema which is provided for free (https://standards.ieee.org/wp-content/uploads/import/download/11073-10207-2017_downloads.zip).
A MDIB is divided into two parts:
- Descriptive Part
- State Part
Here is an example of a typical base structure of response message containing the MDIB of a device:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
...
<ns:GetMdibResponse ...>
<ns:Mdib ...>
<MdDescription ...>
...
</MdDescription>
<MdState ...>
...
</MdState>
</ns:Mdib>
</ns:GetMdibResponse>
In the descriptive part (The <MdDescription> tag) the device defines what kind of information and interaction functionality it does offer. The State part (<MdState> tag) does contain actual values for the provided informations which are defined in the descriptive part.
There several predefined Elements a descriptive part might consist of:
- Battery
- Clock
- SystemContext with contexts for patients, locations, workflows etc
- VMDs (Virtual Medical Devices)
- SCO (Service Control Objects) → what data can be modified by other devices
- Cannels with Metrics
- AlertSystem
Let’s examine an example of the clock part of the MDIB. This will help us understand the correlation between the descriptive and state parts of a MDIB. Furthermore how remote interactions can be achieved.
The Clock
To address the open problem about a general clock synchronization between medical devices, the MDIB includes its own dedicated part. This section is about clock data.
If a device does provide clock functionality it does announce it in the descriptive part of the MDIB.
...
<MdDescription DescriptionVersion="1">
<Mds Handle="mds0" DescriptorVersion="0" SafetyClassification="MedA">
...
<Clock Handle="CL.mds0" DescriptorVersion="0">
<TimeProtocol Code="532225">
<ConceptDescription Lang="en-us">NTPv3
</ConceptDescription>
</TimeProtocol>
...
</Clock>
...
</Mds>
</MdDescription>
...
There a some concepts to be clarified in this example. First the <Clock/> element is embedded inside a <Mds/> Element. MDS stands for Medical Device System which further can be containing virtual medical devices (VMDs). You can think of a medical device, which is actually an assembly of different other medical devices or logical units.
Another important concept to understand is the Coded Value System. The Clock in this MDIB does define the time protocol the internal clock relies on. Since there are different protocols available (NPT V3, V4 ..) we have to specify the concrete protocol this particular device supports. To do that a predefined code must be used to identify the correct time protocol in this case. This concept is widely used within a MDIB for different aspects. These predefined codes are out of scope of the BICEPS standard. They can be found in a different base standards of SDC the IEEE 11073:1010X Coding Systems family. The BICEPS standard itself does require that you must use these values to guarantee interoperability. In this particular example the code “532225” identifies the Network Time Protocol Version 3.0.
While now we know, that this device does have clock functionality the actual clock data we have to fetch from the <MdState> element of the MDIB:
...
<MdDescription DescriptionVersion="1">
<Mds Handle="mds0" DescriptorVersion="0" SafetyClassification="MedA">
...
<Clock Handle="CL.mds0" DescriptorVersion="0">
...
</Clock>
...
</Mds>
</MdDescription>
<MdState ...>
...
<State xsi:type="ClockState" DateAndTime="1579170444576" RemoteSync="true" LastSet="1579170261104" StateVersion="0" DescriptorHandle="CL.mds0" DescriptorVersion="0"/>
...
</MdState>
...
There is always a connection between a description and its state which is defined by its Handle. The description part defines a handle (Handle attribute). This handle is referenced by the DescriptorHandle attribute in the corresponding state part. The <State/> element does contain the current data and time for this device. In our example the handle is CL.mds0. The actual time of the clock can be found in the attribute DateAndTime of the <State> element.
Exposing the data is nice. But for a clock synchronization process you need to be able to change values as well. To manipulate data, a device can expose interaction functionalities described in Service Control Object (SCO).
Service Control Object (SCO)
The Service Control Object (SCO) does provide all interaction possibilities a device can offer. These interactions abilities are defined within a <SCO> element in the MDIB.
Lets have a look into a MDIB where clock manipulation is offered:
...
<MdDescription DescriptionVersion="1">
<Mds Handle="mds0" DescriptorVersion="0" SafetyClassification="MedA">
...
<Clock Handle="CL.mds0" DescriptorVersion="0">
...
</Clock>
...
<Sco Handle="sco.mds0" DescriptorVersion="0">
...
<Operation xsi:type="SetStringOperationDescriptor" OperationTarget="CL.mds0" Handle="SET_NTP_SRV_mds0" DescriptorVersion="0">
<Type Code="128505"/>
</Operation>
<Operation xsi:type="SetStringOperationDescriptor" OperationTarget="CL.mds0" Handle="SET_TZONE_mds0" DescriptorVersion="0">
<Type Code="68632"/>
</Operation>
...
</Sco>
</Mds>
</MdDescription>
<MdState ...>
...
<State xsi:type="SetStringOperationState" OperatingMode="En" StateVersion="0" DescriptorHandle="SET_NTP_SRV_mds0" DescriptorVersion="0"/>
<State xsi:type="SetStringOperationState" OperatingMode="En" StateVersion="0" DescriptorHandle="SET_TZONE_mds0" DescriptorVersion="0"/>
...
</MdState>
...
In this example our device offer two operations. One for setting the address of the NTP server and the one to set a timezone. Since NTP does not include time zone information this has to be configurable separately. The offered operations can be found in the descriptive part as two separated <Operation> elements.
In the state part, the device indicates that both operations are available. This is determined at the time of getting the current state of the device (OperatingMode="En" for Enable).
SystemContext
The SystemContext does provide different information about the current context the device is used:
The descriptive part does declare what context information is available. If a PatientContext is available and declared in the descriptive part, the actual data for the patient like its name can be found in the State part in the MDIB.
An example of a MDIB with patient data:
...
<MdDescription DescriptionVersion="1">
<Mds Handle="mds0" DescriptorVersion="0" SafetyClassification="MedA">
...
<SystemContext Handle="SC.mds0" DescriptorVersion="0">
<PatientContext Handle="PC.mds0" DescriptorVersion="0"/>
</SystemContext>
...
</Mds>
</MdDescription>
<MdState ...>
...
<State xsi:type="PatientContextState" ContextAssociation="Assoc" BindingMdibVersion="1" BindingStartTime="1579170261207" Handle="d78ef3460038401ab90957ec204dba0c" StateVersion="0" DescriptorHandle="PC.mds0" DescriptorVersion="0">
<CoreData>
<Givenname>Jon</Givenname>
<Familyname>Doe</Familyname>
<Title>Dr</Title>
</CoreData>
</State>
...
</MdState>
...
The reference between description and state is again done via referencing the corresponding handle.
Channels and Metrics
A device can collect a lot of very specific data. That can be something like a heartbeat or the blood oxygen saturation of a patient. This kind of data is addressed by the <Metric/> elements inside the MDIB which are grouped by Channels (<Channel/> element). In the descriptive part you can find the definition of what the metric is about (e.g. blood saturation) what unit this metric is in (like percentage) and other constraints like ranges for numerical values etc. The semantic of the metric and the unit is described again with the coded value system. So the actual values have to be looked up at the IEEE 11073:1010X Coding Systems family.
Here is an example of the a blood oxygen saturation metric inside a MDIB:
...
<Metric xsi:type="NumericMetricDescriptor" Resolution="1.0" MetricCategory="Msrmt" MetricAvailability="Cont" Handle="numeric.ch1.vmd0" DescriptorVersion="0" SafetyClassification="MedA">
<Type Code="150316"> <!-- MDC_SAT_O2 -->
<ConceptDescription Lang="en-US">oxygen saturation</ConceptDescription>
</Type>
<Unit Code="262688"> <!-- MDC_DIM_PERCENT = 4:512 -->
<ConceptDescription Lang="en-US">percentage</ConceptDescription>
</Unit>
<TechnicalRange Lower="1" Upper="100" StepWidth="1"/>
</Metric>
...
<State xsi:type="NumericMetricState" StateVersion="108" DescriptorHandle="numeric.ch1.vmd0" DescriptorVersion="0">
<MetricValue Value="98" DeterminationTime="1580311825199">
<MetricQuality Validity="Vld" Mode="Demo"/>
</MetricValue>
</State>
In this case we have a blood saturation metric in percentage from a scale of 1 to 100. The actual value is 98 percent. This was measured at the timestamp of 1580311825199. The provided data are valid from the perspective of the measurement device and generated as demo data. Like manipulating clock data, a device can also provide operations to alter specific metric if possible.
AlertSystem
The alert system does provide all the information about what alarms the device is capable of.
The descriptive part distinguish between Alert Conditions and corresponding Alert Signals. Conditions describing reasons for yielding an Alarm Signal. The Alarm Signal itself does describe the actual signal characteristics like keeping alive even the alert condition does not longer exists. An alarm signal can be further defined that it is able to be delegated. That means that the particular alarm signal can be delegated to another device. This enables implementing a silent ICU scenario. All alarms can be delegated to a separate device, which does not need to be in the ICU room. The local alarm will not occur, leading to a more silent environment.
The State part of the alert system defines the current state of conditions. It shows if a conditions and alarm signals are active or not at a point in time.
If the alarm signal is delegated to another device, it must be possible to acknowledge that alarm remotely. For this, a device must provide a delegatable alarm signal. Additionally, it must be able to receive information about alarm acknowledgments from the target device. For that every device can be define what kind of operation it does a remote device allow to do. This can be declared in the SCO section of the MDIB like we showcased for the Clock functionality.
While understanding the scope and content of a MDIB, it’s still unclear how the MDIBs are exchanged between devices. For that a communication model is defined.
The Art Of Conversation – The Communication Model
The Communication Model describes how the actual data (the MDIBs) are interchanged and operations triggered between devices.
There are two roles in this model a participant can be act in (one of another or both):
- Service Provider
- Service Consumer
The communication between a provider and consumer can be done in different ways.
Message Exchange Patterns
A Service Provider does provide Service Operations which are consumed (called) by a Service Consumer. There are 3 different Message Exchange Patterns defined:
- Request-Response
- Publish-Subscribe
- Streaming
In the Request-Response pattern, the consumer calls a remote procedure provided by the provider. This means the consumer has to pull the desired information from the provider.
In the Publish-Subscribe pattern, the provider automatically delivers the subscribed information to the consumer. The provider does push the information to the consumer in this case.
With the steaming pattern a provider can transmit the information continuously to the consumer with an unknown end.
Service Model
This model does define the API or the services a SDC participant must provide to enable MDBI access and remote control:
- GET Service
- SET Service
- Description Event Service
- State Event Service
- Context Service
- Waveform Service
- Containment Tree Service
- Archive Service
- Localization Service
In this post we will focus on the GET and SET services. The GET Service is used for getting the descriptive and the state part of an MDIB of a device. The SET Service, on the other hand, changes values in the state part of an MDIB. It acts like a remote control.
For each service different methods are defined and which message exchange pattern they rely on (Request Response, Publish-Subscribe or Streaming).
Let’s have a look at the example of clock synchronization. In our example Device A wants to set the timezone of Device B. The used service methods here are following the request-response pattern. That’s the flow:
(1) Device A calls the provided service method from Device B: GET-Service#GetMdib
(2) Device B responses to Device A with its MDIB message
...
<MdDescription DescriptionVersion="1">
<Mds Handle="mds0" DescriptorVersion="0" SafetyClassification="MedA">
...
<Clock Handle="CL.mds0" DescriptorVersion="0">
...
</Clock>
...
<Sco Handle="sco.mds0" DescriptorVersion="0">
...
<Operation xsi:type="SetStringOperationDescriptor" OperationTarget="CL.mds0" Handle="SET_NTP_SRV_mds0" DescriptorVersion="0">
<Type Code="128505"/>
</Operation>
<Operation xsi:type="SetStringOperationDescriptor" OperationTarget="CL.mds0" Handle="SET_TZONE_mds0" DescriptorVersion="0">
<Type Code="68632"/>
</Operation>
...
</Sco>
</Mds>
</MdDescription>
<MdState ...>
...
<State xsi:type="SetStringOperationState" OperatingMode="En" StateVersion="0" DescriptorHandle="SET_TZONE_mds0" DescriptorVersion="0"/>
...
</MdState>
...
- Device A has to process the retrieved MDIB to:
- check if Device B does have a clock (descriptive part)
<Mds Handle="mds0" DescriptorVersion="0" SafetyClassification="MedA">
...
<Clock Handle="CL.mds0" DescriptorVersion="0">
...
</Clock>
...
- check if Device B does provide a operation to set the timezone (descriptive part)
<Operation xsi:type="SetStringOperationDescriptor" OperationTarget="CL.mds0" Handle="SET_TZONE_mds0" DescriptorVersion="0">
<Type Code="68632"/>
</Operation>
- check which type of value the timezone is (in our case its a string value –> Defined by the
SetStringOperationDescriptor) - check if the operation is currently enabled in Device B (state part) –> Defined by the attribute
OperatingMode="En"
<State xsi:type="SetStringOperationState" OperatingMode="En" StateVersion="0" DescriptorHandle="SET_TZONE_mds0" DescriptorVersion="0"/>
- finally get the handle of the operation to set the timezone (the
Handleattribute, here the handle is SET_TZONE_mds0)
<Operation xsi:type="SetStringOperationDescriptor" OperationTarget="CL.mds0" Handle="SET_TZONE_mds0" DescriptorVersion="0">
- (3) Device A calls the provided
SET-Service#setStringmethod
It does have to reference the correct operation handle and setting the desired time zone in a correct string format.
At the end the following message would then send from Device A to Device B.
...
<msg:SetString>
<msg:OperationHandleRef>SET_TZONE_mds0</msg:OperationHandleRef>
<msg:RequestedStringValue>SomeValidTimezoneValue</msg:RequestedStringValue>
</mes:SetString>
...
If all is correct Device A sets successfully the timezone at Device B. In a similar way metrics can be exchanged, activities triggered like alarm delegation and so on.
BICPEPS does not define how the service methods are implemented. It defines the message structures. It also defines what services must or can be provided and what their semantics are. Defining the service technology is done in IEEE 11073:20701: Point-of-care medical device communication — Service oriented medical device exchange architecture and protocol binding (https://standards.ieee.org/ieee/11073-20701/6059/). At the end a webservice API is defined and a WSDL is provided. It specifies the actual SOAP Webservices to be implemented by all participants. The file is available as a free download.
We do know how a MDIB is structured and how devices can interact withe each other. But there is one missing link.
Get To Know Each Other – The Discovery Model
The discovery model does define requirements for a communication protocol addressing how the devices can discover each other. The goal is to add a new device into a SDC network in a plug and play fashion. For that the standard does require two different approaches:
- Implicit Discovery
- Explicit Discovery
Both patterns must be provided by a device.
The implicit discovery pattern defines that a device must announce its presence and readiness. It must do this whenever it enters or leaves the network. Furthermore whenever substantially changes at the device occur it should announce it as well. So these announcements will be triggered by the devices which does act as a provider.
On the other hand, in the explicit pattern the consumer device will trigger a query to the network to find desired provider devices.
BICPES does not specify any technologies how the discovery patterns are implemented. This will be addressed in IEEE 11073:20702: Medical Devices Communication Profile for Web Services (MDPWS) (https://standards.ieee.org/ieee/11073-20702/6034/). Which does rely mainly on the DPWS standard http://docs.oasis-open.org/ws-dd/dpws/1.1/os/wsdd-dpws-1.1-spec-os.pdf) and extend it to some points.
Wrapping Up
We have taken a deeper look into the BICEPS standard, the main part of the SDC core standards. We have shown how devices are described by its MDIBs. How a MDIB is structured and what kind of information can be described by it. We used clock synchronization as an example. We exercised a complete flow on how a device can read the clock of another device. It can also change the clock of another device within the SDC network. Finally we differentiate and relate to the other three SDC core standards to complete the whole picture.
The next step for digging deeper in the topic is to checkout free SDC implementations and play around with them. There are at least two good alternatives you can start with:
- SDC-RI: https://gitlab.com/sdc-suite/sdc-ri
- A java based implementation of SDC using the google guice application programming framework
- SDC11073: https://github.com/Draegerwerk/sdc11073
- A python library implementing SDC