Showing posts with label Certification. Show all posts
Showing posts with label Certification. Show all posts

Tuesday, January 8, 2019

A Bet on Standards for the next round of Certification

It's been pretty clear that ONC is putting its money behind FHIR, and we know that 21st Centrury Cures will require new certification requirements, and are pretty much certain that (based on the last round of regulation), that a standard for APIs is going to be specified.

I see two choices: FHIR DSTU2 with Argonaut, or FHIR R4 with US Core, either of these with SMART on FHIR.  Having read through the new US Core over the last week (for the HL7 ballot cycle), it's pretty clear it essentially replaces most of what was found in the original Argonaut specifications.

So, I'm placing my bets on FHIR R4 with US Core and SMART on FHIR.

What I'm NOT placing bets on is when the regulation is actually going to show up.  HHS has some appropriations already, and ONC is still moving some things forward, but OMB is on furlough and the Federal Register site is non-operational, and NIST has also shut down (not that they are essential for publishing the rule, only afterwards in implementing it).

Given the current situation, I'd rather the rule had showed up on December 24th.

   Keith



Wednesday, March 16, 2016

ONC's statement of Purpose doesn't justify Certification Oversight Expansion

I just started reading the Expansion Rule and am finding myself both confused and alarmed.  At first blush, it all sounds good, but the ramifications are a bit, well, staggering.

First of all, I look at the justification for the expansion, which looks OK in part.  The bits about having oversight over the testing labs looks good, as does the fact that ONC will have a more direct role in addressing testing issues, and even the fact that they can do their own monitoring all seems OK.  But then I get to some of the concerning bits.

First of all, they cite patient safety as a possible trigger.  Now, ONC-ACB's are already certifying systems according to safety enhanced designed requirements, and I can see where if something came up with regard to patient safety where that was an issue, it becomes something that needs to be looked at, and frankly, as a patient, I'm very happy that ONC may decide to do its own looking.

But then there's this nebulous area where Certified components interacting with non-certified components come into play.  And that's where the challenge starts to show up.  This starts to give ONC oversight of EHR system components that aren't involved with the certification program, under some very loose reading of the statute as far as I can tell.

While the "purpose" for which ONC was created includes all the things they cite in the regulation, HITECH did NOT give ONC authority over all those topics described in the "Purpose".  Instead, it gave them a more narrow set of requirements focused (mostly) on creating a certification program, selecting standards, and coordinating federal efforts on HIT strategy and policy.

I don't see how using the purpose statements as a justification for expansion into EHR surveillance beyond the certification program comes into play, and given that loose reading ONC could also justify taking on a large number of other roles which overlap with other agencies responsibilities:

Under similar loose readings, one could suggest that:

  • Improving quality could authorize ONC to take on AHRQ responsibilities.
  • Reducing costs could authorize ONC to take on CMS responsibilities.
  • Just as reducing errors as presently used as a justification seems like it could authorize ONC to take on some of FDA's responsibilities.

This is a bad idea on several fronts.

If there's a patient safety issue with certified product, certainly ONC should address it.  Addressing product issues like that is already covered under the QMS (quality management system) requirements of meaningful use, and a failure of a vendor to adequately provide or execute on QMS for certified product would certainly apply in those cases.

But when we start talking about interactions with non-certified product, I have at least three concerns:

  1. Overlap with FDA requirements for those components that are classified under medical device regulations.
  2. Confusion about responsibilities when certified components and non-certified components are described as a single unit.
  3. Confusion about vendor responsibilities when the challenge may be introduced by product interactions between multiple vendors, some of which may be certified.
  4. Issues where the root cause could be "modification" in the field by non-vendor personnel.  

While ONC is rightly concerned that there need to be ways for some federal agency to act when a patient safety issue is discovered and not being appropriately addressed, neither its ACB's, nor frankly ONC, has the necessary experience to do so, and as I read the legislation, nor do they have the necessary authorization.

Attacking patient safety as an EHR Certification problem is not the right way to handle this.  Safety is built in, not bolted on.  Don't try to bolt it on to the certification process as an afterthought either.  Put some real thought into how to handle the safety issue, and don't confuse the two.  Talk to your colleagues over at FDA, they have a few decades of experience with addressing those sorts of challenges.

I've still got a lot more reading to do, this is just my first reaction to the first half of what I've read thus far.

   Keith

P.S. As a reminder, these are my own personal views, not those of my employer or anyone else.

Thursday, May 28, 2015

Tell ONC to use CCDA 2.1 for Stage3 / 2015 Certification for MeaningfulUse !

Comments close shortly on the ONC Certification Proposed Rule.  If you've already submitted yours, I'd still like you to tell ONC three more things:

  1. HL7 is currently in the process of approving a project to update C-CDA 2.0 to 2.1 ensuring backwards compatibility with Version 1.1 named in previous Certification and Standards Rules.  This will avoid the unnecessary and potential dangerous situation of having to record two documents with dissimilar information about the same patient and encounter to support asynchronous bilateral cutover.  The project team hopes to complete this effort by July or August at the latest.
  2. The changes would enable a C-CDA compliant 1.1 system to read and understand as much of a C-CDA 2.1 instance as is technically feasible.
  3. We think this is a good idea, and would prefer it over other ONC suggested solutions (i.e., using 2.0 and sending two versions to support compatibility).
Click here to comment on the rule.  If you want to copy and paste my words above into your comment, feel free to do so!

     Keith

P.S. SDWG approved the PSS today!  On to the next stages.


Friday, May 8, 2015

Haven't I seen this pattern somewhere else?

With thanks to Randal Monroe, creator of XKCD as always.