As CCHIT published its comments to the ONC IFR, I took another look at the Interim Final Rules and I must admit CCHIT is making some very good points. Read the CCHIT comments here.
Here are a few other odds and ends that I believe will cause problems. I don't quite understand why definitions couldn't have been tightened down a bit more prior to publication. These are pretty elementary things.
Medications & CPOE - Tangled Up
For ambulatory providers Medications are addressed in four different criteria:
170.302(a) - Drug-drug, drug-allergy, drug-formulary checks.
170.302(c) - Maintain active medication list.
170.304(a) - Computerized provider order entry. Enable a user to electronically record, store, retrieve, and manage..... (1) Medications;(2) Laboratory;(3) Radiology/imaging; and(4) Provider referrals
170.304(b) - Electronically exchange prescription information
Theoretically, purchasing a CPOE module and one of the available ePrescribers, like Dr. First for example, should satisfy all four criteria. However, the CPOE module cannot obtain certification for 170.304(a) without managing Med lists, which the ePrescriber already does and must do. So either Dr. First starts managing Lab orders, or Lab order modules start managing prescriptions, or Dr. First and the Lab order vendor need to apply for certification together as one product.
Suggested solution: Remove Medications management from CPOE.
CPOE - No Standards
For ambulatory EHR modules CPOE is defined as follows
170.304(a) - Computerized provider order entry. Enable a user to electronically record, store, retrieve, and manage, at a minimum, the following order types:
(3) Radiology/imaging; and
(4) Provider referrals.
There is no specification of any standards to be used for such recording of orders. This will render CPOE modules, certifying under this premise, useless for electronic orders down the road. I guess buyers need to beware!
Suggested solution: Require that Lab and Radiology orders contain the HL7 required fields for each type of test. Medications, as mentioned above, should be dealt with separately.
Smoking Status - What is that all about?
170.302(f) - Smoking status. Enable a user to electronically record, modify, and retrieve the smoking status of a patient. Smoking status types must include: current smoker, former smoker, or never smoked.
Is anybody envisioning a standalone module that records and displays one item? What would a vendor of such module present for certification? A single screen with three checkboxes and an interface to send the data item somewhere, or a database with two columns (one for patient identifier and one for smoking status)?
Suggested solution: If the insurance industry is hell bent to have physicians record this cryptic and clinically lacking data point, it should be added to 170.302(e) - Record and chart vital signs. This is a temporary solution, and not a very good one, until Meaningful Use requires recording of other History items.
Regarding the EHR Module concept in general, the definition that a Module is anything that satisfies at least one criteria doesn't make sense to me. If we are going to certify Modules, and we should, they need to be defined in a more sensible manner. When I think of an EHR Module, I envision an ePrescriber, or a Registry, not a Smoking Status Recorder.