John’s recent post about ONC trained participants finding it difficult to find jobs struck a chord. A different post over at HIMSS had me thinking in overdrive.

Dr. Noam Arzt has a post on Meaningful Use and public health reporting. In it he discusses the problems faced by providers in submitting health information to public health bodies in ways that are also Meaningful Use Stage 1 compliant.

Health records in provider offices are sometimes stored in disparate silos that are cannot/do not communicate with one another. As Dr. Arzt explains with an immunization records example, there is no demonstrable Meaningful Use if an uncertified system makes the data submissions to public health.

Of course, adding additional functionality to the EHR system with a simultaneous revamping of uncertified system to provide Meaningful Use share data with one another is one (costly) solution. Getting the secondary data system certified is another one. A third approach, which Dr. Arzt touches on, is for Health Information Exchanges to act as/provide for certified intermediaries that bridge the data flow between an uncertified system and one that is Meaningful Use certified.

Here’s what HHS had to say about the subject a month ago:

If an intermediary performs a capability specified in an adopted certification criterion and a provider intends to use the capability the intermediary provides to satisfy a correlated meaningful use requirement (submission to public health according to adopted standards), the capability provided by the intermediary would need to be certified as an EHR Module

This intermediary need can be filled, especially by innovative software vendors or those looking to break into the EHR IT industry. From plain data conversions to web services, IT companies have plenty of tricks up their sleeve to assist HIEs. The technology is there, all we need are savvy techies (companies, people) to see the opportunity this presents and act on it.

Guest Post – Amit Trivedi – As the healthcare program manager for ICSA Labs, Amit Trivedi spearheads the lab’s overall efforts in the healthcare industry, including launching and managing the 2011/2012 Office of the National Coordinator (ONC) Authorized Testing and Certification Body (ATCB) certification program.

We all know there is no such thing as perfect security. All we can do is try to mitigate as many risks as possible. In this regard, there are areas related to information security that the current ONC-ATCB 2011/2012 (commonly referred to as meaningful use) certification testing does not yet address and that the health IT community should be aware of when implementing systems.

ICSA Labs is an Office of the National Coordinator-Authorized Testing and Certification Body (ONC-ATCB), designated to test both complete and modular electronic health record (EHR) technologies under the auspices of the federal government’s Temporary Certification Program. ICSA Labs has a history rich in the certification of security products. We have been testing security products and developing test criteria for more than two decades and we understand the importance of raising security awareness in the health IT community and helping Eligible Providers and Hospitals understand what meaningful use EHR certification testing does and doesn’t cover.

It is important to remember that regardless of the number of security features a product has, an incorrect or incomplete implementation can introduce vulnerabilities or compromise the security of the system. Certification testing can really only demonstrate that a product is capable of being used securely, not that its security can never be compromised.

Testing bodies must test products within the scope of approved test procedures. As an organization that has developed testing procedures and methodologies, we understand that there is a delicate balancing act when developing requirements so that general concepts and capabilities are covered by the testing, but the testing process is not designed so specifically as to stifle innovation in new products. As such, we recommend that end users and implementers be aware of these requirements when deploying ONC-ATCB 2011/2012 certified products.

Encryption Requirements Do Not Address the “What”

Consider the encryption requirements (criteria 170.302.u and 170.302.v). The current testing criteria require FIPS 140-2 level encryption. This an excellent way to require products to support some of the best levels of encryption available today, and that they are also in line with other federal encryption requirements.

One could compare encryption to a bank vault. You might purchase the most secure, unbreakable vault in the world, but if you don’t put your valuables in the vault, it won’t be of any help when there is a break-in. The current meaningful use testing procedures do not dictate what must be encrypted. Ultimately it falls to end users to make a determination as to how they want to implement security – hopefully basing the decision on a risk-based approach. Fortunately, meaningful use testing and certification follows a staged approach to getting from where we are today to where we’d like to be in the future. The meaningful use certification is planned to be rolled out in three stages. Right now, we are in the midst of Stage 1. Some recommendations to the ONC for Stage 2 security criteria include addressing things like encrypting data at rest (including data in datacenters and mobile devices) – something that is not part of the Stage 1 requirements.

Negative Testing Examines the Unexpected

Another area to highlight is related to negative testing, which is currently out of scope for ONC-ATCBs. The testing performed today relies on giving the EHR an expected input and verifying that the expected result is met. Negative testing, however, is the concept of giving unexpected or invalid inputs to a system and verifying receipt of an expected result (typically, that the data is not accepted or an error is generated that does not crash the system). Negative testing is common throughout ICSA Labs’ proprietary security testing programs and something we feel should be incorporated into future testing of EHR technologies under the ONC Certification program.

Consider the authentication and access control requirements (criteria 170.302.t and 170.302.o). Some of you may be aware of an old Unix bug that resulted in the operating system being unable to correctly support passwords over eight characters. If the password was 12 characters long, a user only needed to enter the first 8 characters to be allowed to login. This made password cracking on Unix servers much easier, and because the system allowed the entry of a longer password, most users were unaware of this limitation.

ICSA Labs has discovered the same or similar problems when testing products in our proprietary security certification programs, and the primary way we discover this is by negative testing. For example, we configure a password greater than eight characters, and then we attempt to login to the system using only the first eight characters. This should be treated as invalid by the system and rejected. However, the meaningful use EHR testing only tests that the system accepts valid passwords. There is no testing done on the system’s acceptance or rejection of invalid passwords.

The Future of EHR Testing Must Increase Security, Privacy

As we progress to the next stages of meaningful use certification, the requirements should begin to look at other areas of security, such as application testing for vulnerabilities like buffer overflows, SQL Injection, and cross-site scripting attacks. These are all examples of security testing best practices. In many instances, ONC has signaled its flexibility in allowing third-party products to complement functionality of EHR technologies, which means that not all of the functionality needs to be native to the product. This can allow EHR developers to focus on functionality that their customers are looking for, while at the same time keeping security as an important consideration in the product life cycle development.

It is our hope that future stages of meaningful use testing will raise the bar and specify how and when features like encryption should be used and the scope of testing will be expanded to include things like negative testing. As the meaningful use criteria evolve, it is critical that both the criteria and testing procedures are developed in ways that consider the long-term security and privacy of patient health records.  

Time for the next entry covering Shawn Riley’s list of 101 Tips to Make your EMR and EHR More Useful. I hope you’re enjoying the series.

If you want to see my analysis of the other 101 EMR and EHR tips, I’ll be updating this page with my 101 EMR and EHR tips analysis. So, click on that link to see the other EMR tips.

60. Reporting, reporting, reporting, reports
What’s the point in collecting the data if you can’t report on it? I’ve before about the types of EMR reports that you can get out of the EMR system. The reports a hospital require will be much more robust than an ambulatory practice. In fact, outside of the basic reports (A/R, Appointments, etc), most ambulatory practices that I know don’t run very many reports. I’d say it’s haphazard report running at best.

Although, I won’t be surprised if the need to report data from your EHR increases over the next couple years. Between the meaningful use reporting requirements and the movement towards ACO’s, you can be sure that being able to have a robust reporting system built into your EHR will become a necessity.

59. Are the meaningful use (MU) guidelines covered by your product?
Assuming you want to show meaningful use, make sure your EHR vendor is certified by an ONC-ATCB. Next, talk to some of their existing users that have attested to meaningful use stage 1. Third, ask them about their approach for handling meaningful use stage 2 and 3. Fourth, evaluate how they’ve implemented some of the meaningful use requirements so you get an idea of how much extra work you’ll have to do beyond your regular documenting to meet meaningful use.

58. It they aren’t CCHIT certified take a really really hard look
Well, it looks like this tip was written pre-ONC-ATCB certifying bodies. Of course, readers of this site and its sister site, EMR and HIPAA, will be aware that CCHIT Has Become Irrelevant. Now it’s worth taking a hard look if the EHR isn’t an ONC-ATCB certified EHR. There are a few cases where it might be ok, but they better have a great reason not to be certified. Not because the EHR certification provides you any more value other than the EHR vendor will likely need that EHR certification to stay relevant in the current EHR market.

57. What billing systems do you interface with?
These days it seems in vogue to have an integrated EMR and PMS (billing system). Either way, it’s really important to evaluate how your EMR is going to integrate with your billing. Plus, there can be tremendous benefits to the tight integration if done right.

56. How much do changes and customizations cost?
In many cases, you can see and plan for the customization that you’ll need as part of the EHR implementation. However, there are also going to be plenty of unexpected customizations that you don’t know about until you’re actually using your EHR (Check out this recent post on Unexpected EHR Expenses). Be sure to have the pricing for such customizations specified in the contract. Plus, as much as possible try to understand how open they are to doing customizations for their customers.

Check out my analysis of all 101 EMR and EHR tips.

I’ve been writing about the various open source EHR software options for about 5.5 years right now. I’ve been intrigued with open source for much longer, so it just made natural sense for one of the first things for me to look at would be the various open source EHR options.

5.5 years ago the open source EHR market (although EHR really wasn’t in vogue yet back then) had a solid foundation, but still had quite a ways to go for it to be a great option for doctors interested in an open source EHR option.

I haven’t done an in depth look at the various open source EHR options for a while (I should), but I think the fact that many open source EHR software are now certified EHR and can help physicians show meaningful use and receive EHR incentive money is a good sign. Most of you know that I’m not a big fan of EHR certification, but I do believe that EHR certification takes a certain level of commitment to be able to achieve. Therefore, I think it’s a great sign that the open source EHR options have enough steam and commitment behind them to become certified EHR.

A recent Open Health News post listed the following certified open source EHR:
Ambulatory Open Source EHR
ClearHealth
OpenEMR
Tolven eCHR
Vista (inpatient) Open Source EHR
WorldVistA EHR
OpenVistA
vxVistA
Other (inpatient) Open Source EHR
Indian Health Services’ RPMS

I’d love to hear reviews and experiences that people have working with open source EHR software.

Carl Bergman, from EHRSelector.com, sent me the following email which poses some interesting questions about various certified EHR vendors and the software that they depend on to be certified.

Many of the [certified EHR] products relied on several other software companies to function. Usually this was Dr. First’s Rocopia, Surescripts, etc. However, many others had required several subsidiary modules to work. For example, Pearl EMR lists: MS .NET Framework 3.5 Cryptographic Service Provider; SureScripts; BCA Lab Interface; Oracle TDE.

There is nothing inherently wrong with this, but it raises three questions. Does the vendor include the price, if any, for subsidiary software? More importantly, how well integrated are these programs integrated into the main program? Does the vendor take responsibility if the subsidiary software changes making them incompatible?

He definitely asks some interesting questions. I’d say that in most cases, there will be little issues with the dependent software. Any changes by the dependent software are going to have to be dealt with or in some cases replaced by the EMR vendor. That will just be part of the EMR upgrade process that the EMR vendor does for you.

The only exception might be things like the third party ePrescribing software. Depending on how this is integrated it could be an issue. In most cases, integration with the ePrescribing software can be very much like an interface with a PMS system or even a lab interface. If you’ve had the (begin sarcasm) fun (end sarcasm) of dealing with these types of interfaces you know how it can be problematic and often a pain to manage. I believe the interface with an ePrescribing module is less problematic, but it will exhibit similar issues depending on how the EMR software works with the ePrescribing.

Personally, I don’t have much problem with these types of integrations. As long as the EMR vendor is providing all of the software for you. The reason this is important is because if you get the EMR software from one vendor and the ePrescribing software from another vendor and then tell them to work together, you’re just asking for a lot of finger pointing. However, if your EMR software chooses to integrate a third party software to flesh out the certified EMR requirements and provides you all of the software, then you’re in a much better position. As they say, then you only have one neck to ring if something goes wrong. You don’t want to have to call both vendors and have each vendor point the finger at the other. That’s a position that no one enjoys.

Many of you will probably remember my post about Jim Tate and all his EHR certification experience. As I said in that post, Jim Tate knows his stuff when it comes to the EHR certification bodies (ONC-ATCB). So, I found his advice for EHR vendors on HITECH Answers pretty interesting when it comes to selecting which ONC-ATCB an EHR company should use.

You can go read the whole article, or here’s the Cliff notes version: Responsiveness and Support of the EHR certifying body is most important.

Today, the most interesting thing I heard in the hallway of HIMSS was about ONC and the government’s perspective on the current EHR certification and meaningful use stage 1.

Someone I spoke told me that ONC is vry focused on getting all EHR software certified. It won’t quite be a basic rubber stamp, but ONC-ATCB’s are to work with the EHR vendors to help as many EHR vendors be certified as possible.

Similar to that, ONC wants doctors to easily be able to show meaningful use stage 1. Then, they’ll tighten down on future stages.

On face, this might not seem like a big deal. No doubt, ONC wants as many certified EHR vendors and doctors that are meaningful users as possible.

However, I find it interesting to think that they’re deliberately trying to get as many people as possible meaningfully using a certified EHR even if those users and EHR vendors aren’t likely to be able to comply with future more stringent requirements.

Will this mean we’ll have a whole wave of EHR users having to switch EHR software once the more stringent standards are implemented? Or will doctors just take the meaningful use stage 1 EHR incentive money and then not worry about the rest of the government handout?

I’m not sure the outcome, but it’s definitely something worth thinking about.

I’m not sure how many of you find it interest, but I know I have at least a reasonable number of EHR vendors out there that read this site. Plus, the number of available certified EHR vendors should be interesting to anyone that participates in the industry.

The EMR Daily News recently did a post breaking down the official ONC CHPL list of certified EHR vendors. Here’s my general summary of the numbers:
Total EHR Certifications: 329
Certified Ambulatory EHR: 234
Certified In Patient EHR: 95

I just checked the list myself and found 350 total EHR vendors, 250 ambulatory certified EHR, and 100 Certified In Patient EHR. Although, since those numbers are so round, I’m going to assume that EMR Daily News did a better job looking at the list. I just went off the numbers that the website provided.

Either way, 329 EHR companies is a lot of companies. Granted, that’s not 329 full comprehensive EHR vendors, but the majority of them are or will be. Is there any wonder that there’s such a thirst for tools to help people narrow down the EHR vendor selection process?

EMR Daily news also broke down which ONC-ATCB companies are certifying the 329 EHR vendors:
CCHIT: 54%
Drummond Group: 35%
InfoGard: 11%

I know that SLI is talking to a lot of EHR vendors and I imagine the Verizon associated ATCB is too. Of course, this says to me that there’s still a lot of EHR vendors that are going to be added to this list.

I talked to one industry person about the number of EHR vendors and they said they had 600 on their EHR vendor list. From the looks of this, they might not be all that far off with that number.

Drummond Group has updated their FAQ with an interesting question about how to obtain a CMS EHR certification ID and the difference between the CMS EHR certification ID and the ONC EHR Certification ID that Drummond Group issues.

Q: How do I obtain a CMS EHR Certification ID? Is it the same as my ONC EHR Certification ID I received from Drummond Group?

A: The unique ONC EHR Certification ID issued by Drummond Group is associated with the CMS EHR Certification ID but distinct from it. The ONC EHR Certification ID is one of the “inputs” into the calculation and creation of the CMS EHR Certification ID. However, it is ultimately the CMS EHR Certification ID number which EPs and hospitals will use for the incentive payments.

The ONC Certified Health Product Listing functionality was updated December 24, 2010 and it now has the addition of a shopping cart to create CMS EHR Certification ID number. Users can obtain the CMS EHR Certification ID number by following these steps:

1. Go the ONC CHPL website: http://onc-chpl.force.com/ehrcert

2. Following the instructions on the site, search for the certified EHR products. There are many ways to search, but one option is to search by the ONC EHR Certification ID assigned to the vendor.

3. When the EHR product(s) is found, select the link on its row called “Add to Cart”. There is a shopping cart icon next to it.

4. When all EHR products used by the EP or hospital have been added to the cart, select the “View Cart” link at the top right which also has a shopping cart icon next to it.

5. Now in the Certification Cart section, verify the products in the cart are correct. Then, select the “Get CMS EHR Certification ID” button in the top right corner to request a CMS EHR Certification ID. However, the button will not be activated until the items in your cart meet 100% of the required criteria. If your EHR product(s) do not meet 100% of the Meaningful Use incentives, then a CMS EHR Certification ID number can not be issued.

6. Finally, you will see the CMS EHR Certification ID. It is typically a 15 digit string made up alphanumeric characters.

Interesting that the CHPL website has been redesigned to be able to know which EHR are certified to which module and knows if you’ve reached a 100% certified set of software.

Looks like it also pays off to have a number for your EHR product name so that you’re listed first on the CHPL site.

I often get questions from readers of my sites and I often don’t know the answer. So, instead of acting like I know the answer, I like to put it out to my readers to see what they have to say about the topic. This is one of those cases. Here’s the question I got about Nephrologists and Dialysis Centers and EMR stimulus money.

I am interested in finding out how dialysis centers qualify for the EHR incentive money and best practices for Nephrologists, NPs, and/or PAs running dialysis centers for attestation.

This is an area I’m not that familiar with. So, if you know more than I (which many of you do), let us know your thoughts in the comments. I’ll update the post if needed too.

My only general thought is that it wouldn’t seem like I’ve seen an exception that would exclude nephrologists so I assume they could be considered an “eligible provider.” I also imagine that they probably have a large number of Medicare patients so that they can easily meet the Medicare reimbursement requirements and they might even meet the Medicaid requirements.

I guess the real question might be whether nephrologists and dialysis centers use a “certified EHR” or not. If not, then they’re likely up a creek. If they do, then my next question is whether or not it’s worth their time to ask their patients if their smokers (amongst other meaningful use requirements) every time they come for a visit.

Talk amongst yourselves in the comments.