Implementation Workgroup

I missed the HIT Standards Implementation Workgroup call, but I took a look at their slides after hearing some feedback on the call. The slides appear below.


The real meat starts at slide 7.

1. Keep it simple: Think big but start small, and make standards be as minimal as required to support a necessary policy objective.
My comments:  But don't assume you get to start from scratch either.  The charge of the Standards FACA is mostly to identify and not to "Create".

2. Don't let the perfect be the enemy of good enough. 
My comments:  In general I agree, but we also have a responsibility to ensure the safety of patients.

3. Keep the implementation cost as low as possible!
My comments:  YES!

4. Design for the little guy.
My comments:  YES!

5. Do not try to create a one size fits all standard.
My comments:  DO NOT ASSUME that you need to CREATE a standard.

Slide  8
6. Separate Content and transmission standards.
My Comments:  YES!

7.  Create publicly available vocabularies and code sets.
My comments:  YES! [with a little nit about terms, because I think they mean to say vocabularies and VALUE sets].

8.  Leverage the web for transport.
My comments:  YES, and thats obvious, but let's move on, there's another agenda here that I'll get to in a minute.

9.  Position Quality Measures so that they motivate standards adoption.
My comments:  Quality is the goal, and it starts with a good process up front.  I've been down this path before.  To engineer quality in means that measurement must be built into the process, and that means we need to develop good standards for describing quality healthcare guidelines with measurment built in. The current thinking appears to be that you can measure quality of a process after the fact and get results.  That may be true, but the best results come with quality baked in, so that thinking needs to change.

If you can describe a quality process and the data needed to execute it (not the logic, JUST the data), you can automate not just the computation of measures, but the capture of the data, AND the creation of interfaces to exchange that data. The logic is important, but LOGIC is SOFTWARE, not data.

10.  Support implementators
My comments:  Absolutely.  But that will require some investments in IP from SDO and PEO organizations so that you can put all the pieces together, or development of completely new content based on that, which will have to track work products from differnt organizations.  This is an obvious item, but it will take time.  If all SDOs agreed to one STRUCTURED documentation format to use (and don't JUST say XML, it needs to be more than just XML), it would be a lot easier, but THAT will take a long time.  Don't think this will be cheap either.

Slide 9
OK, so here is where John gets to guide the agenda, and it is a bit slanted.  The REST/SOAP debate is old news, and we know there are some issues that need to be worked out.

Slide 10
But here is where I get just a bit hacked off.  How about fairly representing the position of all sides of a discussion instead of just the side that you favor?  I should be able to expect better than this.  Sean, Adam, Wes and John have all clearly come out complaining about SOAP, but at the same time, when the standards were developed, SOAP was the thing to do because of weaknesses in HTTP that still haven't been addressed.  Don't get me wrong, I like REST.  REST is the complete foundation of this blog, so I get it.  But I'd like to see SOME signs that people are also listening to BOTH sides of a conversation, not just their own.

This is where I stop my commentary on the slides and move on to other topics.

These workgroups need to get CLOSER to the implementer, the people designing and implementing code. When is the last time any of them have written code?  How far are they away from the people who are actually writing code?  It's good to be an advocate for people in the trenches, but it you really want to make their jobs easier, start having them tell YOU what they want, or better yet, get someone who's written production code recently to be part of the group.