Last week I wrote wondering who will police EMRs and EHRs. With the release of IOM’s report recommending the creation of a different federal agency to serve as EMR watchdog, this topic has been generating buzz in healthcare circles. I’m by no means an expert in healthcare IT or policy matters but the discussion surrounding this topic has helped me think things through better than last week. Commenter Don Fluckinger answered the blog post with the first comment on the post – saying “these guys” and pointing to EHREvent.org. Commenter Carl Bergman said the FDA, which is already tasked with gathering adverse events for medical devices, might be the ideal go-to-agency for software adverse events as well. It is my understanding that medical software would receive Category 3 classification, if FDA were to provide the oversight.

IOM’s approach has been to suggest the creation of a non-regulatory, NTSB-like body. IOM’s rationale for undercutting FDA’s role has been that FDA classification system might stifle health IT innovation. (I’ve only had the time to read the very first few pages summarizing the rest of the IOM report, so I’m not sure if/how they address these concerns later.)

Here’s what I don’t get: What’s the point of creating yet another powerless body to issue guidelines? If there’s already a body with regulatory and oversight powers that covers your domain, has a large database of medical device related adverse events, why can its capabilities not be extended further to medical software as well? Further, why are health IT vendors exempt from any slaps on the wrist?

No offense to anyone, but from what I’m reading about EHRevent.org, I don’t see much to recommend them: John says they “are not going to have high enough profile to be able to really collect the reports… a reporting system is great, but if no one knows to report something there, then it’s not worth much. Plus, if someone reports something but the organization doesn’t do anything with that information, it’s not very meaningful”. Valid question but I think there could be some easy workarounds for the problem of not knowing how/where to report shouldn’t be a major issue. Healthcare IT just needs the software equivalents of those “How’s my driving?” flaps adorning the backs of 18-wheelers. The bigger question is what happens when the EMR system fails? Who pays? How much? How does the vendor ensure the failure doesn’t happen again? Do we learn from the cumulative mistakes of the industry? Time will tell.

As you may know, not long ago I wrote up a rant slamming awkward-to-use EHR interfaces, an article which has drawn plenty of reader debate and discussion.

Today, I learned that the government is paying attention to this issue as well (and not a moment too soon).

The National Institute of Standards and Technology (NIST, to its friends and relations) announced that it would be holding a free workshop on EHR usability intended help all sectors of the industry collaborate on the problem. NIST hopes to attract industry players, academics, government officials and healthcare providers to the same table.

The workshop, which will take place on Tuesday, June 7 on NIST’s Gaithersburg, MD headquarters, will focus on four key questions:

• What facets of usability should be measured?
• What measurement methods and protocols should be used to do this?
• What are some of the challenges to rigorous measurement and how can they be addressed?
• How can measurement results stimulate a market and support improved usability?

Call me a cynic, but I don’t see participants making a lot of progress on these questions in a single day. Heck, you could spend weeks or months on any of these issues and still end up spinning your wheels.

That being said, it’s always good to see the bureaucrats pay attention to an issue like this. Why? Because if bureaucrats have any virtues, one is that when they grab an issue, they tend to stick to it. (I’d rather see CMS dig into this topic, but hey, NIST’s a start.)

With hundreds of EHR vendors competing for mindshare out there, it’s not likely they’ll come together to set usability standards on their own. But if pesky government types — from both the policy and tech sides — decide to dig their teeth into the usability problem, it’s probably a good thing.

I don’t know about you, but I think attending is a great idea. If any of you make it, please feel free to let us know what you learned. It should be an interesting session.

Ok, was that enough abbreviations in the title of a post? Well, if you care about this post, you’ll probably recognize all of the abbreviations.

In a post I did on EMR and HIPAA about SureScripts as an ePrescribing ATCB, there was a comment made that possibly some of the ATCB were “in bed” with ONC in order to get their EHR certification body status. In response to the comment, Mark Joyce from SLI Global Solutions (an ATCB) provided some good insight into the process and costs associated with becoming an ATCB that can certify EHR software.

As the team lead for SLI’s application to the ONC I can assure you that our company has no political connections, traded favors or made contributions that won us our certification by the ONC. It was 10 weeks of grueling research by two independent companies (one company focusing on testing and the other certification) that resulted in a 1200 page application.

The application was in two parts: part one required both companies to expand and/or create a Quality Management System for the new process. It’s no easy task to develop both a 17025 and a Guide 65 conformant QMS. Part two required the applicant to have a thorough understanding of EHR architectures as well the NIST testing procedures and tools.

It was evident by the followup questions from the ONC that the application had been very carefully reviewed.

Obtaining certification from the ONC was no easy task. I am proud to be a part of our companies significant investment in the ATCB testing and certification process.

Yes, becoming an ONC-ATCB is definitely not a walk in the park to achieve. Anyone that says otherwise, likely hasn’t ever been through the process.

In case you missed it, I posted on my other site about the NIST EHR Certification testing website. I still haven’t had much time to dig deep into what’s available, but one of my readers sent me the following (excuse the lack of form since they probably didn’t intend it to be published):

Boy, I don’t know what to think. Much of this seems to be piles of words referring to zillions of links.

However, I did find a place where it talks about the “Draft Test Procedures.” Under that heading it lists the “Draft Test Method” for a category such as Maintain Active Medication List. It shows, for instance, that you must be able to enter something like:

RxNormCode Medication Brand Name (generic name) Dose Form Route Frequency DateStarted DateStopped
205875 Diabeta (glyburide) 2.5 mg Tablet By mouth(po) every morning 9/16/09
617314 Lipitor (atorvastatin calcium) 10 mg Tablet By mouth(po) daily 5/5/08

and then modify, and later list. So, I guess if a system didn’t have the ability to enter “route” then does this mean the system fails? Or, does allowing an improper form of “route” for the med make it fail? Unclear. On the other hand, because you can enter and modify all of the above, does it “pass”? What is missing, from my opinion, is the useability factor. My docs, for instance, like to see the history of dispensing of a given medication. Knowing and being able to easily see the various dispensings of amoxicillin is key to practicing good medicine. The Draft does not address that and is, in my opinion, a major missing point. One can have a system where doing anything takes lots of clicks and typing, or common things can be done in a few steps.

The rest of the Draft Test Methods are the same. Enter this, change that, make a list.

It would be nice if someone could tell me what it is I’m missing.

Does anyone else get the feeling that this certification stuff is going to be a mess and add little value for doctors?

CCHIT’s Mark Leavitt has published his analysis of the $400,000 contract that NIST awared to Booz Allen Hamilton to develop a framework for electronic health record certification (see certified EHR).

Honestly, it seems that Mark’s as confused as everyone about this whole process. This is an interesting development since I would have thought that CCHIT would have had a close relationship with HHS, ONC, NIST, CMS, etc. The fact that CCHIT and Mark Leavitt are kind of left in the dark and full of lots of questions is not a good sign for CCHIT and fans of CCHIT. It is a good sign for those who don’t care for CCHIT.