Where there is smoke ...

... There are Chocolate-Covered Bacon-Wrapped Smoked Twinkies

A few weeks ago I got a Vertical smoker for Father's day.  Over (smoked) dinner later that week we somehow got on the topic of disgusting fair food, things like chocolate-covered Corn Dogs and fried Twinkies.  And then the topic of Smoked Twinkies came up.  Of course everything is better wrapped in Bacon, so it became Bacon-wrapped smoked Twinkies.  And then chocolate-coated, bacon-wrapped, smoked Twinkies.

As my daughter will tell you, perhaps the scariest thing about these were that they actually didn't taste that bad.  And from this experience (never to be repeated), we also learned that smoke-flavor imparted into cake can be good (Vanilla ice cream on smoked pound cake turned out pretty well as a follow-up).

As an experiment, it was completely ridiculous, very easy to perform, and resulted in some interesting results that had been completely unexpected.  The cost was virtually nil, and I learned a great deal about my smoker just doing it.  This is much better than spoiling a $60 piece of brisket on a first attempt (that didn't happen either fortunately, it was wonderful).

The point of this post is that sometimes you have to be willing to try an experiment on something complete stupid.  There's value in that because there is no danger that anyone will ever tell you to ship it, and you can still learn a lot just by doing.  And you can throw a bunch of things at it just to see how they would work together.  And if it fails, you never expected it to work anyway, so there's no real disappointment.

[Aside: How many developers have had the scary experience of showing a weekend prototype to a product manager only to be asked how soon you could ship it?].

The trick is to do the best job you can anyway, just to see whether there is something in this completely idiotic idea.  When I smoked the Twinkies, I left a couple of them bacon-unwrapped, just so I could see the difference the bacon made.  When I chocolate covered them, I also covered only the bottom half, again to compare with Bacon alone vs. Bacon and Chocolate.

When I design a form (e.g., for an EHR), I often throw in some features to see how they work together with the form.  Chocolate coating as it were.  But I also leave myself an easy way to see how the form works without them.  Profiles and standards often have some optional bits to, because we aren't sure they'll be needed all the time.  When I implement a standard, implementation guide, or IHE profile, I try to include the optional bits if I can.  It's only when it becomes challenging (doesn't taste good) that I ignore the option. As it turns out, all variations of the Smoked Twinkie were edible, and some (like me) even liked them, although others (like my daughter) would never admit that.

And if, as in my Twinkie experiment, you actually learn something other than how to work with the tools, it was worth more than you expected.  If it doesn't, it was at least something you could chalk up to experience and pass the story along to your colleagues amid gales of laughter.

     Keith

P.S.  How does FHIR fit into this?  Attending my first FHIR Connectathon was just one of those throw-away experiments.  Now I'm a believer.  You should try it at least once.

This is not my Job

So, this morning I got a query from a colleague about a specification that is being developed for one organization that I volunteer with, regarding information that I have expertise about based on another organization I volunteer with.  We have a pretty good working relationship and regularly ask each other quick questions, and sometimes not so quick questions based on each other's expertise.  We are also working collaboratively together on yet another project.

It isn't my "job" to answer those sort of questions.  But it sure makes my life easier when my questions are answered.  And there's no benefit to me from holding back on this information, because it is readily obtainable from other sources.  Frankly, even the longer questions aren't anything anyone could reasonably bill a client.

This Quid Pro Quo exchange goes on all the time in standards development.  It is what makes my job (and the job of anyone like me) possible.  After all, there is simply no way I could be expert in so many places. And so, I'm thankful for it, and hopefully gracious in answering those quick (and even not-so quick questions).  After all, there is no benefit to developing standards if they are only used by a single organization.

   Keith

P.S.  Actually, my self-professed job description includes educating industry about Health IT standards, so really it IS part of my job, just not an obvious one.

HL7's First Payer Summit

This just crossed my desk. Since I'll be at the event, I thought it was worth posting here ;-) Keith

---

Don’t Miss the HL7 Payer Summit Jumpstart your interoperability initiatives with this value-packed event Sept 18-19, 2014 • Hilton Chicago, Chicago, IL   More than just a set of standards for data messaging, HL7 is a family of technologies that provides a universal common framework for interoperability of healthcare data. Using HL7 technologies speeds time to launch and lowers the cost of development for interoperability initiatives aimed at improving outcomes, lowering operating costs, and achieving other critical strategic goals for your organization. This program was created specifically with payers in mind. The two-day summit features influential industry speakers offering strategic direction and practical information on interoperability for healthcare payers, including hot topics such as ADT, mobile health, the regulatory environment and the HL7 FHIR® standard. Schedule at a Glance   Thursday, September 18, 2014 9:00 – 9:45 am What is the HL7 and Why Payers Should Care 9:45 – 10:30 am Industry Adoption and Use of HL7 Standards and Transactions 10:30  – 11:00 am  Break 11:00 – 11:45 am ADT Case Study 11:45 – 12:30 pm HL7 Clinical Exchange, Quality and Population Health Challenges 12:30 – 1:45 pm Focus Group Lunch (Sponsorship Opportunity) 1:45 – 2:30 pm Panel Session on Care Coordination, Patient Centered Medical Homes, and ACOS 2:30 – 3:00 pm Payer Challenges in the New Patient Centered World of Health Information Exchange 3:00 — 3:30 pm Break 3:30 – 5:00 pm One Tree, Many Branches: Making Sense of Today’s Growing Regulatory Environment Friday, September 19, 2014 9:00 – 10:30 am  The Mobile Health Revolution 10: 30 – 11:00 am Break 11:00 – 12:1 pm Why All the Buzz About FHIR®   Event Pricing Members of WEDI and AHIP receive the member rate   Member: $400 Non-Member: $600   Save the date for this new program created just for payers! Registration opens next week. Watch the HL7 website and your inbox for more details soon.

That XML Schema is NOT the HL7 Standard you are reading

With very few exceptions*, HL7 Version 3 standards are models of interactions and information exchanges using messages between various applications acting in different roles in the system.  The HL7 Development Framework then automatically applies rules about how the interactions identified by the model are expressed in XML Schema using the HL7 Version 3 Implementation Technology Specification. That specification relies a bit further on the HL7 Version 3 Data Types (pick any of three releases) for expression of the basic data types in the message.

So when a committee like Patient Care or Orders and Observations creates an HL7 Version 3 standard, they are defining the information content of the exchange, NOT THE XML SCHEMA.  In fact, the XML is NOT the normative definition of the standard that they are producing.

As the XML ITS (Release 1) says of itself:
This document describes how HL7 V3 compliant messages can be expressed using XML. It describes how the definition of the set of valid XML instance documents is derived from a specific HL7 Message Type. It covers ISO levels 5 and 6. Those familiar with V2 might call these the "XML encoding rules" for HL7 Version 3 messages.

So, if need be, someone could create a JSON ITS, or a UML ITS (it used to exist), or a JSON ITS, or a Python ITS.  If you don't like the XML, the opportunity exists to improve it, but the XML itself isn't the standard.  The artifacts you will find in a V3 standard include:

• Story Boards
• Application Roles (which are Informative rather than Normative at this time [still])
• Trigger Events
• Interactions
• Domain Message Information Model (D-MIM)
• Restricted Message Information Models (R-MIMs)
• Hierarchical Message Descriptors (HMD)
• XML Schema (which are not Normative!)

The XML schema is derived from the HMD based on rules defined in the XML ITS.  The HMD is derived from the R-MIM, which are models used to implement an Interaction which is defined based on a set of application roles interacting according to a storyboard based on the occurence of a trigger event.

Thus, the HMD is the "normative" description of the messages being defined by the standard, and it is another HL7 standard (the XML ITS) which turns the HMD into something that can be used in an implementation.  If you don't like the HL7 XML, you could develop another ITS. Some work groups are trying to do so and just not figuring out how to make their ad-hoc XML content actually be algorithmically derived from a RIM-based model.  I'm not too worried about these efforts, or efforts to create a JSON based ITS or any other ITS for that matter.  From my perspective, that's the old way of doing things, and I want to see how we could do it on FHIR.

     Keith

* One HL7 Standard is a big exception to this rule, and that is CDA Release 2.0, which in its conformance section says: A conformant CDA document is one that at a minimum validates against the CDA Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains.

Where will you be in five years?

This is a question that I ask myself from time to time, and I imagine myself, five years hence, and make up stories about where I am and what I'm doing, and how I got there.

This question is especially relevant to Health IT folk at this time, as we are presently in an era of unprecedented EHR and Health IT adoption.  This isn't just a US perspective, but also an International one. HL7 is also at a cross-roads, as I've mentioned in my previous post (see The Future of HL7).  Just for fun, here is an imaginary day in the life of "Motorcycle Guy", on the eve of July 4th, 2019.

I've just finished making travel arrangements to the Second Quinquennial Health IT Conference to be held in (semi-exotic location).  It's a week long conference in which members of CDISC, DICOM, HL7, IEEE, IHE, ISO, OpenEHR, WHO, X12 and others, along with national standards organizations and professional societies from all over the world join together to develop an international Healthcare standards strategic plan.

I'm part of the US delegation as a member of recently formed US Standards Collaborative.  It's a public/private partnership thingy with ONC, CMS, et. al. providing a chunk of the funding (and thus getting to drive some of the agenda), but also has significant vendor and provider engagement.  It sort of evolved in some ways out of the Direct Project and subsequent ONC driven S&I Framework initiative, and later formation of HL7 USA, almost by accident.  You see, after HL7 USA was created, when ____ suggested that it and ___ get together and do something, and those two organizations decided that it was a good idea to get together, a few of the other US based SDOs got a little concerned and decided that they wanted in (rather than trying to break it up).  It got a little bit messy for a while, but eventually everyone agreed that it would be better to work together, and so now we have our own collaborative.

There was enough momentum in that activity to get ___ and ___ to reach out to ___ and ____ and thus we had what's now know as the First Quinquennial Health IT meeting in Geneva (it seemed like a safe place to have it at the time).  We actually had a pretty good turnout, something like 500 of the top Health IT, Standards and Informatics people from around the world.  All we did was talk to each other, ... oh, and we agreed on one thing, to do this again in five years.  Since then, there's been a large number of collaborations that probably wouldn't have happened if we hadn't had that first meeting.  There's not really anything formal about the way that works, but the idea is that if we simply get together and bound around some ideas about what we do.

Anyway, it should be fun, and it will definitely take my mind off the question I've been asking myself lately: "What do you want to do when you grow up?"

So, it's an interesting little exercise, and I suspect some of the ideas that I get when I do it are just a bit far afield.  But at least it makes for some interesting daydreams.

What Happens when the Funding Goes Away?

There are three ways that standards really happen.  One is when a bunch of organizations get together to solve a mutually challenging problem and develop something, like CDA or HL7 Version 2. The other is when a bunch of organizations discover that a particular piece of technology works to solve a problem and decide to make it a standard (e.g. Schematron or PDF).  The third way is when a single organization decides that a standard should exist and funds the development of it.  Large (usually governmental, but not always) organizations do this sometimes.

The question that concerns me about the latter is what happens when the funding goes away.   I've seen this occur already in some funded "meaningful use hopeful" standards projects (projects hoping to get a line a in the reg at some point).  The interesting thing is what happens when the funding disappears.  Momentum gets lost, sometimes enough that the standard itself might never really get finished, or implemented, or used.

Look at Direct for example.  it is certainly suffering from the lost momentum problem.  Was it worth it?  Given that Direct got the MU mention it was after, it will probably succeed.  But is the artificial stimulus the best approach?  Maybe, but maybe not.  I don't know what other levers to pull, but I'm surely looking for them.

The Future of HL7

... is looking pretty rosy right now, at least from a leadership perspective.  There are three excellent (in my opinion) candidates from which to choose the next HL7 Chair,

• Calvin Beebe of Mayo, long time co-chair of Structured Documents, past board member and current treasurer.
• Dough Fridsma of ONC, Chief Scientist at ONC and former Director of the Office of Standards and Interoperability.
• Me

I'd be hard pressed to choose between Doug and Calvin if I weren't running myself, but I am, so my decision is easy.  Yours is perhaps a bit more challenging.

Elsewhere you can read my profile, and see my work experience.  Here, I'd like to talk a little bit more about my vision for HL7.

HL7 as an organization needs to change.  It needs to become more Internationally focused so as to streamline efforts globally, and at the same time, it needs to find a way to become responsive to national initiatives which need HL7 standards.  It's been more than a decade since I joined and first heard the phrase "one member one vote", and while we have made progress on that front, we still haven't achieved that goal.

At the same time, we've taken a tremendous shift towards implementers of our standards, with initiatives such as freeing HL7 IP which I've been a part of, and in the development of implementer specifications like FHIR, which I've also been a strong supporter of.

So, why would you vote for me?

HL7 will be a different organization in four years.  That isn't a promise, nor a prediction, it's a simple fact.  I think the organization needs leadership that recognizes the need for change, and that is willing to act in bringing about that change.  We've made some pretty good changes in the past couple of years, but the momentum needs to increase.  We haven't stopped changing, and to grow, we need even more.  We need to complete the journey of one-member one-vote that we started a decade ago, and we need to complete the major transformation of the business model of this organization that started with our free IP initiative.  In some ways, we also need to return to our roots of developing standards for those who implement them, and focus on our customers.  You should vote for me if you think I'm the right person to lead those changes.

   Keith

P.S.  And if you feel like Doug or Calvin is the right person, you should vote for them.  Like I said at the beginning of the post, there are a lot of great choices available.