Pages

Tuesday, May 17, 2011

Fork It

No, I'm not swearing. At least not now.

More than a decade ago I worked for a company by the name of INSO (it was one of many names it had, it was also known as the Software Division at Houghton Mifflin, InfoSoft, and subsequently eBusiness Technologies).  We had a project to complete - a way to enhance search engines with linguistic analysis, and a MAJOR customer wanted it in time for their next BIG product release.  The deadlines were impossible.  We had cut every possible thing we could and we still couldn't make the deadlines work.  There was no way adding more staff would help (we had 9 months to make this baby walk, and hiring two or three more mothers to give it birth earlier wouldn't help).  We had a "Come to Jesus" meeting.  You know.  Where everyone involved sat there with all of senior management hovering while we tried to work out a solution.  We sat in that room for the better part of a day before someone figured out how to recast the project so that it would fit in the time alloted, and the rest of us joined in.  That project succeeded phenomenally.  In the first year we sold it to 12 of the top 15 search engine vendors.  A short number of years later that market consolidated into three vendors and linguistics was no longer a decent market, and that led to a long series of events that let me into Healthcare IT a decade later.  Oh how I  wish the solution we used then would work now, but it won't.  What I remember most though was how the pressure put on the team produced diamonds, rather than cracked coal dust.

So, let's move forward 15 years.  HL7 and IHE are now in a similar situation with the CDA Consolidation project.  The MAJOR customer is ONC, and their next big release is Meaningful Use Stage 2.  The deliverable is an implementation guide that can be shown to the HIT Standards Committee for consideration for Stage 2. They need it by June or July.

While the solution that the team I worked with used more than a decade ago won't work, there are still a number of tools in my toolbox that I can pull out.  The first one is an eating implement, and thus the title of this post.

We have a WIP (Work in Progress), called the CDA Consolidation Guide (or CCG for short -- just what we needed, another confusing CC acronym.  I hereby claim CC[A-CEFH-QS-Z] as acronyms that nobody else can use).  It's too big to finish in time.  We have 60 days of elapsed time to work with.  We need something that can get done in less than that.  With more than 700 comments, the current work will still be in reconciliation for the next 60 days, especially at the rate we are proceeding with now.  OK, so we take that WIP, and we create a fork.  There are now two projects.  MU2 and CCG.  MU2 is what we are going to deliver to ONC in 60 days.  CCG is something that we give the time it needs.  MU2 is a subset of CCG, so any changes in CCG that are related to MU2 need to be made on the MU2 branch.  Changes to CCG get made on the main line.  We merge back the MU2 stuff when it is ready.

The next tool is a rather brutal one.  I think an acetylene torch will do nicely.  We cut everything from MU2 that isn't absolutely essential.  To do that, we need to talk directly to our major customer and find out what their showstoppers are.  Anything that is a showstopper we keep, but everything else we cut out.  That's going to be some brutal cutting.

Because these items were in MU 1, they need to stay in this guide:
  • Problems
  • Medications
  • Allergies
  • Results
  • Procedures

In addition, there is some work on the CDA header (the consolidated header) that we need to incorporate. There are a few other possible areas of consideration. For that, I think we need to talk to our customer and get their list. Not the wish list, but the short list of must haves moving us beyond MU1. MU1 + the short list = MU2 (what is needed for Meaningful Use Stage 2). There are a number of things that might be nice to have, but lets put them on a longer track, and do them right, rather than muddle things up.

Now we need an adapter to go from 1/2" to 1/4" sockets. There are incompatibilities between what I call MU1 (the C32 requirements in Meaningful Use stage 1), and MU1a, which are the things in MU1 that MUST be corrected. MU1a is a subset of what is needed for MU2.

To bridge the gap between MU1 and MU1a we need to identify what from CCG supports what was in MU1, and figure out how to bridge the incompatibilities. That may mean creating a new template layer that adds back some constraints to ensure compatibility. The function of that layer is to create a way that we can equate C83 templates to MU2 templates where possible. The point here is to ensure that there is an adequate transition path between the existing work and the new MU2 work.

The final tool is a coffee pot. Getting this done is going to require quite a bit of effort, including a lot of late evenings (last night til 3:30 am writing the first three revisions of thi post being the first of many). I'm willing to engage, because the alternatives (and there are more than one) for not doing it are rather unpleasant to say the least.

2 comments:

  1. Isn't it funny how National Implementation Plans (or, NIPs, you can have that one) always seem to boil down to how quickly can we push something out in a short amount of time, with just a few people working their tails off. Just sayin'...

    ReplyDelete
  2. Thank you Keith. I think this is a sensible approach. Prioritization of MU1, MU1a, and MU2, as you said, and a phased path to the end. I hope the fork won't be accompanied by "knives" (as in daggers; surgical scalpels to carve out scope are OK)! There is a dependency as to what the contents of MU2 will be, though, but at least the HIT Policy Committee MU workgroup proposed what should be in a "clinical summary" or "patient download" so hopefully that will clarify MU2 scope. But since they deferred to the HIT SC which data must be structured (vs human-readable), I suggest that only data that can be reasonably harmonized in the CCG should be proposed as structured, any the rest be acceptable as human-readable text. Just including more human-readable content and sharing it (liquidity) is good progress, without forcing everything to be structured too quickly. I agree that adding more "mothers" can't help birth this baby.
    David

    ReplyDelete