Archive for the ‘EMR’ Category

Healthcare Un-Interoperability

Wednesday, November 7th, 2007

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

Taxonomy of Core Standards for the NHIN

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 21st 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.

Health 2.0

Monday, October 22nd, 2007

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

Aggregate, Analyze, and Advise

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

Scoble interview: The Stanford IT doctor is in.

Tuesday, October 9th, 2007

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.

Microsoft HealthVault

Thursday, October 4th, 2007

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?

Microsoft and the Health Care IT Market

Monday, October 1st, 2007

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 Receives FDA 510(k) Clearance for Innovative Clinical Parameters and Electronic Medical Record Compatibility

Sunday, September 30th, 2007

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!

The EMR-Medical Devices Mess

Saturday, September 22nd, 2007

Tim Gee's EMR Connectivity for Medical Devices Is a Mess post is right on target. I've also expressed my opinion ("total chaos") on this, but as you'll see I'm coming from a different perspective.

The HealthLeaders Technology article primarily focuses on the challenges of interfacing medical devices in the hospital environment. I think the situation in a physician's private practice or small group office is even worse.

The needs for medical device connectivity in both environments are essentially the same:

  • Reduction in medical errors.
  • Decrease in paperwork.
  • Increased staff productivity.
  • Timely delivery of clinical results.

Hospitals have the advantage of working with big EMR vendors who in turn can provide connectivity solutions for a larger variety of medical devices. Also, large hospital chains have enough clout to be able to mandate performance criteria from their vendors that include interoperability.

The typical physician's office uses a smaller EMR provider (or even worse, a 'home brew' system) where in many cases connectivity with external devices is an afterthought, if it exists at all. Even when you work with mid-sized EMR companies, each has their own proprietary external data interface. Very few of these smaller stand-alone EMR management systems provide standard interfaces (e.g. HL7) for external device data capture.

The interoperability problem is not a technical one. The issue is the time and resources it takes to implement and validate a given medical device interface. The real hope of a MD PnP-like solution is that the cost of that interface can be significantly reduced.

So, here's my perspective. As a medical device manufacturer, when we take our device into a private practice physician that has an existing (or planned) EMR system the first requirement is pretty much always the same. It's simply that the diagnostic results from our device automatically appear in a patient's record in their EMR system. To make this happen, they have to choose between three possibilities:

  1. Pay the medical device manufacturer (us) to interface with their EMR system.
  2. Pay their EMR vendor to do the interface.
  3. Find a third party vendor or contractor that will provide or build the custom interface.

The problem with #1 is that we don't have the resources to build each unique interface required to satisfy all of our customers. Plus that, our business is building medical devices, not EMR solutions.

#2 might not work out because unless the EMR company has a lot of customers with our devices they will either charge a large custom engineering fee or may just say they won't do it at all. The third option is doable, but is also potentially costly.

Notice that all of the choices require additional investment by the physician. I wonder if these types of issues may be one of the contributing factors for the low adoption rate of EMR for office-based physicians.

Not being able to provide cost-effective EMR integration is bad for everyone involved. It's bad for a medical device manufacturer (like us) because it makes it that much harder to sell systems. It's bad for the physician's office because without EMR integration they'll end up with a less effective paper-based solution. It's also bad for the EMR companies because they won't be able to take advantage of the future opportunities that a fully integrated medical office would provide.

The reasons may be different, but my conclusion about EMR connectivity with medical devices is the same as Tim's: “It’s a mess.”

UPDATE (7/21/08): Ran across this MIT Technology Review post about the MD PnP program:
"Plug and Play" Hospitals (Medical devices that exchange data could make hospitals safer).

Personally Controlled Health Record

Tuesday, September 18th, 2007

Following my EMR-Facebook brainstorming post I ran across the IndivoHealth project (via WSJ-Health Blog). The announcement is that a consortium of large companies, Dossia, would be extending the Indivo open source core. Indivo has implemented the paradigm shift that I discussed.

The Indivo system is essentially an inversion of the current approach to medical records, in that the record resides with the patients and the patients grant permissions to institutions, clinicians, researchers, and other users of medical information. Indivo is a distributed, web-based, personally controlled electronic medical record system that is ubiquitously accessible to the nomadic user, built to public standards, and available under an open-source license.

Very cool. I guess I wasn't the first to think of this! 🙂

A new model for EMR software: Facebook?

Wednesday, September 12th, 2007

There's an article in the October The Atlantic Monthly entitled About Facebook (subscription required) by Michael Hirschorn. His contention is that Facebook is currently the site that "comes closest to fulfilling the promise of social media." As I read though the description of what that means -- the way you qualify friends, the ability to track others and their interaction with others, and the restrictions you can put in place on what others can see about you, the groups you join, etc. -- it made me think of the implementation of EMR systems. The primary components that Facebook has tackled are work flow and interoperability (I've touched a little on this before).

Maybe the Facebook model could point the way to better EMR solutions. As I started to look around I found that others are thinking the same way.

The first question is how are the requirements for an EMR system solved though the functionality provided by a social network?

  1. Patient-centric: I think a huge missing piece in today's EMR systems is patient interaction. Most are only concerned with data presentation, record management, and billing functions for the physician. Except for a few limited read-only web portals, the patient does not have the ability to add content or even interact with their own medical record. An important paradigm shift would be that the physician would seek out and gain permission to access the patients private medical account, not the other way around.
  2. Patient-Doctor interaction: By not allowing the patient to have interactive control over their health information you are also limiting their ability to interact with their physician(s). Also, if multiple physicians were able to have a common platform for patient consultations it would save time, confusion, and duplication. Patients and their doctors can be thought of as a group of friends that need to interact in a unique way.
  3. Multi-media: If teenagers can share music and video, why can't patients and doctors share symptoms and test results just as easily? Also, the improved Web 2.0 interactivity holds a lot of promise for innovations in the presentation of medical data (e.g. Silverlight comes to mind).
  4. Security: Nothing is perfect, but I think the Web has already proven itself secure. Think about the number of Web sites where you've left your credit card number, let alone if you're like me you do all of your banking on-line. HIPAA standards can most certainly be met with current Web technology.

As the article points out:

In Facebook's vision of the Web, you, the user, are in control of your persona.

The same should be said for your personal health information.

In addition to providing work flow restrictions, Facebook also allows developers to create custom applications though the use of the Facebook Platform. By doing so, it has created a well-defined sandbox in which to create user defined content. MySpace will also be following suite in this regard.

It's the "walled garden" that opens the door to interoperability. This strategy is considered flawed by some (quoted in the article), but is perfect for EMR purposes. Within the confines of these APIs any medical record content provider would be able to share their data inside the sandbox. The real value is the content of the data, not the mechanism that allows access into the environment.

I know there are many other issues that need to be dealt with when considering EMR functionality. However, when thinking about the popularity and ease-of-use of these social networking sites it's hard not to see them as a possible model for improving health information flow.

Google, Microsoft, and Health

Wednesday, August 15th, 2007

I think the recent New York Time's article entitled Google and Microsoft Look to Change Health Care missed the bigger picture. The article talks about other Internet companies (like WebMD), but it does not make any mention of the Federal Government's involvement in this arena.

In particular is the Nationwide Health Information Network (NHIN) which was initiated by an executive order in April 2004:

The Nationwide Health Information Network (NHIN) is the critical portion of the health IT agenda intended to provide a secure, nationwide, interoperable health information infrastructure that will connect providers, consumers, and others involved in supporting health and healthcare. The NHIN will enable health information to follow the consumer, be available for clinical decision making, and support appropriate use of healthcare information beyond direct patient care so as to improve health.

At the end of May NHIN published four prototype architectures. The proposals are standards-based, use decentralized databases and services ('network of networks'), and try to incorporate existing healthcare information systems. The companies involved were Accenture, CSC/Connecting for Health, IBM, and Northrop Grumman.

It seems to me that Google and Microsoft are using their proprietary technologies to try to achieve the same goals as NHIN. One of the major differences of course is transparency. Everything that NHIN does is open to public scrutiny whereas GOOG/MSFT have their own market research programs and keep their strategies (for making money) close to the vest.

Besides ensuring privacy, I would argue that one of the key components for creating a successful NHIN is interoperability. Even with "standards" like HL7 and DICOM being available, IMHO the current state of the Electronic Health/Medical Records industry is total chaos. Just like GOOG/MSFT are creating their own islands of knowledge, there are a lot of other vendors (84 listed on Yahoo! Directory) doing the same. As a medical device developer trying to interface with customer EMR systems, we're faced with having to provide essentially unique solutions to (what seems like) just about every customer. If that's the reality down here in the trenches, a NHIN is most likely a very long way off.

In a related item, there are some screen shoots from the future Google Health service (codenamed "Weaver") here.

Update: Dr. Bill Crounse at the HealthBlog also has some thoughts about the NYT article: Doctor Google and Doctor Microsoft; if not them, who?