On June 28th 2011, Integrating the Healthcare Enterprise [IHE] kicks
off its Annual
Free Educational Webinar Series with a wide
range of topics to help organizations - from clinical to vendors – learn about
the benefits of IHE and how your organization can participate in IHE’s
year-round development and deployment activities. "The series provides insights from
thought leaders who can explain the value of standards-based interoperability
as well as the clinical and administrative benefits for end-users who implement
IHE-based solutions and for vendors who develop and offer IHE-based
products," stated Joyce Sensmeier, MS, RN-BC, CPHIMS, FHIMSS, FAAN,
President, IHE USA.

Wednesday, June 29, 2011

What belongs in an implementation guide? Many HL7 implementation guides and IHE profiles include the requirements of an implementation, sometimes with an explanation of the more tricky bits. On a discussion today, someone asked (or at least I thought they did) about the separation of content between documentation stuff and functional requirements with respect to the template meta-Model.

I responded thus:

It's like code. When I'm doing a code review, if a comment in the code is wrong, the code is wrong, even if the comment doesn't functionally contribute to the execution. That's because it does contribute to the maintenance of the code it comments on. So, I don't see a need to keep them separate, and I do in fact see a need to keep descriptive, "non-normative" stuff together with the stuff that allows systems to validate or implement the templates.

The point being that the "non-normative" stuff is what helps implementers do stuff, and it needs to be kept together, even if it doesn't help in code generation.

Tuesday, June 28, 2011

It's very similar to Godwin's law, but related specifically to Health IT. In any sufficiently long discussion of Healthcare IT, the probability of a comparison being made to the financial sector approaches unity. Keith's corollary is that that in any sufficiently long discussion of patient safety, the probability of a comparison being made to the aviation industry also approaches unity.

Last night's HITsm discussion of PHRs (inspired by Google Health's over-reported demise), the financial industry comparison was made. This one just sets the hair of my neck standing on edge for a number of different reasons.

Financial transactions are very small (those dial-up POS terminals you see in small merchants run at 1200-2400 baud!). They include account holder identity information from the credit/debit card (less than 100 bytes of data), merchant identity information, and a transaction amount. They are intermediated by a third party (called an acquirer) who connects to the card issuer. The merchant gets back an authorization for the transaction. Subsequently (usually at the end of a shift or day), the merchant processes the authorizations so that a deposit (minus transaction fees), can be made to the merchant bank account.

Now, look at communicating data in healthcare. The first difference here is in establishing identity of the destination account. Membership in employer health plans turn over faster than jobs do (employers change health plans and people take new jobs, either event results in reissuing a health insurance card). We still don't have a national patient identifier and very likely won't any time in the near future (it may be decades away or even never). So any identity will have to be issued by a third party at the moment. One suggested solution for this is a "Direct" address. That might be OK, but there are some challenges with individually (person) owned end-points around certificate management. It's pretty easy if you want an organization to help manage the communications for you, but to manage it yourself would be more difficult.

The next challenge is around bandwidth. Existing POS terminals at 1200-2400 baud would take about 1-2 minutes per transaction to complete it for the smallest collection of information in a standardized form. Larger ones (imaging) and other study data could take quite a bit longer. That's because the size of the transaction is two to four orders of magnitude larger than existing POS transactions. So the ubiquity of the POS terminal is not an argument for success. Have you ever had to wait two minutes while completing a credit card transaction? Probably, but it's rather rare.

Now the next big hurdle: Regulation. This flowchart from a HIMSS presentation shows the process by which a Healthcare delivery organization can determine whether they must register their systems with the FDA under recent medical device regulation. Would the system be used to transmit data from an EHR, an EKG, an automated blood pressure cuff? These are all medical devices. Would someone want to advertise its use for healthcare? The MDDS rule would probably apply.

There's more. Some risk analysis is needed here. How will the system ensure that the patient for whom data is being transmitted (e.g., identified via some sort of card) is that same as the patient for whom the data is transmitted. BTW: That would mean that you need a card for every family member, and the system needs to make sure that you do not confuse them so that your data doesn't wind up in your spouse's record and visa versa. Does that step exist in current financial transaction protocols at the POS device?

HIPAA and Breach Notification. More regulations to ponder. Yes, there are similar issues in the Financial space, but here there are more specific reporting requirements in healthcare.

Records retention, logging, audit trails, security, yes, the financial industry deals with all of that fairly well, probably better so in some cases, but the real issue is dealing with the fact that we aren't transmitting single pieces of data in the payload (the amount of the transaction), but instead hundreds, thousands or even more for imaging studies.

The other piece of this that comes into play is the business model. What would be the business model for these healthcare transactions, and who would pay for it (even if it is the patient who eventually bears the cost). In financial transactions, there's a payment model that is already built in. In an information sharing model, there really isn't a good one (I'd be rather hesitant to give a few percent of my data to the transactors).

So, look at it in more detail before you make the comparison, and explain it in detail. It's VERY useful to learn from what other industries do, but please, do the comparison thoughtfully, and not just in 140 characters or less.

After reading what everyone else had to say, I decided to not to repeat Google's mistake. So I talked to some real patients who might have used it. My survey is not at all scientific, but here are some of the feedback I got:

Here's what my wife had to say: "What's that? I know more about WebMD than I do about Google Health. (And how does she know about WebMD? Because she was Googling something.) ... I'm sure it'd be cool to have a way to organize all the paper you need to keep track of as a patient, especially as you get older." When I pointed out there was no good way to get it [the paper] to Google, she asked what good it was.
My wife is no slouch on a computer, but not technically very literate (that is, after all, what I'm good for).

My mother had never heard of it either. She was thrilled to hear about it, and then extremely disappointed to hear that it was being discontinued. When I talked to her further about it, it became apparent that it wouldn't have solved her paper problems. She almost repeated my wife's words ... what good is it. My mom is pretty computer savvy when it comes to dealing with the stuff that concerns her. She carried around a 3" thick folder of paper (and x-rays) on my step-father for years. Many of them she'd entered in a word processor. She's got a piece of paper on her refrigerator with all her emergency info in it, including doctor names and numbers, meds, allergies, et cetera. She might have used it, but never heard of it before.

A friend of the family is on MA Health for insurance. Her doctor doesn't take it and when her recently become Ex dropped her from his insurance, she lost access to care. Google Health wouldn't have helped her with any of her problems. For her, it's not about getting data, but rather access to care.

My mother in law spent most of her free time playing with the computer. She generated an extensive family tree. Did she know about Google Health? No. Would she have used it? Perhaps. Would it have helped her create the complex set of legal documents she needed to assure her that her children would be able to assist in her care? No.

All these people could have benefited from some tool. But it wasn't Google Health because a) they'd have no easy way to get data into it, b) it wouldn't solve their real problems, and c) they'd never even heard of it.

It gets back to hammers. When all you have is a hammer (cloud storage and data organizing tools), every problem looks like a nail. What looks like the problem here was not lack of nails, but beams to nail them to.

I'm sorry to see Google Health go, but I also hope it will be replaced with something better, that meets the needs of patients like me and my family members.

Friday, June 24, 2011

On Tuesday, June 28, 2011 National eHealth Collaborative will convene a group of Health Information Exchange (HIE) leaders representing a diverse cross-section of operational HIEs that demonstrate innovative strategies and business models for achieving sustainability and providing value in their communities. These HIE leaders will be brought together for a roundtable discussion that will focus on critical success factors for establishing an HIE, as well as an exploration of the challenges and obstacles to achieving sustainability and building community support.This roundtable will serve as a preview for a soon-to-be released report, which NeHC recently commissioned in order to provide in-depth studies of successful and relatively mature HIEs across a number of spectrums. The report is intended to capture the key dimensions of success for HIE sustainability, contribute to the development of a national roadmap for health information exchange, and to provide insight and guidance for emerging HIEs.

Pretty tied up with stuff lately, so not much external writing happening. Today's post is just a simple observation:

This is an extremely cool looking toy. I can see lots of different possibilities around technology and software like this in healthcare. But then look at the firing mechanism. A mechanical, capacative trigger. Yuck. Can't even have a simple trigger integrated with the device.

The cool thing about Android is that you can take it out of it's tablet skin and use it in a variety of different places, "dumb down" the installed software to support a single purpose, and voilà, you can have controls for a car, coffee maker, dishwasher or any moderately complex device, including many used in Healthcare. Want to integrate wired networking instead of wireless? other inputs? Yep, can do. Imagine trying to get the same sort of iP* components for use in other manufacturing. I'm not sure that's ever going to happen.

Everywhere there's an LCD screen and three or four buttons to control a device, you could replace it with a slimmed down user control supporting something running on the Android platform. There's a lot more of those out there than there are phones and tablets.

Wednesday, June 22, 2011

The hash tag #HIT100 is representative of the top 100 influential people for Health Information Technology in social media.

You are probably familiar with the Modern Healthcare 100 list or the Healthcare Informatics 100 list. When they came around again this year, I was wondering if there would ever be a list of movers and shakers in Health IT that I might show up on. Well, I guess this is one of them.

Given that this was announced on twitter, most of the nominees already thus far are on Twitter, but social media for me includes bloggers and others using Facebook, LinkedIn and other Social Media venues. For example, John Halamka does very little on Twitter, but his blog is extremely influential in Health IT, and the same is true for many others.
My scope is International, rather than US Centric, although it is, due to my location, heavily influenced by my location in the US. Influential to me is qualified by "in social media", so although @Farzad_ONC is extremely influential in Healthcare IT, it is not really due to his activities in Social Media, and so he doesn't make my list (this year).

Here are my selections (around 75), along with a brief explanation of why and links to their twitter handles and blogs (Sorry, just not a facebook kinda person).

Amit is a member of the IHE Quality, Research and Public Health
Workgroup and as you can guess, an avid @motorcycle_guy follower. I conned him into
this gig by tweeting about a conversation he had with another colleage. He's done
remarkable work since then.

Erica is one of the driving forces (along with Dave Shaver) behind the
@HealthStandards twitter handle, and is also the leader of the HITsm chat on Monday
nights. That chat has been the source of a great many twitter connections for
me.

Oh man, do I need to say more? John's probably the single most
influential blogger in the Healthcare IT space that I can think of. His reach is
even more important because he hits people outside of the #HITsm spectrum.

John does for the Security/Privacy space in HL7 and IHE as I do for the
Clinical Content space. He's a colleage at GE Healthcare, and if it weren't for him
(and to some degree Glen Marshall), I wouldn't know half of what I do about
security.

I first encountered Regina's story when it was live-streamed during the
Meaningful Use regulation announcements. I cried for her. I've heard it again
several times. Her work is an extremely powerful incentive to get [Health] IT
right.

Rob is an ubergeek. He does GIT in e-macs. Really well-thought out
insights into Healthcare IT. You don't really get all that from his blog right way,
for that you need to meet him in person, but well worth meeting.

Wes is one of the grand old men of HL7, and a former chair of the
Organization, and an analyst for Gartner on Health IT. I first met him in the Claims Attachments workgroup of HL7 which he
led for many years. He writes periodically about Health IT issues, especially those
being faced by the HIT Standards Committee (of which he is a member). Some of his
writing spawned the Direct project.

Tuesday, June 21, 2011

If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. Its peculiar character, too, is that no one possesses the less, because every other possesses the whole of it. He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. -- Thomas Jefferson

Topic 3 on last nights #HITsm Tweetchat got into discussions of who owns patient data. The moral high ground today seems to be towards "patient ownership." Reality is just a bit different, and I think the discussion of ownership is not all that useful. It should be about rights and responsibilities with respect to patient data, rather than a discussion of ownership. My statement on this is remarkably similar to a post made by Dave Hitz on his blog.

With all due respect to patient advocates who claim ownership of the data, I don't see this enshrined in law, nor do I think "ownership" should be. The challenge to think about are the needs of providers, who collect and organize this data to run their practices. The existence and organization of that data is essential to their practice. Could you imagine the merger, acquisition or other disposition of a healthcare provider practice where the data they used to operate didn't go with the business? Would that benefit patients? Almost certainly not.

What I do see in regulation is the right to obtain the data that a provider has on me (or you). If you think about it, data is something easily shared. After all, it's pretty easy to make copies of information, as Jefferson alludes to in the above quite.

As of now, the HIPAA Privacy regulation gives patients the right to access their information under 45 CFR §164.524 and the right to amend it under 45 CFR §164.526. Providers have the responsibility to make it available and to amend it as appropriate subject to review by the provider (with respect to accuracy, appropriateness and source). There are a lot of caveats here which clearly need to be change. Provisions of this regulation are the cause of Regina Holliday's 73¢ Mural.

HITECH and Meaningful Use change that, but they assert it as a provider responsibility, rather than a patient right. Providers that want to obtain Meaningful Use incentives have to provide patients with an electronic copy of their record within three business days of the request (instead of the 30 allotted by HIPAA) for at least 50% of patients making the request. This is a pretty low bar.

I'm certainly in agreement with the majority that believe patients should have better rights to their data than currently available in law or regulation, but when we talk about ownership, it only confuses the issue.

Monday, June 20, 2011

Just about every standards organization starts from a core or reference information model these days. From this model all things exchanged are eventually derived. The models themselves are most often expressed in a collection of one page UML diagrams.

A model is a description of a thing meant to show important properties and to enable others to study its characteristics. Multiple viewpoints need to be accounted for in modeling. Just like in architecture where we need to show the structural steel and concrete in one view, and the electrical power runs in another view, and the final artists rendering of the building in yet another view. Each of these views "hides" some important component of the finished product, making others clearer and more visible so that the interested parties can see what is important to them. But each view is necessarily incomplete in order to show what is normally hidden behind other parts of the system.

In developing requirements for a use case (such as transfers of care), we being to develop a "picture" (another word for model) describing what is needed. The desire to put these into a model is hard to avoid, and in fact, provides some needed rigor to the process (which often starts off as an Excel table with three word phrases in it). The evolving "pictures" often look pretty familiar. There are already a lot of models of information in healthcare, and in a healthcare activity involving 100 people, I can assure you that at least 50 of them have already been involved in other activities. Having built the table, sometimes we look to adopt a particular model. Model envy ensues, often descending into Ken-L Ration justifications for use specific models.

Right now, there is no single commonly accepted model of healthcare information. There are some common components which just about everyone agrees upon. There are some ways of putting things together that have majority appeal. After that, especially at higher levels of detail, it descends not quite into chaos, but certainly into a variety of approaches defined by a number of different methodologies argued for by experts. These experts are comfortable with one model "brand" or another, and sometimes even formulate their own possibly even based on the work of those others so as to include some viewpoint or feature omitted or not specified in enough detail.

Why are there so many models? Why isn't there just one? Modeling is often a subjective exercise. The model is "complete" when the viewpoint being expressed is understood (and agreed to) by the experts expressing it. Understanding is based on skills, education, and having been present for the discussions where the model is created. There is often no objective criteria to establish completeness, to judge appropriateness, et cetera. It's still largely an art rather than a science, much like gardening.

One of the questions I asked the Clinical Information Modeling team is whether they had been able to establish objective criteria for what information belonged in the "Core" of the exchange packet. As yet, we don't have any. It is based on the subjective experience of the model developers. Perhaps there might be some evidence-based approach we could use to define essential, relevant, et cetera, but we haven't found it yet.

We have the same problem with interoperability. What is the objective measurement of interoperability? The definition doesn't really help.

Bringing some objectivity into the discussion might help us all to move forward. Think about that the next time you build an model. What is your objective criteria for inclusion? Completeness?

Friday, June 17, 2011

Quality, Research and Public Health supplements published for Public Comment

The IHE Quality, Research and Public Health Technical Committee has published the following supplements to the forthcoming IHE Quality, Research and Public Health Technical Framework for public comment in the period from June 17, 2011 to July 17, 2011:

·Early Hearing Care Plan (EHCP)

·Mother and Child Health (MCH)

·Physician Reporting to a Public Health Repository-Cancer Registry (PRPH-Ca)

I spoke to a number of different people over the past couple of weeks, and several other conversations were reported to me. Many of these statements I've heard before. Most of these were second or third hand reports, but many I've heard from multiple sources on the same topic. I'm sure lots of you reading this can fill in the blanks appropriately in the following statements (and there are multiple correct answers). My point is not to call out anyone making the statements, but to illustrate the problem:

What do you mean there's (an SDO/Profiling organization) stuff in (project). It was supposed to be the (the previously mentioned SDO/Profiling organization) killer.

(organization or person) doesn't like (SDO and/or Standard) so we can't talk/think about them/it for this use case.

Few of these statements are anything that the people attributed to them would ever say publicly. Some because it would be bad politically, others because it would be outright suicidal to their careers, and/or contrary to existing government policy on the use of standards, which strongly promotes the use of consensus standards. None of them help us move healthcare where it needs to be.

Some of the complaints about existing SDO/profiling organizations are that:

Their work is too complex (e.g., CDA and/or XDS).

Their work doesn't meet the needs of a particular stakeholder (e.g., small providers and/or vendors).

Their work is driven by ___ (e.g., Big vendors).

Their work is not freely available to all (e.g., HL7).

Their work is not universally adopted or implemented.

We tried this standard once and it didn't work (e.g., C32 in VLER).

The solution to these problems is not to oppose or replace these organizations, but to change their behaviors by participating and contributing. None of them are exclusionary. Many have membership requirements and all have costs associated with them (time and travel at the very least). If the particular issues are reported back to the appropriate organizations, many will be willing to (and some are already) addressing them.

I've been there. The "Kill" strategy on standards is my least favorite, most intensive, and most dangerous strategy to execute upon. I'd much rather work from within. I don't get everything I want, and it isn't always speedy, but I find it to be a much better approach.

I have a problem with all these internecine battles. It results in emergence of so many projects and work groups that I cannot pay attention to all that is going on (and this is my full-time job, unlike many other of the volunteers in the standards space). SI Framework just spent several months addressing one of these issues because there are at least four different laboratory reporting implementation guides that could be used, and what are they going to do? Probably build another one to obtain consensus. These projects are all subject to Rishel's law: Change the consensus group and you change the consensus.

While true, the consensus of many of these projects not often dramatically changed. And from the ONC perspective, what they've repeatedly asked for is "good enough". If nothing major is changing, then why are we spinning our wheels? What we had already was probably good enough. (Note: I'd love to see is a good study of Inter-rater reliability across the different standards projects).

So, the point of my post is that we need a place where we can do this once, instead of over and over and over again. SI Framework, IHE, HL7, eHI, CfH, CHCF, et cetera, aren't managing it alone. We need to work together and come to consensus ONCE, and then implement and deploy it.

A majority of the participants will be the same set of people we see at all of the various meetings and involved in the projects. But it will be broader too. But instead of having to have three or four different projects in three or four different organizations to solve these US problems, maybe we could just have one.

Anyway, that's enough on this topic for now. I need to get back to the real work.

Thursday, June 16, 2011

Several people have been wondering publicly how the delay proposed by the HIT FACAs for phasing in Meaningful Use Stage 2 incentives would affect selection of standards. Let me give you my viewpoint:

A delay in implementing incentives for stage 2 should have absolutely no impact on when the standards being used to meet the requirements for stage 2 will be chosen. The whole point of the delay is to give the Healthcare industry enough time to respond to the new requirements. If you delay the delivery of those requirements a year as well, then we still wouldn't have a clue as to what would need to be implemented, and delaying would have no gain. So, expect an updated standards rule proposed by year-end that will tell us what new standards are being selected for stage 2. My bet is that it will arrive the day before the Christmas holidays (it is the Office of No Christmas after all, and no summer vacations either). We'll then get 60 days to comment (Jan-Feb), and then life will go dark again for 3 - 4 months while the final rule is developed and then published (July or thereabouts).

This is pretty much the same schedule for the standards regulation that was followed in 2010, and its been widely hinted that we can expect similar things for stage 2.

I'm not sure why the FACA chose a year long delay instead of the 90 day reporting option. The latter seemed simpler and gains as much as 9 months (leaving it possible for organizations to move more quickly), while the former seems more complicated, gains 3 more months, but means that there's not much opportunity to move more quickly. But then again, I've been down in the weeds of standards, rather than paying attention to what HITPC and HITSC are doing.

You, represent (and I quote) "an extraordinary diversity of stakeholders who share a commitment to improving the health care system through more effective use of health information."

Come together again, but this time, let's put some skin into the game. Every single one of you has something you are doing that is focused on Healthcare Interoperability and Standards. Many of you are US focused, some exclusively, others have a strong US presence. Many of you derive revenue from these activities.

We need to break down more silos, but these are all your own silos. I'm tired of silos. I want you all to go into a room, we'll feed you coffee, tea, pizza and mountain dew and all the water you can drink, but there will be no bathroom breaks until you've emerged with a solution about how we can develop standards, implementation guides, reference implementations, and open source, under a common governance framework, with shared benefits to all, to meet the needs of the US healthcare system, and to support our goals internationally as well. Call it the US Standards Collaborative. Call it SI Framework 2.0. Call it what you want. Make it happen.

Oh, and ONC, you need to put some skin into this game too. You, as I recall, wanted a public-private partnership to come out of the SI framework process. What will you put forth to make that happen? You know the money for SI Framework runs out in what, two years or so? How will you keep that going.

Nah, it'll never happen. There's just too much competition for leadership in this space for people to work together on a common goal like this.

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.