Dan Pettus: Open vs. Proprietary-Accessible vs. Proprietary-Closed

February 22, 2012

Healthcare IT

Let’s take a stretch and assume the “how” is solved and we can connect medical devices into the IT ecosystem.  Now what?  The “why” may seem obvious, but it is not.  Access to and from these medical devices will assuredly be cause for debate.

Some say a completely open system is the way to go: access to the raw data and even direct access to the medical device.  I’m not sure this is possible. Note that we’re considering highly regulated medical products, and the term “open” does not mean “easy.”  Raw data in the medical industry is highly complex and for the most part not defined.  The National Institutes of Health (NIH) has spent millions of dollars and devoted years to defining medical terminology with limited success.  Visit the Unfiled Medical Language System (UMLS) to get a taste how complex medical terminology can be: http://www.nlm.nih.gov/research/umls/   Also, the developer would need to post data dictionaries and data schemas for each update to the applications or databases.  And then consider liability in the case of patient harm.

Proprietary-Accessible is commonly implemented where access to data is done through interfaces or database-to-database connectivity through some type of middleware application.  The raw data schemas and full access to raw data elements is not permitted.  The advantage of this approach is that data can be accessed, but firewalled from the medical device itself.  It allows the medical device vendor to maintain control and provide updates or enhancements without disruption to the accessible data integrity.  Organizations like the Integrating the Healthare Enterprise (IHE) can now develop message standards via interfaces that can apply to all medical device companies since the internal schema is isolated from what is exposed externally.   The drawback is how much data is available and in what timeframe: real-time, semi real-time, once-a-week, never? Is it omni-directional or bidirectional, etc.?

Proprietary-Closed sounds like a bad idea, but it may be the best method in certain circumstances. Under this type of data schema, the vendor is totally responsible for access to the data via vendor-developed applications. Who knows better how to expose and make use of the data than the developer themselves? In some cases, this is the best approach.  That said, all updates and enhancements will be in the hands of the vendor and may not meet your roadmap or expectations for these types of applications.

Of course, there are many variations to the above methods. My first emotional response is a totally open system based on my earlier practice as a software engineer. That said, I have personal experience with an anesthesia informatics system while working at a large academic medical center where the vendor made a significant change to the internal data schema that made our wonderful hospital-developed applications completely useless and required a complete rewrite.

Then, of course, there are the regulatory concerns.  When do these applications cross the line and become an accessory to the medical device itself?  Is the intent of MDDS Class I to embrace bidirectional connectivity with a medical device?  Performing an IEC 80001 risk assessment is certainly a good practice when integrating medical devices into a hospital ecosystem.  Nonetheless the 80001 is no substitute for a FDA 510(k) cleared accessory to the medical device.   What is, and what is not, a medical device is worthy of a blog on its own!

 What are your thoughts?

Dan Pettus
Vice President Sales | Infusion IT and Connectivity

, ,

Connect

Subscribe to our RSS feed and social profiles to receive updates.

One Comment on “Dan Pettus: Open vs. Proprietary-Accessible vs. Proprietary-Closed”

  1. Ken Fuchs (Mindray NA) (co-chair IHE PCD) Says:

    I think we need some more distinction between your “Open” and “Proprietary Accessible” levels. To me “Open” and “Proprietary” mean whether the interface is implemented using Standards or implemented using a vendor proprietary approach which may be published and not necessarily the degree to which all the internals of the device are exposed to the world – but that is also an important dimension.

    IHE based implementations are “Open” in that they conform to a specific “open” standards based profiles and have probably been tested against that profile. However they do limit access to data based on what the vendor can do or chooses to do – with the benefit that if vendors choose to share the same information (heart rate, infusion rate, ventilation rate, etc.) the message will look the same. The interface should be stable over time though it may be enhanced. The receiver will not need completely different drivers to handle the various devices from different devices, you won’t have to rewrite the driver based on the whims of the manufacturer and the world will be a better place (I did not say a perfect place…).

    So going back to the name game we could have:
    Open Access – Proprietary Protocol
    Limited Access – Proprietary Protocol (e.g. most devices today)
    Open Access – Open Protocol
    – Open Profile
    – Certified Implementation
    Limited Access – Open Protocol (e.g. HL7)
    – Open Profile (e.g. IHE PCD)
    – Certified Implementation (e.g. Continua)

    Where Open Access refers to the ability to somehow get and do anything you would want to the device (probably not going to happen in my lifetime…) and Limited Access is where the vendor provides access to a subset of the devices data and capabilities. Proprietary Protocol is a vendor specific communication approach whereas Open Protocol is based on Open Standards. Open Profile steps it up a notch where the implementation uses a published Profile of Open Standards and Certified Implementation is where the interface has been certified to comply with the Open Profile.

    I provided some examples where I could think of them.

    Sorry, I took your 3 levels and ended up with 8…

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: