In which I have something positive to say about ONC

I spent this morning in a room full of ONC contractors and staff at HHS Headquarters in Washington DC learning about the roll-out of the ONC Standards and Interoperability Framework.  How I got here is an interesting story in and of itself, since this blog helped to contribute to being in the room.  My post of a few weeks ago apparently wound up in Doug Fridsma's inbox with a note attached about "Risk #1" related to communications.  It wasn't just that post, but also the fact that I had done some thinking about replacing HITSP before the contract ended.

It doesn't surprise me that I have readers inside ONC and the contracting organizations, but what did surprise me was the response from ONC.  Someone suggested to Doug that I and a few others like me be invited to this meeting, Doug agreed, and so I was invited (as were a few others).  I don't know what the selection process was for tihs meeting, but I did see several familiar faces this morning in DC.

Doug was clear that he wanted this information to be public and made the slides he presented at this meeting  available to me and thus to you:

Now before I comment on the slides, let me start of with Doug's introductory remarks, which were the clearest departure from the "old" ONC.  He reviewed the agenda, and then said, "and we've set up a couple of rooms for you afterwards, so that you can get with the different people you need to talk with".  Under the "old" ONC, communication between different projects (AHIC, HITSP, HISPC, CCHIT and NHIN) were all funneled up and down the ONC chain until very late in the process, resulting in a game of telephone, with the expected, but not funny result.  There was very clearly an expectation that contractors would be involved in every step of the process, even though they might be responsible for only one deliverable.

The real meat starts on Slide 4.  This slide shows the alignment of the contracts with the various aspects of the Office of Interoperability and Standards.

BREAKING NEWS:  The contract award for Use case development went to Accenture (see Slide 4 and 8).  This was finalized either late Friday or Saturday before this meeting was held, and hasn't even hit the web yet, except in a brief tweet I made from the meeting room this morning.

I spoke with Doug on the Standards Development contract before the meeting. That contract is being re-competed for a number of reasons, including too few competitive bids and a lack of responsiveness to ONC needs in the task order issued.  There also seems to be a need for more clarity around what it could do, and ONC is apparently considering opening this up under GSA which would make it more broadly accessible.  Now, the process they used for many of these existing contracts limited the responders to those with existing government contracts under an NIH process.  It is understandable that these contract holders would not necessarily have the best expertise or most experience available for healthcare standards development.

Doug has "two-sided" conversations, as I've been told.  That means that he listens as well as talks.  When he mirrored my own concerns using my words back to the room on the "Standards Contract", I actually gained some confidence that he does.

My notes indicate that ONC is in the process of rewriting that RFP, to work with the SDOs in a very focused way, NLM, HL7, IHE, et cetera.  I personally expect these "Standards Development" efforts under this contract to be rather focused, much like past contracts that ASPE, CDC, FDA and others have let for the development of specific standards activities.  Almost all of those that I'm aware of include collaboration with existing standards bodies, so while I see this still as being somewhat of a concern, I'm less worried about the government getting into the business of "hiring out" standards development.

Part of the reason for some of the  gaps in communication that I've been complaining about, is as Carol Bean explained at the meeting, that they really couldn't even talk about things while regulation is being finalized around them.  Some of the handicaps that ONC operates under have to do with laws and regulation about what a regulating body can do or say at certain periods of time.  This is also a challenge for Doug as he doesn't come into this position with decades of experience in the Federal bureaucracy.  My advice to ONC on this topic would be to get a regulator,  a marketer, and a well versed lawyer in the same room to hash out (or perhaps even, hack out), the communications strategy for ONC.  It is clearly needed, and Open Government needs to figure out how to accomplish it better.

Slide 5:
Doug talked about "government as a platform" or enabler on this slide.  The real focus here was to have these ONC contracts provide the capabilities that will enable stakeholders to do what needs to be done.  It's not about having the government in the driver's seat so much as it is to have them pumping the gas.

Slide 6 is a title, and slide 7. more of an outline, so I'll skip to slide 8.  This is the slide that Doug pitched in a major way to the HITSC two weeks ago.  You'll note again Accenture as the Use Case contract awardee.  Some notes from Doug on this slide:  While it looks like a waterfall model, it really is an iterative and agile process.  In reviewing this slide, Doug explained that we need to "Find out who is the best of breed in this area, and engage." with respect to the various activities.

BTW: I spoke to a number of people after this event with regard to a number of what I consider to be "best of breed" tools, e.g., the work that Dave Carleson and crew have done on MDHT.  You'll be pleased to hear that this sort of engagement is already happening, not just with MDHT but elsewhere, and further connections also need to (and will) be made.

Slide 9 is the mandatory quote that nobody can disagree with (even me).

Slide 10 starts to talk about the holistic vision of Standards Development that Doug has under this framework.  One of my complaints about the entire AHIC, HITSP, HISPC, CCHIT, NHIN communications debacle is that if a medical device manufacturer imposed the same communications (or lack thereof) regiment on its development processes, the FDA would shut them down.  It's clear that while there are 11 different contracts, they are all part of one process.  In fact, at one point, Doug says "The culture here is that I don't want to know who you are with" .. in fact, he goes on to "I mess up because I don't know who is working for who" ... "because it is all the same thing to me."  That, frankly is a very refreshing attitude.  I wear way to many hats but I can make it work for the very same reason.

Another point that Doug makes is that we need to get out of "Word" and PDF mode, and into the 21st century.  While these are my words, I believe he would very much agree with the sentiment.  He repeated several times the need for COMPUTABILITY and communication of information contained within the standards (Rich Kernan has a good story on that I'll share in a bit).  This is, from my perspective, going to be a HUGE challenge.  The process by which SDOs create there publications is the very foundation of those organizations.  Bob Yencha had a good approach he described:  Tell us your requirements, and we can tell you what tools we (the contractors) can provide to help you get the materials into a computable form.  Now Bob (and I) are structured documents (SGML) geeks with quite a bit of history before either of us ever got into healthcare.  We realize the challenges inherent in this task.  But at the same time, I would also welcome better tools.  The technology that we need is pretty widely available.  Solutions like DITA and DOCBOOK would ease this work greatly.  The BIGGEST challenge will be to get SDO engagement to TAKE ADVANTAGE of resources with $ who are willing to help.  That offer is going to annoy a number of different constituencies in the various SDO organizations,. but hopefully, wiser heads will prevail.

The point Doug makes: We need computable specifications, and artifacts that can help generate data, information, code and specifications.  It's more scalable.  We are presently in an artisan industry, how can we make this available to non-artisans?

Slide 11: This is mostly a reiteration of what has gone on before, but here Doug makes the point that what effectively has been awarded to the contractors is that each has been awarded "Ownership" of a component of the S&I framework, and is responsible for PARTICIPATION in the whole, including at control points, to make it work.  That means that the Testing contractor can look at the Use Case and say "Hey, that [requirement] is not testable".  Now that is, to me, signs that a real S&I Lifecycle is being developed.

Slides 12-15 give a bit more detail on each of the contracts.  On the Harmonization contract Doug makes the point that "Further up the food chain that harmonization occurs, the better off we are." because we want to support the "Reuse of requirements, as well as specification and implementation."

A point I'll make to Doug with respect to Use Cases, is that Use cases IDENTIFY a problem, they don't necessarily solve it.  The use of the S&I framework may do so, but we need to be careful to ensure that we have worthy Use cases to address.  We don't need more H1N1, Katrina or Anthrax use cases that are supposed to be magic bullets for major issues, but with no powder in the charge.  If you have a problem, it should have a measurable cost, and a reasonable belief that with investment, you can recoup more savings that the resources invested in solving the problem.  And when the people, volunteers or otherwise, tell you that it cannot be done "at this time" and "on this schedule", you need to believe them.  This work is like developing a product.  There is a triangle of resources, time and quality, and you may control two sides of it, but the third is simply a product of the other two parameters.  All too often, we need it NOW, with these resources, and quality suffers.  This, I believe, is why HITSP is a dirty word in some ONC circles, because the only leg of the triangle it was left to adjust to meet ONC demands was quality.

The best development efforts are set a high bar on quality (especially in healthcare), and adjust time or resources accordingly.  Some of these efforts will be open ended.  Great, let the process be iterative, and be able to accept at deadline, the number of iterations that can be performed in that time frame.  And you must also measure these processes, not by whether the work was completed, but whether the desired end result was achieved.  If NHIN Direct is done, but nobody ever takes it up, is it successful?

Slide 16:  This shows a swim-lane view of the S&I Lifecycle, along with the various checkpoints or control points along the way.

Slide 18 through 20 are NIEM material, which I'll save for a subsquent more detailed post.  I will repeat  on one quote  from Doug on NIEM "We are not really using the NIEM Core, the goal is to use those processes to ensure harmonization."

The NIEM process, while new to some of us in healthcare, is not foreign.  If you look at HITSP TN903 Data Architecture, and HITSP C154 Data Elements, you'll see a really good foundation for the NIEM Healthcare Core.  We need to figure out how to carry on and reuse that work.

I will also reflect in short form, one problem with the NIEM.  Green Fields and Cow Pastures are not the same thing, and current NIEM experience is in green fields.  NIEM will need extenstion not only to to cover new concepts (services and behavior), but also to account for legacy.

Slide 22: I'll sum up my review of Doug's presentation on this slide.  It shows the expected effort expended by  the different contract activities.  What you will see in this slide is that there needs to be engagement by each contractor in every step of the process.  The point is that each must understand what went on before and the requirements of what comes after in order to complete their task.  This diagram looks very much like the effort expended on a software development project, following a real lifecycle model.

I applaud Doug and his team, and the contractors for what they have accomplished so far.  It is still very early days, and there are still many ways this octopus can get itself tied into knots, but it has gotten off to a great start.  There's a lot more that needs to be done, and getting industry and SDO engagement into this process will be needed.  There won't I expect, be any big calls for participation in the early days, just a few people asked to contribute.  I am hoping that later there will be more active engagement, and even an open call for participation.

My own comments back to Doug and team at the end of the meeting amounted to a charge to engage the industry, the SDOs and the PEOs in this effort.  We are willing to help in this process, you need only to call on us and we will respond.  I am remarkably encouraged by what I see.