Bob on Medical Device Software

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!

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

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.

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:

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:

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.

Or maybe that should be “non-interoperability”? Anyway, I have ranted in the past about the state of the EMR industry. I thought I’d add a little meat to the bone so you could better appreciate the hurdles facing device interoperability in healthcare today.

Here’s a list of the standards and organizations that make up the many components of health information systems. I’m sure that I’ve missed a few, but these are the major ones:

Medical Coding

• SNOMED (Standardized Nomenclature for Medicine)
• LOINC (Logical Observation Identifiers Names and Codes)
• ICD9/10 (The International Classification of Diseases)
• CPT (Current Procedural Terminology)

Organizations

• FDA CDRH (Food and Drug Administration Center for Devices and Radiological Health)
• NHIH (National Health Information Network)
• HIMSS (Healthcare Information and Management Systems Society)
• CCHIT (Certification Commission for Healthcare Information Technology)
• PHIN (Public Health Information Network)
• VISTA (Veterans Health Information Systems and Technology Architecture)

Standards

• HL7 (Health Level Seven: v2 and v3)
• HIPAA (The Health Insurance Portability and Accountability Act of 1996)
• 21 CFR Part 11 (FDA/HHS Electronic Records and Signatures)
• IEEE-1073 (Point of Care Medical Device Communications)
• IHE (Integrating the Healthcare Enterprise)
• DICOM (Digital Imaging and Communications in Medicine)
• HITSP (Healthcare Information Technology Standards Panel)
• EHRVA (HIMSS Electronic Health Record Vendors’ Association)
• NCPDP (National Council for Prescription Drug Programs)
• openEHR (International Foundation that promotes Electronic Health Records)
• CEN (European Committee for Standardization)
• CCR (Continuity of Care Record)
• ANSI X12 (Electronic Data Interchange)
• MLLP (Minimal Lower Layer Protocol)
• ebXML (Electronic Business using eXtensible Markup Language)

This list does not include any of the underlying transport or security protocols. They are either data formatting (many based on XML) or specialized messaging systems.

The diagram below gives an overview of how many of these standards are related (from an IEEE-USA purchased e-book — copying granted for non-commercial purposes):

I don’t know about you, but trying to make sense of all these standards and protocols is not an easy task. A discussion of next generation PHRs summarizes the situation well:

… not only is information scattered, but standards for defining and sharing the data are still evolving; where standards exist, many of them predate the Internet. Standards about how to define consistently the information (clinical standards) and to transmit and exchange the information (technical standards) are not yet formalized and agreed upon.

The point about predating the Internet is an important one. This particularly pertains to HL7 v2.x which still uses ASCII delimited messages for transmission over serial lines. For all you 21^st century programmers that may have never seen one before, here’s what an HL7 v2.x message looks like:

MSH|^~\&|AcmeHIS|StJohn|ADT|StJohn|20060307110111||ADT^A04
|MSGID20060307110111|P|2.4EVN|A04PID|||12001||Jones^John|
|19670824|M|||123 West St.^^Denver^CO^80020^USAPV1||O
|OP^PAREG^||||2342^Jones^Bob|||OP|||||||||2|||||||||||||||
||||||||||20060307110111|AL1|1||3123^Penicillin
||Produces hives~Rash~Loss of appetite

HL7 v3 uses XML for it’s message format but it has not been widely adopted yet. A good history of HL7 v2 and v3, and an explanation of their differences, can be found here (pdf).

HL7 v2 is commonly used in hospitals to communicate between medical devices and EMR/HIS systems. Even though the communications framework is provided by HL7, new interfaces must still be negotiated, developed, and tested on a case-by-case basis.

Most of the large EMR companies provide HL7 interfaces, but many of the smaller ones do not. This is because hospitals are not their primary market so they don’t generally need device interfaces. These EMRs are essentially clinical document management, patient workflow, and billing systems. The only external data they may deal with are scanned paper documents that can be attached to a patients record. The likelihood that they would conform to any of the standards listed above is low.

I’m not sure things will improve much with the recent PHR offerings from Microsoft (HealthVault) and Google (Google Health — not yet launched) . Microsoft appears to be embracing some of these standards as discussed in Designing HealthVault’s Data Model, but there are a couple of telling comments:

Some of the data types we needed in order to support our partners’ applications where not readily available in the standards community.

Our types also allow each vendor to add “extensions” of their own making to item data – so to the extent that we are missing certain fields, they can be added – and the industry can rally around those extensions if it makes sense.

Microsoft says they are not the “domain experts”, so they’re leaving it to the industry to sort it all out. Great! This is probably the same attitude that got us to where we are today.

Hopefully you can now see why I’ve used the words “mess” and “chaos” to describe the current situation. The challenges facing interoperability in healthcare are immense.

The Health 2.0 movement (also see here) is a comprehensive approach to many of the EMR/PHR topics I’ve discussed in the past. Scott Shreeve, MD (there are many good posts on his blog) proposes what he calls the “Triple-A of Health 2.0″ approach (also see the overviews here and here):

I like Dr. Shreeve’s Health 2.0 Business Model analysis in that it clearly defines corporate motivations in this marketplace. It’s hard not to like the Aggregate concepts of Prostitution, Voyeurism, and Fetishes.

How is value going to be derived and payed for? Put into this Health 2.0 business model context at least you can begin to ask the right questions.

What Health 2.0 makes clear is the complexity of the issues that need to be resolved and that there’s a long road ahead.

UPDATE (15-Nov-2007) :

A new Health 2.0 site: Health 2.0 Blog

Here’s an interesting interview with Dr. Christopher Longhurst from The Stanford IT doctor is in.

The discussion of standards and interoperability is very good.

Everybody is talking (WSJ-Health Blog, MedGadget, Health IT Guy, and many more) about the introduction of Microsoft HealthVault.

This seems to be a step in the right direction for personally controller health records. The direct device interfaces are particularly interesting.

Update:

There’s more discussion about this on the HISTalk blog. People certainly have strong feelings about whether PHR has a future, and even stronger ones about Microsoft. From here:

Last on HealthVault: lots of people hate Microsoft. Blue screen of death. Microsoft Bob. Forced upgrades. Browser security holes. Antitrust issues. Internet tollgate. Assume people buy into PHRs on a big scale. Of all the companies offering PHRs, which one would they trust least with their most personal information? Some Ukrainain hater will have it hacked by this time next week, I suspect.

Even if this was a real concern, I’m not so sure the general public has this level of technical knowledge that would lead them to distrust Microsoft.

In any case, I think a bigger concern about companies like Microsoft and Google getting into PHR is their bottom line motive: advertising. You can be sure that everything they do is driven by a business model — i.e to make money. This makes their shareholders happy, but what will it ultimately mean for PHR?

Here’s a good read about Microsoft and the health care IT market: Vertical Markets: Prescription for Profit. Redmond Channel Partner Online is a magazine for the Microsoft partner community so the article is geared more towards third party opportunities. It talks a little about Microsoft’s marketing efforts (or lack thereof), but nothing about their technology strategy. The discussion about the Azyxxi purchase in 2006 and how it’s perceived by some as a competitive threat is interesting.

The overall take-away is that the health care industry has a lot of potential for Microsoft. What you don’t get from the article is where the competitive threats are in this market.

Here’s a quote I like:

Doctors can be tough customers too. “They’re notoriously cheap,”….

CardioDynamics International Corporation (CDIC) Receives FDA 510(k) Clearance for Innovative Clinical Parameters and Electronic Medical Record Compatibility.

WooHoo! Congratulations to all of the CDIC R&D (including yours truly) and Quality teams for getting this done. Great job everyone!