Rethinking Certification

Over the weekend, I finished editing my new book - "Geekdoctor: Life as a CIO" which will be published this Winter.     I was re-reading historical blog posts and reflected on "What Makes Me Happy"

In that post I suggested things to avoid in order to retain your optimism:

"1.  Unplanned work that increases scope without a change in resources or timeline

2.  Needless administrative or bureaucratic processes imposed by those who are not actually doing the work"

As BIDMC prepares for certification of its inpatient and ambulatory applications, I've had the opportunity to review every test script and assess the burden/benefit of certification.    Although attestation criteria are great, the approach to certification could benefit from a reboot to remove scope, reduce resources required for certification, and substantially simplify the process.

Here are a few recommendations:

*Scripts need less optionality -  Although we want to create a smooth trajectory from one stage of meaningful use to another by offering historical, current, and future focused options such as CCR, CCD, and CCDA summaries for attestation, such optionality forces certification to include full testing of all of them. It's a bit like saying that an IT department is forced to support iPhones, Android devices, Windows phones and Blackberries just because someone might buy one.   My organization has put limits on what can actually be used, so I really do not want demonstrate functionality for certification that no clinician will ever need.

*Scripts need more modularity - The Massachusetts State HIE supports the Direct specification for SMTP/SMIME and XDR, enabling any provider to connect to the State HIE via an EHR or HISP.   We want to achieve modular certification of the state HIE so that any clinician can attest to Stage 2 using the State HIE to support transmission of transfer of care and encounter summaries.    However, the script for certification requires a demonstration of CCDA generation and transmission, ensuring no HIE can achieve certification since HIEs do not produce CCDAs, EHRs do.    Our only alternative is to build a mini-EHR so that the HIE can demonstrate all the functions and all the options for every section of the script.    That creates unnecessary burden and stifles innovation.

*Scripts should be less prescriptive - Patient and family engagement is one of my major focuses.  The View/Download/Transmit script requires that very significant new functionality be added to EHRs and describes precisely how it must work.   I wonder if requiring some basic building blocks would be better, then let the market innovate as patients and providers demand new products.

*Certification should not include more functionality than is needed for attestation - there is no attestation requirement for problem list reconciliation or allergy list reconciliation but there is a certification criteria requiring demonstration of these functions using a fully electronic approach.    The standards for allergy clinical models are still in progress, so we're requiring functionality in products that is not required for attestation and lack mature standards.

*The standards committee suggested that some standards not be part of meaningful use stage 2 because of lack of maturity - QRDA for quality reporting, LDAP for certificate discovery, and CDA for cancer registry reporting.    Just as with PQRS XML in stage 1, developers will have to incorporate these into certification, but they are unlikely to be used because there is no ecosystem to support them.

*User Centered design is motivated by the desire to have safe, functional EHRs.   The certification script requires that each developer produce 8 documents with 11 sections describing focus groups with users.   At BIDMC clinicians design software for clinicians via an agile, continuous improvement process.   It's not clear how creating these 8 documents adds value to that process.    Maybe self-developed applications should have a different process than vendor applications?

What is the goal of certification?  I would argue that we want secure interoperability between EHRs.

Maybe the certification process should focus on the capacity of an EHR to follow Postel's principle  "be conservative in what you do, be liberal in what you accept from others"

Certifying organizations would not be prescriptive about user interfaces, workflow, or exhaustively test every variation of every option.   Instead, they would certify that an EHR can securely send a precisely formatted clinical summary and securely receive a compliant but less than perfect clinical summary.

That worked for email, browsers, and the foundation of the internet, so why not EHRs?

ONC has a done a great job with very limited time and resources.   These observations are meant as planning ideas for the future as we refine regulations based on the experience of real world implementation.