Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Adverse Event Reporting and EHRs: The MEDTECH Act’s Effects

Posted on December 18, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

Medical systems generate adverse event (AE) reports to improve service delivery and public safety.

As I described in my first blog post on Adverse Events, these reports are both a record of what went wrong and a rich source for improving workflow, process and policy. They can nail responsibility not only for bad acts, but also bad actors and can help distinguish between the two. The FDA gathers AE reports to look for important health related patterns, and if needed to trigger recalls, modifications and public alerts.

EHRs generate AEs, but the FDA doesn’t require reporting them. Reporting is only for medical devices defined by the FDA and EHRs aren’t. However, users sometimes report EHR related AEs. Now, there’s proposed legislation that would preclude EHRs as medical devices and stop any consideration of EHR reports.

MEDTECH Act’s Impact

EHRs are benign software systems that need minimal oversight. At least that’s what MEDTECH Act’s congressional sponsors, Senators Orrin Hatch (R- Utah) and Michael Bennett (D- Colorado) think. If they have their way – and much of the EHR industry hopes so – the FDA can forget regulating EHRs and tracking any EHR related AEs.

EHRs and Adverse Events

Currently, if you ask MAUD, the FDA’s device, adverse event tracking system about EHRs, you don’t get much, as you might expect. Up to October, MAUD has 320,000 AEs. Of these about 30 mention an EHR in passing. (There may be many more, but you can’t search for phrases such as “electronic health,” etc.) While the FDA hasn’t defined EHRs as a device, vendors are afraid it may. Their fear is based on this part of the FDA’s device definition standard:

[A]n instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

…[I]ntended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals…

I think this section clearly covers EHRs. They are intended for diagnostic, cure, mitigation, etc., of disease. Consistent public policy in general and a regard for protecting the public’s health, I think, augers for mandatory reporting of EHR caused AEs.

Why then aren’t EHRs devices that require AE reporting? In a word, politics. The FDA’s been under pressure from vendors who contend their products aren’t devices just software. They also don’t want their products subject to being criticized for failures, especially in instances where they have no control over the process. That may be understandable from a corporate point of view, but there are several reasons for rejecting that point of view. Consider what the FDA currently defines as a medical device.

Other Devices. The FDA captures AE reports on an incredible number of devices. A few examples:

  • Blood pressure computers
  • Crutches
  • Drug dose calculators
  • Ice bags
  • Lab gear – practically all
  • Robotic telemedicine devices, and many, many more.

ECRI on EHR Adverse Events

The respected patient safety NGO, the ECRI Institute, puts the issue squarely. Each year, it publishes its Top Ten Health Technology Hazards. Number one is inadequate alarm configuration policies and practices. Number two: “Incorrect or missing data in electronic health records and other health IT systems.” Its report says:

Many care decisions today are based on data in an electronic health record (EHR) or other IT-based system. When functioning well, these systems provide the information clinicians need for making appropriate treatment decisions. When faults or errors exist, however, incomplete, inaccurate, or out-of-date information can end up in a patient’s record, potentially leading to incorrect treatment decisions and patient harm. What makes this problem so troubling is that the integrity of the data in health IT (HIT) systems can be compromised in a number of ways, and once errors are introduced, they can be difficult to spot and correct. Examples of data integrity failures include the following:

  • Appearance of one patient’s data in another patient’s record (i.e., a patient/data mismatch)
  • Missing data or delayed data delivery (e.g., because of network limitations, configuration errors, or data entry delays)
  • Clock synchronization errors between different medical devices and systems
  • Default values being used by mistake, or fields being prepopulated with erroneous data
  • Inconsistencies in patient information when both paper and electronic records are used
  • Outdated information being copied and pasted into a new report Programs for reporting and reviewing HIT-related problems can help organizations identify and rectify breakdowns and failures.

ECRI spells out why AE reporting is so important for EHRs:

…[S]uch programs face some unique challenges. Chief among these is that the frontline caregivers and system users who report an event—as well as the staff who typically review the reports—may not understand the role that an HIT system played in an event…

The MEDTECH Act’s Effects

The move to curtail the FDA’s EHR jurisdiction is heating up. Senators Hatch and Bennett’s proposed act exempts EHRs from FDA jurisdiction by defining EHRs as passive data repositories.

Most industry chatter about the act has been its exempting EHRs and others from the ACA’s medical device tax. However, by removing FDA’s jurisdiction, it would also exempt EHRs from AE reports. Repealing a tax is always popular. Preventing AE reports may make vendors happy, but clinicians, patients and the public may not be as sanguine.

The act’s first two sections declare that any software whose main purpose is administrative or financial won’t come under device reporting.

Subsection (c) is the heart of the act, which exempts:

Electronic patient records created, stored, transferred, or reviewed by health care professionals or individuals working under supervision of such professionals that functionally represent a medical chart, including patient history records,

Subsection (d) says that software that conveys lab or other test results are exempt.

Subsection (e) exempts any software that makes recommendations for patient care.

There are several problems with this language. The first is that while it goes to lengths to say what is not a device, it is silent about what is. Where is the line drawn? If an EHR includes workflow, as all do, is it exempt because it also has a chart function? The bill doesn’t say

Subsection (d) on lab gear is also distressing. Currently, most lab gear are FDA devices. Now, if your blood chemistry report is fouled by the lab’s equipment ends up harming you, it’s reportable. Under MEDTECH, it may not be.

Then there’s the question of who’s going to decide what’s in and what’s out? Is it the FDA or ONC, or both? Who knows Most important, the bill’s negative approach fails to account for those AEs, as ECRI puts it when: “Default values being used by mistake, or fields being prepopulated with erroneous data.”

Contradictory Terms

The act has a fascinating proviso in subsection (c):

…[P]rovided that software designed for use in maintaining such patient records is validated prior to marketing, consistent with the standards for software validation relied upon by the Secretary in reviewing premarket submissions for devices.

This language refers to information that device manufacturers file with HHS prior to marketing. Oddly, it implies that EHRs are medical devices under the FDA’s strictest purview, though the rest of the act says they are not. Go figure.

What’s It Mean?

The loud applause for the MEDTECH act coming from the EHR industry, is due to its letting vendors off the medical device hook. I think the industry should be careful about what it’s wishing for. Without effective reporting, adverse events will still occur, but without corrective action. In that case, everything will seem to go swimmingly. Vendors will be happy. Congress can claim to being responsive. All will be well.

However, this legislative penny in the fuse box will prove that keeping the lights on, regardless of consequences, isn’t the best policy. When something goes terribly wrong, but isn’t reported then, patients will pay a heavy price. Don’t be surprised when some member of Congress demands to know why the FDA didn’t catch it.

Rep. Phil Gingrey Comes After Healthcare Interoperability and Epic in House Subcommittee

Posted on July 30, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

On July 17th, the House Energy and Commerce Committee’s subcommittee on Communications and Technology and Health (that’s a mouthful) held a hearing which you can see summarized here. Brought into question were the billions of dollars that have been spent on EHR without requiring that the EHR systems be interoperable.

In the meeting Rep. Phil Gingrey offered this comment, “It may be time for this committee to take a closer look at the practices of vendor companies in this space given the possibility that fraud may be perpetrated against the American taxpayer.”

At least Rep. Gingrey is a former physician, but I think he went way too far when he used the word fraud. I don’t think the fact that many EHR vendors don’t want to share their healthcare data is fraud. I imagine Rep. Gingrey would agree if he dug into the situation as well. However, it is worth discussing if the government should be spending billions of dollars on EHR software that can’t or in more cases won’t share data. Epic was called out specifically since their users have been paid such a huge portion of the EHR incentive money and Epic is notorious for not wanting to share data with other EHR even if Judy likes to claim otherwise.

The other discussion I’ve seen coming out related to this is the idea of de-certifying EHR vendors who don’t share data. I’m not sure the legality of this since the EHR certification went through the rule making process. Although, I imagine Congress could pass something to change what’s required with EHR certification. I’ve suggested that making interoperability the focus of EHR certification and the EHR incentive money is exactly what should be done. Although, I don’t have faith that the government could make the EHR Certification meaningful and so I’d rather see it gone. Just attach the money to what you want done.

I have wondered if a third party might be the right way to get vendors on board with EHR data sharing. I’d avoid the term certification, but some sort of tool that reports and promotes those EHR vendors who share data would be really valuable. It’s a tricky tight rope to walk though with a challenging business model until you build your credibility.

Tom Giannulli, CMIO at Kareo, offers an additional insight, “The problem of data isolationism is that it’s practiced by both the vendor and the enterprise. Both need to have clear incentives and disincentives to promote sharing.” It’s a great point. The EHR vendors aren’t the only problem when it comes to not sharing health data. The healthcare organizations themselves have been part of the problem as well. Although, I see that starting to change. If they don’t change, it seems the government’s ready to step in and make them change.

What Does Direct Messaging Look Like for MU2?

Posted on June 11, 2014 I Written By

Julie Maas is Founder and CEO of EMR Direct, a HISP (Health Information Service Provider) whose mission is to simplify interoperability in healthcare through the use of Direct messaging EHR integration and other applications. EMR Direct works with a large developer community to enable Direct for MU2 and other workflows using a custom, rapid-integration API that's part of the phiMail Direct Messaging platform. Julie is passionate about improving quality of care and software user experience, and manages ongoing interoperability testing within DirectTrust. Find Julie on Twitter @JulieWMaas.

I’m often asked what EHR integrations of Direct are supposed to look like.  In the simplest sense, I liken it to a Share button and suggest that such a button—typically labeled “Transmit”—be placed in context near the CCDA that’s the target of the transmit action, or in a workflow-friendly spot on a patient record screen.

Send a CCD Using Direct Messaging

Send CCD using Direct in OpenEMR

The receive side is similarly intuitive: the practice classifies how their incoming records are managed today and we map that process to one or more Direct addresses.  If we get stuck, I ask, “What is the workflow for faxes today–how many fax numbers are there, and how are they allocated?”  This usually helps clear things up:  as a starting point, a Direct address can be assigned to replace each fax endpoint.

The address structure raises an important question, because it is tightly tied to the Direct messaging user interface.  Should there be a Direct address for every EHR user?  Provider?  Department? Organization?  A separate address for the patient portal?  A patient portal that spans multiple provider organizations? One for every patient?

The rules around counting Direct messages for Transitions of Care (ToC) attestation do not require each provider to have their own Direct address, as long as the EHR can count transactions correctly for attestation.  As far as meaningful use is concerned, any reasonable address assignment method should be acceptable in ToC use cases (check the rules themselves, for full details).  Here are some examples.

records@orthodocs.ehrco-example.com is clearly an address that could be shared by multiple users, though it could be used by just one person, and might be used for both transitions of care and patient portal transmit.

janesmith@orthodocs.hisp-example.com could also be dual-purpose.  Jane might be the only authorized user of this address, or this address may be managed by a group of people at her practice that does not necessarily even include Jane.  Alternatively, this address could be used for Jane’s ToC transactions, while a patientportal@someother.domain-example.com address could be used for patient portal transmit.

So, any of the options proposed above are possible conventions for assigning Direct addresses.  Also, a patient does not need their own Direct address to Transmit from as part of the View, Download, Transmit measure (170.314(e)(1)), but might have their own address to transmit to.  Note that adding a little extra data can elevate a View, Download, Transmit implementation to BlueButton+ status.

It makes sense for patients and providers to have their own Direct addresses if they are using Direct for Secure Messaging – 170.314(e)(3) – for which Direct is an optional solution.  Or, if patients have their own Personal Health Record (PHR) and Direct address, Direct is a great way to deliver data to the PHR.  Incidentally, there are free services such as Microsoft HealthVault and many others that issue patient Direct addresses.

Direct addresses are nearly indistinguishable from regular email addresses, but a word of caution: Direct is incompatible with regular email, and has additional requirements beyond traditional S/MIME.  Although it’s not a requirement, you’ll often find the word “direct” somewhere in the domain part of a Direct address, to help distinguish a regular email address from a Direct address.

Now that you know what Direct is, and what Direct Messaging and Direct addresses look like, I’m sure you’ll start noticing Direct popping up in more and more places.  So, be a not-so-early adopter and go get yourself a Direct address!

What is Direct?

Posted on June 10, 2014 I Written By

Julie Maas is Founder and CEO of EMR Direct, a HISP (Health Information Service Provider) whose mission is to simplify interoperability in healthcare through the use of Direct messaging EHR integration and other applications. EMR Direct works with a large developer community to enable Direct for MU2 and other workflows using a custom, rapid-integration API that's part of the phiMail Direct Messaging platform. Julie is passionate about improving quality of care and software user experience, and manages ongoing interoperability testing within DirectTrust. Find Julie on Twitter @JulieWMaas.

John’s Update: Check out the full series of Direct Project blog posts by Julie Maas:

The specialist down the street insists he wants to receive your primary care doctor’s referrals, but only if it’s digital: “Sure, I’ll take your paper file referral sent via fax. But the service will cost an extra $20, to pay the scribe to digitize the record so I can properly incorporate the medical history.”

Does it really sound that far off? Search your feelings, Luke…

Will getting medical treatment using paper records soon be like trying to find somewhere to play that old mix tape you only have on cassette?  Sound crazy?  Try taking an x-ray film to a modern radiology department, and see if they still have a functioning light box anywhere to look at it.  It’s all digital now.

There are, of course, other factors.

Because MU2.

Because nobody, and I mean no small company and no large company, wants to be referred to as a data silo anymore.

Direct Exchange is a way of sending and receiving encrypted healthcare data, and certified EHRs must be able to speak it, beginning this year.  Adoption of Direct is increasing rapidly, and its secure transfer enables patient engagement as well as interoperability between systems that were previously dubbed silos.  Here is a brief overview of where Direct is currently required in the context of MU2 (please refer to certification and attestation requirements directly, for full details):

Certified ambulatory and acute EHRs need to use Direct for Transitions of Care (170.314(b)(1) and (b)(2)). They have to be able to Create a valid CCDA and Transmit it using Direct, and they have to be able to use Direct to Receive, Display, and Incorporate a CCDA. In the proposed MU 2015, the Direct piece may be de-coupled from the CCDA piece and modularized for certification purposes, but the end to end requirement would remain the same.

EHRs or their patient portal partner additionally need to demonstrate during certification that patients can View, Download, and Transmit via Direct their CCDA or a human readable version of it.  Yes, you heard correctly, I said patients.  As in patient engagement.

So, how does a healthcare provider get Direct?

1. Get a Direct account through your Direct-enabled EHR vendor

One way HIT vendors offer Direct is through a partnership with one or more HISPs (OpenEMR, QRS, Greenway, and others).  Others run their own HISPs (Cerner, athenahealth, and others).

2. Get a Direct account through an XD* HISP that’s connected to your EHR

HIT vendors alternatively enable access to Direct through an XD* plug-and-play (mostly) connector.  These “HISP-agnostic” EHRs allow healthcare organizations a choice between multiple XD*-capable HISPs when meeting MU2 measures (MEDITECH, Epic, Quadramed, and other EHRs have implemented Direct this way).  EMR Direct, MaxMD, Inpriva, and a few other HISPs offer XD* HISP services; not every HISP offers XD* service at this time.  Of course, there is a trade-off between this flexibility and the extra legwork required of the practice or hospital in setting up Direct.

3. Get a web-based or email client-based Direct account not tethered to an EHR or Personal Health Record (PHR)

 

Direct doesn’t have to be integrated into an EHR to transfer information digitally. Non-tethered accounts cannot attest to the sending side of (b)(2) nor the receiving side of (b)(1) on their own, but they can be Direct senders and receivers nonetheless, participating in Transitions of Care or data transfer for other purposes.  They may also be used to exchange health data with patients, billing companies, pharmacies, or other healthcare entities who are Direct-enabled. In fact, some very compelling use cases involve systems who may not have their own EHR, but want to receive digital transitions of care—one such example is skilled nursing facilities.

By the way, patients are also an integral part of the Direct ecosystem.  Several PHRs are already Direct-enabled, and more are on the way.

So, go digital and get your Direct address, and begin interoperating in the modern age!

EHR Post Acquisition, 2014 Certified, ICD-10 and the Amazing Charts Future with John Squire, President and COO

Posted on April 30, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I had the chance to sit down and interview John Squire, President and COO of Amazing Charts. I was interested to learn about the transition Amazing Charts has experienced after being purchased by Pri-Med and the departure of Amazing Charts Founder, Jonathan Bertman. Plus, I wanted to learn why Amazing Charts wasn’t yet 2014 Certified and their plans to make it a reality. We also talk about the value of meaningful use and the ICD-10 delay. Then, we wrap up with a look at where Amazing Charts is headed in the future.

Check out EHR videos for all of my EHR and Healthcare IT interview videos and be sure to subscribe to the Healthcare Scene youtube channel.

Reply to Dr. Jacob Reider on NIST Dissects Workflow: Is Anyone Biting?

Posted on March 31, 2014 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

One comment on my latest post, NIST Dissects Workflow: Is Anyone Biting?, deserves a more than casual reply.

Here’s the comment from Jacob Reider (Note: Dr. Reider is ONC’s Acting Principle Deputy National Coordinator and Chief Medical Officer. He has made major contributions to the HIT field and is one of its significant advocates.)

Carl, ONC’s UCD requirement references ISO 9241–11, ISO 13407, ISO 16982, NISTIR 7741, ISO/IEC 62366 and ISO 9241–210 as appropriate UCD processes.

We also require summative testing as defined in NISTIR 7742.

Might “Refuses to incorporate NIST recommendations” be a bit of an overstatement?

We solicited public comment in our proposed rule for 2015 certification and would welcome specific suggestions for how we can/should improve user experience of health IT products for efficiency and safety.

Dr. Reider, thank you for your comment – it certainly falls into the category of you never know who’s reading.

Let’stake a look at your last comment first, “Might ‘Refuses to incorporate NIST recommendations’ be a bit of an overstatement?”

Obviously, I don’t think so, but I am not alone.

I based my comment on ONC’s statement in its rule making that refers to NIST’s usability protocols. It says:

While valid and reliable usability measurements exist, including those specified in NISTIR 7804 “Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,” (21) we are concerned that it would be inappropriate at this juncture for ONC to seek to measure EHR technology in this way.

Sounds like a rejection to me, however, don’t take my word. Here’s the AMA’s response to this decision. First, they demur and quote ONC:

We disagree with ONC’s assertion in the Version 2014 final rule that, “[w]hile valid and reliable usability measurements exist, including those specified in NISTIR 7804 ‘‘Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,’’ we expressed that it would be inappropriate for ONC to seek to measure EHR technology in this way.”

It then says:

To the contrary, we believe that it is incumbent upon ONC to include more robust usability criteria in the certification process.  The incentive program has certainly spurred aggressive EHR uptake but has done so through an artificial and non-traditional marketplace.  As a consumer, the physician’s choice of products is limited not only by those EHRs that are certified but also by the constraint that all of these products are driven by federal criteria.  The AMA made several detailed recommendations for improving Version 2014 certification in our Stage 2 comment letter, which were not adopted, but still hold true, and we recommend ONC consider them for the next version.  Testimony of AMA’s Health IT Policy Committee’s Workgroups on Certification/Adoption and Implementation, July 23, 2013, pp. 5-6

I recognize that ONC says that it may consider the protocols in the future. Nevertheless, I think the plain English term rejected fits.

In the first part of his statement, Dr. Reider cites several ISO standards. With the exception of the Summative Testing, all of these have been referred to, but none have been adopted. Reference to a standard is not sufficient for its inclusion under the operation of the federal Administrative Procedure Act, which governs all federal agency rulemaking. In other words, these standards are important, but ONC simply calls them out for attention, nothing more.

I think two factors are at work in ONC’s reluctance to include the NIST usability protocols. The first is that the vendors are adamantly opposed to having them mandated. However, I believe there is a way around that objection.

As I have argued before, ONC could tell vendors that their products will be subject to a TURF based review of their product for compliance and that the results would be made public. That would give users a way to judge a product for suitability to their purpose on a uniform basis. Thus, users looking at the results could determine for themselves whether or not one or more non compliance was important to them, but at least they would have a common way to look at candidate EHRs, something they cannot do now , nor under ONC’s proposed approach.

The other factor is more complex and goes to the nature of ONC’s mission. ONC is both the advocate and the standards maker for HIT. In that, it is similar to the FAA, which is vested with both promoting and regulating US aviation.

It’s well established that the FAA’s dual role is a major problem. It’s hard to be a cheerleader for an industry and make it toe the line.

With the FAA, its dual mandate is exacerbated when the highly respected NTSB investigates an incident and makes recommendations. The FAA, acting as industry friend, often defers NTSB’s authoritative and reasonable recommendations to the public’s determent.

I believe that something similar is going on with ONC. NIST’s relationship to ONC is roughly analogous to that of the NTSB’s to the FAA.

NIST is not an investigative agency, but it is the federal government’s standards and operations authority. It isn’t infallible. However, ONC dismissing NIST’s usability protocols, in one word, inappropriate. It did this without explanation or analysis (at least none that they’ve shared). In my view, that’s really inappropriate.

ONC has a problem. It’s operating the way it was intended, but that’s not what patients and practioners need. To continue the aviation analogy, ONC needs to straighten up and fly right.

Interview with ICSA Labs About EHR Certification

Posted on January 31, 2014 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

After hearing the news about CCHIT shutting down it’s EHR certification business, I thought it would be interesting to interview ICSA Labs, the EHR Certification body that CCHIT recommended to its users. The following is an interview with George Japak, Managing Director at ICSA Labs.

Is there a backlog of EHR vendors that want to schedule test dates with ICSA labs?  

A: There is no backlog. Since ICSA Labs received its ONC authorization, it has been our intent to grow our healthcare programs and offer the best testing and certification program in the industry. Over time we have ramped up our testing team and we have a deep pool of very experienced testers on staff. We have been getting a steady stream of news customers and inquiries and expect the CCHIT announcement will accelerate the pace.  At this point we have the capacity to test applicants as they are prepared to do so.

Is ICSA Labs able to support the onslaught of EHR companies that will come over from CCHIT?  Will that cause any delays on getting EHRs certified?

A: ICSA Labs at this point does not anticipate any delays. The ONC program was designed so that vendors and product developers would have a choice when it came to testing and certification. We were not the first lab to be authorized, but we knew that given the opportunity we would be able to deliver a program where customers would experience high satisfaction.

In my post, I suggested that the economics of EHR certification aren’t all that great.  Especially if you have a legacy cost structure like CCHIT.  Is the secret to ICSA’s success having a broader certification business beyond just EHR?

A: ICSA Labs has been in business since 1989, we have a number of accreditations to support an array of certification and testing programs, such as the IHE USA Certification program which just kicked off its second year at the 2014 IHE North American Connectathon. Our business is diverse and we leverage our capabilities across our business. We are used to doing business in competitive markets, so it has always been important for our programs and cost structure to emphasize efficiency and effectiveness and those benefits are passed onto our customers. Our testing and certification programs have always been competitively priced and efficient yet rigorous and done superior quality.

How much more complex is 2014 EHR certification compared with 2011 from an ONC-ACB perspective? 

A: As any recently certified company can attest to, the 2014 Edition criteria are significantly more complicated than the 2011 Edition. There are more test tools to maintain; more test data sets to review; frequent revisions and updates to the criteria and additional types of attestation to review. The time to complete testing has close to doubled and there are more requirements as they pertain to surveillance. After the 2011 Edition criteria, ICSA Labs asked for ONC to raise the bar, and they did. For ICSA Labs the added complexity was not unexpected.

The timelines for meaningful use stage 2 are starting to get squeezed.  Will the majority of EHR vendors be 2014 certified and ready in time?

A: There will always be stragglers, but I believe a majority of EHR vendors will be 2014 certified and ready in time for Meaningful Use 2. There has been an uptick in the vendors getting certified over the last few months. Providers and hospitals however are a different story, and they may feel the squeeze in terms of the timeline to purchase, implement and begin meaningfully using their EHR system. ONC extended the Stage 2 timeline to relieve some of that pressure.

I’ve heard that in some cases the ONC-CPHL has been slow at putting up newly certified EHRs.  Have you seen this?  Do you have a bunch of 2014 certified EHR vendors that haven’t been listed on ONC-CPHL yet?

A: The ONC-CHPL is generally responsive to our concerns and we work with them as they continue to refine new features like links to the public test results summary.

Bill Would Allow Mental Health Providers To Get MU Incentives

Posted on November 25, 2013 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Right now, mental health providers aren’t eligible to get Meaningful Use incentive payments — but a new bill would make that possible.  U.S. Senator Rob Portman, a Republican from Ohio, has filed legislation that would add mental health providers to HITECH, making them eligible for payments if they meet Meaningful Use standards, according to a story in Healthcare IT News.

The bill, the Behavioral Health Information Technology Coordination Act, is intended to “fix an oversight in the system,” said Portman in a press statement announcing its filing. “”[By] making IT the bedrock to fully integrated care, my bill will enhance care and treatment for the mentally ill and put them on a path to lead healthy and productive lives.”

The announcement drew praise from a mental health trade organization in Portman’s home state. The CEO of the Ohio Council of Behavioral & Family Health Services Providers, Hubert Wirtz. “Adequate investment in healthcare information technology is critical to enabling mental health and addiction providers to implement systems that help them improve care coordination, provide quality care, measure outcomes and enable continuity of care between primary care, mental health and addiction services,” reports HIN.

However, it seems that Portman’s bill may not reach a vote, as it now sits in a congressional committee, the HIN story notes.

Regardless, though, Portman’s proposal is a good one. Good mental health outcomes, which the right EMR can enhance, can do much to address the health of a population, empowering consumers to take better care of their physical health.  What’s more, encouraging behavioral health providers to have a mental health EMR in place can share their findings smoothly with care managers (ideally PCPs) who can do their part to provide integrated care. All told, this seems like an idea whose time has come.

Non-Profit Achieves Meaningful Use For In-House EMR

Posted on October 23, 2013 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Most organizations hoping to achieve Meaningful Use milestones buy their way in, by acquiring certified technology from an established EMR vendor. However, there are still some organizations that are working to create in-house technology that meets Meaningful Use standards.

One such organization, the Massachusetts eHealth Collaborative (MAeHC), recently achieved a nice win by meeting all three Meaningful Use Stage 2 requirements for its in-house-built EMR module, according to a report in Information Week. To meet certification criteria, modular EMRs must use the Quality Reporting Document Architecture Type 1 document to capture and input the data electronically.

MAeHC, a not-for-profit health IT organization, has created a modular EMR for clinical quality measurements (CQM) reporting, which the CCHIT certified to support Meaningful Use Stage 2, IW reports. The MAeHC product, which is hosted in the cloud, integrates with stand-alone EMRs and can span across multiple EMR platforms.

Getting certified was partly a matter of interpreting the criteria for Stage 2, which include capture and export, import and calculate and electronic submission, MAeHC execs told IW.

From the get-go, for example, the first criterion was problematic, as “capture and export” require EMRs to electronically record data and export it using established standards. MAeHC’s EMR has no user interface to manually key in data.

But the group’s leaders were determined to meet all three criteria, and they managed to get all of their issues sorted out. The MAeHC system is now certified for eligible providers and should be certified for eligible hospitals within the next few weeks, according to IW.

Looking at the challenges faced by those that blaze their own EMR trail, it’s interesting to note that two years ago, Beth Israel Deaconess Medical Center became the first hospital to have its entire home-brewed EMR certified as “complete” by the CCHIT. Considering the resources required, and the tough problems a group like MAeHC faced just to create one module, I’m not surprised that most of its hospital brethren have gone with packaged solutions instead.

MGMA Raises Meaningful Use Stage 2 Concerns

Posted on August 26, 2013 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Becoming another of several groups asking for Meaningful Use changes, the head of the Medical Group Management Association has written a letter to HHS outlining several concerns the group has with Meaningful Use Stage 2.

In the letter, which was addressed to HHS Secretary Kathleen Sebelius, MGMA President and CEO Susan Turney raised several issues regarding the ability of her members to step up to Stage 2. She argued that physicians have a “diminished opportunity” to achieve Stage 2 compliance, and that as a result it would be unfair to impose Medicare reimbursement sanctions on her members. Turney argues that HHS should institute an “indefinite moratorium” on practices that have successfully nailed Stage 1 Meaningful Use requirements.

Why should HHS give practices a break?  The reason, she says, is that vendors are proving slow to produce Stage 2-certified products, leaving medical practices in the lurch. At the time of writing, Turney said, there were only 75 products and 21 complete EMRs certified for Stage 2 criteria, a small fraction of the more than 2,200 products and nearly 1,400 complete EMRs certified under 2011 criteria for ambulatory eligible professionals.

With vendors largely not ready yet to help practices through Stage 2, practices are likely to have little time to work on software upgrades or expect timely vendor support, she notes. And worse, EPs who invested big in Stage 1-certified EMRs might need to “rip and replace” them for a new one certified to meet Stage 2 if they want to avoid Medicare reimbursement cutback deadline.

On top of all of this, she notes, many practices are having to wait in line for Stage 2 upgrades of their EMR product behind practices adopting  an EMR for the first time. The wait is lengthened, meanwhile, by vendors’ attempts to cope with ICD-10 support, whose Oct. 1, 2014 deadline falls right in the middle of preparations for Meaningful Use Stage 2.

Turney makes a lot of sense in her comments. The vendor market clearly isn’t going to be able to keep up with ICD-10, MU upgrades and new installation within the same time period. I don’t know if an indefinite moratorium on Medicare penalties is the right policy response, but it should certainly be given some thought.

After all, punishing doctors who drop out of Meaningful Use due to factors beyond their control isn’t going to help anyone, either.