NeoTool — Singular Focus, Healthcare Integrated

As noted in HIS-Talk, Former Meriter Hospital CIO Peter Strombom has written an interesting article on Wisconsin’s progress towards a regional health information exchange (RHIO). Peter’s history and thoughts are very pragmatic and, IMO, on target; I thought I would share some quotations.

The motivation behind Peter’s article is that, like many areas of the US, Wisconsin has been talking about building a RHIO (or two) for a long time. The current challenge is architecting the system and ultimately paying for it. The state has issued an RFP asking for help designing the architecture. Costs for the total deployment are estimated at $1.2B and are, presumably, to be funded by the providers.

Peter makes some great points about:

1. The fact that we’ve been at this “regional interoperability game” for a long time.
2. RHIOs are the latest name for an old idea
3. Peer-to-peer communication (rather than centralized “control”) has a better chance of success
4. Good discussion of political v. economic v. quality of care motivations for interoperability
5. Providers must be using electronic records before they can be exchanged, well, electronically
6. On-going work to firm up standards will help with interoperability

Two counter points I would make to Peter’s thoughts:

1. I do not think that the banking analogy Peter uses is a good one. The banking world has (effectively) centralized control over the SWIFT and related networks. A better analogy would be peer-to-peer file sharing networks — heck, if we can share MP3s in an ad-hoc-yet-organized-way, surely we can share healthcare records.
2. IMO, the CCHIT is not the total driver for peer-to-peer interoperability. HL7 (among others) has been working on this problem for a long time and, again IMO, CCHIT is effectively profiling existing standards rather than creating new standards.

Selected quotations from Peter’s article:

[In November 2005 Wisconsin’s Governor] called for “a statewide eHealth infrastructure […]. [P]resident Bush’s State of the Union Address [in January 2004] stated that “By computerizing health records, we can avoid dangerous medical mistakes, reduce costs, and improve care.”
…
The statements were both politically appropriate at the time, but as of June, 2008, little has been achieved in Wisconsin.

We have been at this for a long time. The CHINs (community health information networks) of the mid-1990s were an idea that had merit but was not adequately supported by the technology of the day. The RHIOs (regional health information organizations) of later times were also a great attempt at interoperability but suffered from lack of community acceptance and viable business plans to sustain them. It is telling that only a handful of RHIOs continue in business from the several hundred that were founded on initial seed money only to fail when those funds became exhausted. The poor support from the healthcare providers and the payer community, and the absence of inspirational insight into the opportunity being presented to us by the technology, contributed to the lack of success of what I will call the second generation of this approach at interoperability.

Presumably, the healthcare provider and payer will bear the cost of this process. […] Importantly, to be viable, the plan further assumes that all healthcare providers in the State of Wisconsin will maintain patient records electronically. This is not the current or the foreseeable situation, as many small hospitals and physician practices do not have the available funding to achieve this goal with only their own resources.
…
Application (systems) vendors in healthcare are working together under the auspices of the Certification Commission for Healthcare Information Technology (CCHIT) to develop standards for interoperability. By working together it is planned that their output will become accepted as was the HL7 interface standard. A peer-to-peer network with communications between healthcare providers using software from the same or different software vendors and based on the CCHIT standards could follow a model based on the Banking system model.
…
This peer-to-peer network lends itself to progressive growth and expansion, as warranted as additional providers implement electronic medical records systems. Importantly, a sustainable business plan at the operations level is not needed to finance the exchange of key clinical information in a time of need.

At last week’s HL7 Working Group meeting, it became clear that US adoption of the HL7 Version 3 Standard is still years away, with one lone exception:  Clinical Document Architecture (CDA). 

It seems as though implementation of the larger standard is still seen as a herculean task, requiring not just a rework of HL7 2.X import/export modules but also a potential overhaul of applications’ underlying database schema and object model. But the Structured Documents committee (SDTC) has done a nice job of achieving one of its primary design principles concerning HL7 CDA – minimizing technical barriers to implementation. That mantra has no doubt helped the SDTC create a standard that comprises the ‘piece’ of HL7 V3 that American vendors are willing to incorporate in the not-so-distant future.

Given the lack of a national mandate to move to HL7 Standard V3 that exists in other countries, as well as the lack of demand for V3 in the US marketplace, CDA could be the much needed beachhead for the standard in this country.  As more and more vendors implement CDA and get a small taste of the V3 methodology and associated benefits, the more adventurous (and deep-pocketed) software providers will tip-toe further into the newer HL7 standard.

Until then, the burning question remains:  which comes first – provider demand for or vendor support of V3?

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.

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…

HL7 Standards Update. HL7 2.X continues to march forward with new releases. HL7 2.6 is done (just published this week) and proposals for 2.7 have closed — the first ballot for HL7 2.7 will be in May 2008. From a practical perspective, this means that 2.7 will hit the streets sometime in late 2009.

Most users of HL7 2.X don’t pay attention to the newer releases of HL7 (both HL7 2.X and 3.X) because these current users are building interfaces between existing applications. These applications typically have “more-or-less 2.3″ interfaces and, broadly, those interfaces are “good enough” for most users. There is a comparatively small group that helps create new releases of HL7 or that has an opportunity to improve a vendor’s interface by upgrading to a new release of the HL7 Standard.

It is always interesting to see how the HL7 community continues to push HL7 2.X forward. It is fair to say that HL7 2.6 and, soon, HL7 2.7 are better standards than prior releases. They both have more functionality, better descriptions, and fewer errors.

In a free market, buyers choose (directly or indirectly) the version of HL7 they ask their vendor to create. With time, I hope that many vendors will move to the more-complete standards. In the United States, we must rely on market (buyer’s) pressure to ask purveyors of software to improve the functionality of their interfaces.

This blog post was entered in NEOTOOL’s HL7 Blogging Contest.

Healthcare integration plays a critical role in streamlining billing workflow. As highlighted in an earlier post, the HL7 Standard and HL7 messaging facilitates a more effective data flow.

Healthcare billing departments are dependent on getting accurate information in a timely manner to meet their goals, such as increasing cash flow and decreasing operational costs. Getting the needed patient information and charge capture data can be accomplished using HL7 interfaces.

Automating your environment with HL7 interfaces leads to many tangible and intangible benefits for your billing facility including:

• Increased accuracy with reduced manual entry
• Increased Turn Around Time (TAT) with data flowing to billing in near real time
• Decreased paper records storage and office space with electronic data (digital archive)
• Fewer denied claims due to timely and complete information
• Increased cash flow with lower DSO (Days Sales Outstanding)
• Improved data retrieval - faster, searchable, simultaneous access by multiple users
• Increased patient satisfaction with more accurate billing
• Increase efficiency

As a result, your operations will be more competitive, profitable, and streamlined. To learn more, read another blog post on how to streamline your billing workflow.

Every healthcare environment bills for services provided. The goal of billing is to increase reimbursement in a timely fashion. How does the HL7 Standard help in this endeavor? Automating clinical data delivery through HL7 interfaces provides accurate information quickly to the billing department.

When transferring patient’s billing information through HL7 messaging, it is helpful to know some of the key segments in which to find the data.

PID: Patient Information
PV1: Visit Information (DOS)
FT1: Financial Transaction
IN1: Insurance Information
IN2: Additional Insurance Information
IN3: Additional Insurance Info, Certification
GT1: Guarantor
AUT: Authorization Information

A better understanding of the HL7 messages used in various billing environments may help demonstrate the possible automation and healthcare integration capabilities.

1) In acute care hospitals, the billing department is typically in-house. As a patient is treated, the clinical data is transferred to the appropriate departments throughout the hospital, including billing. The main HL7 messages transferred to billing are:

ADT = Patient demographics
DFT = Detailed financial transaction
ORU = Observation result unsolicited

Below is an example DFT message that shows the addition of a test, Lipid Panel, to a patient’s bill:

MSH|^~\&|FrapLab|StJohn|HIS|StJohn|20071217094822||DFT^P03|MSGIDv|P|2.3
PID||3|82828||Simpson^Margaret^^^Mrs.||19650525|F|||12 Maple St.^^Springfield^OH^21003^USA
PV1|4||^22^1||||2360^England^Mikey|||IP|||||||||4|||||||||||||||||||||||||20071217094755|20071217094813
FT1|1|6|4|20071217094821||Credit|303756^Lipid Panel^L|||2|115

2) For reference laboratories or independent commercial labs, the billing department handles two types of billing: client and patient. Client billing is where the lab bills the services back to its client, the doctor’s office, clinic, etc. Patient billing involves third party billing based on patient coverage or direct bills to the patient. If the lab receives orders electronically via an HL7 interface, then the order message (ORM) may contain the needed billing information. Below is an example order for a serum Vitamin C test for a patient with a primary insurance carrier being Medicare:

MSH|^~\&|SNDAPP|SNDFAC|RCVAPP|RCVFAC|200710021226||ORM^O01|DCGTORD.2.79
|P|2.4|
PID|1|89300043|||MOUSE^MICKEY||19600505|M||||||||||1259801|999-00-888|||
IN1|1|UNK.|MR1|MEDICARE/COMMERICAL|P.O. BOX C32086^^RICHMOND^VA^23261||-0000000000|499032980||||00001231|00001231||MC|O
DONNELL^RICHARD^W^^|1|-19221027|7982 WELLINGTON DR^^WARRENTON^VA^22186^USA||||||||||||N||||-|499032980-A|||||||M||
GT1||ODONNELL,RICHARD w||7982 WELLINGTON DR^WARRENTON^VA^22186|-7033492732|||
ORC|NW|L2435^LAB|^LAB||||1^^^^^R|||||23462^ALVAN^^^||
OBR|1|L2435^LAB|010700^VITAMIN C (ASCORBIC ACID), SERUM^L||||20071002122600||||N||SICK|||23462^ALVAN^^^||||REQ#5468|||||||1^^^^^R|

3) Finally, an independent imaging center takes on the task of billing the technical and professional components of its services. The professional reads they do for hospitals or referring physicians require the patient’s billing information and the final reports for coding. The patient information can be sent via paper (e.g., faxing), sent electronically through an HL7 interface (ADT, BAR, or DFT messages), or sent via a file batch with a proprietary format. The reports used for coding can be transmitted using HL7 ORU messages.

An example BAR message that creates a new account with needed billing information follows:

MSH|^~\&|BRACK|CHA|FIN|5|040112043835||BAR^P01|0000000001|T|2.3|
PID|||3000222452||JONES^SAM^A||19931114|M||||||||||1546740|666381774|
PV1||I|BRACKENRIDGE|||||023434|||||||||023434|||||||||||||||||||||||||||20031121||
GT1|0||JONES^ANN^M||756 E FANNIN ST^^LAGRANGE^TX^789450000|9799660489|||||M|||||CARE INN|457 NMAIN^^LAGRANGE^TX^78945|
IN1|1|T71|||MEDICAID

For additional information, watch a 15-minute web seminar on the role HL7 messages play in different healthcare billing environments.

In the HL7 Standard, there are two versions that people think of - Version 2 (V2) and Version 3 (V3). Outlined below are some of the differences between V2 and V3.

HL7 V2

• 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
• Historically built in an ad hoc way because no other standard existed at the time
• Generally provides compatibility between 2.X versions
• Messaging-based standard built upon pipe and hat encoding
• In the U.S., V2 is what most people think of when people say “HL7″

HL7 V3

• Approaching “Plug and Play” - less of a “framework for negotiation”
• Many decades of effort over ten year period reflecting “best and brightest” thinking
• NOT backward compatible with V2
• Model-based standard built upon Reference Information Model (RIM) provides consistency across entire standard
• In the U.S., when Clinical Document Architecture (CDA) is what most people in the U.S. think of when people say “HL7 V3″

Learn more about preparing for HL7 V3 or more about the HL7 standards, including HL7 V3, through an in-depth white paper entitled The Evolution of HL7 (PDF).

For a 15-minute recorded presentation on HL7 V3, please click here.

It is possible to send a PDF file inside of an HL7 message. However, it is not a simple “encode and send” process as there are many moving pieces that allow a document file to be moved across an HL7 interface. The key question is not what the HL7 standard says about document encoding or even what the interface engine can do with the document. Rather, the focus should be on how the PDF file will be delivered to and from the source and destination application and how the target application will display the document.

The options to move a PDF document include sharing the PDF via a file system (network shared drive), sending the file via HL7 as an ED (encapsulated data) data type, or including a URL to the PDF file via an RP (reference pointer) datatype. The complexity of each solution varies wildly based on the vendors involved.

To begin, start with the answer to this question: How will the source application provide the PDF file and how will the destination application(s) receive the data?

The second question to answer: Once the document is received by the target application, how will that receiving application file it correctly into the patient chart? For example, if you send two PDF files (one pathology report and one ED summary), how will the receiving application know onto which tab of the patient chart the document should flow? Specifically, as a user, I’d hope the path report would appear somewhere on the “lab results” tab. I’d also hope the date of the report would appear next to the paper clip (or whatever) icon to tell me a “scanned report” was available. These questions about how and where the document will appear are much more challenging than, “How do I encode a PDF file in HL7?”

The actual encoding of the document is often done via either an ED or RP datatype inside of an ORU message. Review these prior blog postings for details:

• How Do I Send a Binary File Inside of an HL7 Message?
• Sending Images or Formatted Documents via HL7 Messaging
• HL7 OBX Segment

An Imaging Economics article - The Purview of the PACS Administrator - highlights the critical components of a PACS Administrator’s role that impacts radiology workflow. It is a great article because it outlines many of the key knowledge and work activities required to be an effective PACS Administrator. More than ever, PACS Administrators contribute significantly to defining, enabling, and refining radiology workflow.

Key Knowledge of a PACS Administrator. DICOM is always the healthcare standard people think about when radiology workflow is mentioned. Today, the knowledge required has expanded to include the HL7 Standard. HL7 integration is the standard that facilitates the data flow between the various applications (e.g., RIS, HIS, EMR, PACS, etc.) and streamlines the workflow by automating various activities. It is refreshing to read an article about PACS Administrators that acknowledges the HL7 Standard as a required element to gain efficiencies in a radiology practice or department.

Key Work Activities. PACS Administrators play an essential role in defining radiology workflows, re-engineering radiology workflows, and enabling radiology workflows with the right technology. This requires the PACS Administrator to have strong interpersonal skills along with strong communication, project management, IT, and healthcare standard skills.

Other key activities include monitoring the data flow, ensuring it is continuous so that a radiologist’s workload is even throughout the day. Again, this article points out it is not just the PACS that needs monitoring but also the integrated systems and interfaces. Seamless workflow requires integrated systems, which also requires flexible and robust interfaces between the various applications. The PACS Administrator is required to know more about data flow between all the systems that eventually touch the PACS or are eventually touched by the PACS. 

Equally important is data quality. Automating data flow through the systems and applications removes the opportunity for keying (re-keying) errors; additionally, it means that the data needs to be translated into different formats correctly in order to meet the various applications’ requirements.

As we have discussed in other posts, the PACS Administrator plays many different roles and the responsibilities and knowledge required have grown. In this healthcare IT article, Imaging Economics has delivered this message very competently.