Implementation Guides vs. Specifications

We've been having one of those long running discussions over on the Structured Documents list-serve over the past couple weeks.  There are two parts to the eterna-thread, one on the need for more examples, and another for the need to simplify the documentation.  I've read the free manuals myself, and while I believe every engineer should do so at least once as well, I completely understand some of the challenges they have, because I have them too.

Recently, HL7 published Core Principles and Properties of V3 models, which includes about 30 pages of text on Coded Model elements.  This is a perfect example of where we need to simplify.  I've never had a developer ask me for this amount of detail. They've always asked me two questions, and sometimes a third:

1. What codes do I have to use?
2. What do I do if I cannot use them?
3. What do I do with the other codes I have?

This is the implementer viewpoint.  They don't want the theory, but rather the answers that theory provides.  What this really gets down to is the real difference between what an implementer would find useful as in an implementation guide, and what we in HL7 think is the value we are generating, which is the specification for what gets implemented.  If we were to apply a UX assessment to our documentation, we'd find they were sorely lacking.

For HL7 experts, the specification is what we need.  But for the rest of the world, the real value is in more than just the specification.  From a customer perspective, the ratio of "HL7 Experts" to HL7 users is probably 100:1 or even 1000:1 (where HL7 user = someone who has to look at a raw message or CDA document and do something with it in code or in an interface).  They need the explanations for how to handle common situations, for example, as in the cases described above.  It needs to be clean, crisp and simple.  It can reference the theory, or other documentation, but for the most part, it needs to tell people what they need to do.

There are several challenges with this level of documentation.  The biggest challenge is that it is repetitive, having the danger of nearly, but not correctly duplicating what already exists (we have that challenge today with SHALL/SHOULD and CWE/CNE), thus encouraging implementation behaviors that actually deviate from the standard.  This was the "HITSP" complaint, and given that we were writing quite a bit and basing it on other organizations standards, we definitely didn't want to duplicate what they had already produced.  It also had the challenge of requiring a cascade when the underlying standard changed.  While we cannot avoid that challenge today, we can do a lot better than we did 6 years ago.  We have a lot more tools to generate implementation guides, and to ensure that we follow the rules of the base standards (e.g., Trifolia and MDHT).  

The second biggest challenge is that it is "expensive" to produce.  And when the producers view themselves as the customers, the value to that extra step is negligible.  So, we need to change that viewpoint.  But to do that, we need the consumers of the documentation at the table.  And when they show up and start complaining, we need to listen to them.  We must recognize that the value of a standards organization is not in the number of specifications it produces, but rather in the number of implementations of those specifications.  If we produce thousands of specifications and nobody implements it, and another SDO produces one, but everyone wants to implement it, what will happen?  (Hint, we've seen that occur before).

As a person with a foot in both places, one as an expert at the table who has read all of the docs, and the other as a person trying to get implementations built with engineers that don't have the time to learn everything there is to learn about the theory of healthcare informatics, I am challenged.  I don't always recognize when there is a problem (keep me honest and keep complaining, eventually I do catch on).  At the same time, keep listening and participating.  The only way to EFFECTIVELY change an organization is from within.  When you become part of the organization, you also can improve it.

Unmaking

One of the biggest issues in standards is governance (as will be illustrated if you ever try to play this game).  What kinds of decisions can be made?  Who has the authority to make a decision?  How does the decision get made?  And finally, how can a decision that has been made be changed?  The challenge in developing standards that causes the biggest problems are when the answers to these questions are not clear, and that is especially true in the case of the last question.

"Unmaking" a decision that was made in the first place can be extremely disruptive, which is why is usually takes a super-majority, or approval of a supra-governing body or leadership, in order to be done.  The amount of disruption that unmaking can cause is usually proportional to the amount of effort required to unmake the decision.

There are a number of reasons why what has been recorded decision needs to be altered:

• To Clarify: The statement recorded is an accurate representation of the decision that was made, but it needs to be expanded up in order to to be understood by others.
• Typographic or editorial error:  The statement recorded is an inaccurate representation of the decision that was made.
• Technical Correction:   The statement recorded may be an accurate representation of the decision that was made, but it violates other decisions that the body does not have the authority to change.

Any of these can be addressed in HL7 by publishing Errata (as HL7 Structured Documents has done for CDA and other specifications), or by submitting a change proposal in IHE which then goes through approval and implementation process.

Other kinds of changes are more challenging:

• Addressing an implementation challenge: Something specified may wind up being unimplementable or extremely difficult or costly (under certain circumstances), necessitating a change.
• "Harmonizing" similar processes/behaviors/content: Sometimes the same thing (or nearly the same thing) is handled in different ways, especially in a large (or complex) specification.  Ideally, you'd address these in the same way, but sometimes we fail. This could apply within the same specification, or across multiple specifications.
• Old vs. New: The specification adopts the way "we" used to do things, but now "we" do that differently, and we want to adopt the new way.

If the profile is still in trial implementation stage in IHE, we can still use the change proposal (CP) process.  In HL7, if the specification is a DSTU or non-normative specification, the committee can choose to publish a new version of it (without balloting it), although HL7 governance is not clear specifically what can change in that case.  For  specifications in IHE at the Final Text stage, or in HL7 at the Normative stage, these sorts of changes require that new editions of specifications be written.  In IHE, we generally do not introduce "incompatible" changes to an existing Final Text specification.  We do sometimes introduce profile options that allow previously defined behaviors to be "improved upon".  There is the concept of deprecation (e.g., as was done for XDS via XDS.b), which is essentially what HL7 when it proposes a new version of a standard.

There is are other ways to "unmake" a decision.  One of these is to pretend it never existed, i.e.,  simply ignore it. This isn't something that HL7 or IHE can do realistically with their own specifications, but it is something that implementers of their specifications can do.  Another is to appeal the decision through the organization's appeals process.  Appeals are defined in section 14.12 of HL7 Governance and Operation Manual, but the process is rarely used.  IHE's appeals process is less well defined in its governance documentation.  Most things are usually worked out within the Domain committees, but sometimes are escalated to the Domain Coordination Committee.  

There is also a pretty ineffective way to attempt to unmake a decision, which just to loudly disagree with it after it has been made.  Just because you disagree with a decision doesn't change it.  If you want to change it, you need to follow one of the processes described above.  It is a pretty effective way to disrupt a discussion.

The Standards Game

Did you ever wonder how standards organizations work?  I created this little game to give you an idea.  It's a game best played with 4-8 players.

It doesn't start out with rules, though, instead it starts off with bylaws (because bylaws can be changed).  The bylaws and operations manual are purposefully confusing, ambiguous and subject to interpretation by the players (because that is the way that governance works).

Bylaws:

1. The object of the game is to gain the most influence.
2. To gain influence, you must successfully complete or kill projects.
3. Anything agreed to according by consensus of the players is legal.  Consensus in this case means without objection.
4. Momentum is important.  Any action taken on a turn that is completed by a player with consensus of the group (without objection by any other player) stands, unless it is immediately reversed.  The player immediately following must use two influence cards to raise a motion to reconsider actions in the previous move, and all other players must use one influence card to vote to reconsider.  A successful vote to reconsider is considered sufficient to reverse the action (because in the real world, after a successful vote to reconsider, the next move is to vote to change the action, and if you wouldn't consider changing it, you wouldn't vote to reconsider).
5. There can be at most 4 projects before the board at a time.
6. No more than 50% of players may be aligned identically, and all alignments must be present in game play (see starting play).  Any time a player is to be assigned an alignment that violates this rule, they must be assigned a different alignment (at random unless there is only one choice).  

Operations Manual

Objective

He or she with the most influence at the end of play wins. 

Influence

Influence is measured by the number of cards a player has in his or her hand at the end of play.  Influence cards are distributed based on influence, and are used to perform actions in the game.  Influence cards come from a standard deck of 52 cards (with or without jokers).

Paying with influence: In many cases, members can select which influence card they use from their hand.  However, when paying with influence, the card thus chosen MUST be chosen randomly from the member by another member.  This represents the often random costs on the use of influence in the real world.

Starting the Play 

Each player is initially given four influence cards, the first is dealt face up and determines the player alignment.  This card must remain face up in front of the player. Alignment determines the powers that a player may execute during play.

If the face up card is in the suit of Clubs, the player is a member of the public sector.  The public sector can hire consultants (they provide cards to consultants who act on their behalf during the consultants turn, as well as act in their own turn).  The public sector can create only one project per game, but can commission consultants to do so as often as they like.

If the face up card is in the suit of Diamonds, the player is a consultant.  Consultants can be hired by the public sector an unlimited number of times.  A consultant can create only one new project during the game that has not been commissioned by a customer.  

If the face up card is in the suit of Hearts or Spades, the player is a consumer or producer in private industry.  A member of the private sector can initiate projects as often as they like, but commission a consultant to act for them only once per game.

The game is played in a series of quarters.  Each of these is played in round format.  

Determining the agenda.  In each quarter, players play in the order of their face up card, from highest to lowest.  At the beginning of each quarter a play can replace their face up card with another face up card of the same suit from their hand to change the order of their turn in the agenda.

A token is used to indicate who currently "has the floor".  The player with the floor may act.  When they are done, they must pass the token to the next player on the agenda.  When that player accepts the token, the current player's turn is over, and all actions they performed are completed.

New Business.  When a member has the floor, they may propose a new project.  To propose a new project, the member announces the proposal by selecting an influence card from their hand, and placing it face up before themselves on the board.  They must then place an influence card face up on the project to show that they are participating in it.  They can then solicit participation from other members.  Each member choosing to participate must place one of their influence cards face up on the project card.  No more than half + 1 of the members may participate in any single project.

Determining the Project Leader. The highest rank participant card above a 9 becomes the project leader.  In case of ties, the first played card of the same rank is the leader.  If less than three members choose to participate in the project, the project fails, all cards are discarded, and the proposer must pay an influence card.

A proposed project that has at least two participants (including a leader) moves forward to the voting stage.  Those that do not remain active but not ready for voting, see old business below.

Old Business: A proposer of a project that does not yet have a leader must solicit leadership, withdraw the project, exchange their participation card with a higher card, or pay an influence card to keep the project alive.  If another participant wishes to pay an influence card to keep the project alive, they may do so during the proposer's turn.  The withdrawer of a project must pay an influence card to withdraw the project.

A proposer or leader of a project that has a leader may also withdraw the project, citing inability to reach concensus.  The withdrawer of a project must pay an influence card to withdraw the project.  Anyone participant opposed to withdrawl can pay an influence card to keep the project alive.  All cards played on a withdrawn project go to the discard pile.

Opening the Ballot: Any project with a leader can declare itself ready to be voted on by declaration of the project proposer or leader, and by the use of an influence card by any one of the project members.  When ready for voting, turn the project card face down (but leave others face up).

Distribution of Influence Cards:   Before voting, influence cards are distributed as follows:  Members get one card for each project they are a participant in.  Proposers of a project get one card for each project they have proposed (remember that a proposer must be a participant initially). 

Voting:  Voting is a random activity.  Members shuffle their hand and remove two cards.  They must then place a randomly selected card down on each project they are participating in, representing their vote.  A red card is a negative vote, a black card is a positive vote.  To determine the outcome of the vote, tally all red and black cards separately, (counting Aces as 1, and face cards as 11).  If the black pips exceed the red by more than double, the ballot passes without need for reconciliation.  If the red pips exceed the black pips by more than double, the ballot failed, and must be re-balloted or withdrawn.  Discard all votes on a failed ballot.  Otherwise the ballot must go through reconciliation (see below).

Reconciling Comments.  During this phase (which immediately follows voting), an attempt is made to clarify the results for ballots which have not yet failed or passed.  Each player is given the floor once again to perform resolution actions.  Members can use their influence to change votes of another member by playing a card of a different color on that member's original vote.  Once the tally of red vs. black votes for a project exceeds the 2:1 ratio, that project has been reconciled.  If it started out in the black, and was passed through reconciliation, then it is concluded, and influence is awarded for it.

If it started out in the red, and was passed through reconciliation, then it is ready for reballoting in the next cycle (but someone must use influence to get it to the next voting stage).

If it goes into the red, regardless of where it started, the proposer and leader must pay influence cards, and the project has failed.

Redeeming Influence on a successful project: Return to your hand each card used to represent your participation, or for voting, and each card used by other members to influence your vote (make it more positive or negative) on a project. Return also to your hand the project card if you are the proposer.  If you are the leader or the proposer of a project, take an extra influence card from the deck.

Budget Crisis

If at any time all influence cards are no longer available (because they have all been distributed), declare a budget crisis.  Each member must contribute one influence card, plus one for each project they have proposed or lead to the organization.  The quarter is immediately closed, and a new quarter starts.  No voting or reconciliation takes place in the closed quarter due to the crisis.

Lapse in Membership

Due to the need to pay an influence card, a member may have to use their "alignment card" to complete an action.  The first time this happens to a member, such a result introduces a temporary laps in membership, and the alignment card is turned face down.  The player can take no actions during any subsequent round, until they have paid their dues.  They do benefit from the first available distribution of influence, and simply return one of those influence cards back to the influence stack.  At this time they then turn that card face up and can resume in play.  The second time this occurs, they must pay two influence cards, and so on.  If they cannot pay sufficient influence within two quarters to return to active membership status, they are out of the game.  A lapse in membership can also simply be declared by the member, in which case they are treated as a lapsed member, and they must pay the influence penalty to return to active play.  

All the cards of a member exiting the game are returned to the discard pile.

Lack of Balance

At any time in which the balance of participation of any one alignment in the game exceeds 50% of the remainder, the game is over.  This can happen through lapse in membership.

Members

Players can enter and leave the game at will.  New players become new members at the start of a quarter, when they are given their initial 4 cards.  

OK, play-testing anyone?

IHE and CCDA Entry Comparison

I just finished my first pass review of the comparison between IHE and Consolidated CDA Entries.  Here are my findings (and recommendations):

• ACT/text is required by IHE to contain a reference to the narrative which is being described by the entry.  HL7 Consolidated CDA recommends but does not require this (Keep the IHE requirement).
• The CCD Episode Observation Template is optional in various places in CCD 1.0, and so included (but not referenced) in IHE, but is not mentioned at all in Consolidated CDA (Leave it unreferenced).
• The severity template is not explicitly referenced in various places where it could be used in IHE (reference it as optional).
• Medications, Immunizations and Supply need detailed review, do medications first.
• There are several places where classCode, moodCode or other structural attributes already fixed by CDA are referenced by the templates in Consolidated.  This is not done in IHE.  (Fix the values because IHE ALSO uses these templates in messages).
• HealthStatusObservation is referenced by CCD 1.0 (and thus by IHE indirectly), but not mentioned in Consolidated in the same places (It was garbage, kill it).
• ValueSet and CodeSystem constraints are strangely missing from my output.  I must have a bug somewhere. I'll need to reprocess the data to address those issues.  Code constraints are present though, so it shouldn't be too challenging to figure out.
• Procedure is also going to need detailed review.

It appears that 4 out of 20 templates are going to need a pretty detailed review, and that 12 of them should be pretty easy, and 4 might need more investigation, but should also be fairly easy.

So, another chunk ready for review.

   Keith

P.S. And today, I applied for admission to the Clinical Informatics Master's program at OHSU.

Real Progress on IHE and CCDA Harmonization

I've gotten to the point where I've been able to compare IHE and Consolidated CDA sections based on MDHT content.  For the most part, my findings are that most sections will not be a huge problem to decide what to do with.

There are some general rules that apply to all sections:

• section/code has a fixed value coming from LOINC
• section/title is present
• section/text is present

The latter most rule may be challenging for some sections like physical examination where subsections are present, but given that it says nothing about the fact that section/text could just contain white space, I could live with it in these cases.

For all the sections in the IHE Final Text, IHE and C-CDA agree on LOINC codes.  We don't necessarily have the SAME set of constraints listed, but that can be normalized.  This is something that just about everyone gets right.

We also agree mostly one what kinds of things belong in each section, e.g., medications in a medication section, et cetera.

The place where IHE and HL7 seem to disagree most is on the structure of a Physical Examination Section.  IHE allows it to be multi-level with subsections.  HL7 allows multiple levels, but doesn't reference the subsections any more as it did in the H&P Note, and requires section/text in the Physical Examination Section.  That's worthy of some discussion when we review this section in the future.

I have a two IHE sections that appear to be missing in the MDHT content:
Assessments Section: 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.4

Procedures Section: 1.3.6.1.4.1.19376.1.5.3.1.3.12

I'll have to model those and rerun.  I'm looking forward to Friday when I can actually present and discuss something to the IHE folks who have been patiently waiting for me to present something.

Here are the major decision points we need to address (with my recommendations):

1. The rules for every section (listed above).
2. The choice of the entries optional section or entries required section (take the best match).
3. Cardinality of Family History Entries; do we match HL7 or require entries (depends on the IHE template).
4. Handling Results: IHE has requirements on content, HL7 has requirements on organizers which require content (shift to HL7 way).

My next step is to look into the entries.  I don't think we need to worry about documents.  In fact, as best I can tell, documents are national extension content.

Patient Access Summit II

Thursday of last week, I spent a half day in the Indian Treaty Room of the Eisenhower Executive Office Building.  I was joined by at least 50 others, including patients, health IT vendors, healthcare providers, and quite a number of federal agency staffers, as we talked about the next steps for providing patients with access to their data.

Kicked off by Matthew Holt (@boltyboy) of Health 2.0 fame, and hosted by Todd Park and Farzad Mostashari, this meeting was a followup from last year's Patient Access Summit (which I also attended with my daughter).

We reviewed the progress we've made since our first meeting (about a year ago), and identified the things that we still need to work on.  As an outcome of this meeting, we identified six separate gaps to address:

1. Awareness:  More needs to be done to raise awareness among patients, providers and health IT vendors about patient rights and technology available to access data, and Blue Button Plus alignment with Meaningful Use incentive programs.
2. Services:  Identifying needed services (e.g., data reconciliation and filtering), and prioritizing them was another issue.  We expect that industry will develop services as the needs are identified.  In other words, the ONC role here is more to shine a light one what is needed.
3. Trust. "Trust me", and "I'm here to help" are two statements that get even scarier when you start them off with "I'm with the government".  There's a lot that needs to be done to develop trust.  Some of that is time, and some of that is awareness.
4. Provisioning.  This is more about provisioning patients, and/or making it easy to provision patients with a Direct address, or an identity supporting OAuth 2.0.  It was focused on workflow and user experience rather than technology.
5. Pull.  We need data holder participation, and when we asked for it, a number of them (in fact, about 1/4 of the room) raised their hands.
6. Payers. There's an interim payer specification that we'd like to see payer's start using, and a need to get that on a standards track.

In reviewing the list of gaps, one thing that Farzad noted was that we didn't have any issues around standards needing to be developed, which was a big different from where we started a year ago.

I did manage to leave Farzad speachless when I asked if we should hold our calendars open for Patient Access Summit III next June.  Next year, I think we need to be in the West Wing.

IHE and HL7 Jointly Balloting Healthy Weight Profile

On Monday, IHE announced the opening of its Public Comment period for several profile proposals.  Today, HL7 announced an out of cycle ballot occurring concurrently with the IHE public comment period ON THE SAME CONTENT.  This is part of the pilot process announced by the two organizations earlier this year.

The purpose of this out of cycle ballot is, as explained in the announcement, is to help IHE and HL7 understand the mechanisms necessary to jointly ballot material, and at the same time, to obtain more input for IHE on profiles using HL7 standards.

Getting this ballot together was a bit of a challenge, but we (IHE and HL7) did manage to make it happen, and we already have a list of things that we can do to simplify this in the future.

   Keith