The MDCF framework is a publisher-subscriber model that provides a prototypical implementation of the ICE Standard. More information on the ICE Standard can be found on the MDPnP website. In this post, I summarize what I’ve learned while working on one of my project on the MDCF framework. The code base is the frozen version (MDCF 2) available on the MDCF website, rather than the one being actively developed on Github. As always, thanks go to Andrew L. King for the careful explanations, and mistakes and errors are on me.

ICE Illustration (Courtesy of MDPnP.org)

The ICE Architecture

The ICE architecture stands for the integrated clinical environment, currently in the process of being standardized as ASTM F2761-2009. The architecture, shown in the top (as used on the MDPnP website), describes a possible means for medical devices to be connected to a central network so that they could potentially interoperate with each other for meaningful clinical use scenarios.

The MDCF framework is an implementation of the ICE architecture. It can be used as

  1. An underlying framework for the communication of messages in between devices and apps in a publisher-subscriber fashion.
  2. A development environment for fast prototyping and evaluation of medical devices and application scenarios.
  3. A logging simulation environment for the medical application scenarios before their deployment.

To understand the MDCF framework, this post will review the project code structure of the framework, while the process of developing a customized ICE app will be summarized in my next post in this series of MDCF related posts.

MDCF Overview

Supervisor

In an ICE platform, A supervisor serves as the top leven control of of an application scenario. A supervisor may be responsible for the configuration, management, monitoring, and analysis of an application scenario. System configurators setup an application scenario, and a system user interact with the system via predefined methods by the supervisor.

App

An app in MDCF is synonym of an application scenario. A few medical devices connected together serving a specific purpose is an app. The app contains definitions of how components are connected, including the port connections.

App Database

By design, the MDCF framework only allows apps that are certificated by regulators. The fact that an app is certificated is seen by having a registered entry in the app database. Each entry resides in a folder in the file system, containing a few XML specification files. At runtime, the MDCF framework scans an app database folder and loads all known apps with a proper signature. The code responsible for loading the apps is at AppLauncher class of the mdcf.gui.clinicianconsole package, in the mdcf2-swingconsoles project. For the loaded apps, the MDCF framework is able to show a Clinician Console to let the user select known apps to run.

Components

There are three types of components that can be included in an MDCF app, DeviceComponent, LogicComponent, and AppPanelComponent. A DeviceComponent represents an actual device connected to MDCF. A LogicComponent represents a simulated device. An AppPanelComponent represents a GUI shown to the end user. The three types of components are defined in the mdcf2-core project, under the mdcf.core.ctypes package.

Default Channels for MDCF Connection Manager

The MDCF connection manager is responsible for the connection of each individual device to the framework. Upon startup, the connection manager is started and it has the following list of channels established.

  • to_mgr_atrium
  • mgr_atrium
  • HBReportChannel
  • mdcf.channelservice.common.GlobalChannels.ADMIN_SERVICE_BROADCAST
  • mdcf.channelservice.common.GlobalChannels.ADMIN_SERVICE_LISTEN
  • mdcf.channelservice.common.GlobalChannels.CLINICIAN_SERVICE_BROADCAST
  • mdcf.channelservice.common.GlobalChannels.CLINICIAN_SERVICE_LISTEN
  • mdcf.channelservice.common.GlobalChannels.LOGGER_SERVICE_BROADCAST
  • mdcf.channelservice.common.GlobalChannels.LOGGER_SERVICE_LISTEN

These definitions are in the mdcf.nc.connectionmanager.ConnectionManager class of the mdcf2-server project. Quite often in my hack with the MDCF project, I find it a quick and dirty way adding a global channel in this place.

Code Summary

Default Managers for MDCF Service

Upon start-up of the MDCF Framework, a list of managers are initiated and loaded. The code for loading such managers is in the constructor for the MdcfConfiguration class of the mdcf.main package, in the mdcf2-main project. The managers loaded are

  • Channel Servcie Server
  • Connection Manager
  • Device Database
  • Device Manager
  • Component Database
  • Component Manager
  • App Database
  • App Manager
  • Admin Console
  • Clinician Console
  • Logger Service

Loading An App in MDCF (From the Clinician Console)

When MDCF is started with the ExecuteServerAndConsole class in the mdcf.main package of the mdcf2-main project, a Clinician Console GUI is shown for the user to select an app to run.

Once the user makes the selection and clicks “Launch”, the code parses the selection to see which app is selected, and prepares and sends a list of InstantiateAppMsg messages to the mdcf.channelservice.common.GlobalChannels.CLINICIAN_SERVICE_BROADCAST channel. A listener for the mdcf.channelservice.common.GlobalChannels.CLINICIAN_SERVICE_LISTEN channel, residing in the mdcf.supervisor.clinicianservice.ClinicianService class (mdcf2-server project), intercepts the message and calls the instantiateApp method to load the app. Details of loading different types of components (logic, device, and app panel) are in the implementation of instantiateApp function of the mdcf.supervisor.appmanager.AppManager class (mdcf2-server project, supervisor-appmanager folder).

Summary

This post initially served as my memo of reading the MDCF code. As I played with the MDCF code base more and more, I feel less need for writing everything down in such a detail. To continue reading, an older post in my blog talks about how to implement a data logger for the MDCF framework the hard way.