An open letter to members of the HL7 Board

I am asking for your support in the upcoming vote to appoint the incoming chair.

Shortly you will be making an important decision for HL7, which is who will lead the organization in the coming years. It’s an unprecedented decision for this Board to make, but I certainly understand the circumstances that brought it about. I also realize that you would probably rather not be forced by our organizational bylaws to be making the decision that you are now faced with.

We are truly faced with bigger crises in governance ahead. While HL7 FHIR®™ has taken off, and HL7 has also established itself as a leader in many national programs, we are faced with several challenges in the near future.

• For the most part, we are still responding to trends rather than being ready for them or better yet, creating them.
• The evolution of HL7 as an organization has been a painful and slow process, now accelerating as a result of many years of effort. However, it is still unclear how our future business model should evolve.
• Participation of the International community in HL7 governance is still a major concern of many members. We’ve been working on that for a decade or more with little substantial change.

On the flip side, we have received a great deal of increased attention due to success of many HL7 initiatives:

Freely licensed standards FHIR  Consolidated CDA

Quality Improvement Mobile Health Payer Summits

We cannot rest on these successes. Collectively we need to understand not just how to take advantage of and respond to emerging trends, but also how to be setting them. Our attention five years ago to taking a “Fresh Look” at HL7 produced amazing results with FHIR. When the trend emerged towards open APIs, FHIR was standing in the wings. As a result, it produced an unanticipated re-invigoration of interest in HL7 from the Health IT community.

We need to institutionalize this success, and be ready with the standards when the next trend occurs. We need to become known not just for the standards that meet emerging trends, but for creating them in our industry. And not just in my home country, the US, but also internationally.


Some of you I am certain have also thrown (or had your name thrown) into the ring with me. I know almost all of you personally, and am certain that you too have a vision for making HL7 a successful organization. I am also certain that you will do a good job, and if you are appointed to the role of incoming chair instead of me, I offer you both these thoughts, and any assistance I can provide in bringing them about.

        /S/

     Keith W. Boone

P.S.  For those of you not on the board, you can find the board members here. Feel free to contact them and tell them your opinion.

Catching Up from Paris

Between driving through storms, reaching my vacation spot, getting over more storms there, and then heading off to Paris for IHE meetings, I've not spent any time here too long, so I'm overdue.

IHE PCC has been looking this week at Workflow, Remote Reading for Radiology, CDS for Radiology and our newly christened accompanying component call Guideline Appropriate Ordering (GAO).  We've also looked at Remote Patient Monitoring, which is simply Continua's framework recast as an IHE profile, and what is now known as Clinical Mapping (CMAP).

GAO is looking at different ways to integrate the ordering process with clinical decision support in a lightweight way.  One proposal is to use RFD with a CDA document, the other, is to develop a FHIR service endpoint which accepts the proposed order, some clinical and demographic data, and responds with a classification of the proposed order (in guideline, not in guideline, no guideline available), and possible alternatives, along with an "authorization".  This is principally to support the requirement that certain imaging orders be accompanied by an evaluation of appropriateness of the order by 2017, or no payment will be provided.  However, we can see already how this can be applied to the Order Placer and Order Fillers in Laboratory, Pharmacy, Cardiology and other profiles from other domains.  It can also support prior authorization, and a few other possibilities.

The CMAP profile will likely use FHIR's ConceptMap resource and the $translate operation it provides to map from IEEE to LOINC (using the Device Mapping option), or SNOMED CT to ICD-10 (using the Billing Option).

I've got way too many balls in the air, this year, as I'm basically working on every topic.  Somehow I thought my "retirement" as PCC Cochair would be easy.  I just dropped the IR and rearranged the remaining letters to become coach.

The BPMN work went through a brief review of standards in the early part of the week.  Admittedly I did a small amount of market research before settling on BMPN, and got called on it.  Mostly I relied on the opinions of other experts I highly trusted not to steer me wrong.  Fortunately, I came prepared with a good deal more for this meeting, and we did rightly (I think), settle on the standard with the greatest Market awareness (2-3 times more than its closest competitor), if not penetration in the Healthcare space.  So, it's still based on BPMN, which is good.  The other thing we did was look at whether we wanted to make this a profile.  We decided against it on two counts: The DSUP CP 613 being processed by ITI addresses one of our issues.  Secondly, the other reason would be to get actors to use BPMN, and we want to make sure we get the BPMN right.

In other activities, we came very close to resolving our long-standing PCC-0 issue, the missing Document Sharing transaction (which we will call PCC-1).  I have a few more edits to make to that CP and we'll be ready to send it out for broad review.  Lastly, we have some actor cleanup to do.  We discovered we had 26 different actor names in PCC, and we figured out how to clean a lot of that up by updating workflow profiles.

The newly proposed common names for workflow participants are:
Service Requester
Service Dispatcher
Service Scheduler
Service Performer
Workflow Monitor
Workflow Manager

Only a couple of workflow actors don't merit one of these names, so they have one-off actor names which may also be renamed to be more reusable [BTW: The difference between the Service Dispatcher and the Service Scheduler is that the latter needs to look at a resource calendar, the former does not].

So, the week is rapidly coming to a close, and I'll have more to report tomorrow night.

The Best Standards are International

What prompts this post is the fact that I'm preparing to head off to IHE meetings in a week in Paris, and that HL7's May Working Group meeting will also be in Paris this year.  The challenge for many people involved in standards development is the cost of participation.  US participants have it easy, because so many IHE and HL7 meetings are held somewhere in North America.  I'd say close to 90%.  And I'd guess about half of the DICOM meetings are held here too.  So complaints about the cost of travel fall on deaf ears in the International community, as they well should.  Most of them have a much greater expense than we here in the US do.

However, if we really want standards to be international, we have to realize that the US covers less than 5% of the world's population, and 25% of the world's GDP.  So if we (speaking as a US citizen) want the rest of the world to be using the same standards as we are, we need to reach out.  That means going out to International locations to create those standards.  I hope that future ONC plans on standards development address the need for standards to be international, and plan for international travel.  It drive me crazy that some of the best international standards efforts going on right now (e.g., FHIR, which was first launched by an Australian, and strongly led by a European and a Canadian) will be missing key participants from the US because they are "Federally" sponsored.  If, as a nation we want more respect in the international standards community, we need to stop acting in such an insular fashion.

I'm truly sorry that some of you cannot make it, or that to be engaged, some of you might have to be getting up at 3am. But I'm not apologetic at all that these activities are happening Internationally. Yes, I do understand it is expensive, and it has just as much a negative impact on my budget as it would on yours.  But it is what is necessary to ensure that the standards that are being developed are agreed and used to worldwide. Otherwise, our healthcare interoperability efforts will be just as successful as the Mars Climate Orbiter.

   Keith

P.S.  For those of you who can make it, thanks for making the effort.  For those of you who cannot, this is NOT directed at you, but rather the decision makers who won't let you.  Because I know most of you want to be there.

A new Mission for HL7

Last year the HL7 Board somewhat quietly changed the organization's Vision and Mission:

HL7 Vision

A world in which everyone can securely access and use the right health data when and where they need it.

HL7 Mission

HL7 empowers global health data interoperability by developing standards and enabling their adoption and implementation.

Compare the new mission to the previous one:

HL7 provides standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients. In all of our processes we exhibit timeliness, scientific rigor and technical expertise without compromising transparency, accountability, practicality, or our willingness to put the needs of our stakeholders first.

The old mission was rather a mouthful, and threw in everything but the kitchen sink; likely to please all stakeholders.  The new mission is rather concise.  It has two parts:

1. Develop standards
2. Enable adoption and implementation of standards.

This is almost the way I describe my day job:

1. Develop standards
2. Promote their use in industry
3. Teach standards

I don't think HL7 needs to do much different to be able to declare success in developing standards. On adoption and implenentation, we've seen some remarkable changes to the organization as it restructures to play with FHIR (all FHIR puns are intentional).  The growth in services to improve implementation (the help desk, remote education, the CDA examples task force), all illustrate ways in which the organization is responding to support implementation.

The last piece we really need to focus on within HL7 today is that word "Global". FHIR originated in Australia (via Grahame Grieve). The FHIR chiefs come from Europe and Canada. HL7 needs to restructure itself to better support the adjectives "global", "worldwide" and "International" that we like to throw around.

I acknowledge that such a change is scary, but I also think it is extremely necessary if HL7 is to remain relevant in the remainder of this century.  If we, as an organization, really want to take over the world, we better understand the needs of that world that we are asking to give us responsibility for.

Over the last four years as a member of the HL7 board, I've worked towards making HL7 focus more attention on its key audience, implementers; supported efforts to make the standards accessible to them; and have been working on new business models and structures to help the organization grow and become more international.  I'd like to continue that work as incoming chair.

The current process for adopting an incoming chair is governed by the organizational bylaws, and those bylaws state that for every office other than Chair (Chair-elect is NOT chair), the board must appoint a replacement.  I suspect that a bylaw change is already in process to adjust that process. We've frankly never encountered a situation (in my memory) like we have today, where the chair-elect has resigned.

What you can do is let the HL7 Board and the HL7 Executive Committee know that you would support me in that role.  To do that, simply nominate me here.

HL7 Process for Filling the Chair-Elect Office

This crossed my desk this morning. Even though it isn't a formal election, I have already submitted the requested papers, and would appreciate your nomination.  I'll catch you up tomorrow on why I still want to be the HL7 chair-elect.

     Keith

---

Health Level Seven^® International

Unlocking the Power of Health Information

---

An ANSI accredited standards developer

February 11, 2015

FR:       Stan Huff, Chair, HL7 International

TO:      HL7 International Membership

RE:       Doug Fridsma’s Resignation and Process for Filling the Chair-Elect Office

Dear HL7 Members:

Last week, Doug Fridsma tendered his resignation as HL7’s Chair-Elect. Given his new role as AMIA’s CEO, Doug feels that his resignation will allow for greater collaboration between the two organizations. We appreciate Doug’s contributions to our Board and the HL7 organization during the last several years and respect his decision on this issue. We must now undertake the task of filling the Chair-Elect position.

According to Section 06.02 (Officer Vacancies) of the HL7 Bylaws, officer vacancies, other than HL7 Chair, are to be filled promptly by a vote of the HL7 Board of Directors with the appointee completing the open term of office.  While appointing a replacement is clearly a Board responsibility, the Board understands the importance of this decision to the organization as a whole.  Therefore, the Board is seeking input from the membership regarding candidates who should be considered to fill this vacancy. To gather this input, we have opened a Nominations site on the HL7 website at:

http://www.hl7.org/memonly/vote/nominate.cfm?electionCode=BODOfficers
(Access the link directly from the HL7 Homepage under the News & Announcement heading)

During its February 9 call, the Board voted unanimously to use the process outlined below to appoint the Chair-Elect:

·         Nominations shall be accepted online only from February 11-24. Individual members of HL7 International and designated voting representatives of current organizational and Affiliate members are eligible to submit nominations. Nominees must meet officer requirements as outlined in the Section 06.01.02.02 of the HL7 Governance and Operations Manual (GOM) but will not be required to secure 10 nominations. Staff will validate that nominees meet the requirements and are willing to assume the office of Chair-Elect if so appointed.

·         Nominees shall submit the required paperwork (Profile, Conflict of Interest Disclosure Form, Board Commitment Form and Board Nomination Confirmation Form) by February 24. Nominees failing to submit the required paperwork by February 24 shall not be considered. Note: required documents are attached)

·         Because this is not an election, the Nomination Committee shall not be engaged.

·         An Executive Committee call shall be convened on February 25^th to review the nominations and to make a recommendation to the Board.

·         The HL7 Board shall convene on March 2^nd to vote on the chair-elect appointment, which will be promptly announced to the HL7 membership

·         The newly-appointed chair-elect shall assume office immediately.

The timeline is provided below:

Date	Activity
Feb 11-24	Nominations accepted
Feb 24	Deadline for nominees to submit all required forms
Feb 25	EC call to review nominations and recommend candidate for appointment
March 2	Board vote on appointment; announcement to membership
March 2	Newly appointed Chair-Elect assumes office

We appreciate the membership’s input and seek your patience as the Board undertakes this important decision on behalf of the organization. Please feel free to contact me directly should you have questions or concerns.

Sincerely,

Stan Huff, MD

Chair, HL7 International

Stan.huff@imail.org

                                                                                               

Karen Van Hentenryck

Associate Executive Director

Health Level Seven International

3300 Washtenaw Avenue, Suite 227

Ann Arbor, MI  48104

734-677-7777 x104

www.HL7.org

March 2015 HL7 FHIR® Institute & Meaningful Use Standards Implementation Workshop
March 16 - 19, 2015
DoubleTree by Hilton Hotel & Suites in Pittsburgh, PA
Register Now!!

May 2015 International Working Group Meeting
May 10 – 15, 2015
Paris, France
Register Now!!

Let it Snow

I don't know what it is about snowfall that makes the ice dam leaks want to flow into and out of electrical sockets and lighting connections in my home, but I sure wish it would stop.  Tomorrow I have a professional coming to remove my ice dams to mitigate the problem.  I just couldn't keep up.  I don't have the equipment, the training, or the where-with-all to de-ice my roof myself.  And of course, I didn't do my gap assessment on the attic insulation on the new place because  I have no attic access (but I will soon).

I couldn't predict this would be a problem, because I couldn't even see the symptoms until too late.

Right now, I cannot even get inside to see where my problems really are, and what I need to do to fix it.  And of course, this is not really the most ideal time of the year to do some of the work necessary. Parts of it I already know ... the roof needs some work (that was figured out during the home inspection). Other parts are that this is (even for us), unseasonably snowy.

I've never had this problem before with other homes that I've lived in, how could it hit me now? 

Well, clearly I've lived in homes that have better insulation, or snow shedding characteristics.  This is a pretty well known problem. Ignoring the risk because I've never experienced the problem before isn't really an excuse.

According to various news sources, this is the 10th snowiest season on record. The average snowfall around here for the season is three feet.  We've had that in the last two weeks, and twice that in the last 6 weeks.  So, it was fairly predictable that I'd encounter a snowfall like this at least once living here.  Read on...

This is a once in a lifetime event, I couldn't be expected to protect against that, could I?

Well, actually, this is apparently a one in ten year event so far.  And I remember several similar snowfalls in the past two decades of living here.  So that excuse doesn't cut it.  Even if it did: A few years back my neighborhood suffered a once-in-a-century flooding.  Fortunately for me, I had a few basement tiles pop due to moisture, but others had fully flooded basements (two feet or more of water), causing thousands of dollars in damages.

I can't afford to protect against every risk!

A flood insurance policy covering building and contents that would have covered that kind of damage I just mentioned would cost something like $200 dollars per year.  The chance of a once in a century flood occurring in the ten 17 years I lived in that home is something like 1 in 6. Would a flood insurance policy have been worth it?  With 20-20 hindsight, I'd say, probably not, because even the once a century flood wasn't enough to cause me concern.  But assuming it was, it would have been worthwhile. And certainly was my immediate neighbors, on the North, South and East of me in my old neighborhood. They suffered several thousand dollars of damage, enough to easily cover the cost of insuring against flood.

Which would you rather have: a 100% chance of a $3000 expense or a 10% chance of a $30,000 dollar expense? They are approximately equally valued (the cost of money has some impact).  If the trigger for the $30,000 expense is going to have ripple effects, consider that as well.

Now, imagine if you will that instead of my home, I'm talking about a data center.  And instead of snow, I'm talking about a concerted attack against the data being stored there.

Who's whining now?

BPMN and Actor/Transaction Diagrams

In all of my playing around with BPMN it's become apparent that it has a number of different uses for IHE profiles.  One of them is to represent actors and transactions.  Here are two views of IHE Radiology's Scheduled Workflow B Profile:

The IHE Actor/Transaction diagram on the left from SWF shows you what the different actors do in the profile.  The collaboration diagram on the right does exactly the same thing. I chose SWF because it's one of the more complex IHE profiles, and I can still capture the detail in almost the same amount of space.  The nice part about the latter component is that the collaboration diagram is computable. I've even embedded the documentation for the actors in the BPMN diagram.

One of the things that's missing from BPMN is a way to indicate which messages (IHE calls them transactions) in the workflow must be supported by the sender and receiver.  This isn't reflected in the Actor / Transaction Diagram that IHE uses either, but does show up in the Actor/Transaction Table that follows it.

BPMN can actually handle this with extensions, as I show in the following example:

    <bpmn2:messageFlow id="MessageFlow_2" name="Patient Update [RAD-12]" sourceRef="#Participant_1" targetRef="#Participant_2">
      <bpmn2:extensionElements>
        <ext:style/>
        <ihe:supportRequired ihe:source="Required" ihe:target="Required"/>
      </bpmn2:extensionElements>
    </bpmn2:messageFlow>

And if I could actually figure out how to use the BPMN Model editor in Eclipse, I might even be able to create this extension without having to edit the XML directly.  At this stage, it looks like I could capture a good deal of IHE Volume I content in BPMN.  I could go a step further and represent some of the use cases in BPMN models.  At this point though, I could see how a model driven development tool could be created for several different types of IHE profile.  I'm unlikely to take this further (at least from the IHE perspective) unless there is some interest in further developing the material further.

    Keith

Device Clinical Bridge

After a couple of months of slacking off (you know, doing stuff like HL7 Ballots, going to the working group meeting, IHE Connectathon, and Radiology workgoup meetings), PCC members are preparing for our meeting in Paris.

I think I have four things on my plate, one of which is workflow, the other deals with CDS for Radiology, one supports existing Continua work I helped out with a half-decade ago, and the last of which is integrating clinical devices with an EHR.

We had our first call for a while on the Device Clinical Bridge work that PCC agreed to do. The work on the device clinical bridge really amounts to how we can adapt a PCD-01 inbound message to terminology that supports EHR adoption.  When you get right down to it, the biggest challenge is the terminology mapping.

For the bridging work requested for this profile, the challenge is to convert PCD-01 messages using IEEE nomenclature (so-called MDC codes) into equivalents using LOINC, that being the preferred vocabulary for certain kinds of measurement under Meaningful Use.  In other cases, we could see the need to translate from ICD-9-CM codes to ICD-10-CM, or from SNOMED-CT to ICD or vice verse. There are also cases where you might need to translate from NDC to RX-Norm, or again, vice verse. You might also use such a facility to translate from local codes to standardized code sets.

From an actor/transaction perspective, I see
In looking at the available standards, I found three possible candidates:

• HL7 Common Terminology Services Release 1
• HL7 + OMG Common Terminology Services Release 2
• HL7 FHIR ConceptMap Resource

In addition, a simple extension to IHE SVS could also have supported the required capability for the Device Clinical Bridge, but would likely have been insufficient for other uses.

In looking over these specifications, I came to the following conclusions:

1. CTS Release 1 doesn't readily support all the mapping requirements, and has also been replaced by CTS2.
2. CTS Release 2 does support the mapping requirements, but implementing it would be a bitch.
3. The current FHIR ConceptMap resource supports what is needed. but the translate operation isn't quite there yet.

I can pretty much rule out CTS1 for a number of reasons, including the fact that it doesn't fully support the requirements.  We'll have to look at CTS2 and FHIR's ConceptMap.  Honestly, CTS2 suffers tremendously from over-engineering, and while we could profile it down to something reasonable, I'm just not convinced that it would be readily adopted.  FHIR is in much better shape, but we would be waiting for the next DSTU release for this operation.  There's a little bit missing here, in that the context (dependson) for the mapping cannot be specified in the operation.  A little tweak is all that is needed to make that work.

This is especially needed to handle concept mapping from IEEE codes where the units are necessary to fully specify the resulting LOINC code in the principle use case.  I can also see other cases where additional concepts might be necessary for ICD-9-CM to ICD-10-CM, or in other mappings.

   Keith

Workflow stands alone

I do stuff for a while, and as I do it, eventually I realize that I develop a method.  Over time, my method evolves into what I consider to be a set of best practices and principles.  Often I've internalized these without even thinking about it.  And then somebody says something, and words come out of my mouth explaining why I do it this way.  At which point I finally realize that there is a method to my madness which I've just shared with myself and others, sometimes to my own surprise.

Yesterday, in discussing the Remote Read workflow being developed in IHE Radiology, I was asked a question about the infrastructure being used for XDW.  "We know the infrastructure is XDS," I said, "but I ignore that when crafting the workflow.  IT Infrastructure is presently working on making XDW work with XCA and XDR (and maybe even XDM).  We don't want to get caught up in the infrastructure"

Later: "So your tasks should always have as inputs everything they need to complete, even if you don't always use them.  This is because you might not have an XDS infrastructure to go back to get information about a preceding task in the workflow.  So the task needs to know everything when it gets notified."

And "We don't put any Service Level agreements in this workflow, that's policy stuff we enable with it. Implementers can argue about it later. That's not our problem."

Then there was my morning realization today: The main point of an IHE workflow profile is independent of the underlying implementation technology altogether.  It's the definition of the tasks, roles, and inputs and outputs that is critical.  If well defined, a workflow task can be integrated with multiple technologies, and still work.  In other words, an IHE Workflow profile should be able to stand by itself, without needing an infrastructure like XDW to be implemented.

Like IHE Content profiles, which can work with IHE profiles like XDS, XCA, XDR and XDM, but which can also work with technologies like Direct and Blue Button + and FHIR; IHE workflow profiles also need to be designed to be technology independent.  Yes, we expect to apply them over XDW, and there will be defined rules for how to do that.  But we can also apply them over other technologies.  If IHE workflow profiles are really to have value in the industry, we should design them so that they work in other environments too.

The ONC Standards Advisory

ONC published the 2015 Standards Advisory last week, a first of its kind document talking about the best available standards for various uses.  These includes:

1. Vocabulary/Code Sets/Terminology
2. Content/Structure
3. Transport
4. Services

Notably missing are standards for privacy and security, but this is by design.  According to the publication:

An explicit stand-alone category for “security standards” was purposefully omitted because security standards for information exchange using the internet are commonplace and not unique to health care.

This document is a first for ONC, in that as an assessment of standards, it shows an awareness of available standards that I don't always see in this space.  There were no big surprises here, not really should there be.  I might argue some of the finer points, but the broad strokes are solid.

I could wish that such a document was produced at the beginning of all of this Meaningful Use stuff, but as is the case with every program of that magnitude, we must muddle around until we find something that works.  Here, I'm speaking in the collective "we" of the taxpayer, which really means: our government. And while they may have muddled getting to producing this document, the content is actually pretty good, and furthermore it appears as if this will be a regular thing.  Good.  We need something like this.

   Keith

P.S.  I'll be back later this week to talk about the Interoperability Roadmap, also published last week.