NeoTool — Singular Focus, Healthcare Integrated

During a recent stay at a very well respected Dallas area hospital that saw my wife and I welcome our first child into the world, I was reminded that the “Device Divide” that separates the vast majority of healthcare providers’ medical device data from the rest of their clinical information network is not limited to just small to medium-size hospitals.

Given the fact that the hospital is part of a large statewide chain and would likely be labeled as cutting edge from a technological standpoint, I was somewhat surprised to see a nurse come in every 2-3 hours to dutifully record my wife and son’s vitals in a paper chart. I’m sure that information was re-entered into an EMR at some point, but I couldn’t help but wonder how often the data gets transposed or forgotten.

That experience begs the question - why has it taken so long to bring patient care device data online, even at some of the nation’s largest hospitals? The problem of crossing the “Device Divide” – that gulf between the hospital network and its medical devices that is typically traversed by the nursing staff with pen and paper – is not an easy one.

One reason is a lack of cost-effective, reliable solutions for doing so. Device connectivity has only recently (within the past couple years) been given the attention that it warrants, and early solutions have been plagued with the same kinds of ‘kinks’ that any early stage technological advancements have encountered.

Another closely related explanation for the delay in crossing the “Device Divide” is that enabling devices to bridge that gap represents quite a leap outside of most manufacturers’ technological sweet spot. That’s not to say that they’re not extremely capable. In fact, the exact opposite is true – patient care device OEM employees are some of the brightest that I’ve run across. It’s just that, as Robert Nadler, an employee at a device manufacturer, recently blogged:

“The problem… is that we don’t have the resources to build each unique interface required to satisfy all of our customers. Plus that, our business is building medical devices, not EMR solutions.”

Device companies have spent years building R&D and engineering departments focused on building better and better equipment that takes more and more accurate readings in the easiest possible manner. Their aptitude for doing just that is what has always separated them from every other device manufacturer with whom they compete.

But bridging the divide requires a very different skill set – the ability to write software that provides HL7 integration capabilities that enable devices to interface with countless EMRs and other clinical applications. And once written those healthcare integration systems become much like an NFL referee – the good ones go unnoticed, and the bad ones gain the kind of notoriety we would all like to avoid. Despite representing a critical part of the total connected device solution, from the customer’s perspective there is nothing tangible about an interfacing system that will make them value it enough to justify the cost of ramping up a development shop to construct it in-house.

That’s why I think the interfacing conundrum is one that lends itself nicely to the idea behind Joseph Nemeth’s article entitled “The Drive Toward Collaborative Innovation for Medical Devices” in the August 2006 issue of Product Design & Development magazine. In it, he concludes that:

“Collaborative partnerships provide a balance of assessing what organizations require from outside sources given their need to innovate, and what they must retain to achieve their business and revenue objectives. It is a sound enterprise strategy that can minimize time to market, reduce costs, generate differentiated offerings, and drive a business model for sustained industry growth.”

Collaborating with a strategic partner well versed in ways to cross the “Device Divide” could prevent manufacturers from stretching their resources too thin and keep them from stepping too far outside their core competency. If chosen wisely, such a partner could help get a sound connectivity strategy in place for much less than the cost of taking on the initiative in a vacuum.

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.”

HIStalk posted an interview with Eric Fishman MD, President, EHRConsultant. This is an interview worth spending a few minutes to read. Dr. Fishman’s site is EHRScope.

The HIStalk interview spans several topics including:

• EMR vs. EHR terminology
• Implementing EHR insights
• CCHIT and their impact
• Insurance companies providing EMR software to physician practices
• General physician practice trends

One missing question that would be interesting to ask:  What are physician practices doing to implement effective interfaces to their partner providers, such as labs, imaging centers, and hospitals? EMR connectivity plays a key role moving patient data effectively through their complete cycle of health care interactions.

In your EHR efforts, HIStalk and EHRScope are great resources for healthcare IT professionals and physicians.

The demand for healthcare interfaces with Electronic Medical Records (EMR) is increasing. This increase is due to the rising adoption of EMR systems, emerging clinical healthcare data standards (HL7, CCR, CDA, CCD, ELINCS), and increasing interoperability requirements, such as CCHIT (Certification Commission for Healthcare Information Technology).

To achieve the most effective and efficient EMR connectivity, the following steps should be included in the process:

1. Understand workflow:  Define the workflow within your organization and between your organization and the organization with the EMR system
2. Document requirements:  Define the data requirements of your systems and the EMR in which you will be exchanging patient information
3. Implement interfaces:  Build the interfaces to facilitate the workflow and meet each application’s requirements

Understand workflow.  Understanding the healthcare data flow within your organization and then the data flow of the organization with the EMR system is critical when you start automating the healthcare workflow. You cannot successfully automate a system or workflow which you do not fully understand.

Document the requirements.  Documenting the requirements for both applications in terms of the standards being used to transmit the clinical data in the specific data format will help identify the gaps between the two clinical applications. The interface can then bridge the identified gaps between the EMR and your application.

Implement interfaces.  A systematic approach to interface implementation should include the basic stages of developing, testing, implementing, and maintaining the interfaces. An effective and flexible approach, that can include tools, will help overcome common challenges such as technology, patient matching, procedure or physician code matching, and lack of cooperation to meet the end goals.

In summary, an interface to or from an EMR application is no different than an interface for any other healthcare application. Connectivity is achieved by acquiring knowledge regarding the workflow and the requirements, plus utilizing effective methodologies or solutions to implement the interfaces.

The Medical Records Institute (MRI) has launched EMRCompare with 14 Electronic Medical Record (EMR) companies participating initially. MRI anticipates that another 30-50 EMR solutions will be available by the end of the year. 

The EMRCompare website contains cost, functionality, and usability information for each of the participating EMR vendors. Also included is a short video that shows the look-and-feel of the EMR application.

The first 14 vendors to participate are:

• ABELSoft
• Amazing Charts
• Bond Technologies
• e-MDs
• Health Communication Systems
• iMedica
• iSALUS Healthcare
• MediNotes   
• Mednet System
• Noteworthy Medical Systems
• Pulse Systems
• Sage Software
• SSIMED
• Waiting Room Solutions

EMRCompare looks to be a valuable tool for physician practices that are beginning to evaluate various EMR applications.

The EHR-Lab Interoperability and Connectivity Specification (ELINCS) specification provides a profile that refines (or constrains) “standard” HL7 messages to moving lab results from reference labs to physician offices. Like IHE, the ELINCS profile constrains the generic HL7 standard to a specific set of use cases. In addition the ELINCS standard provides business rules that must be followed between the trading partners. Such rules are outside the scope of the base HL7 standard.

ELINCS is part of the 2007 CCHIT Ambulatory Interoperability requirements.

Note that sometimes this standard is misspelled as e-links or elinks.

Resources for ELINCS:

• Accelerating EMR Interoperability with ELINCS: Streamlining Lab Connectivity to Physician EMRs
• ELINCS Standard: Laboratory Results to EMRs
• Why the Increasing Demand for Electronic Results to Physicians?
• ELINCS overview and downloadable documents
• ELINCS Specifications
• Direct link to ELINCS 1.1 PDF file

This diagram shows the most common use case for ELINCS:

There is an interesting statistic hidden in a posting this week from Healthcare IT News:

… CCHIT spokesperson Sue Reber … estimated that more than 40 percent of companies with ambulatory EHR products have been certified.

That’s a huge percentage and represents real market acceptance of the CCHIT standards. Why should we care as HL7 integration experts? Here are three reasons:

1. The CCHIT criteria started life as HL7’s EHR standard. The goal was to spell out what it means to have an EMR and what features / functions it must support. These are high level goals such as “maintain list of allergies” or “supports outcome Measures and Analysis.” Think really big picture concepts - the devil is in the details.
2. With market acceptance of the base criteria, CCHIT has leading US market mind share. Good, bad, or indifferent, it seems like it will soon be a requirement to be “CCHIT Certified” in order to sell an EMR in the US market. This means there could be a rush for EMR vendors to get certified quickly.
3. Going forward, CCHIT is raising the bar and adding interoperability requirements. This is critical to the integration world as it effectively demands that EMR vendors support certain interactions, data models, and work flows. As an example, CCHIT is adding the requirement to support ELINCS, a lab result reporting standard. This will drive lab result interfaces to be “more standard” and they will, over time, move towards using the LOINC code set for the “typical” lab tests.

The HIMSS annual conference has now passed. The presentations are over; the exhibitor booths are gone; and the attendees are back to work. It will be interesting to measure the impact of HIMSS on initiatives with the thousands of healthcare provider attendees or with the hundreds of healthcare vendor exhibitors. What will change? What new thoughts will be considered? What new solutions will be considered? What existing solutions will be re-considered?

From our vantage point, there were several themes evident in our various discussions with attendees.

• EMR / EHR: How do we integrate to hospitals, clinics, labs, and imaging centers? What is the best approach?
  • Read a best practices white paper entitled What Is Your EMR Connectivity Strategy? Defining the Best Attributes to Approaching a Connected Physician Community.
• Continuity of Care Record (CCR) and Continuity of Care Document (CCD): How do these new standards impact EMR integration efforts?
  • Read blog posts on CCR, CDA, CCD, or just search our blog site.
• For vendors, buy or build a healthcare interface solution? There is so much flexibility with the “healthcare standards” so how do we focus, adapt, or handle integration?
  • Answer five questions outlined in a white paper entitled Before You Build a Healthcare Communication Subsystem…
• Simplicity, speed of healthcare interfacing: How can we build healthcare interfaces simply with limited or hard-to-find resources and build them quickly?
  • Review solutions available to speed the healthcare interfacing process.

The themes that you heard or championed may be different. Please feel free to post your insights as a comment. We welcome the interaction.

We found the dialogue at HIMSS extremely valuable. The important element now is to do something with what each of us learned and apply it in our initiatives. Next year, we can revisit how much progress was made.

The Continuity of Care Document (CCD) was approved earlier this week. The CCD is a collaborative effort between the HL7 standards and ASTM International organizations. To add to confusion, there are multiple standards for electronic patient record (EMR / EHR) integration. They are:

• Continuity of Care Record (CCR) - authored by ASTM
• HL7 Clinical Document Architecture (CDA) - authored by HL7
• Care Record Summary (CRS) - original HL7 attempt at patient care integration standard, later incorporated into HL7 CDA
• Continuity of Care Document (CCD) - jointly agreed to by ASTM and HL7 and endorsed by the Healthcare Information Technology Standards Panel (HITSP)

CCD is a part of the healthcare interface standards “harmonization” effort, which is worthwhile and needed. Regardless, it creates confusion in the marketplace as to which standard to use or ask for when evaluating EMR and EHR systems as well as in determining the overall connected healthcare community strategy for a hospital, lab, clinic, or imaging center.  Which one?  CCR, CDA, or CCD? 

In a Modern Healthcare article entitled CCD Standard Up for a Vote, there is a quote from the American Academy of Family Physician’s Center for Health Information Technology as to why the different standards.

“There isn’t really a rift between ASTM and HL7. I think where the rift starts to come is between legacy vendors and some of the Internet-technology-based vendors. You have the large hospital vendors (more or less in the HL7 camp) and the smaller physician office system vendors (using CCR). That’s where the controversy starts to explode.”

Peter Waegemann, chief executive officer of the Medical Records Institute, adds to this in a subsequent Modern Healthcare article entitled Standards Rivals’ Collaboration Could Have Major Impact:

“Vendors and users of large IT “legacy” systems that are backers of HL7’s Clinical Document Architecture will gain the most benefit from the CCD because they will be able to use the CCR format in their systems, Waegemann said. But the collaboration with HL7 on the CCD further establishes the CCR, he said.”

Both are valid points. The good news in this announcement is that CCR and CCD will work well together. This will facilitate a more integrated healthcare environment. As clinics, hospitals, labs, and imaging centers move forward, they will need to continue to be adaptive in their integration approach. Flexibility is essential in the near term.

The HL7 Continuity of Care Document (CCD) is the result of a collaborative effort between the Health Level Seven and ASTM organizations to “harmonize” the data format between ASTM’s Continuity of Care Record (CCR) and HL7’s Clinical Document Architecture (CDA) specifications. 

The CCD will enable greater interoperability or healthcare integration of clinical data and “allow physicians to send electronic medical information to other providers without loss of meaning.”

With CCD, the CCR is represented and mapped into the HL7 CDA. These are structured XML standards for clinical information exchange. The harmonized standards should support greater streamlined exchanges with Electronic Medical Record (EMR) and Electronic Health Record (EHR) systems as well as various healthcare providers.