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?
Vice President Sales | Infusion IT and Connectivity