NeoTool — Singular Focus, Healthcare Integrated

This week is the May HL7 Working Group Meeting in Phoenix, AZ. I’m looking forward to meeting up with the HL7 community and helping build the HL7 standard.

NeoTool will be hosting our Tuesday Night Party (TNP) at Gallagher’s, a sports themed bar. If you are at the WGM or in the area, please stop by Tuesday. More details over at our TNP page.

The WGM details page is really hard (ok, impossible) to find on the HL7.org web site so I thought I would put as link here on the NeoTool blog.

In a previous post, I highlighted several healthcare IT perspectives on the Stark Law changes and the impact on EMR implementations through hospitals. A recent article in Inside Electronic Medical Records is an interesting edition to this topic; the article is entitled:  Hospitals Take Tentative Start EMR Steps, Struggle with Charging Overhead to Doctors.

A few interesting points in the article:

• Different approaches are being taken by hospitals. In the article, one hospital is offering just a single EMR offering to their physicians, and another hospital is offering 3 to 4 EMR application options. The primary reason for the multiple EMR offerings is that “We realized that one size doesn’t fit all.”
• Integration is essential. The reason for the one hospital to offer single (hosted) EMR offering to their physicians is so that the patient has one medical record in their system. In the other hospital’s case, clinical integration is still essential. As they stated, “You have to have clinical integration between multiple entities. If you are not sharing data, you are losing the real benefit of EMR.”
• EMR certification also plays a role in the selection process by the hospital. In one case, only CCHIT certified EMR vendors are considered.
• The amount of the hospital subsidy varies. One hospital is covering 60% of the EMR services while the other seems to be taking advantage of the full allowable amount of 85% of the covered services.
• Trust is a factor with physicians. If a physician practice is going to take advantage of a hospital supported EMR, they will need to trust that hospital.

Forward progress? Time will tell which approach will work the best, or it may be that the approaches do vary… select the approach that best fit the needs of the connected healthcare objectives being pursued. As long as everyone involved trusts the objectives, it may work.

An article in FierceHealthIT highlighted a recently published paper (PDF) on how Electronic Medical Record (EMR) adoption is driving the need for more Healthcare IT (HIT) jobs. A key statement from the report:

“While hospitals with basic implementation are utilizing about 0.1 IT staff per bed, this rises to around 0.2 IT staff per bed as hospitals advance from Stage 1 to Stage 4 implementation based on the HIMSS EMR Adoption Model. If our data represent a correct sampling of the entire US, then the current IT staff workforce is about 108,390 FTE. However, if the US HIT agenda is fulfilled and hospitals move to higher levels of adoption, an additional 40,784 FTE will be required.”

Characterizing the Health Information Technology Workforce: Analysis from the HIMSS Analytics Database, April 2008.

In the EMR adoption model as defined by HIMSS, the various stages are succinctly defined. Stage 1 includes basic systems in place - radiology, laboratory, pharmacy - while moving to Stage 4 includes implementation of a Computerized Practitioner/Physician Order Entry (CPOE) system.

The key point of the paper and discussion: Adopting new technologies in hospitals require additional IT personnel to support and ensure success. In selecting new technologies, it is important for hospitals to evaluate the type of IT skills required to support the required new applications. Balancing the type of skills required with the associated costs is essential.

Despite previous warnings, I recently committed a cardinal interfacing sin when working on an HL7 integration project. Upon kicking off a large project involving several applications with which we’re interfacing, I requested both specifications and sample HL7 messages from the vendor. The specifications came right away; the sample messages unfortunately did not.

Rather than making a big deal out of the messages and insisting that we get them prior to interface construction, I dove right in to perform a gap analysis based on the specifications that we were furnished in order to determine the incompatibilities between the systems involved. After carefully identifying the mappings required to transform the HL7 messaging such that it would satisfy each system’s specs, the interfaces were configured.

It was time to test, and out came the disappointingly small (in some cases just 1 or 2 messages per application) sampling of test messages that had slowly trickled in but had been shelved until the ‘real’ work of building the interfaces could be completed. Those messages were loaded, the interfaces were turned on, and voila!

Errors.

The sample data didn’t align with the specs, rendering my beautiful side-by-side comparison spreadsheets useless. The mapping tables I developed from those specs to translate representations of common fields such as gender, race, and relation? Worthless as well.

How could I have so quickly forgotten that the proof is almost always in the sample message pudding?

Specification documents are often hailed as the keys to unlocking the secrets of the import/export modules of healthcare applications and successfully brokering communication between disparate systems. Good specs do just that. The only problem is that you stand a better chance of finding a few needles in a hay mountain. They’re out there; they’re just not very plentiful.

The shortcomings of specs are attributable to a variety of factors:

• They’re rarely updated at the pace of development. While correct at a particular moment in time, changes are often times made to the interface that either never make it into the document or do so after those changes have been introduced to the marketplace.
• They’re often out of sync with upgraded software versions. Even if a vendor takes extreme care in updating both the interface and the specifications simultaneously, healthcare facilities may have upgraded their software since receiving their specification document and therefore unknowingly hand an outdated version to trading partners/interface analysts.
• Variances in installed modules/features are difficult to document. Many applications offer a wide array of software modules and features that can be alternatively installed depending on the customer’s budgets or workflow that make the production of a “one size fits all” specification difficult.

But the messages don’t lie. Having them takes the guesswork out of determining exactly what is coming out of or readily received by a healthcare application. Today’s most sophisticated interface engines will even go so far as to take those messages and build an HL7 derivative to which they’ll conform at the click of a button! There’s not much left to the imagination, and thus interfaces can be built with a much greater level of confidence.

So if you’re a vendor, be sure to stamp out a good sampling (at least 50) of anonymous messages for each message type supported through your application interfaces each time a change to the interface is introduced. Doing so will not only be appreciated by interface analysts trying to connect your systems to others in a hospital, clinic, imaging center, etc. It will also ease your own interfacing burden by reducing the number of calls and questions you field related to interfacing.

And if you’re an interface analyst, stranded on a deserted integration island and given the choice between sample messages and specifications to ensure your survival, always opt for the messages. They represent much more than a means to validate interfaces - they can be vital to successfully building them. Just make sure you don’t settle for 1 or 2 like I did.

Just recently, I wrote about how workflow discussions are frequent, and sometimes it is easy to lose sight of what needs to be simply done. In the current issue of Health Management Technology, there is an interesting article of how Meadows Regional Medical Center applied lean manufacturing principles to their workflow. The article is entitled Leaning Towards Efficiency, and is written by the hospital CEO, Alan Kent.

The hospital worked with Georgia Tech’s Enterprise Innovation Institute and focused on improving the Emergency Department (ED) workflow.

In healthcare IT, it is great to read about how workflow projects are undertaken in a straightforward way and achieve significant results in a short time period. As the article states:

“The lean team at Meadow’s developed 44 action items for reducing lead time to admit, treat and discharge a non-critical ED patient, 18 of which were determined to be low cost and high impact.”

The results, according to the Georgia Tech press release:

“… a 44 percent reduction in average length of stay per patient, a 10 percent boost in patients served and a 92 percent patient satisfaction rate.”

Great work!

In radiology particularly, there is alot of discussion around workflow. Streamlining radiology workflow creates even more conversations. Where there is talk is their action? Probably not to the degree that you would think… With such a flurry of words, the important point may be lost.

In my opinion, the important point is keep it simple. For your radiology workflow:

1. Document your current workflow
2. Document what you would like your workflow to look like
3. Identify the gaps
4. Adjust the workflow to close the gaps
5. Enable the flow

A little more detail on each:

Document your current workflow. Talk to the people involved in the key steps - from schedulers, physicians, radiologists, technologists, billing professionals, etc. Get the current workflow first-hand, from the people doing the work.

Document what you would like your workflow to look like. As you talk to people, ask for ideas on how to improve. Meet with key leaders in your organization to determine objectives. Most importantly, talk to the physicians who receive the results that you deliver. Get the customer feedback!

Identify the gaps. What are the key differences between the way you do it today and the way you would like it done? Again, more importantly, what is the way your customers want it done - both patients and physicians?

Adjust the workflow to close the gaps. Not all of the gaps can be closed simply. Identify the high impact - low implementation effort items and do those first. For the others, develop a plan of how to close the gaps and continue to implement to the defined goals. Communicate your results along the way!

Enable the flow. Some activities in the workflow will require no technology. Others will require technology investments. Look for ways to automate the radiology workflow, simplify the steps, and deliver value to the people doing the work throughout the process. Look for ways to leverage technology for the improvements that enhance patient quality, enhance radiologist productivity, and deliver real service to the referring physician community.

There are many ways to improve your workflow, but the best way is to get started… with the basics.

Since it’s inception in 1998, IHE (Integrating the Healthcare Enterprise) has embarked on a commendable mission to “improve the way computer systems in healthcare share information.” Over the past 10 years the initiative has made great strides in standardizing the implementation of not-so-confining “standards” such as HL7.

In so doing IHE has developed a plethora of integration profiles across a dozen or so clinical and operational domains, from Cardiology and Radiology to Patient Care Devices and IT Infrastructure.  These profiles take a lot of the interpretation and guesswork out of the implementation of the underlying standards and thus make the messages transmitted between clinical information systems much more consistent and predictable, at least amongst supporting systems.

Sounds great – so what’s the problem?

In the most recent North America Connectathon only 70 organizations tested just 130 systems for IHE profile compliance. Don’t get me wrong – that’s a really nice turnout that marks continued growth in support for the initiative. But when compared to the thousands and thousands of clinical information systems impacting patient care delivery in this country today, that total represents a disappointingly low percentage.

Why don’t more vendors participate? Quite simply, because doing so is difficult, and there’s been no surge in customer demands for IHE compliance in the marketplace to date to prompt most vendors to tackle that difficulty.

To be clear, the difficulty associated with participation isn’t attributable to any overly complex technical challenges to which vendors are subjected. On the contrary, the profiles, though imposing at first glance due to their length and exhaustive nature, spell implementation details out quite clearly. Nor is the difficulty attributable to the committee meetings, conference calls, and face-to-face meetings required to stay engaged with the ongoing developments of a particular domain, although that investment in time and energy certainly isn’t trivial.

Rather, the difficulty in participating stems from a fundamental flaw in the way vendors have historically addressed interface challenges. That flaw continues to plague their ongoing integration efforts today.

For most vendors, the world class system cart came long before the integration horse. When interfacing requests first began to surface, code was hastily added to the existing application code base in an effort to provide a solution as quickly as possible.

As connectivity demands have grown at an ever-increasing clip, that interfacing code not only grows with them but also undergoes innumerable changes to accommodate the customization required by so many interface partners. And each time a change is introduced the entire code base is recompiled and regression tested to ensure that customization did not have a deleterious effect on the core application.

As a result, growing software companies see deployment cycle times balloon and valuable development resources diverted from core technology to high tech plumbing.

Sounds a lot like initiatives to adopt IHE profiles and participate in Connectathon events, doesn’t it? Profile changed? Code, recompile, test. New profile? Code, recompile, test. Vendor X needs the message you’re communicating tweaked? Code, recompile, test.

The path to IHE compliance need not be so difficult!

Thankfully, healthcare middleware can go a long way toward remedying the difficulty felt by the vast majority of healthcare vendors today. Amongst many other things, middleware technology can:

1. Eliminate the need to alter existing import/export modules.Middleware can receive the existing feeds an application supports and transform those messages into an IHE compliant data stream.
2. Move interfacing logic outside the core application. In so doing supporting changes becomes a matter of reconfiguring, typically in a graphical user interface, rather than recoding.
3. Provide greater interfacing flexibility. Supporting IHE profiles is a great idea, but as mentioned above the number of non-IHE compliant systems far exceeds that of compliant systems.
4. Support IHE profile variability.Despite best intentions, much of the code written to conform to IHE tests ends up being thrown away, introducing variability outside of Connectathon events.
5. Free up development resources.Configuration of interfaces utilizing middleware requires analyst level skills, allowing development talent to refocus on the core application.

Don’t believe me? Just ask the vendors who have used healthcare middleware with their products in an IHE Connectathon. They’re the ones taking coffee and snack breaks…

A recent article in Radinformatics highlighted the radiology workflow of one of our customers - EPIC Imaging. The article is entitled Look, No Hands: Reports Go Directly to Referrer EMRs. 

As the title implies, the article is about how EPIC Imaging implemented an electronic means to connect with various referring physician practices and send patient reports quickly, efficiently, and accurately. John Griffith is the CIO at EPIC Imaging, and he and his team have taken the initiative to solve the radiology workflow and operational challenge.

A few highlights from the article:

• Addressing Physician Requirements:  “The physicians wanted the reports to show up automatically in each patient’s electronic medical record (EMR). They wanted to open the patient’s EMR and have the report right there waiting for them, with no staff time spent clicking links or handling paper.”
• Maintaining High Service Levels:  “We have been held as the gold standard for providing service… but Epic administrators knew that if they were to retain that gold-standard mark in the face of increasing competition, they would have to answer the demand for electronic report delivery.”
• Delivering to the Physician - Choices:  “We could not have used a Web-based system because the physician would still have had to log in, look up the patient, and move the report into the chart… The demand was to get that report seamlessly into the chart with very little human interaction.”
• Leveraging Healthcare Interfaces:  “We had an existing interface that was sending results from our RIS to our PACS. We redirected that results feed to the NeoTool engine, and then NeoTool forwarded the report from there onto the PACS… Then, Epic constructed a rules base to tell NeoTool how to route the report to the referring physician’s EMR and directly into the patient’s electronic folder.”
• Achieving Positive Impact: 
  • “Clients, once interfaces are complete, will find report delivery much more convenient. That means that Epic will probably retain their business, or get more of it.”
  • “Quicker, more direct reports mean that patient care can be expedited. From the standpoint of eliminating human intervention and becoming more solidly electronic, we improve patient care.”

Since the above bullets are just clips from the article, take a few minutes and read the article. It provides great insights into how EPIC Imaging (case study PDF) understood their physician requirements and addressed them in a creative and operationally-sound way while also - and importantly - improving the way patient care is delivered. 

Congratulations to John and his team!

Yesterday I wrote an article about formatted documents and HL7 2.X. The focus of that posting was to suggest that in the real world HL7 does not control the formatting of a document on a receiving system.

René Spronk wrote an interesting reply that I did not want to get lost:

From the blog it isn’t clear whether you’d like HL7 to address the formatting of documents or not. The fact that the FT datatype is rarely implemented seems to suggest that there is no underlying requirement. Otherwise, implementers would use it and request enhancement of those features (maybe even to make them mandatory) as part of the development standard of the v2.x standard.

The CDA standard (HL7 v3) contains markup with a functionality akin to FT. It focuses on medical content, not on font-size. CDA is usually displayed using a style-sheet - albeit one that the receiver chooses, which may be a different one than was used by the document creator.

In case of CDA HL7 leaves it up to the communicating parties to “contractually” agree to use a specific style-sheet. Whether or not such agreements are in place depends on the jurisdiction where CDA is used.

Are there uses cases and jurisdictions where it makes sense to give more control to the sender of how the receiver should view the data? Yes.

One of the enhancement requests for the next release of CDA (CDA R3) is to support a much larger set of XHTML tags for formatting. This is however a balancing act - I wouldn’t want to support all of XHTML (including scripting stuff) in a CDA. The more formatting we introduce in a CDA, the more we’ll be moving away from the actual content, and the more things will be focused on formatting. I’m not sure if we should go there…

As always, René made some great points; thanks for your comments. I think that users of HL7 (either 2.X or 3.0 family) wish for many things — mostly they wish that the standard will make their lives easier. Often they look to HL7 to “force” an application to do something that “seems obvious” to them and their world. In terms of document formats from the perspective of a sending application, they wish that their “pretty report” would be displayed correctly by the receiver.

Once a week I hear someone wish they could force that mainframe or mumps application (which was coded in the early 1980s) to take an HTML or PDF document.

“Why can’t it display bold text? Our paragraphs are not wrapping correctly! The reason people use our service is that we produce these great reports. It is one of our key selling features! We just hate to fax or email them. Can’t HL7 deliver the same thing? Can’t I force that receiving HIS/CDR/EMR at my customer site to take this document via an interface? What does HL7 say about that? Can’t HL7 make the receiver display this correctly? I wish this was easier!”

To answer the questions above, read my posting. In short, HL7 does not force a receiver to format a document in a particular manner.

As noted in René’s comment, HL7’s CDA standard is mostly focused on the content and coding of the information — the display or rendering was, IMO, a secondary aspect. In fact, one of the key points of CDA is that the same document can be rendered on many devices — cell phone, printer, HTML, thick client, thin client, PDF, etc. As noted by René, the receiver’s style-sheet controls the final display.

IMO, the major display advantage of CDA is that it provides a much more structured starting point. In theory, we no longer have to worry about boring stuff like word wrapping or section headers — these display features “come for free” with the style-sheet used by the receiver.

Hopefully as a community we will not lose track of the fact that what CDA is really about is coded documents — the “easier display” is just a bonus.

It is interesting, however, to note that often what real world users of either HL7 2.X or CDA want is a mechanism to get a document “nicely displayed” on the receiving system. Sure, the informatics geeks can talk about the coding/format of the document and how many places we have clever OIDS, but ultimately it seems that much of healthcare is still about paper documents. Kudos to the CDA visionaries who seemed to get this up front — allow for lots of coding but also allow for simple blobs of text split into sections.

HL7 does not provide a real world standard for controlling the display of text documents on the receiving system. While there are some rarely-implemented formatting codes provided in the Formatted Text (FT) section of HL7, often senders must deliver “plain, vanilla text” in order for a receiver to accept a text document via HL7 messaging. The receiver will then display the lines of text in whatever manner is appropriate for that application.

Typically this question comes up when someone is trying to ensure that text documents they send (such as a radiology report) will be displayed a specific way on a remote application. Asked another way, the sending HL7 user want to know if the receiving (remote) application will display the report in a given size font or a fixed-width font. The question revolves around the desire to put “low tech text formatting” in place to build things like tables, indented paragraphs, or even nicely word-wrapped paragraphs.

The reality is that HL7 messaging does not imply or demand that an application display a text report in any specific manner. If there is a need to ensure that the receiving application displays data in a specific way, the interface analyst must review the display mechanisms in the receiving application to see what is possible. The analyst must then change the message (text) format to work within those provided by the receiver’s display mechanisms. Typically the sender can not force the receiver to take a “pretty text document.”

The problems most frequently encountered when moving text reports are related to the size of the text, how long the lines can be, indenting text, the desire to make headers “stand out”, and how word wrapping is accomplished. All of these items are under the control the receiving application. In the real world, HL7 has no opinion on these issues.

Often applications support moving rich text documents via either an ED or RP data type. This means that the sender can deliver a PDF, Word document, RTF document, HTML document, etc — but only if the receiver supports the format. More details on rich documents are provided in this blog posting.