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.
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
- An underlying framework for the communication of messages in between devices and apps in a publisher-subscriber fashion.
- A development environment for fast prototyping and evaluation of medical devices and application scenarios.
- 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.
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.
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.
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.
There are three types of components that can be included in an MDCF app,
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
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.
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.
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 (
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.