Is ONCHITT about to ‘Chase the Clouds Away’?

My sincere apologies to Chuck Mangione. For our younger readers
Chuck is a great flueugel horn jazz musician from the 70’s and his
signature song was ‘Chase the Clouds Away’. Now back to ONCHIT.

Cloud computing is the latest systems deployment panacea. In the
recent past it was referred to as SaaS (Software as a Service) and
before that remote hosting. The word ‘cloud’ clearly has a better visual
impact. Cloud computing runs all your data and applications at a remote
facility giving the user many advantages. Some benefits are; built in
redundancy, reduced capital investment, no effort backups, better
integration with many other web services, and faster and simpler
delivery of updates and fixes.

One of the core elements of the ONCHIT certification process and the
Meaningful Use attestation requirements is that a provider must run
certified software, and the certification must tie back to a vendor’s
specific version and build. Directives from two of the current ATCBs
state:

    CCHIT: If you modify or update your CCHIT Certified product in a manner that carries
    a significant risk of affecting compliance, you must follow this procedure. Before
    marketing the modified or updated product as CCHIT Certified, you must apply for
    re-testing of the product to verify continued compliance with all published criteria
    and Test Scripts.

    Drummond: If changes are made to the Drummond Certified EHR product, you must
    submit to Drummond Group an attestation indicating the changes that were made,
    the reasons for those changes, and a statement from your development team as to
    whether these changes do or do not affect your previous certification and other
    such information and supporting documentation that would be necessary to properly
    assess the potential effects the new version would have on previously certified
    capabilities.

If you sell and install a certified full EHR, or EHR module, you must
notify the ATCB with each new version/build so that your previous
certification gets inherited to your new update /release, preferably
before you send it out to your client base.






Turnkey system vendors (they fly above the Cloud?) would send out
two or three updates during the year, one perhaps being a major
release. If there was an emergency fix needed for a specific client they
might send that out separately. Clearly the update notice to the ATCB
should happen before you would send the fix out, but in an emergency
situation if the impact was on only one or a few clients you could send it
out first and notify /attest later.  

The same would be true for any special enhancements. Say a new
customer required a specific enhancement as part of a new install
contract. For the time your client is running the enhanced software that
version/build would not be deemed certified. This means they could not
use your package to attest to MU. But it’s only one client and if you are
a best of breed or niche vendor it may not matter to that client since
they might be able to cover the MU criteria with other vendor certified
products. A good example is with demographic criteria, this requirement
could be covered by several EHR modules. Lastly, and most important,
the assumption is that your updates/fixes do not impact any certification
criteria. At this time how ‘no significant impact’ is defined and
determined is left to our imagination, but starting next year it will be a
question that must be tackled by the ONCHIT AA surveillance auditors.  

Meanwhile back in the Cloud it gets little more complicated. As noted
before one of the real advantages of the SaaS approach is the user
never has to load updates, they are handled centrally, one load and all
clients are running the new code. So, back to our example where a new
client contracts for a special enhancement, or a fix is needed, you code
them, load them and go. Everybody has access to the new
enhancement; everybody is now running a non-certified system. Ouch!

The simple solution of course is to make your new customer wait for a
full version release, or in the case of a fix, require a work around until
you get re-certified. Either way, ONCHIT has succeeded in turning the
clock back to those Neanderthal days of legacy and turnkey system
releases.      






Cloud vendors who are ONCHIT certified will really need to rethink that
load and go approach.

This article was first published on HISTalk.com on 9/20/2011

9/09/2011
All rights reserved
Frank Poggio
The Kelzon Group