NeoTool — Singular Focus, Healthcare Integrated

There is an interesting blog post in BNET entitled Electronic Medical Records:  Bad for Health? The discussion around EMRs is fascinating. There are many differing perspectives on various topics:  privacy, interoperability, usability, acceptance, failure, etc.

This article consolidates some of the recent negative articles or perspectives on EMRs, including:

• Privacy - exposing patient data to outsiders.
• Savings - insurers gain more than physicians
• Copy-and-paste - copying notes from one patient record to another, because it helps with billing
• Too much information - no human selection of relevant information
• Physician insensitivity - “Dr. Computer”
• “Cookie-cutter” medicine - just using the template

These points may be valid, but is the status quo better? Continuing with a paper-based system does not seem to be the better answer. Having the right sense of responsibility to deliver the right approach in using EMRs seems to address many of the potential issues.

With Stark Law changes, there is increased interest in what hospitals can and cannot do as it relates to giving Electronic Medical Record (EMR) software to physician practices. A recent article in Physicians Practice highlights the fact that there is no such thing as “free.”

Although some EMR costs are covered (e.g., software purchase, order and results integration), there are other costs that will be required. For example:

• Hardware costs
• Technical support costs
• Ongoing application support costs
• Hosting costs (if SaaS or ASP model is used)

The article points out the obvious point:  With Stark and other “free” options, the overall costs of an implemented EMR are still lower than if the physician practice implemented it on their own. Implementing the EMR application still creates benefits such as potentially higher pay-for-performance payments, possible payer subsidies and, of course, more accuracy in patient care. “Free” may not be completely free, but it is a reasonable starting point.

HIMSS EHRVA developed a Quick Start Guide for implementing the Continuity of Care Document (CCD). HIMSS EHRVA is a trade association of Electronic Health Record (EHR) vendors. Included in the file are two sample CCDs. The guide seems to be a useful resource for implementers of integrated healthcare systems.

A few past posts and insights that you may want to explore:

• What is the CCD?
• EMR Interfacing Best Practices
• Get the Workflow Right First
• Comparing HL7 Messages to HL7 Documents

Please post any experiences that you have in implementing the CCD or using this Quick Start Guide.

As noted in HIS-Talk and HANYS News, CMS released an advisory opinion that allows for hospitals to pay the cost of EMR interfaces without violating the Stark Law. Hospitals are restricted under the US law regarding compensation arrangements between physicians and hospitals. HANYS News wrote:

Specifically, a hospital system can pay for the creation of an electronic interface between unique electronic health record (EHR) systems of individual physician practices and the hospital network’s EHR system. The interface would allow physicians, from their practices, to order and communicate the results of tests and procedures performed.

The CMS news was delivered in “Advisory Opinion No. CMS-AO-2008-01″. There are many words used in the advisory; here is a quote that is the meat of the opinion:

The Requestor … owns and operates … hospitals … [and] contracted with a third-party … Vendor … to install a proprietary health care software information …System …, customized to the Requestor’s specific requirements, including a software interface engine that facilitates access by the custom Physician Practice Interface(s).

Pursuant to the contract between the Requestor and the Vendor, the Vendor provided software licenses to the Requestor that permit the Requestor and its controlled affiliates to use the System.

Currently, the medical staffs of Requestor’s … hospitals have the option to view laboratory reports for the Requestor’s patients over a protected internet connection to the System. The Proposed Arrangement would permit also the ordering or communicating of laboratory tests or procedures performed by the Requestor using the Physician Practice Interface(s).

Numerous physicians on the Requestor’s medical staffs have begun to purchase and use electronic health records (“EHR”) systems for their private practices. Requestor would like to integrate its System with individual information systems maintained by the Affiliated Physician Practices to promote the secure transfer of patient data between the parties. Integrating the System with each Affiliated Physician Practice requires the custom development of an interface that can extract data from the System and transfer it to the Affiliated Physician Practices’ EHR systems. The Requestor may need to develop several versions of the Physician Practice Interface to accommodate the various EHR systems. The Requestor would limit the functionality of the Physician Practice Interface to the ordering or communicating the results of laboratory tests or procedures furnished by the Requestor.

Under the Proposed Arrangement, the Vendor would develop, and the Requestor would pay the development cost of, a Physician Practice Interface customized to the Affiliated Physician Practice’s existing EHR software. … Physician Practice Interface would be used only to order or communicate the results of tests and procedures furnished by the Requestor and could not be used for any purpose other than the ordering or communicating of the results of tests or procedures furnished by the Requestor.

…

Therefore, we have determined that the Proposed Arrangement does not meet the definition of “compensation arrangement” for purposes of the statute’s prohibition on physician self-referral
…

The National Alliance for Health Information Technology (NAHIT) recently released new definitions of certain healthcare IT terms. This project was completed for the Office of the National Coordinator of Health Information Technology; this office was created by the President on April 27, 2004 to promote the adoption of electronic health records by most Americans by 2014.

Outlined below are the definitions published by NAHIT. These healthcare IT definitions were published in the report entitled Defining Key Health Information Technology Terms (PDF).

• Electronic Medical Record: An electronic record of health-related information on an individual that can be created, gathered, managed, and consulted by authorized clinicians and staff within one healthcare organization.
• Electronic Health Record: An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be created, managed, and consulted by authorized clinicians and staff across more than one healthcare organization.
• Personal Health Record: An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared, and controlled by the individual.
• Health Information Exchange: The electronic movement of health-related information among organizations according to nationally recognized standards.
• Health Information Organization: An organization that oversees and governs the exchange of health-related information among organizations according to nationally recognized standards.
• Regional Health Information Organization: A health information organization that brings together health care stakeholders within a defined geographic area and governs health information exchange among them for the purpose of improving health and care in that community.

The greatest understatement in the report is: “Interoperability is the common thread running through health IT terms. Interoperability is the essential factor in building the infrastructure to create, transmit, store and manage health-related information.”

For more definitions, check out our healthcare interoperability glossary.

In a previous post, I highlighted several healthcare IT perspectives on the Stark Law changes and the impact on EMR implementations through hospitals. A recent article in Inside Electronic Medical Records is an interesting edition to this topic; the article is entitled:  Hospitals Take Tentative Start EMR Steps, Struggle with Charging Overhead to Doctors.

A few interesting points in the article:

• Different approaches are being taken by hospitals. In the article, one hospital is offering just a single EMR offering to their physicians, and another hospital is offering 3 to 4 EMR application options. The primary reason for the multiple EMR offerings is that “We realized that one size doesn’t fit all.”
•  Integration is essential. The reason for the one hospital to offer single (hosted) EMR offering to their physicians is so that the patient has one medical record in their system. In the other hospital’s case, clinical integration is still essential. As they stated, “You have to have clinical integration between multiple entities. If you are not sharing data, you are losing the real benefit of EMR.”
• EMR certification also plays a role in the selection process by the hospital. In one case, only CCHIT certified EMR vendors are considered.
• The amount of the hospital subsidy varies. One hospital is covering 60% of the EMR services while the other seems to be taking advantage of the full allowable amount of 85% of the covered services.
• Trust is a factor with physicians. If a physician practice is going to take advantage of a hospital supported EMR, they will need to trust that hospital.

Forward progress? Time will tell which approach will work the best, or it may be that the approaches do vary… select the approach that best fit the needs of the connected healthcare objectives being pursued. As long as everyone involved trusts the objectives, it may work.

An article in FierceHealthIT highlighted a recently published paper (PDF) on how Electronic Medical Record (EMR) adoption is driving the need for more Healthcare IT (HIT) jobs. A key statement from the report:

“While hospitals with basic implementation are utilizing about 0.1 IT staff per bed, this rises to around 0.2 IT staff per bed as hospitals advance from Stage 1 to Stage 4 implementation based on the HIMSS EMR Adoption Model. If our data represent a correct sampling of the entire US, then the current IT staff workforce is about 108,390 FTE. However, if the US HIT agenda is fulfilled and hospitals move to higher levels of adoption, an additional 40,784 FTE will be required.”

Characterizing the Health Information Technology Workforce: Analysis from the HIMSS Analytics Database, April 2008.

In the EMR adoption model as defined by HIMSS, the various stages are succinctly defined. Stage 1 includes basic systems in place - radiology, laboratory, pharmacy - while moving to Stage 4 includes implementation of a Computerized Practitioner/Physician Order Entry (CPOE) system.

The key point of the paper and discussion: Adopting new technologies in hospitals require additional IT personnel to support and ensure success. In selecting new technologies, it is important for hospitals to evaluate the type of IT skills required to support the required new applications. Balancing the type of skills required with the associated costs is essential.

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!

The Stark Law is potentially changing the landscape in the adoption of healthcare IT in physician practices in communities across the US. What change actually happens is still up for debate.

A recent article in Government Health IT entitled Picking Up the Check for EMRs does a good job of outlining the differing perspectives:  hospital, physician practice, and vendor. Outlined below is a brief summary of each perspective.

Hospital Perspective.  Although some hospitals may implement strategies and programs to offer EMRs to physician practices, there is skepticism that it will work. Hospitals like Partners Healthcare System do not have plans to start paying for local systems. Other hospitals note that they would have to offer physician practices more than one EMR option in order to meet the differing requirements. The bottom line, though, is that many hospitals are not in the financial position to fund EMR adoption in physician practices.

Physician Practice Perspective.  Doctors are independent and do not want to take hospital incentives which may compromise their independence. Also, what if a physician practices at more than one hospital and each hospital has a different supported EMR application? There is also some concern about patient data security.

EMR Vendor Perspective.  Essentially, the vendors like the possibility of additional funding to support EMR adoption. However, there are concerns this would benefit the larger EMR vendors more than the mid-to-small sized ones.

A recent HIS Review blog post also provides a good overview of recent updates to the Stark Law and what hospitals need to be considering.

The most detailed outline of what a hospital will need to do around the Stark Law changes comes from a hospital CIO blog post. In Life as a Healthcare CIO, John Halamka describes the top ten planning items for hospitals to consider as they implement a strategy and program that leverages the Stark Law changes.

Obviously, how this all plays out is still up for debate. There are many elements to consider, not the least of these being how to integrate the patient data flow together between the different EMR applications, physician practices, and hospitals. In many respects, the debate is happening at the right level – the local level.

If healthcare IT is to be adopted by physician practices, the issues and plans will need to be resolved between the players in the communities.

Or, as is being done in some instances, the connections are being made between the different healthcare providers and their applications by leveraging interface engine technology.

The driving forces in these electronic transaction interactions are streamlined workflow, increased referrals, and faster turn around times to support quality patient care. There are several case studies that highlight specific providers connecting to various EMRs successfully and exchanging patient information. Business or operational drivers, not the Stark Law, are moving “connected healthcare” forward in these examples.

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.