Bob on Medical Device Software

Google recently open sourced Protocol Buffers: Google’s Data Interchange Format (documentation, code download). What are Protocol Buffers?

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler.

The documentation is complete and worth a quick read through. A complete analysis of PB vs. XML can be found here:  So You Say You Want to Kill XML…..

As discussed, one of the biggest drawbacks for us .NET developers is that there is no support for the  .NET platform. That aside, all of the issues examined are at the crux of why interoperability is so difficult. Here are some key points from the Neward post:

1. The advantage to the XML approach, of course, is that it provides a degree of flexibility; the advantage of the Protocol Buffer approach is that the code to produce and consume the elements can be much simpler, and therefore, faster.
2. The Protocol Buffer scheme assumes working with a stream-based (which usually means file-based) storage style for when Protocol Buffers are used as a storage mechanism. … This gets us into the long and involved discussion around object databases.
3. Anything that relies on a shared definition file that is used for code-generation purposes, what I often call The Myth of the One True Schema. Assuming a developer creates a working .proto/.idl/.wsdl definition, and two companies agree on it, what happens when one side wants to evolve or change that definition? Who gets to decide the evolutionary progress of that file?

Anyone that has considered using a “standard” has had to grapple with these types of issues. All standards gain their generality by having to trade-off for something (speed, size, etc.). This is why most developers choose to build proprietary systems that meet their specific internal needs. For internal purposes, there’s generally not a need to compromise. PB is a good example of this.

This also seems to be true in the medical device industry.  Within our product architectures we build components to best meet our customer requirements without regard for the outside world. Interfacing with others (interoperability) is generally a completely separate task, if not a product unto itself.

Interoperability is about creating standards which means having to compromise and make trade-offs.  It would be nice if Healthcare interoperability could be just a technical discussion like the PB vs. XML debate. This would allow better integration of standards directly into products so that there would be less of the current split-personality (internal vs. external  needs) development mentality.

Another thing I noticed about the PB announcement — how quickly it was held up to XML as a competing standard. With Google’s clout, simply giving it away creates a de facto standard. Within the medical connectivity world though, there is no Google.

I’ve talked about this before, but I’m going to say it again anyway. From my medical device perspective, with so many confusing standards and competing implementations the decision on what to use ends up not being based on technical issues at all. It’s all about picking the right N partners for your market of interest, which translates into N (or more) interface implementations. This isn’t just wasteful, it’s also wrong. Unfortunately, I don’t see a solution to this situation coming in the near future.

Last year I looked at the MSCUI. Along with the v1.3 release is a glimpse into the future. The user experience is greatly enhanced with the use of Silverlight 2.0. Check out the Patient Journey Demonstrator (you’ll need to install Silverlight first):

Bill Crounse has a good overview and links here.

The UI busy and complex, but there seems to be an intuitive consistency to the madness. Besides the slick look, one of the great things about Silverlight (and WPF) are the transition animations that makes using the controls a feel-good experience.

Most of the Silverlight/WPF demos I’ve seen are photo/video mashup types of applications. The MSCUI clinical workflow and patient record demos give you a much better appreciation for how this UI technology can be put to effective use.

I still think the MSCUI Design Guidance documents are the key to success. Everybody goes gaga over the cool graphics and animations, but these requirements need to drive the use of the technology.

I mentioned an Open Source Medical Software list before. Here’s yet another list:

The Top 100 Open Source Software Tools for Medical Professionals

The contents of this one provide a broader selection of functionality. Annotated lists like these are a great resource.

Hat tip: The Healthcare IT Guy

Free Medical Software appears to be a comprehensive list that’s currently being kept up-to-date (hat tip: LinuxMedNews). The project attributes and annotations make the list quite useful. Nice job Holger!

I read with interest “Art Vandelay’s” (an anonymous Seinfeld fan and HIStalk contributor) comments regarding Patient Command Centers on HIStalk Update 1/21/08. Here’s what the PCC is supposed to do:

It will manage service desks for IT, facilities, clinical engineering, and equipment, as well as clinical alerts and data from medical devices and the computerized patient record for singular issues and trended problems.

Wow! That’s a tall order. Even with advanced tracking systems and AI software trying to make sense of all the activity (events), it seems to me that all these management tasks would require intensive human interaction.

“Art” also raised a question regarding device communications:

SNMP isn’t that complex. What are the chances of getting the medical device vendors to add this to their devices?

IMHO, probably not real good. SNMP was primarily used for the management of network devices (routers, hubs, etc.) and protocols. On the surface, its ability to manage large numbers of enterprise networked devices seems like it would be a good fit for hospitals. Unfortunately, the development and adoption of a unique object identifier (OID) for each medical device seems unlikely. Also, a new OID would require the SNMP manager software to be updated in order to recognize it and properly handle the new data.

As medical devices have become networked, the trend has been to embed an HTTP (Web) server in them. This allows secure remote access and control via any Web browser. Many other commercial networked devices have also taken this route.

Even with my pessimistic view on a couple of the details, I don’t think the vision for a PCC is any worse off than it was before. The concept of a PCC is broad and ambitious. As such, its value to an institution and implementation details need to be continually explored and refined.

Here’s a quote from the post: Is this the future of Software and Services?:

…in healthcare these same types of solutions will save lives…as well as reduce stress levels…don’t fear the technology that could some day save your life or the lives of others…

Yes, Software as a Service (SaaS) is a real technology that has a number of pros and cons. All major EMR/EHR software vendors effectively use server-based systems in order to protect data and provide disaster recovery.

The referenced video is essentially a Microsoft advertisement for their Windows Mobile and Surface technologies. This is cool stuff, but I don’t see how it’s going save lives. I also doubt it will reduce the stress levels of clinicians.

If you’re interested in SaaS topics, here are some good resources:

• SaaS Week — SaaS, Software as a Service Weekly
• Software + Services (S+S, Microsoft)
• SaaS Showplace
• ZDNet: Software as Services Blog

Check out the IEEE Spectrum article Visualizing Electronic Health Records With “Google-Earth for the Body”.

The 3-D coordinates in the model are mapped to anatomical concepts, which serve as an index onto the electronic health record. This means that you can retrieve the information by just clicking on the relevant anatomical part. It’s both 3-D navigation and a 3-D indexed map.

Interesting stuff. Especially the general discussion about physician and patient acceptance of EHR systems in the clinic.

Many doctors complain that eHRs have turned them into clerks, while patients say that doctors using these automated systems seem more interested in typing on their computer keyboard than in listening to their health problems.

Also, I wonder how applicable the European experience with exposing patients to this 3D mapping technology would be to US doctors?

My last post prompted a comment from Mary Hawking which asked this question:

How does the legal framework in the USA influence the design of US EMRs?

My answer:

The only legal requirements for protecting patient health information in the US is the Health Insurance Portability and Accountability Act of 1996 (HIPAA). HIPAA became effective in 2001, with mandatory compliance in 2003-2004. These rules only specify who (“covered entities”) must protect health information and the security standards for electronic transactions. All covered health care institutions in the US must now comply.

How does HIPAA influence EMR design? IMHO: Not a whole lot. Most of the functionality of an EMR system is incorporated in the data presentation and work-flow management within the EMR itself. HIPAA only dictates privacy rules and data protection when health information is being transmitted from one institution to another. Privacy and security measures must certainly be implemented within an EMR, but it is usually a relatively minor component.

I’m talking specifically about the affect HIPAA has on EMR software design though. HIPAA has had a large influence on the behavior of covered health care institutions. Here are some related resources:

• Health Care Law Blog
• HIPAA Blog
• EMR and HIPAA
• FierceHealthIT

I’m a regular Slashdot reader and it’s rare to come across a health care related post. So Arguing For Open Electronic Health Records of course caught my eye. I’m sure it was the open standards aspect that attracted them, but I also wanted to point out why the use of software modeling is so important to the development of EHRs.

The Tim Cook post is interesting in several respects.

The first is the reiteration of the importance of the “lack of true interoperability standards” and its affect on adoption of EMR. I’ve talked about this numerous times.

Another important point is that even though open source licensing may be free, the real costs of implementing any EHR system (i.e. going paperless) are significant.

The importance of understanding and communicating the “semantic context” of patient data is also a key concept.

The goal of the openEHR open-source project is to provide a model and specifications that capture patient data without loss of semantic context. A “two-level modeling” approach is used (from here):

(click on the image to see it at full resolution)

Within this process, IT developers concentrate on generic components such as data management and interoperability, while groups of domain experts work outside the software development process, generating definitions that are used by systems at runtime.

If you’ve done any work with Microsoft’s WPF, this model should look familiar. Separation of responsibilities (designer vs. developer) is one of the fundamental shifts in GUI development that XAML provides. Separating the domain experts from the developers when building a health care IT system is also clearly beneficial.

No matter how good the openEHR model is, it unfortunately has the same adoption problems as many other health care interoperability systems: competing “standards”. For example, HL7 V3 Reference Information Model (RIM) and CEN 13606 have the same goals as openEHR.

Developing software systems based on conceptual models of the real world is not new. For example, the OMG Model-driven Architecture (MDA, also see here):

These platform-independent models document the business functionality and behavior of an application separate from the technology-specific code that implements it, insulating the core of the application from technology and its relentless churn cycle while enabling interoperability both within and across platform boundaries.

These types of systems not only provide separation of responsibilities but are also designed to provide cross-platform interoperability and to minimize the cost of technology changes.

The future of inter-operable EHR systems will depend on choosing a common information/behavior model so that the benefits of these development technologies can be realized. The challenge is to make the use of a framework that implements that model something that all stakeholders find advantageous.

Tim Gee mentions the Mirth Project as a cost effective solution for RHIOs (regional health information organizations). In particular, he notes that the WebReach appliance is “ready to go” hardware and software.

I’ve recently started looking at HL7 interface engines for providing our ICG electronic records to customer EMR systems. I’ve mainly been evaluating Mirth and NeoIntegrate from Neotool.

One of the Neotool bullet points about HL7 V2 states:

Not “Plug and Play” - it provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interface-by-interface basis

Since HL7 V2 is the most widely adopted interface in the US, that last 20% can be a significant challenge. This is one of the primary purposes for HL7 integration tools like Mirth and NeoIntegrate — to make it as easy as possible to complete that last mile.

If you look closely at the Mirth appliance literature you’ll see this in the Support section:

For customers requiring assistance with channel development, WebReach consulting and engineering services are available, and any custom work performed by WebReach can be added to your annual support agreement.

They’re providing a turn-key hardware and integration engine system, but you either have to create the custom interfaces yourself or hire them (or someone else) to do it for you.

<AnalogyAlert>
This means that you have bought the hammer and identified the nail(s) to pound in. All you need to do now is find and hire a carpenter to complete the job.
</AnalogyAlert>

This really shouldn’t be that surprising though. Custom engineering and support is the business model for the WebReach Mirth project and I’m sure a large revenue generator for Neotool.

There is certainly great value in being able to purchase a preconfigured and supported HL7 interface appliance. Just be aware that it’s not quite ready to go.

Update 17-Dec-07:

If anyone has experience using HL7 integration engines that they’d like to share, I’d love to here for you (preferably through the comments so they’re shared, but private mail is also fine). In particular, I know there are a number of competing offerings to the ones mentioned in this post, and it would be good to know if they are worth evaluating. Thanks!