Not Fully Baked

My daughters like Pineapple Upside-Down Cake, especially for breakfast.  The first time my wife made this, she made it up because she didn't have all the ingredients called for in her cookbook to make it from scratch.  She made it using yellow-cake mix, fresh pineapple, brown sugar, and maraschino cherries and a square cake pan.  It took about two hours to finish, instead of the 45 minutes that just mixing and baking the yellow cake would have. We discovered that it wasn't done when we went to cut and serve the cake and discovered that the inside was quite runny.  Time was short, so we decided to do something else for breakfast.  It still had promise, so we put the cake back in the oven instead of throwing it out.  We wound up having it with lunch.  It was yummy.

We aren't sure why it needed 1.5 hours in the oven, but there was a pretty good test we could use for done-ness.  If the toothpick came out clean, it was done.  The next time my wife made it, we planned for 1.5 hours of baking time, and that's about what it took.  Our experience in doing it once before was used to estimate how much time it would take to do it again.

We need new standards.  That is a key message behind the ONC Standards and Interoperability Framework initiatives.  We need mature standards.  That is a key message from Doug Fridsma to the HIT Standards FACA found in John Halamka's blog post of yesterday.  I'm reminded of a cartoon that John Moehrke tweeted yesterday where two parts of an organization are not in sync.

The Direct Project was planned to take six months and instead took nearly a year.  It's maturing quite rapidly compared to other efforts, but still, maturity takes time.  That's an obvious syllogism that seems to have been lost somewhat in the aggressive development activities going on in the Standards and Interoperability Framework.  Project planning 101:  If it's something new that's never been done before, it needs even more time than you probably think.

The CDA Consolidation project got 3 months to complete development of model driven tools and to use them to produce an implementation guide.  The project completed the required document on time, but as I dig into the results, it's still quite runny inside.  If this was a green field, the document would be great.  But it isn't and the document doesn't outline what is different from the C32 Version 2.5 and C83 Version 2.0.  So until I analyze those changes, I won't know what must change in an implementation to know what can be reused.  That analysis of the new requirements for an implementation is a struggle for me, and if I'm having problems with it, I'm certain that others are either equally struggling or even just plain stymied.  If they treat this guide as a new set of requirements, it's simply back to the drawing board and time to start over.  It's only when we can reuse what we did before that it becomes better.  The current specification also did not meet many the requirements that the Documentation Workgroup outlined at the start.  Nor, in my opinion, will it meet the success metrics outlined on the project page as it stands today.  The model data isn't delivered, nor are schematrons, UML models, nor tooling to support import, creation and validation.

As critical as I am, the CDA Consolidation project still has great promise.  I think we are going to need to put it back into the oven before it will be ready to serve.  It may or may not be ready in time for stage 2, but if we wait, it should still be yummy.