Health Standards Blog

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

The Office of the National Coordinator (ONC) for Health IT announced two organizations as an Authorized Testing and Certification Body (ONC-ATCB). The two organizations are the:

1. Certification Commission for Health IT (CCHIT). Read the CCHIT press announcement.
   
2. Drummond Group (DGI). Read the DGI press announcement.

According to David Blumenthal, M.D., national coordinator for Health Information Technology:

“Less than two months following the issuance of final meaningful use rules, we have approved our initial ONC-ATCB certifiers.  EHR vendors can begin immediately to get their products certified. This is a crucial step because it ensures that certified EHR products will be available to support the achievement of the required meaningful use objectives, that these products will be aligned with one another on key standards, and that doctors and hospitals can invest with confidence in these certified systems.”

Additional information on the ONC certification programs is available on the HHS Health IT site.

This is another step forward in putting the parameters and processes in place which are being driven by HITECH and the standard of Meaningful Use. HITECH is driving the adoption of EHR systems, offering physicians up to $44,000 in Medicare incentives and almost $64,000 in incentives through Medicaid. Hospitals are eligible to receive millions of dollars as well. In addition to implementing certified EHR systems, providers must meet staged Meaningful Use benchmarks to gain the full incentive amount.

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.

A post on the KevinMD.com site caught my eye. The title:  Why radiology should become more like McDonald’s. Attention-getting, yes. Applicable, maybe.

The article was written by Paul Dorio, MD, an interventional radiologist. In reading his article, it seemed to be directed toward two concepts. The first concept is that radiology practices need to communicate with patients more effectively and empathize more appropriately. The second concept is that efficiency, consistency, and accuracy are essential elements in radiology workflows. This really sounds familiar; it sounds like applying lean manufacturing techniques, or six sigma, to radiology. More on this in a minute.

Outlined below are the last two paragraphs of Dr. Dorio’s post:

“In my radiology group, we pride ourselves on turnaround times of less than two hours for most reports. In this manner, the requesting physician will have the findings of the patient’s study and can quickly take any necessary action for their care. Communicating important, critical findings by calling the physician is also one aspect of customer service that I (and the American College of Radiology) feel is essential to offering and delivering good service.

Overall, good customer service in the medical field comes down to good communication, empathy and understanding. It’s not that difficult. It’s just that very few physicians receive any training in their early years to foster and develop those skills. It’s time that we focus on this aspect of health care delivery for the health and satisfaction of our patients.”

As you might imagine, there were some very good comments on his blog post. If you have some time, please click on the article link above to read it all.

Getting back to the discussion, it is interesting that turnaround times (TAT) was mentioned. This sounds familiar, too.

If you go back to an article published by Imaging Economics in November/December 2000, you will find one entitled Six Sigma: Applying a Corporate Model to Radiology. Guess what topic was a part of the discussion? Yes, that is correct – TAT and:

“We found that if we had all the information that radiologists needed to make decisions at hand when the cases were presented to them, it cut down the amount of time needed to get those orders written, which reduced the patient wait time.”

Radiologists need all the patient information at the time when they need to make a decision.

Now, fast forward to 2010 again, and on the iSixSigma site, you can find an article entitled Applying Transactional Lean at Medical Imaging Firm. In their initial project scoping, the number one focus area:  “report turnaround time as a key factor affecting delays and satisfaction.” TAT and patient satisfaction are tied together again!

The iSixSigma article is definitely worth the reading time. You will learn about payoff matrix, value stream mapping, time value analysis, and “trystorming.” All are great tools in applying lean techniques to radiology workflows. My favorite is “trystorming.” This is a take on brainstorming. Changing processes in health care need to be done very carefully. Trystorming is a conservative approach to implementing changes; the changes are put into a trial run so all the impacts are understood as much as possible. When the trials are successful, the changes can be put into “production” fully.

The point of this post may be, you say McDonald’s, I say Lean Manufacturing, and someone else says Six Sigma. Each get at the same goal – improving radiology workflow TAT and enhancing patient satisfaction. These approaches have been discussed for many years, and progress is still being made, although slowly and probably not widespread.

Learning more about these lean techniques may be even more important today, given all the changes in health care and radiology, so it may be worth a renewed look for many radiology groups, departments, practices, and imaging centers as the goals for efficiency and satisfaction grow more intense.

Has your radiology operations team used, or is planning to use, lean techniques to improve your workflows?

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?

On Tuesday, the New England Journal of Medicine published a testimony by the Surgeon General of the U.S. Public Health Service, Regina Benjamin, M.D., M.B.A., advocating for the use of electronic health records (EMRs) reflecting on the recently released meaningful use criteria.

In addition to the article’s applicability to the HITECH news in the healthcare industry, the article was particularly profound given the events that the southern Louisiana area has experienced in the last decade.

Take a minute to read through our Surgeon General’s experience with EHRs and healthcare integration.

Finding My Way to Electronic Health Records