Archive for the ‘Healthcare Integration’ Category

Do you remember your first interface?

If you do, chances are likely that it was a custom point-to-point interface, very expensive, took many months to finish, and it did not necessarily meet all of your needs. Right?

Ouch. Let’s not go back to that ever again.

Welcome to the next generation of integration = faster, better, and cheaper. Interfaces can now be done in hours. They are also designed to meet specific needs, and the cost can be contained, i.e. minimize the customization on the vendor sides.

Believe me, this is true, though it sounds too good to be true. I understand because I, too, was a non-believer when I worked for one of those vendors.

The typical process as I remember it back then looked something like this over a year, if I were lucky:

1. Customer calls to explain they need an interface
2. Customers are redirected to inside sales to get a quote
3. Customer approves quote
4. Request is sent to the integration team queue
5. After the queue wait time which could be weeks or months, the request is evaluated
6. Specifications for the interface are discussed, documented and confirmed
7. Interface goes to the development black hole
8. Months later, you are told the interface is in your test environment for testing
9. You test and it doesn’t work
10. Repeat steps 8 and 9 until it works and pray it does not fall out of the scope such that you end up back at step 6
11. Plan, schedule and deploy into production
12. Troubleshoot production issues until interface stabilizes

I failed to mention the organizational politics and red tape, the lack of response or interest after time, and attrition over the year for any or all of the parties involved.

Whew!

Then when you think you are done, the support burden kicks in. It was amazing to see from the vendor perspective that the interfacing module (20% of the product) caused about 80% of the support tickets that could only be supported by less than 20% of my staff.

Interfaces were downright no fun.

That was then, this is now.

Now, I can configure an interface to go into system testing in minutes to hours. Interfaces can go live in days, or a few weeks at most. All the interfaces can be centrally monitored. I get proactive alerts if something is wrong rather than a call from the floor, tech, or doctor.

May not perfect, but life is much better with the new technologies in the integration world.

You understand HL7, its purpose and use, and you are ready to establish interfaces for your integration engine. What should you be sure to do as you move those interfaces into production?

We asked a senior implementations consultant at Corepoint Health, Alex Lin, to provide his top three suggestions:

Test the workflow.

Before moving an interface into production, it is important to test the workflow of data from “end to end.” A well designed interface engine will have tools to test messages and is able to show you the results without actually needing the end points. If you can prove that your messages are properly filtered and mapped, you should be able to test with vendors with confidence in your work.

After you are sure you have your part right, the messages should be monitored as they interact with system firewalls and various networks. Firewall preferences and network settings tend to be unexpected road blocks for developers as they are different for each application and organization. They can, however, have a dramatic impact on time and money spent in establishing interfaces; so be sure to remember to test the message interaction.

Communicate with vendors.

As mentioned in previous blog posts regarding the development and use of HL7 interfaces, it is important to always communicate with vendors prior to interface implementation. Test the connections with test messages (provided by the vendor) to prevent any errors that could occur when real data is at stake.

Also, take advantage of testing scenarios as an opportunity to become acquainted with the customer support side of the engine vendor. It is possible that you may learn a more efficient method for mapping workflow, discover a new and helpful feature or simply make a contact for the times when you need to call on support. Having a relationship established with a support team that is familiar with your workflow can improve the quality of that experience.

Utilize monitoring and alerting tools.

Some interface engines provide proactive features such as monitoring and alerts, in addition to basic message translation and routing. Identify the features available with the engine to test your interfaces for errors and general performance. The alerting and monitoring features available within an engine can have a profound impact on an organizations’ experience.

An interface in production can be a smooth running machine and monitoring and alerting will help you know when all is well or when something needs attention. Face it. No one wants to hire someone to “babysit” connections all day.

Although establishing interfaces with an interface engine can be a quick and simple task, it is important to test the workflow and integration engine prior to moving the interfaces into production and to communicate with vendors at all times.

Taking these three steps can significantly improve the implementation experience, in addition to minimizing the time and money that could be spent if an error were to occur.

Additional resources:

• HL7 Interface – An Overview
• Distributing Results: Message Routing
• HL7 Terms – A Topic Category

In a recent poll, we asked our readers who they felt would benefit the most from the recently released meaningful use standards and incentives. The results indicated that meaningful use is understood to be focused on the improvement of patient care, and there is a belief that insurance companies may benefit in the process of doing so.

Question: Who do you believe is the real winner with Meaningful Use?

• Patients – 33%
• Insurance companies– 20%
• Physicians – 13%
• Government agencies – 13%
• Vendors – 13%
• Hospitals– 7%
• Trade associations – 0%
• Health IT press – 0%

The results additionally indicated a belief that physicians, government agencies and vendors may equally benefit from meaningful use.

As new stages are defined, do you feel that the attention paid to improving patient care will change or stay the same?

If there is a poll topic you think would be appropriate or interesting, please send it to info@HL7Standards.com.

In a recent poll, we wanted to know about our readers’ reactions to the meaningful use and standards final rules. As expected, the results noticeably reflected similar attitudes expressed in a number of publications following the release of the final rules.

Question: What do you think about the meaningful use and standards final rules?

• They are better than before but need further discussion. – 50%
• They are in line with America’s healthcare needs. – 38%
• They are unachievable and impractical. – 13%

In a recent blog post, the Integration Generation (GENi) blog referenced a number of sources in its article, “Meaningful Use Debate.” The article identified two clear arguments supporting the legislative actions for the meaningful use of electronic records, and the other suggesting that improvement is still needed before the rules will satisfy America’s healthcare needs.

How do you anticipate the meaningful use and standards final rules will affect you as a professional and as a patient?

If there is a poll topic you think would be appropriate or interesting, please send it to info@HL7Standards.com.

For system analysts and interface developers, testing and managing HL7 interface connections is a large part of day-to-day responsibilities. Therefore, knowing and understanding the nature of HL7 messages and its structure is helpful in optimizing the time and money invested in the interfacing process. Senior implementations consultant at Corepoint Health, Alex Lin, identifies his top three suggestions that everyone should know about working with HL7 standards:

A standard is not a rule, only a suggestion.

HL7 is a standard.  By definition, a “standard” is, “a basis for comparison; a reference point against which other things can be evaluated.” A standard in computer software is often referenced when discussing software interoperability.

Because HL7 messages are a standard, there are no defined repercussions for any healthcare organization who decides to not abide by that standard. Instead, that healthcare organization, and those who interface to it, is inconvenienced by the time and money it costs to customize an interface to accommodate the non-standard messaging type.

With the help of an interface engine, communicating with vendors using different versions of HL7 or other messaging standards and formats (XML, CSV, X12, etc.) will be much easier than trying to build an interface manually.

The HL7 version you use is flexible.

When deciding which version of HL7 to use for your messaging needs, there are a few things to keep in mind. First of all, two-thirds of the industry currently uses HL7 v2.3 and v2.3.1. It’s not surprising, then, that HL7 v2.3.1 is the HL7 standards version most cited within the Final Rules issued for Meaningful Use and Standards.

Secondly, HL7 v2.x versions are backwards compatible. This means that if you have v2.3 and you need to interface with a v2.1, your version will be able to accommodate the differences. However, if you have v2.3 and you need to interface with someone using v2.5, they will have to accommodate your version.

Again, with the help of an interface engine, translating between different versions is simpler and time and money will ultimately be saved in the long run.

Each 2.x version is more customized and backwards compatible.

Each new version of HL7 adds more specific and customized messaging standards for communication with specialty organizations, such as a blood bank. In each new version, some message and data types are deprecated, elaborated and replaced with new ones. Additionally, some of the newer 2.x versions simply offer new message and data types.

The XML-based HL7 v3 is not backwards compatible with the 2.x versions of the standard, so existing v2 interfaces would not be able to communicate with interfaces using v3 without considerable modification.

Knowing and understanding the nature of HL7, its history, structure and relationship to the industry is helpful for any analyst or developer working with HL7 interfaces.

What other characteristics of HL7 do you find to be helpful to understand when working with HL7?

Among applications that produce Result messages, there is considerable variation in the way that the individual report lines are structured. The following three methods are common:

1. Repeating OBX segments: where each OBX segment contains exactly one line of report text in the OBX-5 field.

OBX|1|FT|||FX OF LT FIBULA
OBX|2|FT
OBX|3|FT
OBX|4|FT|||Technique: Three views left ankle.
OBX|5|FT OBX|6|FT|||Findings: There is an oblique fracture of the lateral malleolus at the level
OBX|7|FT|||of the mortise. No other fractures are identified. The mortise is symmetric.
OBX|8|FT
OBX|9|FT|||Impression: Oblique fracture of the lateral malleolus at the level of the
OBX|10|FT|||mortise.
OBX|11|FT
OBX|12|FT

2. A single OBX segment with repeating OBX-5 fields: where each OBX-5 field contains exactly one line of report text

OBX|1|FT|||FX OF LT FIBULA~~~Technique: Three views left ankle.~~Findings: There is an oblique fracture of the lateral malleolus at the level~of the mortise. No other fractures are identified. The mortise is symmetric.~~Impression: Oblique fracture of the lateral malleolus at the level of the~mortise.~~

3. A single OBX segment and a single OBX-5 field: where a special character or series of characters act as the delimiter that separates individual report text lines.

OBX|1|FT|||FX OF LT FIBULA\.br\\.br\\.br\Technique: Three views left ankle. \.br\\.br\Findings: There is an oblique fracture of the lateral malleolus at the level\.br\of the mortise. No other fractures are identified. The mortise is symmetric. \.br\\.br\Impression: Oblique fracture of the lateral malleolus at the level of the\.br\mortise. \.br\\.br\

With the use of an integration engine, converting from any one of these message variations to another should be a relatively simple task.

Maintaining original report line breaks. In general, the application that produces the text of a report will structure the lines of the report in an appropriate fashion. The following report message excerpt illustrates how important the position of the original line breaks can be.

OBX|1|FT|||CONFUSION
OBX|2|FT
OBX|3|FT
OBX|4|FT|||RT CAROTID
OBX|5|FT|||ICA PSV: 92 cm/s
OBX|6|FT|||CCA PSV: 99 cm/s
OBX|7|FT|||ICA/CCA PSV RATIO: 0.9
OBX|8|FT|||ICA EDV: 34 cm/s
OBX|9|FT|||RT VERTEBRAL ARTERY FLOW: Antegrade
OBX|10|FT
OBX|11|FT
OBX|12|FT|||LT CAROTID
OBX|13|FT|||ICA PSV: 66 cm/s
OBX|14|FT|||CCA PSV: 88 cm/s
OBX|15|FT|||ICA/CCA PSV RATIO: 0.8
OBX|16|FT|||ICA EDV: 38 cm/s
OBX|17|FT|||LT VERTEBRAL ARTERY FLOW: Antegrade
OBX|18|FT
OBX|19|FT
OBX|20|FT
OBX|21|FT|||Right carotid: Color and spectral Doppler failed to show evidence of
OBX|22|FT|||significant focal measurable stenosis. There is antegrade right vertebral
OBX|23|FT|||artery flow.
OBX|24|FT
OBX|25|FT|||Left carotid: Scattered focal calcified plaque formation is present at the
OBX|26|FT|||left bifurcation. Color and spectral Doppler show mild turbulent flow in the
OBX|27|FT|||proximal left ICA. However, flow ratios and velocities remain within normal
OBX|28|FT|||limits. There is antegrade left vertebral artery flow.
OBX|29|FT
OBX|30|FT|||Impression:
OBX|31|FT|||1. Study fails to show evidence of high-grade focal stenosis either carotid.
OBX|32|FT|||2. Calcified plaque formation left bifurcation which produces a visually
OBX|33|FT|||estimated 50% diameter stenosis in the proximal left ICA. If asymptomatic for
OBX|34|FT|||left hemispheric symptoms, a follow-up carotid ultrasound is recommended in 1
OBX|35|FT|||year.
OBX|36|FT
OBX|37|FT

Special lines, such as the individual measurements with units in the initial sections and the numbered list items in the Impression section, would have severely compromised readability if the original line breaks of this report were not maintained. For this reason, when we are converting a report from one message format to another, we have very strong motivation to maintain the integrity of each line of the report as it was produced in the originating application. In general, this does not present a problem and, in fact, is the most straightforward way to perform the conversion.

Be aware of line length limits. If, however, the maximum number of characters per line in the original report may exceed the allowed character limit of a destination application, we are presented with a challenge. Even with powerful tools provided by an integration engine, the handling can become complex.

In the report above, the sections labeled “Right carotid”, “Left carotid” and “Impression” contain lines of text that may be up to 78 characters long. If a destination application with a report line character limit of 70 characters needs to receive this report, we need to modify the placement of the original line breaks.

A useful feature of an integration engine for this task is the ability to appropriately “wrap” the text of one line to the next line without splitting the text in the middle of a word. Unfortunately, we have more work to do than simply applying that feature to each line of the report. Our first problem is that if we are iterating through the lines of the report and simply inserting a new line when we encounter one that is over 70 characters, we will end up with report lines structured like this:

[…]
OBX|21|FT|||Right carotid: Color and spectral Doppler failed to show evidence of
OBX|22|FT|||significant focal measurable stenosis. There is antegrade right
OBX|23|FT|||vertebral
OBX|24|FT|||artery flow.
OBX|25|FT
OBX|26|FT|||Left carotid: Scattered focal calcified plaque formation is present
OBX|27|FT|||at the
OBX|28|FT|||left bifurcation. Color and spectral Doppler show mild turbulent
OBX|29|FT|||flow in the
OBX|30|FT|||proximal left ICA. However, flow ratios and velocities remain within
OBX|31|FT|||normal
OBX|32|FT|||limits. There is antegrade left vertebral artery flow.
[…]

This strategy maintained the original line breaks and simply added a new line break where a line over 70 characters was encountered.

Our strategy must be modified to use our word wrap feature on a block of report text that has been stripped of the original line breaks. You may recall, however, that for some special sections of the report, we must maintain the original line breaks to maintain its readability. Our strategy needs to be much more complex, such that it will apply appropriate handling to different sections of the report.

The result is that the conversion process must now begin to “pay attention” to the actual content of the report. While this can be done, it is an undesirable situation, mainly because the variation in the reports may be great enough that detecting the beginning and end of any given section is highly unreliable.

Using an integration engine that has robust message processing capabilities, this type of complex restructuring of the lines of a report is possible, but it can be a significant effort. The easiest solution to the problem, if it is possible, is to decrease the maximum line length of the application that is generating the reports to a length that all destination applications can handle.

For more information and to see the original PDF, click here.

“ONC did an excellent job of creating pragmatic, achievable guidelines for physicians while still maintaining an ambitious vision for health IT… Now that EHR systems are affordable and Meaningful Use is within grasp – doctors have absolutely no reason to stick with paper records.” – Ryan Howard, CEO of Practice Fusion

“We have revised the definition of meaningful use … and are requiring an overall lower bar and an approach that is more flexible.” – iHealthBeat

On Tuesday, the Department of Health and Human Services announced the release of the final rule establishing the incentive program guidelines for the meaningful use of electronic medical records.

Reactions to the final rule have been relatively positive as it appears that the 2,000+ comments submitted in response to the interim final rule were well received by those involved in the decision making process.

The following articles by various healthcare leaders and organizations provide a great summary and commentary on the final Meaningful Use guidelines:

• The New England Journal of Medicine article by David Blumenthal, M.D., M.P.P., and Marilyn Tavenner, R.N., M.H.A.: The “Meaningful Use” Regulations for Electronic Health Records. This article does a great job of explaining the importance of EHR adoption and how meaningful use relates to the EMR integration in healthcare. Additionally, the article includes an outline of core objectives as well as an explanation on the menu of options added to the final rule.

• iHealthBeat article: Final Rules on ‘Meaningful Use,’ EHR Standards Released Today. This article breaks down the final document into five key topics that one must know regarding the meaningful use standards. The article touches on high level topics and provides additional links to more details.

• Health Data Management article: A First Look at Final MU Criteria. This article provides a high level summary of the meaningful use changes from the previously proposed rule to the final rule, as well as a brief summary of next steps for healthcare providers as well as meaningful use’s own stage two.

• HealthImaging.com article: CMS, ONC release meaningful use final rules. This article includes a section on the core objectives of meaningful use as well as links to other external resources on the topic.

• Healthcare Standards blog post by Keith Boone (@motorcycle_guy): Meaningful Use Standards Summary. This blog post summarizes identifies 15 key points from the final rule on meaningful use and includes a table, organized by Don Sepulvada, Sr. Marketing Manager of GE Healthcare, on the stage one certification criteria and requirements for ambulatory and hospital EHR products.

• Life as a Healthcare CIO blog post by John D. Halamka, M.D., M.S.: A Do it Yourself Presentation on the Standards Rule and A Do it Yourself Presentation on the Meaningful Use Final Rule. These blog posts offer valuable presentation outlines on the standards and meaningful use rules that can be used for anyone communicating the new requirements to a larger audience, or simply looking to learn more on the new information.

• The Integration Generation blog post: Standards and Certification Criteria Final Rule – Healthcare Standards Overview. This blog references some supplementary materials provided by John D. Halamka, M.D. on the Meaningful Use and Standards rules. This post additionally includes a matrix of information breaking down the standards requirements into content and vocabulary categories.

As Brian Ahier noted on his recent blog post, defining moment for meaningful use, “we have reached a fulcrum point in the history of health care in our country.” The acceptance and support of meaningful use is instrumental to the future of the healthcare industry and subsequently, HITECH’s impact on the quality of healthcare in America will be no less than meaningful.

You can find a PDF of the Meaningful Use Final Rule here.

Are there any other articles or summaries that you have found to be particularly helpful?

In order to make the most out of your time and ultimately streamline the process of building an HL7 interface, there are some key things every interface developer and analyst should do. As a senior implementations consultant at Corepoint Health, Alex Lin offers his top three suggestions for interface developers and analysts:

Test – Early and often. Ask your vendors for a varying number of test messages and obtain up-to-date system specifications. (System specifications are particularly important for an interface developer as they can often be wrong or out-of-date.) It is important to always test interface connections prior to putting an interface into production. As you test, remember to save your work. Save early and often.

Talk to your vendor. Communicate with your vendors and test with them if possible. This not only streamlines the implementation process but helps build rapport and a healthy relationship. Moreover, be flexible and understanding. It is better to have problems identified early than to strain a relationship when things don’t work later on.

Document your changes. Sometimes you will establish an interface and not revisit it for a few years. Later on, it will be valuable (for you or whomever inherits that interface) to see what changes you made when you initially established the interface and why you did what you did.

For an interface developer or analyst, investing in the establishment of an interface by testing, saving and documenting your work, will not only help future interfacing needs, but also help preserve the long-term value of the interface connections.

Are there any additional actions you like to take when developing an HL7 interface?

In the constellation of separate systems within a healthcare facility, it is common to have a single application which produces (HL7 ORU) Result/Report messages.  These ORU messages may correspond to Orders that originated with several different ordering facilities or ordering physicians.

In many instances, there is a need to send a different message structure to each of the systems which need the ORU messages.  The task of appropriately formatting and distributing the ORU messages is manageable with the flexibility and message processing power provided by an integration engine.

With a single inbound stream of ORU messages flowing to your integration engine, a method to route messages to the appropriate destinations is required.

If the ORU message contains a field to indicate which facility initiated the order, that field may be the only thing we need to use in order to route messages properly.  Another option is to route messages based on the field that contains the identity of the ordering physician (or “Ordering Provider”).  In this case, we are likely to benefit from the use of a lookup table, since there may be many ordering physicians associated with a given ordering facility. The technology used to implement the lookup table may vary, but the methodology would be consistent.

OrderingProviderID	OrderingProviderName	DestinationFacility
123	Smith, John  MD	Riverside
234	Jones, Mary  MD	Riverside
345	Johnson, Bill  MD	NorthSideClinic
456	Williams, Mike  MD	MemorialHospital
…	…	…

Our message processing logic would simply use the lookup table to find the DestinationFacility which corresponds to the OrderingProviderID presented in the ORU message (commonly populated in the OBR-16.1 field).  Using the example table above, an ORU message with an ordering provider of John Smith should be sent to Riverside.

An ordering physician may be associated with more than one ordering facility. In this case, a more robust routing method may be desired. We may want to send the Result message to all destination facilities that the ordering physician is associated with. This would require a slightly more complex lookup table and associated logic.

OrderingProviderID	OrderingProviderName	DestinationFacility
123	Smith, John  MD	Riverside
123	Smith, John MD	NorthSideClinic
345	Johnson, Bill  MD	NorthSideClinic
456	Williams, Mike  MD	MemorialHospital
…	…	…

In this case, our message processing logic would use the lookup table to find all rows that contain the OrderingProviderID and route the appropriately formatted message to each DestinationFacility. Using the example table above, a Result message with an ordering provider of John Smith should be sent to both Riverside and NorthSideClinic.

Something to keep in mind when using lookup tables such as the examples above is that the tables need to be maintained. A procedure to keep the lookup tables up-to-date should be put in place in order to ensure that message routing is accurate.

For more information and to see the original PDF, click here.

Questions regarding the certification process of EMR technology, as well as the relevance of previous certification procedures, were key topics this week within the healthcare IT industry. Additionally, the impact of Meaningful Use and what it will mean for the EMR certification process was of importance.

A few interesting articles shared among users online explain the impact of recent legislative events and the overall implications of HITECH for patients and providers alike.

• Software Advice: The Medical Blog by Chris Thorman: EMR Ratings: How Relevant Is CCHIT Certification In the HITECH Era? This blog post discusses CCHIT’s role in certifying EMR software products. Recent legislative actions regarding the HITECH Act will be the catalyst for change in the certification process of EMRs, and niches within the market will be redefined.

• HealthImaging.com article: ONC issues final rule for EHR certification program. This article highlights breaking news from this week that involved the Office of the National Coordinator for Health IT (ONC). The ONC issued a “final rule to establish a temporary certification program for HER technology.”

• Health IT Buzz by David Blumenthal, MD: Adoption of Health IT. This blog post by the national coordinator for health information technology responds to several questions regarding the state of health IT and the positive impact of Meaningful Use.

The above information is helpful to follow as progress continues with the HITECH implementation.