NeoTool — Singular Focus, Healthcare Integrated

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!

By now, you may have had enough of primaries and election results. What if, however, we applied the primary election process to healthcare standards? What would happen? 

Just as there are factions the political candidates are trying to pull together to win, they probably have not seen as many factions as there are in healthcare standards. There is a major faction called the HL7 Standards, but emerging factions are getting noticed which are XML related - from Continuity of Care Record (CCR) to a faction-within-a faction, that is, HL7 V2, HL7 V3, HL7 Clinical Document Architecture (CDA), and HL7 Continuity of Care Document (CCD).

We don’t need new healthcare standards. We just need to enforce the ones we have.

What about the X12, DICOM, NCPDP, ASTM, LOINC, and SNOMED factions? And, let us not forget the common person’s healthcare standard - plain ol’ CSV file formats.

If the United States was going to eventually elect a healthcare standard to lead us in the 21st century, which one would win? All we need is a little harmony.

Harmony may be over-rated. How could someone from SNOMED endorse the LOINC? What do you mean CCR is campaigning with CCD? If these events happened, some people may just sit out the healthcare standards election.

What about the special interests? Each healthcare vendor has their own standard. Let’s hope that someone doesn’t “swift boat” one of the healthcare standard candidates.

The campaign slogans:  Healthcare standards are broken. We just don’t need to move the same standards to different chairs. We need to stand for change. We need hope! We need a healthcare standard ready to solve all of our problems Day 1!

Or, maybe what we need is another healthcare standard - a “third party” candidate - that can just end all of the “politics” and work for the people in health care. A “uniter” of healthcare standards. Some standard that can “reach across the aisle” and reach consensus.

Can’t we all just get along in the healthcare integration world?

Yes, this is a parody of sorts on healthcare standards, but it is the practical world that we live in. There are many standards, and we do all need to get along in order to deliver the best possible care for patients. Each healthcare standard faction delivers an essential piece in the healthcare puzzle, but putting the puzzle together can be challenging at times.

Maybe the final rallying cry should be:  “Read my lips. No new healthcare standards!”

For those who have been involved with the HL7 Standards over these past decade, there has been a slow evolution to expand the standards, change the approach (i.e., HL7 V2 to HL7 V3), and include clinical documentation. Healthcare integration initiatives are benefiting from the changes, but confusion rises as to the differences and the growing complexity.

One question that arises is:  what is the difference between HL7 messages and HL7 documents? Outlined below is quick review of differences.

HL7 Messages:  HL7 messaging is usually a real-time flow of patient and clinical information. They convey current information about a patient, including updates to admissions or discharges (ADT), orders for tests (ORM), and test results (ORU). The more current the data, the more relevant it is in the delivery of patient care. HL7 messaging impacts the ongoing process of delivering care by delivering the most current, updated patient information available.

HL7 Documents:  HL7 documents are static - accurate given the point-in-time in which the information was captured. HL7 documents contain important information, but it is a snapshot. The documents are useful in providing relevant information in referrals to other physicians or healthcare organizations. Accordingly, it provides a starting point for the next step in patient care.

The differences in HL7 messages and HL7 documents can be summarized as active vs. passive information. HL7 messages are continuously delivered as status changes or new information is obtained. HL7 documents contain information at one specific point in time. Both are critical, however, especially when delivering connectivity or integration to Electronic Medical Record (EMR) applications in various healthcare provider offices.

How do the healthcare standards apply? In HL7 messaging, HL7 V2.X and HL7 V3 apply. In HL7 documents, HL7 Clinical Document Architecture (CDA) and ASTM Continuity of Care Record (CCR) standards apply. Both approaches deliver value to healthcare integration initiatives.

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.

A recent Physicians Practice article entitled Technology: Should Your EMR Be Certified? provides an interesting give-and-take on the Electronic Medical Record (EMR) CCHIT certification process.

The Certification Commission for Healthcare Information Technology - CCHIT - is a private organization that offers a voluntary certification process for EMR vendors. To achieve certification, the vendors must complete tasks in 40 categories (the article highlights all 40 categories). The features and functionality tested are general in nature, but the plan is to introduce certification for specialty areas, including emergency medicine, cardiovascular, etc.

With over 200 EMR vendors, finding the right solution for a physician practice was challenging, so the certification process provides a quality check on core functionality and, in the process, has jump-started market adoption. On the possible downside, adding feature after feature may be overload for some practices, and the certification process does not test ease of use of these features. As a result, an EMR may have more features than needed, and it may be very inefficient to use (e.g., too many clicks to enter or retrieve patient information).

Another gap is interoperability or healthcare integration. Although the objective is to introduce more healthcare integration criteria to the CCHIT certification process, buyers will need to determine the ease of interfacing with other systems such as billing, laboratory systems, radiology systems, etc.

Certification, consequently, is not the final stop in selecting an EMR that may be right for your practice. Key actions still need to be taken in evaluating an EMR application. Suggested additional evaluation steps are:

• Work with the application to determine ease of use - get “hands-on” with the EMR
• Talk with existing users to determine experiences - good and not so good - with the product and customer support
• Create healthcare integration scenarios to ensure that the EMR can easily interface with other healthcare vendor or provider applications

As one of the IT consultants in the article states, “Create a scripted patient exam for the vendor to follow when they demo the product. Otherwise, it becomes just a show of bells and whistles instead of showing you how it would work in your practice.”

As you read this, do you know the status of every clinical interface in your environment? Unfortunately, a common answer to this question may be, “I have not received a call from anybody, so everything must be fine.” 

What needs to be monitored in HL7 messaging? Some examples include:

• Guaranteed message delivery
  • ACK vs NACK
  • No response
• Connection status
  • Started
  • Connected
  • Messages moving
  • Messages backlogged
• Errors in message processing
  • Invalid HL7 structure
  • Invalid message data
  • Database interaction issues
• Machine issues (e.g., hard drive space)

The question remains:  Do you know the status of every clinical interface in your environment? What if you could answer this question confidently and say, “Yes, I know my interfaces are all running without an issue?” How can you get to this level of confidence in your healthcare integration environment?

To get to this level of confidence, you will need interfaces that are capable of monitoring themselves. When unexpected events occur, the interfaces need to be able to recognize these events and alert the IT staff that there is a problem, and it needs immediate attention. With this level of alerting, often times HL7 messaging and communication problems can be diagnosed and resolved before the clinical staff knows they even existed. 

In today’s fast paced world, doctors need to have access to information as soon as it’s available. If the interface between two clinical applications is down, the delivery of critical patient information cannot be completed.

You don’t have to be around interfacing long to talk to somebody who has a horror story about an interface that went down, but nobody knew it was down for hours or even days. This is a common problem that many healthcare providers are facing today. These types of problems are occurring in a very controlled environment, on a local network, within the walls of a single organization.

As healthcare evolves and the communication and sharing of information continues to expand beyond the four walls of a provider organization (e.g., to a regional or  nationwide sharing environment), the importance of self monitoring interfaces and pro-active alerting becomes increasingly important.

If you’ve been in healthcare integration for any amount of time, you’ve probably seen an HL7 ORU^R01 message. As we like to say at NeoTool, if you’ve seen one HL7 message, you’ve seen one. This is especially true in the case of an ORU^R01 message. The following example illustrates some possible variations to this message.

Scenario: An imaging center (IC) is receiving some order messages (ORM^O01) from 2 external hospitals for which they complete the orders and send back transcribed reports (ORU^R01) in an HL7 standard format. The IC is also completing their own internal orders, and the resulting reports need to be routed to their internal PACS system. Overall, there are 4 separate systems involved. In the world of HL7 messaging, this often means there will be 4 custom formats of the transcribed report.

Original Message from RIS/Dictation System:
Notice that the message is loaded with Z-segments. These Z-segments will most likely need to be stripped out of the message that will be delivered to the other 3 systems. Also, notice that in the OBX segment each line of the transcribed report becomes a separate repetition of the OBX-5 field (separated by the ‘~’ character).

MSH|^~\&|System1||||200707090801||ORU^R01|3542196||2.3
PID|1|000-0000|||”"|1922974|151-76-5760|||||||||||N
ZPI|1|N|N|N|N|N|”"|”"|”"|”"|”"| | | | | |”"|N|0|0|0|0|0|0
PV1|1|2|||||||| ||||||N|| ||
ZVI|1|”"|”"|”"|”"|”"|N|0|0|”"|”"|N|N|N|N|N|”"|”"|”"|”"|”"|0| | | |/NONE/
IN1|1|P|||||
ORC|RE||2060059||||^^^200707061707^^ ||200707051013|DIONA |||”"|||1007
OBR|||2060059|999991^Knee MRI WO| |200707061707|200707061621|200707061707||||”"|”"|||
ZOR|1|1831236|X|1|01|66696|2| |”"|”"|”"|
ZEX|1|2060059|5|G|CC11043257 |R/O MMT|1004959042 CASE # VERIFIED ONLINE DGC|APRV^APPROVED|200707090801||||||||||||0|0|0|0|N|N|N|N|N|”"|”"|”"|”"|”"||EOK
OBX|1|TX|||PROCEDURE: MRI OF THE LEFT KNEE WITHOUT CONTRAST~ ~HISTORY: Left knee pain for three months. Patient experienced a “pop” in her knee when playing tennis.~ ~TECHNIQUE: MRI of the left knee was performed on the 1.5 Tesla magnet operating at ECIC. Images were obtained in multiple planes and with varying pulse sequences. No contrast was utilized.~ ~FINDINGS: Comparison is made with radiographs of 6/22/07. These demonstrate a small joint effusion but otherwise unremarkable. ~ ~There is a very small joint effusion noted. There is also a small popliteal cyst on the posteromedial aspect of the knee.~ ~The anterior cruciate ligament is nearly completely torn with only a very thin strand of the anterior ventral fibers remaining intact. This involves the proximal third of the ligament. The posterior cruciate ligament is intact. The collateral ligaments are intact although the medial collateral ligament demonstrates mild thickening. ~ ~In the lateral compartment there is a mild impaction fracture near the sulcus terminalis of the lateral femoral condyle. There is a mild resolving contusion present on the posterior lip of the lateral tibial plateau. Along the periphery of the posterior horn of the lateral meniscus there is a subtle area of linear increased signal concerning for potential vertical meniscal tear. This would be in the excepted location of the red zone. ~ ~In the medial compartment, the meniscus is intact. No articular cartilage defects are seen. ~ ~In the patellofemoral joint the articular cartilage is intact. ~ ~IMPRESSION:~ ~1. Findings are consistent with a high grade, probably unstable, near complete tear of the anterior cruciate ligament. ~ ~2. Small peripheral vertical tear through the excepted location of the red zone of the posterior horn of the lateral meniscus.~ ~3. Contusions in the lateral femoral condyle with a mild impaction fracture at the sulcus terminalis as well as in the lateral tibial plateau consistent with a pivot shift mechanism of injury. ~ ~4. Small joint effusion and small popliteal cyst. ||||||F

Now, to illustrate how non-standard HL7 can be challenging, take a look at how the following 3 receiving systems are expecting to receive the transcribed report.
1. Internal PACS System
This system does not support the PID,PV1,IN1,ORC or any of the Z-segments. All these segments must be removed to make this message conform to the specifications of the PACS system.

MSH|^~\&|System1||||200707090801||ORU^R01|3542196||2.3
OBR|||2060059|999991^Knee MRI WO| |200707061707|200707061621|200707061707||||”"|”"|||
OBX|1|TX|||PROCEDURE: MRI OF THE LEFT KNEE WITHOUT CONTRAST~ ~HISTORY: Left knee pain for three months. Patient experienced a “pop” in her knee when playing tennis.~ ~TECHNIQUE: MRI of the left knee was performed on the 1.5 Tesla magnet operating at ECIC. Images were obtained in multiple planes and with varying pulse sequences………

2. External Hospital 1
This Hospital Information System (HIS) does not support multiple repetitions of the OBX-5 field for each line of the report. Instead each line of the report must be contained in its own OBX segment. Also, all Z-segments must be removed.

MSH|^~\&|System1||||200707090801||ORU^R01|3542196||2.3
PID|1|000-0000|||”"|1922974|111-22-3333|||||||||||N
PV1|1|2|||||||| ||||||N|| ||
IN1|1|8129||UNITED HEALTHCARE||||700049||P|||||
IN2||151-76-5760|||||||||||||||||||||||||||||||||||||”"|||^^ |||||
GT1|1|1075861|^”"^”"^”"||ALBUQUERQUE^NM^87111|||19711101|F|P|1|
ORC|RE||2060059||||^^^200707061707^^ ||200707051013|DIONA |||”"|||1007
OBR|||2060059|999991^Knee MRI WO| |200707061707|200707061621|200707061707||||”"|”"|||
OBX|1|TX|||PROCEDURE: MRI OF THE LEFT KNEE WITHOUT CONTRAST
OBX|2|TX|||
OBX|3|TX|||HISTORY: Left knee pain for three months. Patient experienced a “pop” in her knee when playing tennis.
OBN|4|TX|||
OBX|5|TX|||TECHNIQUE: MRI of the left knee was performed on the 1.5 Tesla magnet operating at ECIC. Images were obtained in multiple planes and with varying pulse sequences. No contrast was utilized.
OBX|6|TX|||
OBX|7|TX|||FINDINGS: Comparison is made with radiographs of 6/22/07. These demonstrate a small joint effusion but otherwise unremarkable.
OBX|8|TX|||
OBX|9|TX|||There is a very small joint effusion noted. There is also a small popliteal cyst on the posteromedial aspect of the knee
…
…
OBX|32|TX|||Small joint effusion and small popliteal cyst.||||||F

3. External Hospital 2
This HIS has no inbound results interface. Therefore, the reports are delivered to the inbound transcription interface. In this case, the ORU^R01 message must be converted to an MDM^T01 message. Also, they do not want the text of the report to be contained in the body of the HL7 message. Instead, they want the text written out to a formatted RTF file, complete with a report header and saved to a local share on their network. The path to this file needs to be included in TXA-16 (example C:\InterfaceShare\reports\42077460200.rtf). Notice also that the backslash characters (\) in the path need to be properly escaped using the HL7 escape sequence \E\.

MSH|^~\&|System1||||200707090801||MDM^T01|3542196|P|2.3
EVN|T01|200707090801|200707090801
PID|1|000-0000|||”"|1922974|151-76-5760|||||||||||N
PV1|1|2|||||||| ||||||N|| ||
TXA|1|DI|TX|200707191339|1578|200707200812|”"||1578||XI|42077460200||200|| C:\E\InterfaceShare\E\reports\E\42077460200.rtf

The interfacing challenge above was accomplished using an interface engine. The flexibility of the HL7 standard allows an interface engine to receive any format of HL7 and modify the data to be delivered to multiple destinations in the custom format that these systems require. Without this technology, these systems would have to create custom point-to-point interfaces in order to share information.

For more information on working with ORU messages, listen to a 15 minute presentation to learn more.

In this post, we interviewed Brian Moreau, IT Director, Henry County Health Center. Henry County Health Center was recently recognized as being one of the Top 100 Most Wired hospitals in the US by Hospitals & Health Networks magazine. Below is the interview with Brian.

What was the evaluation process to become one of the ‘most wired’ hospitals?
Henry County Health Center raised its hand to participate in the 2007 Most Wired Survey and Benchmarking Study sponsored by released Hospitals & Health Networks magazine. It is a detailed study that covers how Henry County Health Center uses information technology to address five key areas:  safety and quality, customer service, business processes, workforce, and public health and safety.

What was it that motivated you to undertake this initiative?
In 2003, the Henry County Health Center management team developed a strategic plan in which being a “Most Wired” hospital was one of the key elements. We knew it would be important to advance our information technology efforts in order to deliver the right type of care and services to our patient community. 

In Good to Great, Jim Collins talks about the flywheel concept. If everyone in the organization is pushing on the flywheel – moving initiatives forward turn-by-turn, momentum is gained. It is a continuous improvement effort over time. This is illustrative of our approach – everyone was involved, and we made significant incremental improvements over time.

We had initiatives to realize our strategic plan, including physician chart, electronic medical records (EMR), website additions for patient education and personal health manager, etc. These initiatives were not single stroke, bold implementations, but many people working hard and strong focus on improving turn-by-turn.

For us, it came down to setting a vision, and sticking to it. We kept the discipline to stay with it.

As part of your strategic plan, what was the level of focus on workflow?
It was one of the key elements, and one in which technology can play a significant role in advancing and streamlining various operational processes and patient flows.

One of the key workflows for our hospital was the relationship with ambulatory clinics. To enhance the flow of patient order and results, bi-directional communication was essential. A significant tactic to enable this was purchasing and implementing an interface engine. In a recent article – IT Performance Excellence, I highlighted how we used technology innovatively to make workflow easier and connect effectively with our doctors.

What about patient flow specifically?
The patient experience has changed significantly. With the advances that we have made, patients now have educational content they can access from our website; patients can pay bills on-line; patients have access to health calculators; and patients have access to a personal health manager. Basically, much more relevant information is now available to our patients in a convenient, accessible manner.

Another patient flow enhancement is the efficiency that they experience. Physicians have immediate access to a patient’s information. EMRs and healthcare integration technology have positively impacted efficiency, accuracy, and access – all which enhance the patient’s experience.

The physician’s experience has changed as well. The physician now orders requested patient tests electronically and receives the results back electronically in their EMR system. No paper, no scan … radiology, laboratory, etc. results are seamlessly received in a faster turnaround time. With these changes, quality is enhanced and greater efficiency realized, positively affecting both physicians and patients equally.

One of the ten lessons from the top 100 hospitals was that infrastructure is key to the future. What are your thoughts on that lesson?
In my view, infrastructure is a fundamental responsibility of IT. We need to advance, protect, secure, and unify it. Infrastructure is a very important piece of the puzzle. We need to deliver all of the elements that I just mentioned while ensuring that it is reliable. In the end, infrastructure translates to patient safety and quality.

What lessons have you learned in working through this process?
Two key lessons learned:  never give up or get discouraged, and never make excuses. 

On the “never give up” principle, there are many great people on my team and throughout this hospital that made the strategic plan happen. Their work and diligence enabled our achievements and recognition. Whether we realized it or not, we were all advancing the “flywheel,” and together we realized a significant transformation in how we deliver care in our community.

With the “never make excuses” principle, saying you cannot afford it is not an answer. There are good vendors willing to work with you. Find them. From medical content to health management to interface technology, we found great vendors willing to work with us.

This is a team effort across the spectrum:  people, physicians, patients, and partners.

What’s next?
We are done celebrating. We want to continue our success, so we have a number of initiatives to “keep pushing on the flywheel.” Initiatives include a new CPOE system, redesigning our website, electronic documentation, etc. We look forward to our work ahead.