Friday, July 29, 2011

2nd Public Comment -- Cross-Enterprise Document Workflow

IHE IT Technical committee has resolved public comment on the first draft of the Cross-Enterprise Document Workflow profile, and have determined that the changes are dramatic enough to call for a 2nd Public Comment.

This is a key core profile that will enable other use-case specific workflows to happen across different organizational boundaries. It sets forward a basic workflow 'token' system by profiling OASIS WS-HumanTask (the original public comment used CDA). This profile does not define any working workflow, but rather sets a framework that others will use to support HIE based workflows like Patient Transfer, Referral, and many long-term care plans.

This does NOT replace departmental workflows, although it might leverage a departmental workflow as one of the larger steps that are managed by XDW. This does NOT replace centrally managed workflows such as those controlled by BPEL, but might leverage a BPEL controlled workflow as one of the larger steps that are managed by XDW.  The XDW workflow may refer to an externally defined and possibly not computable workflow definition, but is designed to support evolution to completely enclosed and/or computable workflows.

IHE IT Infrastructure Technical Framework Supplement Published for Public Comment

The IHE IT Infrastructure Technical Committee has published the following supplement to the IHE IT Infrastructure Technical Framework for Public Comment on July 29, 2011:

·         Cross-Enterprise Document Workflow - Rev. 2.0 (XDW)

The document is available for download at Comments submitted by August 26, 2011 will be considered by the IT Infrastructure Technical Committee in developing the trial implementation version of the supplement.  Comments should be submitted at 

Thursday, July 21, 2011

GreenButton - a bad Marketing term for a good idea

I understand that a new concept was presented to ONC today called GreenButton (see twitter #GreenButton). I reacted strongly to the terse twitter posts (like there is anything other than terse on twitter). This exposed that GreenButton is simply an effort to enable the patient to choose to have their data available for research. ePatientDave posted a blog article.

I think the concept is fantastic. I think marketing it as 'greenbutton' is a bad idea. From the discussions I have seen this morning, the concept is simply to enable the patient to be active in pushing their data into research, studies, teaching-files, etc; without defining the standards that would be used to do this push. Where as BlueButton was both a patient empowering concept with a defined quasi-standardized file-format that was totally different than any open 'standard'.

I think that the greenbutton (wow, hard not to use the marketing term) would need to be an opportunity for the patient to choose which research projects will get their data AND if their data needed to be de-identified. I suspect they will almost always want their data de-identified, and this is why I want the patient to choose each research project. Because successful de-identification can only be done when the context of the research needs are understood.

When the push method is a Health Information Exchange, one could use the existing standards for consent to 'authorize research project X'. The act of the patient 'pushing' the greenbutton will need to be captured as an 'authorization' anyway. The standards we have been working on for Consent are not just for 'Consent' as we know it in the USA, but rather are broad enough to handle any privacy policy (with some stepping stone restrictions).

I like the concept, lets figure out how to make it happen. There is lots of actual work necessary to see it through. In many cases research is being done, without empowering the patient. Some providers are already empowering their patients. Most PHR services enable this kind of thing. I am a 23andMe participant and very much participate in the 23andWe effort. So, there is experimental efforts. Given time these experiments will shakeout the bugs/issues into solutions.

Wednesday, July 20, 2011

Standards - one more and we will have it right

xkcd seems to nail our space more often than not, of course the same can be said for Dilbert and many others. I think we are being watched, but this really means that we are just like everyone else.


Wes asks, over in Google+, "Would that we were so orderly in health IT standards and that we were moving towards simplicity."

I am sure that everyone is thinking their plan brings Health IT to simplicity, and I would even assert that each plan would succeed. The problem is we don't all have the same plan, thus your efforts to take us down your plan toward your simplicity takes everyone off of my plan toward my simplicity (metaphorically speaking you vs me). Multiply this by the 100 some plans in play, and we get a mess.

This is not specifically bad, because every individual plan has some specific perspective on the problem that exposes a specific need. It is only with these divergences that we get to see what the other plan has to offer. Ultimately we get course corrections that are good. Good examples can be seen in the standards around ‘documents’, going back to text documents (with various character encodings).

Unfortunately in healthcare right now, there are too many alpha-dogs that are unwilling to listen to others. Some are protecting their business-plan, some are wounded by history, some focus on the big picture, some focus on the minute details. Unfortunately in healthcare we don't have just a few big vendors pushing the market, we have 10s of thousands (this is not bad, just not helpful toward fast convergence). We also have intermediary payers that most other industries don't have, who also have an opinion. Unfortunately in healthcare we also have a strong influence by some luminary patients (this is also not bad, just not helpful toward fast convergence). Specifically these unfortunate facts mean there are many plans in play.

This is reality, we must accept and work with this reality. Best case we would use an open and transparent discussion among equals where these perspectives can be harmonized before we start developing. This is simply not reasonable. I hope for reasonable ‘good enough’ stepping stones that seem to head in the direction that most plans are pointing. Each step is an opportunity to re-evaluate both the horizon, present, and past. I see evidence of this behavior changing, I am hopeful that we are close to making a huge leap forward. Unfortunately we have 1000* that huge leap to go. 

Thursday, July 7, 2011

HealthIT standards Maturity vs Adoption

This week the HIT Policy committee had a meeting with an agenda item where Doug Fridsma and John Halamka gave a Briefing on HIT Standards Committee. I have been following these meetings closely, so it was rather surprising what this Briefing contained. As always I encourage everyone to participate, this is one of the only Transparency mechanisms that these FACA committees have (They claim to be Open with the open public comment at the end of each meeting, but these comments seem always to fall on deaf ears). John Halamka blogged his summary of this testimony.

One slide has come up over and over in discussions, slide 24. This slide seems to have appeared out of nowhere. I know that none of the groups I participate in were asked for input to it. There is no explanation of the axis, but they were verbally explained. Not too surprising. Maturity is related to how solid the specifications are and includes if there are implementation guides available.

The concern I have is with the Adoption definition. I am hearing the same concern from others as well. The problem is that the Adoption measurement don't seem to be being applied equally to each item. The REALLY BIG PROBLEM is that there seems to be no way to correct the chart. Now that the chart has been presented to the HIT Policy committee, it will now be considered fully correct. Now, I don't have too much in the way of corrections, but I would like to see an OPEN and TRANSPARENT analysis.

I understand how "Direct Transport" is being looked at as "SMTP", and easily agree that SMTP is very mature and widely adopted. But if we look at how a Direct ecosystem is built, this is not enough of a picture. We must also think about the support transport for all of the Direct Specifications and specifically how well these are implemented in Healthcare workflows. Saying that "SMTP" is highly adopted doesn't mean that "Direct" is highly Adopted. Until the transport is integrated into Healthcare workflows we must recognize this as pure pilot projects and pure pilot use.

I really don't understand how the "Direct Security" is put into this space. The HIT Standards, HIT Policy, S&I Framework, and others are still arguing over certificate distribution; something that will take a long time to argue over due to the need to have the certificates before you communicate.

Where as the NwHIN Exchange specifications seem to be split all over the pace. I am surprised at how the Query could be less adopted than the Retrieve; especially since the only way to Retrieve something is to have previously Queried for it. Thus one must implement Query at the same rate as Retrieve.  I and others on the NwHIN Exchange calls expressed surprise at the NwHIN Exchange evaluation. Somehow all the participation in the NwHIN Exchange is discounted as LOW:

From the NwHIN Exchange site -- Participants (as of 6/13/11):

And that list is short, as GE Healthcare participates through my direct participation and indirectly through a set of State based Health Information Exchanges such as KeyHIE.

Please give us a way to provide input. Please allow us to participate in an open and transparent process. There is such positive movement, why is it always ignored?