It's still Wednesday at the HL7WGM (barely)

It's been too long since I've written an HL7 Plenary Wednesday post, but if you understand the history of this blog, you know what is coming.  For rather understandable reasons, I have shifted a great deal of my focus towards implementations and standards supporting Public Health, rather than the EHR space.  Some of that has to do with what my employer Audacious Inquiry does, but other parts of that stem from seeing an unmet need that can impact people around my country, and even more so, the public health people working very hard, and on very limited budgets to keep us all healthy.  That unmet need became even more apparent as we went through COVID-19 and are still in many ways recovering from it.

Significant effort is underway even now to connect public health to the health information eco-system that we in HL7, IHE and other organizations have been creating for patients.  One of those efforts is to enable public health agencies to connect to that eco-system through TEFCA and national networks to make it easier, cheaper and faster to do the jobs that need to be done, and to improve the infrastructure that is long overdue for a major upgrade.

Over the last couple of years, I met a young leader whose team is developing tools to enable public health agencies connect to the Health Information Superhighway we have been trying to create for the past two decades. Over the past year, I worked closely with him and his team at two different FHIR Connectathon events to better enable agencies to build on-ramps to that expressway.  Through his work, I've been able to make some on-ramps of my own that should enable public health agencies better access to their own data using a more modern infrastructure and achieve a five-year goal I set for myself back in early 2021.

This next recipient is someone I've not had a chance to watch over a long period of time, nor see him grow (though I know he has even in the short time I've known him).  He does what all good leaders do, which is to enable others to succeed, and by others, in this case, I mean me.  We have infrequent contact, we don't really work on the same project, but where our roles intercept, he's made it possible for me achieve a significant goal. Without further ado, here's the next Ad Hoc Harley.

For Daniel Paseltiner, of Skylight 

For leadership that enabled me an opportunity to nail a 5-year goal

P.S. I know this post was more about me than Dan, and for that, I'm sorry.  I do wish Dan and I had more opportunities to work more closely together on a project.  To see some of the work of Dan and his team, check out the DIBBS Query Connector project on GitHub.

   

The January HL7 Working Group Meeting

HL7 Working Group meetings are a phenomenal way of keeping up with what HL7 is doing. The biggest challenge I have is that I cannot be everywhere at once.  January is also the HL7 Payer Summit, and so there is a lot of activity going on.

The working group meeting starts on Saturday with two activities: The FHIR Connectathon, and the International Council meetings.  I didn't go to either this year, but heard we had about 240 people at the 20th FHIR Connectathon.  I expect to be at the next Connectathon.  For a variety of reasons, a lot of payers were in attendance at the FHIR Connectathon trying out some of the new Da Vinci profiles (e.g., CRD).

While I had some minor challenges with my flight out on Sunday (for some reason my expense application notified me of flight cancellation, but United completely failed to let me know until I arrived at the airport), I did arrive just in time for the working group meeting "proper", the Monday to Thursday (and sometimes Friday) meetings that make up the bulk of HL7 activities.

Structured Documents reviews their plan for the week first thing Monday morning, and I make mine.  I still consider SDWG to be my "home committee", but my interests are too divergent to spend time with any single group.  My plan for the week was to spend some time with SDWG, CQI and CDS, Patient Care in a large joint meeting with CQI and CDS and others, Attachments (another "old home"), and FHIR-I (joint with SDWG). Structured Documents is one of the work groups piloting the use of Confluence to capture the WGM activities.  You can see the output from SD here, including the results of the Wednesday morning, and Wednesday afternoon sessions that I also attended. 

Provenance

The Monday joint meeting with Patient Care discussed a new Provenance project, which several workgroups have interest in.  PC was going to sign on as a "Interested Party", a commitment with no actual governance associated with it, and there was some ongoing discussion during the week between the Security Workgroup, the Community Based Care and Privacy workgroup (formerly Community Based Collaborative Care, renamed to effect what has been the reality for this workgroup over the last half-decade) about who might become primary sponsor.  I had suggested the EHR workgroup (not even in the room at the time, but the one workgroup who had published functional requirements on Provenance, but they later declined).  It eventually wound up I think, with Patient Care as a sponsor (a role that does provide project governance).

Attachments

I got to spend some time with attachments at their joint meeting in the Payer Summit and hear from Steve Posnack and folks from the CARIN Alliance, and where I popped in for a a few other meetings to hear what is going on.  Attachments is very closely following the Da Vinci project, so it is a good place if you aren't a member of the Da Vinci project to learn about what is going on there.  There are a number of payers and clearing houses working on Coverage Requirements Discovery, a topic I have some interest in.  It's basically a "pre-prior-auth" sort of specification, that basically allows a provider to ask a payer what data requirements a payer has to cover care for a given condition (including the need for a prior-auth, since there are no "standards" for what does require one).  FHIR has got payers excited, and for good reasons.  It's allowing them to modernize a HealthIT infrastructure that's long been in need of rejuvenation.

Da Vinci

Da Vinci has several projects going on.  I'm not specifically a member of the Da Vinci project (it too requires a membership fee, and I've got a limited budget).  Even so, many of the Da Vinci specifications are being balloted in HL7 projects, and you can follow them through their sponsoring workgroups, including:

• Electronic Clinical Data Exchange (eCDX) in Patient Care
• Document Templates and Rules in CDS
• Electronic Payer Data Exchange (ePDX) in Financial Management
• They are also looking for a home for the eHDX framework being used for eCDX and ePDX specifications (I haven't found this PSS on Confluence yet).

The eHDX project was discussed somewhat in the Patient Care joint meeting.

SD to be Cleaning up the Template Publication Format

Wednesday morning I found myself in a discussion of a topic that I complained about on Twitter and FB a year ago, the use of PDF (or other document formats for multi-ream documents (if printed).  SD won't do that any more after projects in flight are finished (you can't retroactively make a project do more work than they've committed to, HL7 would never get anything done, they learned that from V3).  I nudged that one along after Bret complained ("can you perhaps state that as a motion"), which I quickly seconded.  We spent a lot of time working out the exact wording of the motions, and the follow-on details, but just about everyone was on board with this. 

Technically, this is not as huge a challenge as it once was.  Later in the week Structured Documents assimilated the Templates workgroup, and the FHIR StructureDefinition and ImplementationGuide resources can handle most of the heavy lifting publication needs that the former V3 Templates specification was supposed to help with.  Between the publication of CDA R2 as a StructureDefinition, and the aforementioned resources, CDA templates can be published using FHIR IG tooling with perhaps some modest changes being needed.  I'm still using Trifolia as my de-facto reference for C-CDA templates until HL7 fixes this problem.

HSP Marketplace

No plan stays the same once the battle is engaged, and I found myself in other places, most notably a quarter with the SOA workgroup "battling" out my feedback on the Health Services Platform Marketplace negative.  As battles go, this one was mild, since the workgroup took most of my feedback into account.  The biggest discussion was around Chapter 4, the API, in which my major comment was simply put: "Use API documentation tools to document the API", and "describe your concepts better", again, they agreed in general, and we spent most of our time arguing the specifics.  The HSP Markeplace is shaping up, but I think it still has a long way to go.

V2 to FHIR

I also spent time with Orders and Observations (a.k.a, O&O, or simply OO), on the V2 to FHIR specification.  I spent the last half hour of one meeting unsuccessfully trying to find out what was going there and failed due to agenda overload, but DID get a good overview Wednesday afternoon.  This one has meat on its bones, and offers incredible value as Healthcare organizations figure out the many and various ways to get data into FHIR format.  I also spent Thursday morning 7-8am with several supporters of this project to talk about the tooling needed for this specification.    We agreed in principle to use the FHIR ConceptMap or StructureMap to capture the results of this effort, so that the end result will be computable. I am clearly going to be spending more time with this group, as this is directly related to my current work.

What I Missed

I had plans to spend time with both the Clinical Decision Support and the Clinical Quality Information workgroups this time around and failed because a 30 minute diversion (SOA) turned into the entire quarter, and OO's V2 FHIR project was more immediately compelling.  The case for cloning is never stronger than attending an HL7 Working group meeting.  I also missed out on some discussions in Public Health (formerly Public Health and Emergency Response, but the latter simply folds into the former), and Infrastructure and Messaging (InM) [which simply had nothing on their agenda to which I needed to pay immediate attention].  I'm certain I'll have to spend time with these groups at future meetings.

     Keith

Matt the Mighty, A PrecisionMedicine Super Hero (Dad)

Every year in September, HL7 has its "Plenary" session. This is a half day where we hear from folks outside of the working groups on important topics related to what we do.

This year we heard from Matt Might, whom I now would christen Matt the Mighty for his Super-Dad precision medicine powers.  Either that, or as close in real life as one could come to a Doctor McCoy.

You really have to hear him tell the whole story because A) He is an awesome story teller, and B) there's simply so much more depth to it.

The long and short of it though, is not only does he help to figure out how to identify a rare (n=1?) disease, and develop a diagnostic test for it, and identify other possible sufferers, but also a treatment (not a complete cure,  but addressing some effects) among already FDA approved substances (lucking out on an OTC drug), and develops model legislation that his state passes to allow for "Right to Try" use of medications for these cases, and builds a process by which other n=1? disease patients can benefit from it, starting with his own son.

That's Mighty powerful application of precision medicine (pun fully intended).  If you weren't here, I'm sorry you missed it, and urge you to listen to him speak elsewhere.

   Keith

And then Magic Happens

Engineers do this all the time.  We make some simplifying assumptions about how a design will work, so that we can then focus on other more important stuff.  Sometimes these simplifying assumptions are well understood, and sometimes they presuppose some things that have yet to be proven.  This is what I'm referring to in the title.  It's those simplifying assumptions where "magic [science as yet insuffuciently explained] happens".

In discussing FHIR workflows in Q3 and Q4 today at the HL7WGM, I described some of the simplifying assumptions about how communication would be syncronized between a sender and a receiver, asserting without showing the proof, that there were several ways these systems could be synchronized without having to worry about the exact details.

Grahame balked (rightly so, as we do have to explain this to our readers at some point), and he wasn't convinced that I was right.  He could figure it out quite well on his own, but I'm the one making the assertions, so it is fitting that I prove it.

So, here are the assumptions and assertions:

1. There are three actors: A sender (which could be an Order Filler or Order Placer) as system tracking tasks which I'll call workflow, and a receiver (which could be an Order Placer or an Order Filler).
2. The sender can create or update  a resource (the general pattern is the same, the only difference is between PUT and POST), and as a result of that create or update, the receiver can be seen to eventually act upon it within a reasonable time period ensuring synchronization at some granularity of time units.

So basically, this is what we want to ensure is present in all cases:

There are three ways to do this that I covered:

1. Polling
2. Subscriptions
3. Grouping (Receiver and Workflow system are part of the same system)

Polling

Polling looks like this, with the polling system periodically making a query for tasks of interest (in this case, tasks assigned to the polling system), and acting on received results:

Not shown here but which may need to be accounted for:

Time should be synchronized for all systems (so _lastUpdated query works).

The receiver should recognize when a bundle contains a [specific version of a] Task resource it has already acted upon, and not act upon it again.

Subscription

Polling is slow and inefficient in some cases.  Some systems would rather be notified using subscriptions.  That would look like this (note: I didn't go into details about the four different kinds of subscription channels which could be supported):

In some cases, subscriptions are really just a tap on the shoulder that you need to ask for data, and in other cases the data is already presented to you in the subscription communication channel.  So that middle GET on the bottom right might not be necessary.  Again:

Time should be synchronized for all systems (so _lastUpdated query works).

The receiver should recognize when a bundle contains a [specific version of a] Task resource it has already acted upon, and not act upon it again.

Grouped

Finally there is grouping the workflow system with the intended receiver.  In this case, you can simply treat it as if there was a magical subscription present.  You don't need to seen information back and forth because it is already there:

This is the simplest of the three cases, and might be the preferred implementation for simple workflows where you "post something" and it just magically happens.  In this case, it is additional, unspecified by FHIR logic in the server, which simply ensures that tasks are processed.

In this example, you can ignore time synchronization and logic to avoid reprocessing a task, since it won't get messed up that way (although I'm sure someone will figure out how to do that anyway).

As you can see in all of the above, the preconditions and postconditions are reasonably met in a couple of different ways.  Hopefully this addresses some of the concerns raised about how the "magic happens."

    -- Keith

What is workflow?

A 1921 reference to the term Workflow as we use it today, from The Railway Engineer Volume 42

I devoted most of Q3 and all of Q4 at the HL7 Working group meeting today in a session hosted by Orders and Observations, and including participants from Financial Management, Patient Care, Modelling and Methodology, Imaging Integration, Pharmacy, Healthcare Standards Integration, Security and FHIR Infrastructure work groups to discuss the addition of workflow to FHIR DSTU 2.1 in the coming months.

There's a ton of information packed into that single sentence, so let me parse that for you:

1. A lot of people in HL7 are interested in workflow.
2. It will be a focal point of the next FHIR DSTU release, presently known as 2.1.
3. The material will be developed fairly quickly (at least to support FHIR connectathon testing), and will likely be balloted in the next six months (although unlikely to be balloted in the next cycle due to the short time frame for it).

One of the things we didn't yet agree upon is what we mean by workflow, and it was fairly clear that what a lot of people were talking about addressed workflow at a variety of different levels.

Many workflow standards exist today without even defining what a workflow is.  BPMN is a perfect example, as is OASIS Human Task (the standard IHE used to support Cross-Enterprise Document Workflow).  Fortunately, the Workflow Management Coalition (WfMC) defines workflow in their glossary as:

The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.

This is a fairly straightforward definition, which I will build upon further based on my work with BPMN over the past year or so.  Some of the terms in this definition are a bit slanted towards business process automation and workflow management tools, but for the most part what it says can readily be applied to what we are trying to do with workflow in healthcare at HL7 and elsewhere.

From my perspective:

Workflow is the creation of a good or service through the collaboration of multiple parties performing a defined process.

Each component of this definition is essential.
An activity that does not provide some utility (the good or service) is at best boring, and at worst wasteful.

• If only a single party (person, organization or system) is involved, then we don't need to manage it in the same way as when is is performed by multiple parties, at at best our "workflow" becomes a process or algorithm by which a good or service is produced.  So without multiple parties, our need to manage "workflow" disappears.  
• The defined process is also essential, because that is how we can measure progress through a workflow.

It's fairly clear in many discussions that I have had with others about workflow that some of the essentials are missing when workflow is being discussed.  People often talk about "their workflow", but what they often mean is their process, which moves us a bit further along to the next definition:

A process is a defined sequence of activities and decisions to be performed by an entity that has a clear starting and ending point, and may have inputs and outputs.

Without clear endpoints, we cannot tell how far along a process is.  Without sequence, we cannot ensure that steps occur in the appropriate order when necessary. Decision points allow for alteration or repetition of a process based upon defined criteria [wash, rinse, repeat until done]. Inputs and outputs provide for interim measurable results that show progression through the workflow, and through which quality of the process can be evaluated and managed.

The parties, entities or whatever phrase you might want to apply are simply autonomous actors, things able to do something of their own volition having been appropriately prepared.  That can be a person, an organization, or a system, or some entity composed of two or more of those parts.

Finally,

An activity is a unit of work which can be treated atomically.  Activities are performed by people, organizations or systems (or by any composition of the same).  Activities may be further broken down, in which case it can be viewed as a "subprocess."

Some processes are comprised of a single activity.  When my daughter (either of them) creates a drawing, they may not have a defined process for how they do that activity (arguably, it is very ad hoc).  But there is a very clear beginning point (a blank page), and an end-point, which often includes a decision to be made (an artist decision, a filled page, or bed-time, whichever comes first ;-).  So even a not very well defined activity can have a moderately well defined process.

The definitions I've provided are clearly informed by BPMN, but are also consistent with other definitions of workflow found elsewhere, going back as far as 1921.

I don't know that it is all that important to get people to agree with MY definitions, so long as we agree to work from some definition.  I think making sure that we understand the distinctions between the concepts associated with (in my definitions) the terms workflow, process and activity, we'll be able to move forward successfully.

One of the important distinctions that Lloyd made in the meeting is that Resources aren't activities. There is a difference between "Resource" and "Service", in that a resource can describe what needs to be done, e.g., a request or order.  The service actually executes the activity, and as a result may alter, create, delete or access other resources.  What FHIR operates on today are resources, and it includes the basic functions Create, Read, Update and Delete on those resources.  Those familiar with security ontologies will realize is that the missing action from FHIR resources is execute, and that is what services enable, the execution of a process.  And enabling collaboration (through FHIR) among multiple processes will result in integrated workflow, for perhaps the first time in healthcare.

Travel Weary

I head out today for my last travel for some short period of time (probably not long enough, at least according to my wife).  I spent last week (it seems like longer ago than that) just outside Paris near the CDG airport, at the HL7 Working group meeting.

Last Tuesday I mentioned a quickly run project to update C-CDA 2.1.  We talked with the steering division and they approved the idea in principle.  We've updated the C-CDA 2.0 Project Scope Statement and will be voting in Structured Documents later this week to approve that additional scope of work.  We'll see how that goes.  Some still want to see ONC back off to C-CDA 1.1.  While I agree that wouldn't be a bad idea, I want to make sure that the only sensible decisions they could make would lead everyone to success.  If we only leave them with the choices to back off to C-CDA 1.1, or proceed with a compatible but rather difficult to use C-CDA 2.0 (at least with regard to asynchrounous bilateral cutover), then we could wind up in a very challenging situation.  Given that ONC invested in the 2.0 work, I'm sure they'd like to see it be adopted.  There's some important material in that package (Care Plans) that we really need to meet some of the MU Stage 3 goals.

At the same time, we are also planning the kick-off meeting for the Relevant and Pertinent project to occur some time after Memorial day.  I already have an introductory call scheduled with the Health Story project the first week of June.  We probably won't begin the official engagement with them until later.  The Clinical Interoperability Council also signed onto the project last week.

Keeping up with school this term has been a little bit challenging, but fortunately I've only got four credit hours.  I must have been prescient when I scheduled things that way.  I have a lot more to line up for myself there, and I'm way behind on some of my planning, but will be able to catch up in the next couple of weeks.

I'm looking forward to meeting up with friends this coming Memorial day.  I managed to get the lawnmowers working this weekend and cut about 2 of my nearly 3 acres.  The tractor that came with the place does a good job.  I also cut up about half a cord of wood for drying and later splitting.  I have about another half-cord to finish with.  Before I left for HL7 I had someone come out and cut down the three trees in my side yard that were rotting and dying (one had half fallen over the week before).

Dual CCDA Reprise and an Action Item for You!

One of the issues that has been taking up my time over the last five weeks is an evaluation of the backwards compatibility issues between C-CDA 2.0 and C-CDA 1.1 with the Structured Document workgroup at HL7.

There are basically three different kinds of problems and one non-problem that we thought we might find:

1. Things that just don't work without a fix to one specification or the other.
2. Things that do work, but which are ugly if we are to use them, and so we'd like to make some changes to resolve them.
3. Things that could work but might need some clarification or explanation as to how to resolve in the Asynchronous Bilateral Cutover case where a dual-capable C-CDA was being used.
4. Things that simply work (which isn't really a problem).

There are also three different levels of compatibility that we likely needed to address:

1. Cases where the incorporate provisions of the rule would be impacted.  These are cases where the C-CDA entries are required to be transferred in some way to the EHR, such as with problems, medications, and medication allergies.
2. Cases where the viewing requirements might be impacted (different section requirements), or where clinical content varied between versions of a document.  For example, the Care Plan Section in C-CDA 1.1 includes Goals content, but in 2.0, there is a separate goals section.
3. Cases where other ("secondary") uses of the content, such as with quality measures, would potentially be impacted. These are not specifically requirements of the Certification rule, but are capabilities that some have used to facilitate other requirements.

The essential feedback from the evaluation is that it is technically feasible to create a C-CDA document that supports both specifications and which might be understood by both systems. However, such a solution seems to be more technically challenging that any would like.  HL7 members think we can do better.

The solution appears to be to quickly issue a DSTU Update of C-CDA to address these issues. Because of the timing of the regulation, we think this might be workable, but there are still a bunch of ducks we need to get in a row and then shot down.

SDWG will be seeking advice from its steering division and the TSC this evening, and will likely be taking action on it based on the outcomes.  I will report more on this later in the week (perhaps as early as tomorrow). Those I have discussed this with seem to think that it is feasible.

We have maybe six weeks to accomplish this task.  Due to the work of the Dual C-CDA task force we have an idea of what changes would need to be quickly implemented.  Here is how I think the timing works:

The ONC comment period closes in a month.  They will take at least two months to review the comments and produce a new rule, perhaps three.  One month before they submit the final rule, they have to have the published content available.  That gives us six weeks (not counting this one) to get 'er done.

Your action item is to reference an updated C-CDA in your comments on the Standards and Certification rule.  The only way to ensure that ONC references a new edition is for a) HL7 to make one available quickly, and B) for you to make comments referencing the C-CDA DSTU Update.

To submit a comment, click the link above, and hit the SUBMIT A FORMAL COMMENT button on the right hand size underneath the the title.

Is Your CCDA Document Relevant?

One of the challenges with Meaningful Use has to do with the way that it started; first with one kind of document, the CCD (using the HITSP C32 specification), later migrating to CCDA which supported multiple document types.  Meaningful Use never gave any guidance on which CCDA document types to use for different purposes, and in fact, defined content based on a combination of document types found in CCDA.  As a result, most folks are still using CCD, which really is designed to be a general summary of care.  But physicians generate other kinds of documents during routine care, such as a history and physical note, or a consult note, or an imaging report.

Because the 2011 edition required use of CCD, but these weren't related to what physicians were generating, the documents were automatically generated. And since they were automatically generated, there's no physician in the loop to determine what is relevant and pertinent.  Vendors have built interfaces to make it possible for them to select relevant and pertinent, but that takes time in the physician workflow.  So vendors get told to automate the generation process, and depending on how they do that, the result is often less than ideal.

By about 65 pages.

I've talked about this problem previously, and at the time, it seemed to me that the solution should have been obvious: Use the physician's existing documentation process to select what is pertinent and relevant.

But the evolution of Meaningful Use from a document that physicians don't generate to a collection of documents which they might use assumed a level of integration with physician workflows that simply wasn't allowed for by Meaningful Use timelines.  Basically the setup of clinical documentation workflows is something that is usually done during an initial EHR installation.  It isn't redone when the system gets upgraded, because that is usually a non-essential disruption for the provider.  But that is what it would take to use the new document types.  Now, that process will likely occur over time as hospitals and providers update their systems to improve their workflows, but in the interim, it leaves automatically generated CCD 1.1 as the documents that get exchanged for Meaningful Use.

Now we get into the disconnect.  Most EHR developers that I've talked to know that clinicians are the best judge of what is pertinent and relevant content to be exchanged.  This results in the choice of what is relevant to be set up as system configuration parameters.  Lawyers and HIT administrators (and sometimes physicians), tend to err on the side of caution when trying to figure out what should be sent to a receiving system in this configuration.

Which results in a 70 page "summary" of the patient data, which is at least 65 pages too long for anyone to read (and probably closer to 68 pages too long for the average physician).  As a result, when these documents get created and sent, a physician will look at them once or twice, and then decide they aren't useful and never look at them again.

How do we fix this?  I ran into a similar challenge over the last year and the answer that I came up with then was to talk to clinicians about what the right rules were for limiting the data that would be provided.  There were three sets of limits, time based, event based, and state based limits.

Information about active issues needs to presented regardless of time (assuming appropriate management of active and resolved in the provider's workflow).  This would include problems (conditions), allergies, and any current (active) medication.

Event based limits are based on recent care, e.g., activities done in the last encounter.  So any problem or allergy marked as resolved in the last encounter would also show up so that you could see recent changes in patient state.  Additionally, any diagnostic tests and/or results related to that last ambulatory visit would also be included (inpatient stays need a slightly different approach because of volume).  Finally, the most recent vital signs from the encounter should be reported.

Time based limits include dealing with stuff that has happened in recent history.  For this, for an adult patient, you probably want the last year's immunization history.  You likely want to know about any problems whether they were active or resolved in the patient's recent history (we wound up equating recent history to the last month).

There are certain exceptions that may need to be added, for example, for pediatric immunizations you might extend history to a longer period, but in an age dependent way.

HL7 Structured documents has agreed to begin working on a project in which we will work with clinicians, and reach out to various medical professional societies to help define what constitutes a reasonable set of limits for filtering relevant data.  I'm thinking this would be an informative document which HL7 would publish and which we would also promote through the various professional societies collaborating on this project.

So, I think I was both wrong and right in my original post on this topic.  It is impertinent for a developer or a system to decide what is relevant, but,  it is possible, with the participation of clinicians, to develop guidance that system implementers could use to configure the filter of what should be considered relevant.  And my advice to system designers is that while you might want to supply a good set of defaults, you should always let the clinician override what the system selects.

The HL7 September Plenary

I spent a good bit of time at the recent HL7 September Working Group Plenary meeting over the past five days with a lot of different workgroups.

While my home is usually Structured Documents, I only spent two quarters with them, first on forward planning and next hearing about the DAF FHIR project (which I'll talk about a bit more later).  We also talked briefly about ONC's HIT Standards and Policy FACA's feedback on C-CDA and also recent issues regarding the quality of CCDA documents being produced.  I agreed to bring this up in the HL7 Policy Advisory Committee meeting later on Wednesday.

I spent a good quarter with InM and ITS talking about the Data Access Framework PSS to create Query and Response profiles, in part satisfying one of the gaps identified in IHE's white paper on the Data Access Framework (this is the link to the public comment version, the Final is to be published soon).  One of the challenges here is that DAF wants to develop profiles that eventually will take advantage of the C-CDA on FHIR project, but they want to do things sooner than that project will be ready so that people can take advantage of the Query and Response profiles to test them.  I made the point that this needs to be coordinated across the other HL7 CDA/FHIR projects and the feedback I got was that "That isn't our project".  This is a common misconception that happens quite a bit when folks bring projects to HL7 is that they think they own the project.  The reality is, this becomes an HL7 project, and HL7 needs to do what it must to manage and coordinate ALL of the projects in its portfolio.  So, there will be some coordination there, and hopefully, we'll figure out how to do that properly.

Another good quarter was spent on QUICK, in which we talked quite a bit about my ONE negative comment on QUICK, which was the "Bad" ballot you can read more about in this post.  We traded a lot of thinking about what QUICK is trying to do.  One of the challenges of this work is that they think some of the names of things in FHIR are actually misnamed when approached from a quality and/or clinical decision support perspective,  I think there are probably three or four things that QUICK needs to do to address these mismatches, including getting some change proposals on the FHIR agenda to address some of these naming issues.  After all, if FHIR is truly EHR focused, we need to recall that at least in one market (the US), both Clinical Decision Support and Quality Measurement are key features that have to be present.

I spent a quarter with the HL7 Policy Advisory Committee, in which we spent about half the time planning the Policy Summit to be held in early December, and the other half discussion how to respond to concerns raised by the HIT FACAs on C-CDA.  We already have many processes within HL7 to address such feedback, and HL7 members use these to get improvements into the standards pipeline.  For example, the Examples task force headed by by Brett Marquard has already begun work on some of the examples that had been identified by the FACA.  Fortunately, we've been tracking these issues, but it might be nice if someone actually fed them more directly into HL7.  We'll be working on how to streamline that.

I spent a quarter with the Attachments workgroup, and we resolved some issues with esMD, but more importantly, Paul Knapp, chair of the HL7 Financial Management workgroup showed up to report on what he has been doing with FHIR in the Financial sector.  A while back I wrote a post about how Blue Button Plus and EOB data might be used to help reduce costs, but one of the outstanding issues has been the missing content standard for an EOB.  Building from the work that Paul has already completed with Claims and Remittances, we believe that FM could (and Attachments would support) the creation of an EOB resource that could be used with Direct, Blue Button Plus, or any other transport.

Thursday morning I spent with at the Payer Summit, giving payers a very high level view of HL7 Standards, along with many other HL7 luminaries.  It wasn't the largest room, but it was certainly chock full of some very interested payers.  I wasn't able to stay for the full summit, but I heard many good things.  Also speaking at the Summit was Brian Ahier (@ahier on twitter).

Finally, I spent my last quarter at the Working Group meeting with a number of HL7 and IHE members discussing the formation of a joint workgroup between IHE and HL7, preliminarily known as the Healthcare Standards Integration workgroup.  The IHE board has already approved this in principle, and we are following the HL7 Governance process to finalize the new workgroup, with the expectancy of final IHE board approval. Hopefully it will be in place before we complete the 2015/2016 Profile Selection process with several IHE Domains in October/November.

All in all, it was a pretty busy week, and I was quite happy to get home to finish packing for my big move to the country, a week from tomorrow.

That takes guts

Normally I do this post Wednesday morning, but quite honestly had day job and personal distractions (I'm moving in about a week) this week, so I'm doing it today.  Wednesday morning at the HL7 Plenary the God Father of Health Level 7, Ed Hammond gives out the Ed Hammond awards, and I traditionally also give out an ad hoc award.  I do that not so much to compete with Ed (I hope I can do what he does when I reach that degree of tenure)., but to continue the tradition.

Tuesday morning I saw a combination of ribbons on an HL7 Member's badge that I found stunning. They were "First Time Attendee" and "Co-chair".  When I asked further, I discovered that this person was a new co-chair of perhaps the most technically challenging, and also difficult collection (which is a compliment, not a critique) of people to manage.  The Security Workgroup is relatively small, but contains some of the top names in Health IT Security, and has always been a very challenging place to engage.  I leave that to my colleague John Moehrke, who has much more experience in this area.  I know enough about security to know that I'd rather defer to seasoned experts that to try to do it myself.

So this combination of badges deserves special recognition, because while it takes guts as an HL7 first-timer to join the Security workgroup, it takes even more than that be willing to co-chair the group.  An extra special thanks and here we go ...

This certifies that 

Alexander Mense of HL7 Austria 

Has hereby been recognized for for having the guts to take on a role as cochair of the HL7 Security Workgroup

The FHIR Code

A guest post from one of the FHIR Chief's: Lloyd McKensie

---

A little over three years ago, when Grahame introduced the concept thFHIR(TM) standard, he didn’t just have set of technical ideas for how to better share healthcare information. He also had some fairly strong ideas about what we needed to hold as “important” as we pursued that new approach. The technical approach has evolved, in some places quite a lot. However, the underlying priorities have remained pretty consistent.

at would become

Principles are actually important core to FHIR – or any standards effort. They drive what gets produced. They also guide the community. If the principles aren’t well understood or clearly expressed, it’s easy for a standard to drift and lose focus. It’s also easy for it to deliver the wrong thing. V3 had a really strong focus on “semantic” interoperability. We made great strides in that space. However, we sort of lost track of the fact we still needed technical interoperability underneath that. (And that ease of use was sort of relevant too . . .)

Some of those principles such as “the 80%” have been widely shared (though not always well understood) . Others have found their way into presentations in slides such as the FHIR Manifesto. However, we’d never really sat down as a project and written down exactly what the fundamental principles of FHIR were or why we felt those principles were central to what FHIR was.

So the FHIR Governance Board (with review from the FHIR Management Group) has written down what we see as the “core principles” of FHIR – the FHIR Code, if you will. These are the underlying drivers that we feel should guide every design decision, every methodology rule, every step we take in deciding on scope, ballot timelines, etc. They can be found on the HL7 wiki.

I don’t think any of these principles will be a surprise to those who have been following the FHIR project. They pretty much all stem from the first principle:

FHIR prioritizes implementation 

Note that these aren’t hard and fast rules, but guidelines. You can’t say “I’m an implementer, I don’t like what you’re doing – therefore you’re violating FHIR core principles”. But they do reflect the spirit of what we’re trying to do and we’ll try to adhere to them as much as we can. (As well, we interpret “implementer in the broad sense – we don’t only care about those who write code but about all those who use FHIR.)

The FHIR code isn’t done though, because FHIR isn’t a top-down process. It’s about community (Grahame’s been re-enforcing that a lot this week.) And as I write this, I realize we may have missed a principle that should be added to the list. In any case, we want the principles to be reflective of the desires of the community – so we’re throwing them out to implementers and the broader FHIR community:

Do these principles reflect your vision for FHIR? Is this what should be guiding our decisions? Will this help us to keep our focus on the right things? Are they clear enough?

We’ll take your feedback (here, on the FHIR list, implementer’s Skype chat or any other means you choose). Then we’ll seek feedback as part of the next FHIR DSTU.

HL7WGM Plenary

The HL7 Plenary session is an annual event in which HL7 members hear from folks outside the standards development space.  This year the topic this year was around data, with focus on analytics, privacy and ethics.  First up was Dr. Richard Platt, who talked about the value of Mini-Sentinel and PCORnet, and the value of a standard data model to support the benfits of a learning healt system.  His talk was good, but what I found unfortunate was that we still focus on claims data.  One of his key points was that clinical data used in the EHR is designed to meet the neds of clinicians, not computers.  And so we get the problem below, which physicians resolve quite readily, but computers do not.

Next up was Zoi Kolitsi, Ph.D. Who talked about the balance between data protection and innovation.  The key points in her presentation were:

* Health and health data is special, even in the EU it receives an exception in legislation.

* Everytime that eHealth comes up, the legal aspects are also brought up.

* Governance, identity, and privacy are important principles to build into data sharing.

After the break, Marc Overhage gave a great presentation the challenge given to JASON (find the Golden Fleece).  He was quite quotable in his presentation.  For example, "if Interoperability is the problem, then architecture was the answer... not that anyone had ever thought of that before."  Or "the simple fix is to change the Universal Gravitational Constant..."

Here are his key challenges for interoperability:

* Maintaining privacy

* Misaligned incentives

* Competing priorities

* Same old problems

 - semantic variation

 - patient, provider and location matching

* Missing events model

Note that only one of these is technical (missing event model is one worth a whole blog post).

While Mike Jennings from Walgreens made a good start talking about how Walgreens use HL7 standards like CDA, Version 2 and Version 3, the rest of his presentation was little more than either an advertisement, or a rehash of all the reasons (which we well understood) for using health data.

Last up was Ken Goodman who talked about ethics in interoperability.  His presentation was very thought provoking.  Fitting ethics into the process of standards development and software development is something that he thinks is critical.  I need to digest his slides a bit more.

All in all, it was a useful plenary.  I'd give it an 8.5 out of ten.  Next time, I think we should probably provide the speakers with the same warning about "advertising" that HL7 tutorial speakers get.  That might have made it a 9 or 10.

Because MeaningfulUse

I listened closely at three different workgroup's meetings last week at the HL7 WGM as nine different project scope statements, none of them more than 100 hours old (that's about four days) wended their way through committees last week in order to meet deadlines for a September Ballot.  What's the reason for this deadline I asked, and invariably the response is "Because ... Meaningful Use ... Standards ..."

And I laugh because I can add.  If the rule shows up in December, then you have to have the text ready in October AT THE VERY LATEST.  And the ballot is August for the September WGM, and you need at least 6 seeks to reconcile and publish as the very best speed.  Some of these projects carry forward work that has already been in flight, and others are simple add-ons, but some are truly brand new standards.  And those are the ones that make me laugh at the absurdity of it all, because if you want mature standards, newborns just don't make it, and the numbers just don't add up.

Oh Congress, what have you wrought with these crazy deadlines?  Do you even care?  Did you even care? Did you even know?  All rhetorical questions.

There are times that I wish there was a cost to members for voting for a Project Scope Statement.  I wish votes cast for a project were a scarce resource whose value could be subject to market demands.  I've wondered if there is truly a revenue model for HL7 simply around the development of standards and the execution of ballots.

Because ... I need a better reason that Meaningful Use to develop standards.

Just Popping in at the HL7WGM

Yesterday I had another one of those "I'm glad I came here" moments at the HL7 WGM.  I had a "free" quarter, so decided to see what was up with Claims Attachments.  They were discussing the Complete Documentation Templates specification.  One of the issues that came up was trying to identify what this thing was and several things became clear to me during the discussions:

The specification is designed to meet the needs for CMS Auditing with respect to attachments.  The payers in the room indicated that their needs were mostly met already just using the Consolidated CDA, and they didn't need further conformance requirements.  So now it seems that we could have two kinds of attachments, one required for CMS, and other that would be desired by Payers.

"How," I asked, "is this administrative simplification?"  

Several other people in the room responded positively to that query, but we never quite got an answer.

One of the issues raised by this document was how you would be ask for attachments conforming to it, rather than just the Consolidated CDA.  One proposal was to request new LOINC codes, at which point I almost exploded (OK, perhaps I did explode).  After all, the LOINC codes that are used in CCDA came out of the original Attachments guides, why did a new attachment guide using the same concepts (History and Physical, Consult, et cetera) need to have NEW LOINC codes.  If we start messing around with new LOINC codes, those codes aren't even going to show up in CCDA, so many will question whether they are even valid CCDA (they still would be since those value sets are dynamic).  One possible solution is to simply request a new LOINC modifier code, which doesn't confuse LOINC document ontology, and meets the requirement need.  That suggestion seemed to have merit, but we never decided on it.

Following all this discussion, the comment that raised up all these issues (a descriptive name for the guide) triggered a motion to rename the document.  I observed then something I've never seen in all my years of committee work, which was a tied vote which had to be broken by the chair. The motion failed, which means that we remained at status quo.  This is a good thing in my mind for a tied vote, because it is easy to move from status quo later, but hard to go back to it.

I'm sure there will be a lot more to do on this topic, the guide itself attracted quite a number of negatives (89 out of 101 votes), many of which still have to be resolved (70 out of 101) before it can move forward. There's enough negatives on this ballot that the committee may decide it needs to go out for another cycle.

Tuesday at the HL7WGM

It's already Tuesday at the HL7 Working Group Meeting.  Today I taught the CDA and XDS class to a small but very interactive International group of developers, including some from Saudi Arabia and New Zealand.  It's a fun class to teach and I was happy to be able to bring some of my experiences in Saudi Arabia to the classroom here in the US.

Monday was a good day.  My one burning issue for the week was to make sure that we finally addressed the issue of format codes for CCDA, which we resolved yesterday.  However, we also worked out (for the next FHIR DSTU), the structure of FHIR RPC services, which is essentially:

[base]/_services/FHIR/ServiceSpecificURL

And makes it pretty obvious that if you want to define your own services simply using something other that FHIR to identify your "services" namespace.  So I hadn't expected to resolve that issue so easily (even if it took nearly an entire quarter to do it).

And then finally at the Cochairs dinner (which I get an ex-officio invitation to as a Board member), it was reported that HL7 TSC has adjusted some of its procedures to ensure that we don't have a repeat of the CDA stylesheet incident.  John Quinn and the TSC by the way were all over the issue before I had even brought it up to the board last month.  And as far as it goes, I think we truly have corrected the issues that need to be corrected.

Now the decision I need to make is whether I have enough time to attend the TNP before I have to go finish my homework.

   Keith

‹xi:include href="wheel.xml"/›

The topic of incorporating components from one HQMF in another came up today in an SD/CQI discussion today at the HL7 Working Group Meeting.  On a related note, one observer pointed out that if we are successful, we should also be able to use decision logic from one resource, such as a CDS Intervention, in another, such as a quality measure.

Fortunately, we really don't have to reinvent this wheel in HL7, because W3C already foresaw the need to include parts of one resource within another resource.  It's defined in the XInclude specification, and it provides a way to reference an entire file, or component of a file within another XML resource.  All you need is an XML processor that is capable of performing the inclusions.  Even if you don't have such an animal, you can create one quite readily through an XSLT transform on an XML resource, provided you limit the features of xi:include element that you use (and you can probably implement the whole thing with the right XSLT processor).

If you are familiar with the #include preprocessor directive of C (and C++), then you already have a good idea of how this works.  You name the resource to include (e.g., the file), and can even specify the [fragment] identifer (or other expression) to select the appropriate content.

The reason I like this approach is because no matter how you slice it, an HQMF instance, or a CDS intervention is still defined in code.  You may not look at it as a piece of software, but I certainly do.  And you'll want to manage that software in ways that allow you to reuse components over and over again.  HL7 doesn't need to define this capability, it already exists as part of the base XML standards which we are all using.  We might just have to get a little bit smarter though about how we load XML resources in order to take advantage of that capability.

However, if you are having to interpret HQMF (or HeD), or any other complex XML component, it's surely worthwhile building support for xi:include into your code base.

It must be Wednesday at the HL7WGM

If you've figured it out by now, I have a tradition on Wednesday mornings at the annual plenary meeting.  Of course it's a time for recognition in the HL7 community, but I have to tell you those blue vases are quite heavy.  What I've got is much cooler and lots easier to carry around.

So who's next up for an Ad Hoc Harley?  I'll give you some hints.  He's young, probably late 20s. He's smart. He knows CDA. And CCDA. And FHIR. Already his contributions to interoperability are great.

Give up?  Need more hints?  He's disruptive.  He knows OAuth. And RDF.  If you haven't figured it out by now, I'm pretty sure he has.

Let's delve a bit more: Genetics.  IT.  Software.  Geeky software.  Health IT Software.  And Poetry.  I'm told he likes poetry.  And speaks fluent French.  He's also an all around nice guy.  And smart?  Did I mention smart?  It doesn't hurt to say it again.

If I were to give this award for one of his accomplishments, I don't know which it would be.  Many of the things he's managed to accomplish is stuff I should have, wanted to or aspired to do, but couldn't pull it off. And I don't know what he'll do next and look forward to it, but frankly I'm also hoping he'll stick around for a while, because we [patients] need him.

So here we go...

This certifies that 

Josh Mandel of Children's Hospital Boston 

Has hereby been recognized for outstanding contributions to Healthcare IT including, but not limited to: SMART and Blue Button Plus and C-CDA Examples and Scorecard and FHIR Open Source

Versioning Templates in Definitions and Instances

We had a great discussion this morning in the Templates workgroup.  One of the agreements that we came pretty close to making was how to address referencing a templateId in an instance when you are dealing with old-style (version-unaware) templates, and new-style (version aware) templates.

In the old way, this was the correct way to reference a template.
<templateId root='1.2.3.5'/>

In the new way, this is the correct way to reference a specific version of the template.
<templateId root='1.2.3.5' extension='versionLabel'/>

When operating under the old world order, and in the new world order, the first reference to a template identifer in an instance still needs to work.

That's because instances created using version aware templates may still need to refer to other templates that aren't yet version aware (under the new model).

So, the first example above is what I'm calling a version unaware templateId, and the second example is a version aware templateId.  The former can only point to a version unaware template definition, and the latter can only point to a version aware template definition.

Instances can use either or both forms.  And in fact, this is perfectly legal:

<act>
  <templateId root='1.2.3.5'/>
  <templateId root='1.2.3.5' extension='versionLabel'/>
   ...
</act>

In the example above, the instance of the act is declaring conformance to both the version unaware release of the template, and to the newer version aware edition.

The Art-Decor project currenly uses <templateId root='1.2.3.5'> to reference "the current version" of the template, enforcing a "dynamic" constraint to the template.  I would argue that any content creator knows WHICH version(s) of a template are being used, and so MUST report the version identifier.  That is because versions are allowed to introduce backwards incompatible changes (which is part of why we doing this).

In any case, we will be discussing this further next week.

It's Wednesday at the HL7WGM, and that means it must be time for ...

It will soon be the morning for recognition of HL7 members who've achieved special standing.  During regular working group meetings, that special standing is for "veterans" of HL7, those with 10 years or more of membership (I get my 10 year badge next year).  I seem to have a tradition of my own at HL7 meetings too, so here we go again.

As you may recall, the last award I gave out was to someone entering retirement.  This next one goes out to someone who is still early in his career.  I'm quite jealous of him, and that's really because of his youth, and his meteoric rise in expertise.  He's quite a number of years younger than I am, but already I can see that his career is blossoming.  When I met him about five years ago, he knew little about CDA, but was clearly already quite an adept developer, and quite eager to learn.  So, I taught him what I knew, and not just about CDA, but also about being a committee chair, and working in the standards space.  What he's absorbed in these years that I've known him is phenomenal.

Outside of the HL7 world (and even inside it), there are few people who can stand toe-to-toe with me in CDA debate and win it.  And there are also relatively few that have written two, let alone more than half a dozen CDA implementation guides.  This next person is one who can, and has.

Without further ado, my next Ad Hoc Harley goes to...

Tone Southerland

of Greenway Medical

for outstanding contributions in Perinatal Care

When I first met Tone, he and his wife were preparing to have their first child.  Tone took a leadership role in developed the Antepartum Summary profile in IHE.  Tone and his wife now have four children, and Tone has written, edited or majorly contributed to a total of ten CDA implementation guides on the topic of Perinatal care over the last five years.  Congratulations Tone, and when I retire, I hope that you'll stick around for another decade or so to keep these folks whipped into shape (but you better stay in shape, because I intend to have a career like Ed Hammond).

I'm an Implementician and other Stories from the HL7WGM

It started out as an overheard at HL7, but then turned into a misheard, and so now I'm going to claim this portmanteau word as my own neologism.  It's a combination of implementor and informatician, with the best properties of both (or perhaps that's the worst of both, it really depends on your point of view).  Used in a sentence you might say something like FHIR is built for implementicians.

I like to build stuff that works that makes both academics and developers happy.  Perhaps I'll use it as a job title on my next order of business cards, but I still think Standards Geek has more panache.

I wish I could tell you what happened with the HL7 Working Groups today, but I spent much of the day in the Board meeting.  There were some good outcomes there.  There will be a Paris WGM in May of 2015, as a result of outstanding support of the European community members from the International Council.  The foregone conclusion at the beginning of the board meeting was that it wasn't affordable, but we determined that this was a) an investment worth making, and b) an opportunity that was worth pursuing to ensure that the meeting brought value to members of both the European community and to the HL7 organization as a whole.  I was really impressed with the decision making here.

We also made progress towards development of a new membership model, but that is still under development.  The membership task force has made good progress since the last time we heard from them.

There were a number of discussions that should also result in both a more transparent board and a more effective leadership team.  We did finish the board meeting in time to resume Q4 with the working groups.  Most of the board felt that trying to hold the board meeting starting Q1 on Tuesday probably wouldn't work going forward, because of the unpredictable ending times, so we'll likely start it Q3 at the next WGM.  That pretty much guarantees two lost quarters, but two known quarters down, is better than two plus some unknown additional time.

CDA R3 is still making progress, and there seems to be a general idea that this will go to ballot "soon", although I expect that there are still a few cycles that work product will have to run through.

We talked about the Consolidated CDA update project scope statement, which was floated past Structured Documents just before the WGM.  There'll be more discussion about it this week, and a final discussion next Thursday before it goes up to the steering division.

As currently outlined, that project will incorporate existing errata, make some adjustments to the Consult note, and add a referral and transfer summary, and a care plan.  These will be coordinated with existing S&I framework activities as well as ongoing IHE work with the Consolidated CDA Harmonization project it is executing.

IHE members are getting antsy about the joint ballot project, and several approached me to discuss their concerns and propose a candidate, because if we truly want to do an out of cycle ballot, we need to get it rolling NOW if we want to align IHE and HL7 comment periods.  So, I get to try to address that tomorrow in my role as HL7's liaison to IHE.