Archive for the ‘EMR’ Category

Microsoft Health Common User Interface (CUI) v1.3

Tuesday, May 13th, 2008

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):

Patient Chart

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.

UPDATE (9/11/08): MSCUI R1.5 is now live.

100 Open Source Software Tools for Medical Professionals

Wednesday, April 16th, 2008

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

Open Source Medical Software

Monday, January 21st, 2008

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!

Patient Command Centers

Saturday, January 19th, 2008

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.

Software and Services: A stress reliever?

Sunday, January 13th, 2008

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:

EHR Visualization: “Google-Earth for the Body”

Thursday, January 10th, 2008

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

Image: IBM

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?

HIPAA and EMR Design

Thursday, January 3rd, 2008

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:

EHR System Modeling

Tuesday, January 1st, 2008

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):

Two-Level Software Engineering
(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.

HL7 Interfacing: The last mile is the longest.

Saturday, December 15th, 2007

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!

Healthcare IT Interoperability Defined

Tuesday, November 20th, 2007

I guess I've been obsessed with interoperability (or lack thereof) lately.

Definitions:

interoperability

Dictionary interoperability 1,0,0,0;interoperability=555039

Main Entry: in·ter·op·er·a·bil·i·ty Listen to the pronunciation of interoperability
Pronunciation: \ˌin-tər-ˌä-p(ə-)rə-ˈbi-lə-tē\
Function: noun
Date: 1977
: ability of a system (as a weapons system) to work with or use the parts or equipment of another system

Interoperability:

The ability of two or more systems or components to exchange information and to use the information that has been exchanged.

From the National Alliance for Health Information Technology (NAHIT) definition:

In healthcare, interoperability is the ability of different information technology systems and software applications to communicate, to exchange data accurately, effectively, and consistently, and to use the information that has been exchanged.

The four NAHIT levels are:

  1. Non-electronic data. Examples include paper, mail, and phone call.
  2. Machine transportable data. Examples include fax, email, and un-indexed documents.
  3. Machine organizable data (structured messages, unstructured content). Examples include HL7 messages and indexed (labeled) documents, images, and objects.
  4. Machine interpretable data (structured messages, standardized content). Examples include the automated transfer from an external lab of coded results into a provider’s EHR. Data can be transmitted (or accessed without transmission) by HIT systems without need for further semantic interpretation or translation.

From IEEE 1073 (Point of Care Medical Device Communications) and IEEE-USA Interoperability for the National Health Information Network (NHIN) -- original definitions are from IEEE Standard Computer Dictionary: Compilation of IEEE Standard Computer Glossaries, IEEE, 1990:

Functional: The capability to reliably exchange information without error.

  • Shared architectures (conceptual design)
  • Shared methods (processes and procedures)
  • Shared frameworks (goals and strategies)

An architecture is the conceptual design of the system. Systems inter-operate if their architectures are similar enough that functions that execute on one system execute identically (or nearly identically) on another system.

Shared methods refer to the processes and procedures that a system performs. To ensure interoperability, these operations must be capable of being performed identically at any point in the network, regardless of implementation.

A shared framework is a shared set of goals and strategies. Stakeholders must agree on a shared set of goals and approaches to implementation.

Semantic: The ability to interpret, and, therefore, to make effective use of the information so exchanged.

  • Shared data types (types of data exchanged)
  • Shared terminologies (common vocabulary)
  • Shared codings (standard encodings)

Shared data types refer to the types of data exchanged by systems. Interoperability requires that systems share data types on many different levels, including messaging formats (e.g. XML, ASCII), and programming languages (e.g. integer, string).

Shared terminologies refer to establishing a common vocabulary for the interchange of information. Standardized terminology is a critical requirement for healthcare applications to ensure accurate diagnosis and treatment, and has led to developing standards such as SNOMED-CT.

Shared codings refer to establishing standard encodings to be shared among systems. Codings refer not only to encoding software functions, but also to encoding medical diagnoses and procedures for claims processing purposes, research, and statistics gathering (e.g. ICD9/10, CPT).

At Healthcare Informatics Technology Standards Panel (HITSP) I came across a maturity model of interoperability types from the Mayo Clinic. Even though this table is taken out of context, the Technical-Semantic-Process model shows yet another view of interoperability.

Mayo Clinic Interop Types

There are also a number of Models of Interoperability that describe abstract interoperability. For example, a finer grained layered model is called Conceptual Interoperability. This model encompasses the previous healthcare IT definitions:

Levels of Conceptual Interoperability Model (LCIM)

Besides these definitions there are many articles (and books), especially as it relates to healthcare and EMR/EHR, that espouse the benefits of interoperability.

From a broader software industry point of view you can imagine the number and variety of issues that a company like Microsoft has to deal with. They claim Interoperability by Design. Of course Microsoft has gotten a lot of attention about their push to get Open Office XML (OOXML) approved as a standard by EMCA -- some quite negative:

NoOOXML

Even though I don't believe the healthcare industry has the equivalent of 'Da Bill' (or maybe it does?), this points out one of the necessary components for the implementation of interoperability: standards.

I was on an ASTM standards committee a number of years ago (E1467-94, now superseded) , so I have some understanding of how difficult it is to get consensus on these types of issues. The process is long (years) and can sometimes be contentious. Even after a standard has been balloted and approved, there's no guarantee that it will be widely adopted.

Summary:

In my previous post on this subject I pointed out the plethora of healthcare IT standards and their confusing inter-relationships. The definitions of interoperability can be just as confusing. Each of the different models has a slightly different way of looking at the same thing. This is certainly one reason why there are so many overlapping standards.

Conculsion:

Interoperability in healthcare IT is multi-faceted and complex. This makes it difficult to agree upon exactly what it is (the definition) and even harder to develop the standards on which to base implementations.