HL7 Officer Elections are now open, I'm running for Chair, please VOTE (for me).

The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata

Tuesday, September 21, 2010

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.


11 comments:

  1. So - what's in a Cow Pasture is "legacy" ? ...

    ReplyDelete
  2. Re: "computable specifications"

    Actually, it would be a great idea if this process would produce tools usable by all SDOs for production of 21st century standards artifacts, and resources to transition the legacy artifacts into the new format.

    Example 1 - How about a standard tool for submitting and managing problem reports / change requests for all standards. (Just within HL7, there are different processes for v2, v3, CDA, CCOW, EHR-FM, etc.)

    Example 2 - DICOM has been struggling for over five years to transition its standards from Word/PDF to XML, but it has not had the resources to carry it through to completion. Perhaps the Standards Development contract could help SDOs step up to the computable specifications bar.

    ReplyDelete
  3. Keith, thanks for the very helpful update. I'm glad you were invited. Thinking back to some of the many questions you asked about this several blog posts ago, I wonder whether one of your (and my) major concerns is being addressed, i.e., how do the experts who have spent years on this get engaged? You wrote: "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." Will the contractors "do" the work themselves, or will they guide and facilitate and open process? For example, Deloitte could just "decide" how to select and harmonize standards, but I doubt that would be the best way to do the job (though unilateral decisions can be made quickly). I don't expect that the S&I framework means that unilateral decisions will be made, but am just posing that extreme example to frame the question of how the contractors will engage the public.

    ReplyDelete
  4. One important distinction I would make re: contractors and their work in standards harmonization:

    If you look back at the HITSP process, there were a core set of volunteers, people like Keith, John Moerhke, Robin Raiford, and Charles Parisot (a few among many names) who did a lot of work in harmonizing standards and in assisting in writing the actual specifications. However, there was also a core group of contractors behind the scenes who did a lot of the actual technical writing and modeling for the HITSP work that you see today. In that process, contractors did not make "arbitrary" decisions on how to build specifications but were guided by volunteers and SDO/health IT experts.

    I expect that the process will be pretty much the same; contractors write, experts guide. I dont expect to see contractors go off on their own to simply make selections on health IT standards.

    How to identify the actual experts needed for a specification and what the engagement model is going to be to get them into place is still up in the air. That engagement model will go a long way to determining how the public actually would be involved in standards harmonization work.

    ReplyDelete
  5. Thanks for this refreshing post Keith. I too am encouraged by most of the message...that is till you got to the NIEM elements. I like Doug's comment that ONC is interested in the NIEM process and not the core. This is the right approach in my mind. I think anyone who has looked carefully at the core elements will realize pretty quickly that it suffers from the same problems that other implementers of ISO 11179 have had, namely early binding of context that leads to an ever exploding group of elements that limits reuse. We have certainly learned from the past 6-7 years of experience at the NCI and have now taken a hard look at what we have and are plotting a new course. I hate to see ONC waste time, energy and precious resources digging that same hole.
    I am glad you were invited to participate. I can think of no one better to speak wisely to the standards issues.
    I also hope that ONC is thinking not only about agile development, but also about agile governance and agile software. Agile development does not necessarily lead to agile software and some of the 21st century tools, W3C standards and loosely coupled and abstracted services and knowledge constructs need to be a big part of the planning to make these standards work.

    Keep up the good work. See you in Cambridge.

    ReplyDelete
  6. Agile is certainly the word of the day. I just hope that it doesn't mean what I most often interpret as "We don't know what we are doing so we will just make it up as we go along."

    There are certain aspects of agile that might look like that to a non-practitioner, but that isn't the essence.

    ReplyDelete
  7. Eric, thanks for the response. I know the volunteers (like me) appreciated the "behind the scenes" work of the contractors. Your answer is what I hope the official response will be, and I look forward to hearing what the "engagement model" is. (We former HITSP volunteers have all this free time on our hands and are sitting around waiting for something to do until we "get engaged" again -- just kidding!)

    ReplyDelete
  8. ASC X12 has been using DocBook for about 5 years for their HIPAA mandated content. The XML is transformed to HTML and PDF.

    ReplyDelete
  9. My apologies if I missed it but was there any mention of an update to the Syndromic Surveillance referencing the wrong mapping guide? It was mentioned in the August 30th HIT Standards Committee meeting but I have yet to find the resolution.

    ReplyDelete
  10. Anonymous: There was confirmation of that issue addressed in a recent FAQ. I expect to make another post this week on the topic once I hear back from a few people.

    Steve: That's good news. DICOM also uses DOCBOOK, and I think we can get IHE shifted over because there are DOCBOOK plugins for Word. It should be possible to do a transform from HL7 PUBDB XML format to DOCBOOK as well, so that at least there is a common input form. I'm hoping that we could eventually shift from the PUBDB format in HL7 to DOCBOOK, and the MDHT tools also show some promise in this area.

    ReplyDelete
  11. Disappointing to see so many of the critical elements on slide 7 listed as recommended rather than required. If those aren't done and done well, the required elements won't be any good.

    ReplyDelete