Monday, January 17, 2011

A Virtual Connectathon

Those of you who regularly follow me know where I am this week... The IHE North American Connectathon.  I think that connectathon is one of the coolest events the healthcare industry does, and its because of the collegial atmosphere and get it done attitude that permeates the whole event.  I'll be live-posting on Connectathon more this week, but I wanted to start off the day with an interesting and related exploration.

A couple of days ago, Doug Fridsma (the keynote speaker at the Connectathon conference on Tuesday) commented to me that this is something that should also be available virtually and year-round (he attended the HL7 Working Group meeting which I was also at last week).
Help Needed
I'm gathering all the web commentary on the PCAST report I can find for a submission to the ONC RFI. If you have links that may not be what I have already seen, tweet me or send me an e-mail with it. 

I've been thinking about this topic a little bit, and wondering what a virtual connectathon would look like.  There are a few challenges to overcome to make the connectathon a virtual event, and the first of these is the intensity of the atmosphere.  This year's North American Connectathon includes more than 150 systems (up 25% over last year), which will execute over the course of one week tens of thousands of tests which will be reviewed by a team of more than 50 people.  According to Bill Majurski, about 70% of the registrants will be using XDS in some form.

I recommend that product teams send at least 2 people to connectathon per product being tested, which gives a fixed cost of about two weeks of effort.  You can do it with one (I've been there and done that), but that's a mountain of effort to put on one persons plate.  Teams also put in about 1-3 weeks of effort pretesting each profile (not including development time).  Most companies test more than one profile, and can often take advantage of overlaps in product requirements to reduce the aggregated time.  Even so, it's still a large time committment.  Spreading that effort out in a virtual event over the course of a year reduces the intensity. 

But the intensity is one of the reasons why connectathons are so valuable.  Participants have a week to succeed.  To do so, they MUST work with their partners, sometimes deep into the night.  There is no other choice, and this necessity makes for partnerships not heard of in the real-world.  How, in a virtual event, can we ensure this kind of participation?  Outside this room, these people are often stiff competitors, but inside they are your testing partners. You work face to face with your partners to succeed at this event, sometimes shouting down the row, skyping or talking with cell-phones, while making code changes live.  A success is often celebrated with a beer or dinner later with these same people.

So a virtual connectathon has to have another purpose, and another way to ensure success, than the event I know and love.  It's pretty hard to share a beer virtually, and without the deadline, impossible to get that kind of coordinated effort among competitors.  Some other possibilities come to mind.  One is to have shorter, more frequent regional events.  We've done that for several years.  IHE members attended a number of different events and demonstrations, some of which included connectathon like testing including the VITL Summit, the eHealth Connecticut Demonstration (2008), and PHIN's annual conference.  While it adds value, it's not what I think Doug is asking for.

So what would a virtual, year-round testing event look like?  Who are the stakeholders?  What are the benefits?  What are the costs?  Who would pay for them?

Stakeholders and Benefits
Governments
Readily available testing of healthcare IT that meets regional requirements.
HIE Organizations
An opportunity to test their systems with new products as they become available.
Healthcare Providers
Products that have been tested more recently and frequently than annually.  The ability to test homegrown solutions and integrations.
Healthcare IT Vendors
The ability to test more frequently than annually, the ability to test at much lower cost and intensity of effort, the ability to test with partners that you didn't have the opportunity to test with at connectathon.
Costs
There are a couple of things that go into the cost equation.  You probably need a virtual private network to set up a "Connectathon" like network environment.  You need someone to manage this, assign access, et cetera.  You also need monitors / test proctors and someone to manage them.  Connectathon itself requires a team of 3-4 people to manage all that, plus a team of about 50 monitors.  You could probably get by with a team of 1-2 to manage the virtual environment and manage test results to start off with, but you still need a larger team to proctor the tests. 

The IHE monitoring team is made up of volunteers.  The concentration of time at Connectathon is what makes it possible for many volunteers to participate.  Some of the monitors are friends of friends of IHE who got dragged in once and keep coming back, others are IHE committee chairs or participants, and a few others are contractors working on large projects (e.g., HITSP) who come as part of their work.  Most come to Connectathon because they like the atmosphere, support the work being done, and they also get free travel to Chicago in January.  Some are giving a week of their lives for nothing more than the experience on the Connectathon floor, using up vacation time to boot.  Many are rather skilled IT people, some with very specialized skills.

Something else has to be done to provide value for monitors other than the free travel because there is no free travel once you go virtual, and you've also radically changed the atmosphere.  Because of the diversity of experience, you'd probably need to pay several skilled individuals to do the job, and you'd need to invest in their skills as well.  My guess is that to do as much work as the 50 volunteers do in one week over the course of a year, you'd need to hire 3-6 part-time contractors to do the same work, and you'd also have to spend some time training them, which might also include participation in new IHE work.

I'd ballpark that a virtual connectathon would have a budget of anywhere from a half-million to a million dollars depending upon how you got the monitors.

Paying for It
So, just to make it simple, let's say that the cost was a cool million dollars.  Cheap at twice the price.  How could that be funded?  At $4000 per system you'd need to get 250 systems to participate in the virtual connectathon.  That's more systems than participate in the annual connectathon, and an enrollment likely not to be reached for some time if ever.  I could see maybe 100 systems after two years if the right incentives were present to participate, and in the first year, 25 - 50 systems if you were lucky.

We could maybe cut the networking costs and staffing requirements by getting the state HIE's to supply resources, equipment, et cetera to the effort.  Maybe the RECs which already have developed some requirements of their own could support testing efforts by supplying monitoring and management skillsets in exchange for having a testing environment and audience they could use for their own purposes.  Educational institutions could support testing as well, exchanging student assistance with testing for the training that the virutal connectathon experience provided and the educational credits that the institution offered.  Hmm, those two weren't even in my original list of stakeholders.

We still lose the intenstity of the live event, but that could be supplied (in smaller doses) by other special purpose time driven events.  State HIE X could sponsor an event designed to test conformance of a variety of systems to an Immunization message.  REC Y could sponsor an event designed to test conformance of a variety of systems to their own region's initiatives.  Sponsorship of an event might have its own costs born by the sponsor, with possible additional fees assessed to event participants, but those fees would have to be reasonable. 

I could certainly see the advantage to vendors to be able to have a system connected year round where these sorts of tests could be routinely performed.  It could eliminate a lot of duplicated effort around the country, and could enable many activities not possible in current Connectathons.  Some of those same resources could be used to support other opportunities in education and innovation later, but I wouldn't want to get too defocused in the first year or two.

It's an idea worth persuing further.  If I were on the board IHE USA, I'd be thinking long and hard about this one.  We could make this idea work, and it could shortly become self-sustaining.  It wouldn't be the same as Connectathon, but nothing virtual ever would be. If you happen to be at Connectathon this week and have read this post, I'd be interested in getting your feedback.

Sunday, January 16, 2011

More of Robin's Eggs

January 16, 2011
Robin's at it again. Here are the bookmarked final rules from 2010 and January 2011 which are available in Google Docs for viewing or download

And here's a worksheet you can use for commenting on Stage 2 objectives.

Netizens 2.0 Response to PCAST

Government 2.0 (of the USA) meet Citizens 2.0 (of the World)

There is an amazing capacity among us humans to hear what we think is important, and not hear at all what we don't care about. We respond to what makes us feel strongly and not at all to that which doesn't. The PCAST report was something that many of us who blog responded to in these terms.  Some of us who responded may not be interested in formulating a direct response to ONC.  After all, this is a US issue, right?  Others of us will revise our initial visceral responses into much more finely tuned words and phrases better suited to use with policy makers.

 I've gathered up commentary from the Blogosphere to the PCAST Report to put together what I call the "Netizens 2.0" response.  The only editing is to make it readable as a PDF document (so I have to change background and text colors), and removing unnecessary multimedia (YouTube videos of the PCAST Video, the Presidential Logo, copies of the PCAST report and pictures of the commentary authors).  I'm also including the comments on the comments.  I figure that there's as much or more expertise on the net that has already commented on the report as went into the report itself, and that expertise is already much more focused on healthcare, so it is vital reading.

This response WON'T have the finely edited turn of phrase that is typical of formal public responses to federal RFI's.  It's rough, and even the very slight reformatting I did do wasn't quite as thorough as I would have liked because of the hours in which I have to fit this in.  But it will content the cogent thoughts of very skilled professionals who also write well, and to a much broader audience.
Here are the list of postings that I included.  If I missed your favorite, my apologies.
All told it's about 65 pages of feedback.  Happy reading.

-- Keith

P.S.  Contrary to what the PCAST reports, modern search engine technology provides inadequate recall and precision on queries.  I had to use both Google and Bing to find some of these reports, and even then,  @VinceKuraitis did a much better job that either.  Thanks Vince, yours was the first on the list.


Friday, January 14, 2011

IHE Workshop Results

Today I facilitated an IHE Workshop for the third time.  This is always an interesting program.  The first half of this half-day program is spent describing how IHE is structured, what it does, why, the benefits, how the processes work, et cetera.

The second half is done in five stages.
Step 0: We review the IHE profile proposal template.
Step 1: This step includes brainstorming interoperability problems in healthcare.  We simply come up with an unconstrained list of problems that IHE might be able to solve. 
Step 2:  The next step divides the room up into teams of 3-5 people and having them select a particular problem to solve.  Each team has to develop a profile proposal (short form), which includes four things:
A) Problem and Value Statement
B) Use Case
  i)  Current State
  ii) Desired future state
C) Available Standards
D) Systems involved

Step 3: Teams present their proposal in 5-10 minutes, and answer any questions on them from the class.  I also gently critique the proposals, explaining what might be done to make them a little better.

Step 4:  The class votes on the proposals.  Because of the timing, the class dwindled a bit from 12 to 6 people (it was the last class on the last day of HL7).  So, I didn't let teams vote for their own proposal.

One proposal today got overwhelming support, and it was from the Opthomologist who worked solo with a bit of help from me.  So, I'll be flying that one past some friends in IHE Eyecare to see if I can find a supporter of it to present at the next opportunity.

The problem described was lack of consistency in data collection on cataract surgeries.  This is apparently a very common surgery (in general as well as in that specialty).  The proposal was to develop either an OpenEHR Archetype or a CDA Document template that could be used to gather and report on the data pre and post-surgery, with use of SNOMED CT or LOINC Vocabulary, and restriction to appropriate units to report on vision acuity.  A 20/20 in the US translates into 6/6 here in Australia, but there are also log scales.

I'll get the complete proposal from my student in my e-mail.  We also looked at remote (home) monitoring, but that one didn't "win the prize".  It had some valuable points also, and was well done, it just didn't have the same focus as the Cataract Surgery one.  So, I'll take the output from that group and forward it to some folks in PCD next week also, and make sure that the team at least gets feedback on what is available.

The last proprosal was for ePrescribing, and had participation from AU, NZ, and CZ.  The challenge here is that there really are NO common standards available for the electronic prescribing acrosss these regions, so the proposal was not terribly feasible.  Even so, I promised to point them to the work being done by epSOS as a possible starting point.

Everybody gained something.

Next week I'll be doing something similar, but with much more limited time.  Students will identify problems, and use existing IHE profiles they've had described to them earlier in the day to design a solution to an interoperability problem.  I won't have to provide as much background for them because they'll have been at the Connectathon conference and will have also already toured the floor.

-- Keith

Thursday, January 13, 2011

An overdue Ad Hoc Motorcycle Guy Harley Award ...

The Ad Hoc Harleys are headed into their second year.  They were initiated on January 20th of 2010 (my Birthday).  The whole point of the Ad Hoc Harley is to recongize the contributions of someone with regard to standards who would otherwise be an unsung hero.

This particular award goes to one of those heros I first met in 2003 at an educational meeting in Chicago.  Since then I've watched him over the years invest tremendous amounts of time and effort into ensuring that more than a 1000 products work with each other, using more than 200 different specifications.  Unlike many others who get recognized here, this is part of his job, but he does that job well, and as a result of his efforts millions of lives have been made better by more interoperable healthcare products.  It is not unusual for a computer to review hundreds of thousands of complex transactions, but it is the rare individual who can claim some responsibility for the same.  This person can, and has done so more more than a decade.

In his role as "Mother" he has raised up a number of children through the complex process of ensuring systems work together.  He is a bit stern, and expects his children to grow up rather quickly, but he also manages to ensure that they do.  For his efforts, I award the next Ad Hoc Harley to:

This certifies that 
Steve Moore of the Mallinckrodt Institute of Radiology


Has hereby been recognized for outstanding contributions to the forwarding of Healthcare Standardization

Congratulations Steve, and here's to another decade of testing fun.  See you in a couple of days.

Wednesday, January 12, 2011

Convergence

Today's Q2 meeting in Templates with Structured Documents, Patient Care, Vocabulary and Tooling was a continuation of several discussions (of which my post on Triplets is one) that have occured over the week regarding templates, detailed clinical models and archetypes.  The focus of the discussion was the refresh of the HL7 Templates Draft Standard for Trial use.

The Templates DSTU was both a great success and a great failure for HL7.  It was successful in its ability to clarify what an HL7 Template is.  There are now over 1000 templates that conform to the HL7 definition of what an  HL7 template is, used in national and international programs all over the world, including the US, the EU, and Asia.  In fact, I've participated in the development of a set of more than 100 templates through IHE and HL7 that have been reused in national programs in those regions.  It's even the same set in those regions, which provides a remarkable amount of consistency in clinical information found in CDA documents.

The failure of the Templates DSTU is a failure not in the details of what a template is, but rather in the information that is used to keep track of it, locate it, vet it, et cetera.  The XML representation of that metadata has gone largely unused.  When we reviewed the Templates DSTU for the Template Registgry Requirements project, we found it lacking in several places.

We discussed working on some common definitions that would help us parse all of the terms that I mentioned in Triplets, and to define the concepts, identify super concepts, and describe the various differences.  So you could imagine that we would have the concept of an Archetype, and that would be specialized to describe HL7 based archetypes and openEHR based archetypes.  Similarly with Templates and/or Detailed Clinical Models.

The audience in the room was generally supportive of this idea, and there seems to be a general consensus that this would actually have value not to just HL7 but also to openEHR.  Apparently this is a shift in the relationship that has changed recently, spawned by nobody knows what.

A point which I made to the room.  We, sitting in the room, are the people who care about these distinctions.  To the average healthcare provider, they are meaningless.  It is to ALL our benefit to have a common way to describe these things that we ALL understand and to promote its use, because no matter what we call it, Doctors just want it all to work together.

In that veign, I learned of a remarkable piece of work done by Heath Frankel.  He was able to create a solution which took information from an HL7 Version 2 message, store it into an OpenEHR based repository, map from the OpenEHR structuire to the IHE Referral Summary, and then submit it to an XDS registry.  I've known about the technical feasibility of this for some time.  I wrote a few months ago on converting from Version 2 to CDA.  I've also generated CDA from several EHR database structures from several different vendor's systems in my career. 

I think about combining this idea with the notions that Robert Warden has about Neutral Mapping.  I can envision a world where their exists a neutral mapping between the OpenEHR Information Model and the HL7 Reference Information Model.  I believe this to be readily managable for a core subset that has yet to be determined.  If this were to exist, I can see ways in which existing OpenEHR tools could be used to benefit the development of HL7 Detailed Clinical Models and HL7 and IHE Templates, that clinicians could use.

I've recently seen some demonstrations of tools which already in use in this space, and after sitting down and putting all the pieces together, my brain just exploded.

I'm sure most of you by know are wondering if I'm headed into the Dark Side of openEHR.  Fear not, I still remain a huge fan and strong supporter of HL7 and IHE.  But what I see here are some possibilities and synergies in convergence that would greatly benefit all of healthcare IT.  The real challenge will be whether there is a way to truly take the best of both worlds forward.

Expressions in HL7 Data Types R2 and Computable Clinical Guidelines

The HL7 Structured Documents Workgroup met with Clinical Decision Support today to discuss some of the issues with the HL7 Quality Measurement Format that would need to be addressed in the next release.  Bob (Dolin) gave a quick update on the NQF status.  Apparently the Meaningful Use measures have all been converted to HQMF, including all the value sets in all the Meaningful Use specified vocabularies (ICD-9-CM and SNOMED CT) and are in CMS hands.  We heard that there may be some sort of comment / vetting process as a later phase.

The issue that Bob wanted to address is the way to represent an expression in a computational language in a measure.  HL7 Data types release 2 includes the EXPR data type.  This data type is an extension of a data type of type T which has one new component: expression.  An example representation of this is shown below:

‹value xsi:type='EXPR_INT'›
  ‹expression mediatype='application/javascript'›
    foo.value.value - bar.value.value
  ‹/expression›
‹/value›

Now, by itself, this isn't completely useful, but when you put it inside an Observation that you are defining, the expression can be used to define how the value is computed.  There are a couple of other things that you need.  One of these is a binding from the variables foo and bar above to specific classes.

The HL7 RIM has a way to create bindings for the derivationExpr component of the act class, but hasn't defined how to create bindings for EXPR_T.  I'd stick with using the same mechanism for derivationExpr.  What could be done is something like the following:

‹observation moodCode='DEF'›
  ‹value xsi:type='EXPR_INT'›  ‹actRelationship typeCode='DRIV'›

    ‹expression mediatype='application/javascript'›
      foo.value.value - bar.value.value
    ‹/expression›
  ‹/value›


    ‹localVariableName›foo‹localVariableName›
    ‹observation›
       ‹value value='1'›

    ‹/observation›
  ‹/actRelationship›
  ‹actRelationship typeCode='DRIV'›

    ‹localVariableName›foo‹localVariableName›
    ‹observation›
      ‹value value='2'›

    ‹/observation›
  ‹/actRelationship›
‹/observation›

What this essentially says is that the outermost definition of the observation has a value.  That value is computed from information contained in two other named classes: foo and bar.  These classes are then defined to be local variables representing the named observation classes. 

So, why is this cool?  Well, it's something only a geek could love.  What it does is provide a mechanism whereby we can bind an HL7 class represented in XML to a programming language like javascript (Bob wanted to use GELLO, but I can hand you a book today on javascript if you really need it.  And you can probably already figure out how to access the classes.

The next piece of this is that it allows certain computations to be defined based on the contents of other stuff.

What is missing from this is the binding rules that tell us how to evaluate the named portion of the expression.  I cheated by using the binding rules for derivationExpr, which are very simple.  Those rules state that the named variables are contained within in derived acts.  I could have used other binding rules, e.g., that the named variables are contained within some other set of named variables.

What I like about this is that it gives me the missing pieces needed to define a Structured Document for a Clinical Guideline.  Those two pieces are what I call level 3 and level 4 of clinical guidelines.

The structured clinical guideline in my head has four levels.  Level 1 contains a header comprised of metadata used to allow the guideline to be found in a repository of guidelines and human readable content as an attachment, e.g., PDF or XHTML.  Level 2 contains the information structured into sections where each section is addressible, coded, and has additional metadata describing it, along with human readable content in a format like XHTML.  Level 3 are the definitions of things that need to be tracked to manage the guideline (e.g., heart rate, ejection fraction ratio, blood preassure, comorbidities, et cetera).  Level 4 is a way to bind to ANY computational langauge, such as javascript (my preferred language for reasons of reduciong complexity).

So we never did get to discuss the idea of how to build this thing in clinical decision support like I had wanted to, because we could hardly get away from the discussion about how what Bob wanted was already in scope of VMR [sort of like swatting flies with a sledgehammer].  But now I know the pieces are there.  It's time to start thinking more about how to put this together.

And see, I don't even need to worry about the Gello, Arden, GLIF, ... debate because any mediaType will do as the computable language.  The standard need not state a preference.

So, it looks like there might be enough to define a quality process that has measurement built in.  One of these days, I'm just gonna have to take a class on that six-sigma thingy-ma-bob.

G'Night all.

   Keith

P.S.  They tell me that there's a foot of snow back home.  I hope you all are enjoying it.