Hi Thomas,

This sounds like an exciting project! We have in fact implemented the Philips MIB protocol and tested on the MP70 and MX800. Other intellivue monitors should work but YMMV.

I would emphatically recommend option A. The easier to implement OpenICE than to re-invent the Intellivue device-adapter. Option A has a major advantage over a standalone implementation of the Intellivue protocol - the OpenICE system integrates the data from all supported devices and manufacturers on the ICE network. If your head-mounted device also wanted to include data from the patient's ventilator or anesthesia machine or use a monitor from a different manufacturer, that's possible without much additional development (presuming the device-adapter has been written already or you could write a new one yourself).

There is usually one or more Intellivue devices connected to our streaming demo. You can check it out here: https://www.openice.info/diagnostics.html. For example, select the patient "John Sullivan" in the "Partition" field to see the Philips MX800. An application written for OpenICE would be able to receive any data on the page. 

Our platform is still in alpha and is moving quickly so the documentation has been unfortunately sparse lately. We do however have some resources available:
A wiki of sorts - https://sourceforge.net/p/mdpnp/wiki/Medical%20Device%20Plug-and-Play%20Interoperability%20Lab/
A description of an app's architecture: https://docs.google.com/document/d/1g1zYd3kdxk8tL3zzkTJM38ied9Mi-prGTvvsf9LkDJw
"Hello OpenICE" - https://github.com/mdpnp/hello-openice
The vast majority of OpenICE (not the web demo) is written in Java. Check out the repo here: https://sourceforge.net/projects/mdpnp/

We'd love to help you however we can on our end. Keep us posted on your progress as well!
Also, is it okay if I post your question on our community support page? I like to try and share resources for others looking for the same information.

Thanks!
Jeff Peterson

Hey Rado,

Great to hear that adding the user to the dialout group worked! :) This is not a bug but rather the intended functionality of Ubuntu. We've tried to socialize information like this about common failure modes to others through tutorials and this forum. Hopefully this post will save somebody some time in the future.

Thanks,
Jeff

Hi Vasanth,

Beaglebones are available for purchase from many online electronics marketplaces. Two that I have used in the past are http://www.logicsupply.com and https://www.sparkfun.com. Both ship internationally. There's detailed instructions for setting up the beaglebone here: https://www.openice.info/device-adapter-setup.html.

As a reminder, OpenICE can run on any Java platform so feel free to try out the MP70 connection using your laptop or computer. 

Thanks,
Jeff

Thanks for the information Alistair! Hopefully socializing this information will help further the efforts of our community as a whole.

Developing device-adapters in parallel with developing OpenICE is a cart before horse situation. In a perfect world, medical devices would natively 'speak' to OpenICE using a yet to be completed ICE standard. The internal team here at MD PnP is focused on developing the infrastructure that comprises OpenICE, rather than supporting soon to be legacy serial communication protocols. Yet to demonstrate and utilize this new infrastructure's functionality, we need to support current devices - as a matter of fact adoption is impossible without this support! We're stuck walking a fine line between supporting devices and developing new infrastructure functionality. The hope is that we can create enough interest in this effort that community members will help expand our list of support devices. I know MD PnP can't do it alone...

Thanks,
Jeff

Hi Alistair,

First off, thank you for your interest in our project. Developing drivers (device-adapters, as we call them) is a time consuming process and something we generally only do for funded projects and devices we have in the lab. That said, the beauty of open source software is that anyone can write the device-adapters and contribute them back to the community. To enable this activity, generally two things are needed: the protocol manual/description and a device to test your code. I'd love to have a look at the GE, NK and Mindray protocols! I haven't had the time or need to investigate them personally. Would you mind sharing the links or documents below? Maybe we can help enable someone out with our efforts here.

The good news is that we already support several "modern" patient monitors. We have developed a device-adapter for the Philips MX800. We also have existing Drager Medibus device-adapters developed and a Drager Infinity monitor in the lab that we will hopefully have full support for soon. We also have a GE Carescape B850 in the lab that's in the queue. We don't do a particularly good advertising what devices we support. I am going to try and find the time to add this information to our main website.

Thanks,
Jeff

Hi Allistair,

I cannot definitively answer your question without more information so big disclaimer here, but in general yes - there is a way (with several caveats).
TL;DR - both RJ45 serial ports on the MP70 will export data - but only one can get the waveforms at a time. The LAN RJ45 ethernet port will work as well but is most likely occupied with a connection to the patient monitoring network.

Device data integration into the EMR from a Philips MP70 typically happens through one of two vectors: through a Philips DBS (database server) on the network or through a dongle connected to the serial port on the monitor. If the EMR is connected through the DBS, you're in the clear and can connect to the serial port without issue. If there is another device already connected to the serial port, this gets more complicated. Let's dive in -

I've attached two pictures of the back panel of our MP70 in the lab. One picture of the whole connection panel and one close up of the serial connectors.
MP70 back connector panel
MP70 back panel detail

If you open the picture "MP70 back connector panel", in the red square you can see an RJ45 connector labelled LAN. This connector is an ethernet port used to communicate with other Philips monitors, central stations, and databases via the Philips monitoring network. In the green rectangle you can see four RJ45 connectors - these are the serial ports. The next picture, "MP70 back panel detail" is a close up of these connectors. In the blue rectangle, the two connectors labelled with an arrow coming out of a circle (indicated with the LED) are the serial data export connections. In the yellow rectangle, the two connectors are labelled with an X are not configured as data export.

The serial port connectors (again labelled with the arrow coming out of a circle in the blue rectangle) are the ports of interest. The protocol is the RS232 serial Philips MIB. These two connectors are configured as data export in the monitor and are where you connect the device adapter. The setting to configure these as data export interfaces are found in service mode under "Interfaces" in the setup menu. The device adapter can work on either of these ports. The one caveat here is that only one of these serial connections can receive waveform data - meaning that both will receive the numbers you can see on the monitor like HR, SPO2, Pulse, etc. but only one will receive the graphs on the screen like ECG Lead II.

I hope this helps and let me know if I should clarify anything.
Jeff

Yes! I'm glad you understand. We do need to implement multiple solutions of the different components of the system and compare them - what we are doing now is building the rest of the platform and deriving the metrics that we should them compare against! Exactly as you said: technologies "should be considered and compared based on their functionalities, capabilities and implementation". The middleware, or transport layer protocol plus API, is one single piece of a large puzzle. We need to understand the interactions and requirements amongst all these pieces by building a prototype before we can optimize any one given piece. As I said before, "if ... the DDS piece does not fit into the OpenICE puzzle, we will change it." We can't do so blindly.

You make a fantastic point (that I agree with) about standards-based technologies. I brought that point up previously to inform you about the original decision to use DDS. Companies that we would be dependent upon for adoption are asking for this even today. We cannot ignore that request. However, as you undoubtedly understand, we can build an intelligent case to justify an alternative approach.

With respect to x-ray / ventilator synchronization - your hesitation is exactly why we need to understand all of the use cases of the platform so we can inform the design decisions of future technologies. This is one of MD PnP's key goals! None of what we are building today will be possible without influencing design decisions of both medical devices and regulatory pathways. By the way, we have a simulated version of this use case that we have presented at conferences and prototyped in our demo-app on mdpnp.sourceforge.net. I don't know offhand how precise or accurate the synchronization is (in milliseconds) but it does work well with a simulated x-ray and Draeger V500.

Also thank you for your list of functionality you want to see incorporated into OpenICE! This is the beginnings of some fantastic input. Is it okay if I follow up with you to further refine these requests into use cases, requirements and specifications? I have some time allotted to this activity from several other sources and can add you to the list.

Again, I'm glad to see that you're on my page and that we are both focused on creating the best possible medical device interoperability platform possible. I look forward to discussing your functionality request with you further.
Thanks,
Jeff

As an addendum and for the community's record, the author of the benchmarking blog post linked in the previous post deprecated his code and results. He recently published a follow up post about "Benchmarking Responsibly" and advised that there are "different use cases for different systems". A worthwhile read: http://www.bravenewgeek.com/benchmark-responsibly/