A Theory of Everything

Within HL7 we have produced or are producing numerous specifications dealing with Quality Improvement:

• VMR for CDS Logical Model
• VMR for CDS Templates
• VMR for CDS XML Implementation Guide
• HED Knowledge Artifact Implementation Guide
• Decision Support Service Implementation Guide
• HQMF Specification
• HQMF QDM-Based Implementation Guide
• CCDA Specification
• QRDA Specification
• Arden Syntax
• GELLO
• InfoButton
• QDM

Each of these addresses a variety of things, some things in the same way, and others in different ways, sometimes for really good reasons, and at others for reasons we perhaps don't yet understand.

We didn't know (and still don't yet in full detail, but we've at least gathered the data), where these specifications overlapped, and what was missing.  Today, Clinical Quality Improvement, Clinical Decision Support, Structured Documents and Templates members met to talk about what is our Theory of Everything, or more specifically, our Quality Improvement Architecture.  I presented the following slide deck to help us figure this out (the magic is on slide 5).

We took the list of specifications above, and parceled out the pieces into slide 5, and put it on a white board [this picture is after we cleaned it up].

As you can see, there is plenty of overlap.  We also noted quite a bit of gap, because we are missing (actually, it exists, but it's lore rather than publication) a lot of specifications where we agree (at the conceptual level). 

In fact, we agreed that at the conceptual level, we are almost in complete agreement.  The one place where we have some variation is between QDM and HL7 Clinical Statements, where there are some disconnects.  There is also a great deal of consistency at the platform independent information model level.

One of the realizations that I came away with was that in the RIM, the rules for interpretations for how to deal with certain structures in the RIM are behavioral/interpretation models ion the computation viewpoint space, rather than logical models in the information viewpoint (e.g., joinCondition has implied behaviors).

There's plenty of work to turn this diagram into an Architecture, and that's what I'll be spending the rest of my week on (when I'm not doing other things).

I was extremely pleased with how this workout went.  We had a room filled to the brim (nearly 50 people) who were writing on post-its and pasting them up on this diagram.  We came to an agreement on where we agree and disagree, and we have some plans for how to move forward.  And I totally was making this up as the week was proceeding, but it worked really well.

We still disagree on some things, but now at least, we have a much better idea about where.  There was a point in the meeting where someone was talking about one thing, and I disagreed, and then we clarified what boxes we were both talking about, and were instantly back in agreement.