Thoughts after a Standards Meeting

It's not a Healthcare standards meeting unless sushi has been eaten.  Tonight several (6) of us went to my favorite DC Sushi Restaurant: Sushi Taro.  We all ordered the Sushi Tasting, and it is definitely an experience to be savored.  We spent nearly three hours on these 11 courses.  Dinner tonight was on my own dime because there is no way this would fly on my T&E budget, but it was worth every penny.

The SI framework meeting that I'm attending has been equally valuable on many different fronts.  Being present face to face is the first opportunity many of us have had to meet new faces.  It's also a good opportunity to meet many old friends from HITSP, and continue ongoing relationships in HL7 and IHE.

What's up at SI Framework?  I'm pretty much focused on the Transfers of Care work, so I don't have much to say about the LRI work.  But here are some high points:

Clinical Information Modeling:  This workgroup is closing in on content needed for 4 different transfers of care use cases (Discharge, referral to consult, consult report and patient discharge instructions).  There are three tiers of information.  In Tier A is the data that is needed for every transfer:  Active Problems, Meds, Allergies, et cetera.  In Tier B is the stuff that should be available to be sent because it may be pertinent and relevant for a transfer.  I'm not sure about Tier C, but I think it falls into the category of nice to have but not necessary.  So, we should soon have the CIMs.  What's a CIM?  Well, these are ONC SI Framework CIMs not HL7 constrained infomation models (isn't it lovely that we can reuse the same acronym for a similar thing).  And not to be confused with Intermountain's Clinical Element Models (that is clearly a CEM).  I'm not sure why there's all this reinvention, but because we don't have a metamodel for CIMs yet (I hope to be working on that with the MDHT team), it's something that can be fixed by retrofitting what we already know about clinical models from around the world.  The workgroup lead is someone I hadn't previously met, Dr. Holly Miller.  I got to listen to her explain the importance of pertinent and relevant to the CIM team while I was in the back of the room.  This evening I upgraded her ribbon from Rock Star to Goddess.  I don't know how many times I've tried to explain that to people.  She joined the group who headed to Sushi for dinner.

Data Elements:  This workgroup has nearly completed mapping data elements required for the use case back to the HITSP C154 work that was done in 2010.  John Donnelly led these efforts (he was another member of the dinner team tonight).  It's almost all there, which is what I would expect.  There's some confusion because there's a different between a set of data elements to describe something like a condition, and the clinical context in which it appears.  For example, you use the same set of fields to describe a condition regardless of whether its part of the active problem list or is part of the history of past illness.  It's that classification of the set of data elements which is dynamic (and depends upon clinical judgement about relevance), and the data elements themselves, which are static.  I got to spend some overdue time with this workgroup.

Standards Analysis is proceeding well, but depends on the output of the CIM workgroup.  It appears as if the strategy might be C83 for today, moving towards the CDA Consolidation work when it is ready (e.g., when we have some deployment experience and a reference implementation).  The CCR doesn't seem to be up to the job from the reports of several people (not just me).  I described it to one person thus:  You can have a fast motorcycle and a fast car.  In a short race, the fast motorcyle will win every time.  But in the longer races, the car will beat it every time.  The motorcycle has more accelleration, and will get you to top speed faster (e.g., the CCR and transfers of care), but the Camaro will beat it out in any long race because it has a higher top speed (CDA and CCD).  That is going to be an interesting discussion because most of the CCR proponents aren't at this face to face meeting.  I miss seeing Steve Waldren, he was a force for good in HITSP, and we haven't connected back up since those days.

The Reference Implementation and Architecture workgroup came under quite a bit of fire when we reviewed their scope and purpose. Even when  we ripped that to shreds and reworked it, much of the architecture remained, but our focus appears to be changed.  That group seems to want to adopt me and I'm not adverse to the idea.  There's quite a bit of overlap between what they want to do and work that already exists in MDHT and the Template Meta-model work.

There's a ton of data that we need to gather.  Some of that will likely be in a template exchange format based on the template meta-model.  My own work in this space is leading me down the path of rebuilding the model from an XML Schema designed from the model.  While EMF is capable of generating a schema from a model, I'm not well versed in how it does it yet to get the XML Schema that I think should be generated.  So I generated and XML schema that I'll hand-edit, and then reverse engineer that back into an EMF model.  I some work I've done this week I've already identified a gap, which is a business name associated with the class attribute being constrained.  That might actually enable us to tie the clinical information models, data elements and template models together in MDHT.  Then we can build a transformational architecture based on the model data using something like MDMI (which we may shortly have access to an open-source implementation of).  Once I get that working the way I like it I'll have to explain it to the templates workgroup at HL7 who is working on updating the Templates DSTU.  I wish all these projects weren't trying to be pertinent and relevant at the same time.

From there, I think there is a step of building an interface to support storing CIMs in an exchange instance and loading an exchange instance into a model so we can extract the data elements from CIMs.  That's a place where something like MOF2TEXT could help.  Any .Net coders out there that want to write code generation for the .Net interfaces?

There's some thought that the interface for the reference implementation should be a service.  I think the first step is to build an API and then to refactor a service interface out of it.  The former will be more fine-grained than the latter.  Since the API is model driven, it shouldn't be too difficult to get several implementations if we can get the right people engaged.

There's clearly signs of growing pains in SI framework.  The late venue change (we are now in the Hilton Hotel down the street instead of in another office buidling) is due to 170 people registering for the meeting.  This would have been pretty normal turnout for a HITSP meeting, probably five times what they had for Direct, and predictable given the size and number of workgroups.  Both ToC and LRI workgroups were stuck with two large conference spaces that we had to share for our breakout sessions.  Communication has been a bit of a challenge, but late breaking news has made it to people via e-mail instead of just being on the wiki.  This is a welcome change because I do read my e-mail every day, several times a day, but I don't go to the SI Framework wiki all that often.  Wiki's are great collaboration and documentation tools, but lousy ways to deal with conversations.  I wish we'd just get a list server and figure out how to integrate it into the wiki.

There were some other "up-level" conversations that we also had about the SI Framework process.  One of my challenges is having yet-another-standards-activity to follow.  ToC alone has umpteen hours of calls a week, at least twice as much as what I try to follow in HL7.  The RI workgroup was new to me because I cannot keep up.  They are spawning (in ToC and LRI) about two workgroups a month -- with more to come on at least two other projects (Provider Directories is one of those, and the other you'll hear about later).

One of the things Doug asked, first to the workgroup leaders, and second to the entire group was "what is it that this organization does that the SDOs do not."  There are a lot of different answers to this question.  One of them is "Support from ONC".  For some reason, neither IHE nor HL7 (nor the former HITSP) seem to get the respect from certain people at ONC or the FACA's that they'd like.  And yet when I look in the room for the SI framework project, more than half of it is made up of HL7, IHE and former HITSPites.  There seems to still be a belief in some quarters that these organizations haven't served the industry.  While they all have their blemishes, I think that they have done so.  One of the comments made about the need for SI framework was that "we aren't there yet", but the same person also said "Interoperability is a journey, not a destination."  Clearly there are some waypoints on this journey that people would like us to hit.  I want to know what they are, and how they are being established (something not apparent in how SI framework projects get chosen today).  This is not any one organization's problem.  It belongs to all of us, just like my jacket tells not just my story, but those of many other volunteers in many different organizations working to bring about change.

Members of IHE and HL7 will continue to participate in these efforts, but I really wish that someday there could be a come-to-Jesus meeting with all parties where everyone could air their griefs and get over some of these impasses, so we could be more focused across the board.  There's still too much back-room-snyping going on in way too many places.  Maybe it's all just "Politics" and I should just ignore it, but I'd really like to make it go away so we can focus on the real work.  This shouldn't be so dog-eat-dog competitive.  There should be a way for all of these organizations to work more closely together (maybe something like the Canadian model -- I think I'll propose something later in a blog post).

The Documentation workgroup meets in the afternoon to talk about the "transition strategy document".  This was deemed out of scope in the HL7 efforts, but really needs to exist if the ToC project is to succeed.  There needs to be a map drawn from the way we do it today (C32 Version 2.5 and CCR) to the way being proposed for the next stages of meaningful use.  I'm wondering if trying to bring in a publisher might help with this.

All-in-all, it's been a very productive standards meeting thus far.