ONC S&I Data Access Framework

This just showed up in my inbox. It looks like ONC is finally catching up after the latest Whitehouse meeting.

   Keith

---

 Call for Participation

Office of the National Coordinator for Health Information Technology (ONC)

Data Access Framework Initiative

ONC is pleased to announce the launch of a new S&I Framework Initiative, Data Access Framework, on Tuesday, July 16^th from 12:00-1:00pm EST.  This initiative will focus on the standards and framework necessary for clinicians, providers and healthcare professionals to gain access to patient data within their own organization and from external organizations which may contain patient data.   On behalf of ONC, I am pleased to invite your valued participation in the kickoff of the Data Access Framework Initiative.

As the nation moves toward an Electronic Health Records (EHR) critical mass, the ability of healthcare providers to access their patients’ data presents multiple challenges. These challenges include the lack of standard interfaces in which to access data from the organizations’ EHR and a limited set of standards to use when accessing data from external organizations.
 Giving healthcare providers a standard way to access patient data helps improve healthcare quality, which includes improved patient outcomes.  The Data Access Framework will be addressing among others, the following questions:

• Who – who is accessing the data? 
• What – what mechanisms will be used to access the data?  what data is accessed?
• Why – why are they accessing this data?

The goal of this initiative is to leverage existing standards to create a modular data access framework based on the identified business requirements of the community.
The official launch of the Data Access Framework Initiative will be held as a web meeting and teleconference on Tuesday, July 16^th, 2012 from 12:00-1:00 pm EST. Details on the Data Access Framework launch including web meeting access, call-in information, reference materials and the Project Charter are posted on the Data Access Framework wiki.

If you would like to participate in the Data Access Framework Initiative, please review the documentation on the S&I Framework wiki:  http://wiki.siframework.org/Getting+Started+as+a+Volunteer.

Once you have read through the material regarding participation, levels of commitment, guidelines for participation and voting rights,  please sign up to participate in the Data Access Framework Initiative by completing the registration form on the Data Framework Access Join Page.

Your experiences, thoughts, expertise and solutions are critical to the success of this initiative.  We look forward to your participation and getting to know you as part of this new initiative.

John Feikema, Coordinator, Standards & Interoperability Framework - Initiative Coordinator
Mera Choi, ONC Lead, Standards & Interoperability Framework

Office of the National Coordinator for Health IT

What is in a name?

I hardly ever get worked up about what you call some things (whereas I really care about others).  It's not my job to name things, or at least the things that aren't important, like what you'd call a product or service that you are selling.

The discussion I found really amusing today was on the "Is HIE a noun or a verb?"  It really depends on what you are selling I would guess.  If you "are" an HIE, then you are selling yourself, and the services provided by your organization, so you'd probably fall on the noun side of this debate.  If, on the other hand, your customers are "HIE" (noun form), or others who need exchange services, then you'd probably fall on the "verb" side of the debate.

Linguistically, the phrase "Health Information Exchange" parses ambiguously as either a noun or a verb.  The first two words "Health Information" are descriptive of either the kind (of noun), or the subject (of the verb). And exchange itself is ambiguous. As a verb it is the trade of information.  As the noun, it is the act or place where such trades occur.

Does it matter what "we" agree on?  No.  The word will still be ambiguous because usage creates definitions, not the other way around.

One of my followers pointed out that Name = Brands = Function = Market, and referenced Kleenex, Ziplock, Web, Chapstick, Coke and Sharpie.  I'll point out in response that it was the product that came first, then the name recognition that established the brand and subsequently the market.  While the name was important, what made the name successful was the product it was applied to, NOT the other way around.

Arguably, a bad name can kill a good product or service.  But I've never seen a good name save a bad product or service.  In fact, a bad product or service can kill a good name.  Did you see what happened to United stock when they broke his guitar?

Don't worry about the name.  Worry first about the product or service.  Even a silly name can become a great brand, but it never would have happened if the product hadn't tasted so good.

Failure has to be an option if success is to be Meaningful

Anyone familiar with one of my favorite TV shows:  MythBusters has probably heard the expression "Failure is always an option".  Co-host Adam Savage indicates that the principal behind this is that you learn from what you are doing, whether or not you succeed.

Compare that attitude with this most recent report to cross my twitter feed: Alarming Fact: Meaningful Use Dropout Rate at a Staggering 17%.

That 17% figure is staggering only if you aren't thinking about what it means.  17% of early adopters have decided to take an implementation break.  For some of them, that may be a signal that they are giving up, and for others, it might be a well considered strategy to ready themselves for the next stage. As I recall, Meaningful Use is forgiving for early adopters, allowing them to take a year off and still get the entire $44K reimbursement.  Of those 17%, I wonder how many are doing that?

We don't know because that isn't reported in the CMS attestation figures.  You'd have to ask providers what their intentions are.  There's another report that does just that, and finds that 14% of providers attesting to Stage 1 do not intend to attest for Stage 2.   Unlike the author of the first article, I don't find the conjunction of the two findings to be "even more alarming", since the second report simply confirms the results of the first, that somewhere around 15% of providers won't be moving forward (at least as far as incentive $$$ goes) into Stage 2.

Who are we losing?  The only group that this information can be readily applied to is early adopters, because those are the only providers who could have been doing MU Stage 1 for 2 years at this point.  So, my inference here would be that early adopters have a high failure rate.  The author of the first report is concerned because those are also the most experienced.  Another possible explanation here is that it was the ones who tried to be an early adopter but weren't the most experienced who dropped out.  Another possible explanation was that is was the specialty providers for whom Meaningful Use (especially Stage 1) wasn't a great fit.  There are a lot of unscary possibilities, and also some scary ones.  We need more data to evaluate.

Even so, I'm not really all that worried about the Meaningful Use program, and here is why: If failure isn't a possibility, we aren't pushing hard enough.  Failure has to be an option before success is at all meaningful.

   Keith

Principles for Standards Selection

In a discussion earlier today, the topic of principles for standards selection came up.  In determining principles for selection of standards, the first thing to realize is that this is not principally a technical issue, but rather one of policy and governance. The following factors influence choices between standards:

• Cost
  The cost to implement a standard can be measured in currency (e.g., USD) or time and effort, or a combination of both. Costs incurred may involve upgrading or retooling existing systems and infrastructure, licensing fees, or acquisition of new products to support the standard.
• Suitability to Purpose
  Suitability to purpose is a measure of quality of the standard with respect to the purpose to which it is being used. This factor addresses “functional” requirements. A standard that is ill-suited to a particular (not designed for) purpose may still succeed, however, it will likely not have the same return on investment. Using a standard that is perfectly suited to a specific purpose does not guarantee success either though.
• Availability
  Availability is most closely associated with cost and suitability to purpose. A standard that is “perfectly suited” to a particular purpose, but not widely implemented will cost more to deploy than one that is already available in existing products.  Availability is often a better measure than costs or suitability alone because it allows the market to find the right balance between these two factors.  Availability is not just with respect to "this instant in time", but also addresses the future.  You may choose a standard because even though it isn't widely deployed now, it is expected to be in the future.  That's a choice based on availability.
• Standing
  The standing of a standard addresses “non-functional” issues regarding the “quality” of the standard. These often have to do with how the standard is developed, it's "openness", its structure, the methodology used to develop it, or its recognition by other bodies (see also alignment with other policies), and its current buzzword compliance.  Common questions addressing standing are: Is it developed by a consensus-based standards body? Who maintains it? What other organizations use it?  Is it Service Oriented?  Is it RESTful?  Sometimes questions of standing overlap with ones of policy alignement.
• Alignment with Policies
  Policy alignment addresses issues with whether the chosen standard is aligned with, against, or without interfering with other policies. An alternative way to look at it is whether the choice of standard would be impacted by a change in policy. Some choices are “policy neutral”, that is, choosing those standards neither advances, nor interferes with implementation of a specific policy. 

Balancing these factors is necessary. No single factor always takes precedence in decision making about terminology (or any standards for that matter).  However, there are certain principles that can be reasonable developed:

1. Pay Attention to Policy
   Making standards choices which fly in the face of recently established policy is not a good idea. However, there are some fairly narrow lines to be navigated here.  Rarely is it the case that the policy being aligned with is directly related to the purpose for which the standard is being chosen (because if it was, the policy would simply be applied and there wouldn't be a choice of standard to begin with).  A perfect example of this in the US is the selection (by policy) of ICD-10-CM for diagnoses in administrative transactions as compared to the selection of SNOMED CT for clinical content.  In this case, "suitability to purpose" trumped policy alignment.
   When there is a policy, or a policy making body already charged with making choices in the area where the standard is needed, it is wise to consult with them.  You might not agree (I've been known to take issue with some of our national policy making bodies), but at the very least you need to consider what they are doing when making your choices.
2. Where do you stand on standing?Figure out what is acceptable and what is not?  Must it be developed by a consensus-based SDO?  Is formal governance necessary?  Is International necessary, or is National good enough?  Do you like HL7 and hate IHE (or vice versa).  These are all decisions based on standing.  Use this to set the boundaries between what is acceptable and what is not, and don't let it further influence your decision making.  Realistically, the "fine detail" it isn't a huge factor when you go to implement.  Frequently, fine detail is simply an excuse to exclude one body or another, especially since there are few ways those details can be measured by anything other than subjective criteria.
3. Cost at the start and the end.Issues of cost should be addressed at the beginning and the end of the discussion. Ignoring all other factors, how much does cost matter? If the answer is that you have no budget to acquire the standard (or license to it, or whatever it is you need to use it), then free becomes the only possible answer.  And again, at the end, having considered all other factors, which path will cost the least?  Like "standing", let cost set boundaries.
4. Focus on Suitability to Purpose and/or AvailabilityIf you are in a green field, go with suitability to purpose. In a brown-field, you have to decide whether "status-quo" is acceptable or not.  If the status-quo is acceptable (and you like it), focus more on availability.  If not, focus more on suitability to purpose.  That doesn't mean you should ignore one or the other, you simply need to decide how much weight to give it.

The choices you make for one project will differ from those you make on a different one.  Even within the same project, you might make a different set of choices because of where you land on the acceptability of the status-quo.  After you've made all of these decisions, then you can get down to the business of making technical choices, but usually buy now, your choices have been narrowed down to one or none already.

Evaluating Open Source Software for HealthIT

This post is about learning how to fish.  I don't plan on providing dinner ;-)

There are a number of different open source software (OSS) products available that support IHE and HL7 profiles.  Some of that is used by widely known hospitals, integrated delivery networks, or health IT vendors.

How can you tell which OSS components are worth looking into?

1. Who is working on it?
This is a big tell.  There are several IT vendors which strongly support OSS initiatives and basically staff open source projects with small teams.  The affiliation of the OSS project committers will often tell you what organizations are backing the project.  If you can also find evidence that they use the OSS in their own offerings, then you have an even better signal.

2. Recency of Updates?
When was the project last updated?  How frequently do they ship new releases?  A project that ships new releases 2-3 times a year for the past six years is much more viable than one who has only two releases in the same time period.

3. How big is the team?
Are you dealing with OSS developed by one person, or is this a team effort?  Don't get me wrong.  Really good OSS can be developed in a one person effort, but not everyone is a James Clark (a well known contributor to OSS in the SGML world).

4.  What does the defect tracking system tell you?
If there isn't a defect tracking system, walk away.  If defects have been reported but nothing has ever been done about them, walk away.  If there are a bunch of defects reported, that's almost surely a good sign.  You can find out at least two things from defect reports: Who uses the OSS product, and how responsive the team is about the defects.  Fixes may not happen overnight, but if defects are responded to quickly, that is a good sign.  Response need not be a problem resolution.  Some problems can take a long time to fix.  But at least the initial assignment and analysis should be fairly quick.

6.  How many other OSS projects rely upon it?
In my own list of Open Source XDS implementations, the IHE Profiles project under Open Health Tools really stands out because there are about a half dozen other OSS projects I've run across using one or more of its components.  Similarly on the CDA side, there are four different projects that I can think of that are making use of MDHT.

7.  Finally, has it done any public testing or certification?
Testing and certification are fairly extensive undertakings.  Few OSS projects are well enough resourced enough to undertake such efforts.  Those that do are worth checking out.  For example, OHT attended an IHE Connectathon in 2010 and tested a dozen profiles.

With a little bit of digging, you can readily identify the best open source projects to use, and figure out which ones are keepers, and which should be thrown back to grow some more.

The Calm Before...

I have no great wit to share today, just quiet.  I'm looking forward to my vacation this summer.  At the same time, it leaves me with precious little time to finish up several projects that need to be ready before I go.  Even so, at this stage, the only projects that I'm working on are ones of my own choosing, not those that others have subjected me to (or at least at this stage, my subjugation to those projects is now complete).

We'll be spending a week+ in England this summer.  I'll be meeting my family there on the way back from another international trek.  I'm looking forward to spending a week and more in the home of Shakespeare and Doctor Who.

And when I return, I'll have barely enough time to head to Chicago and Montreal in the same week for IHE and HL7 meetings. Somewhere in the coming weeks I need to find time to update a book chapter, and if all goes well, start a grant project in my hometown at the start of the next month.  And in a few more days, the very last piece of paper is expected to arrive at admissions to move me into yet one more step of my career. But all that turmoil can wait just a little bit longer.

Right now, at this very instant, all is quiet.  I have a moment or two to listen to the thunder and await the rain.  I can hear the frogs.  I try to close my eyes and focus so that I can see the future, so that when I have the time, I can make it happen.  But nothing comes.  So, I'll enjoy the quiet, and not confuse it with peace...

News from IHE USA

This just crossed my desk. The most important part of this announcement is in the first paragraph. When IHE USA had negotiated the dates for last year's connectathon, they also scheduled a year ahead. Unfortunately, that wound up being right on top of the HL7 Working Group Meeting. Enough members complained that it was changed. Thanks IHE USA for listening!

The next most important part is about the "Interoperability for Dummies" book.  No, they aren't kidding.  A free e-book on Interoperability, written for your boss (or his or hers).  I can't wait for my download.

   Keith

---

 

 New Dates for IHE NA Connectathon 2013 Announced!

IHE USA has announced new dates for the IHE NA Connectathon 2014- January 27-31, 2014 at the Hyatt Regency in downtown Chicago. For more information visit IHE USA’s website, or download our new CAT flyer. Registration opens on September 23, 2014. Mark your calendars now.

NA Connectathon 2014 & HIMSS14 Interoperability Showcase: An Introductory Webinar

June 27, 2013 11AM – 12:30PM CT| REGISTER NOW!

First time participant? Learn how your organization can participate in the IHE NA Connectathon. Prepare for successful testing by joining us for a two-part webinar on the HIMSS Interoperability Showcase and IHE NA Connectathon. Review the full educational session online. Registration is free for attendees.

Digital Dentistry testing at NA Connectathon 2014- Vendors of dental systems are invited to participate in testing their systems for conformance to the new interoperability standards at the IHE NA Connectathon 2014 in Chicago. Annually thereafter, the American Dental Association (ADA) and IHE will hold the Connectathon for vendors of digital dental health care information and imaging systems to test the implementation of interoperability standards. Read the full article.

Educational Opportunities to Learn More about IHE:

Uncover the Power of IHE! Download your copy June 26^th
IHE USA is proud to announce the upcoming release of our exiting eBook, Interoperability for Dummies, IHE Edition. Learn how you can leverage IHE profiles to achieve health information exchange, enhance your business, and improve quality care for patients. The complimentary eBook will be available for download this June 26th! Read our press release.

Interoperability in Action, IHE Virtual Event- June 26, 2013 11AM – 2:30PM CT| REGISTER NOW!

IHE Profiles are the foundation for interoperability and integrated care. Experience the promise of interoperable healthcare in across multiple diagnostic specialties, providers and workflows that positively affect patient care. Vendors in healthcare IT are advancing interoperability by implementing IHE Profiles and leveraging IHE’s global testing grounds, IHE Connectathons. Learn how your organization can utilize IHE’s free profiles and testing methods to develop new integration products. Attendees of the IHE International Academy for Interoperability will receive a complimentary copy of IHE USA’s new eBook: Interoperability for Dummies, IHE Edition.

IHE International Educational Webinar Series- Discover the latest IHE profiles!

Join us for the annual IHE Educational Webinar Series. This series will provide you and your organization an update on IHE Domain's latest profile development. Learn about IHE, become engaged in IHE development and testing activities, and leverage IHE solutions to develop and implement interoperable health information technology. These educational events are available to you FREE. Visit the IHE USA website for the complete listing. Register Today!

Questions?

Contact IHE USA at secretary@iheusa.org or IHE International at secretary@ihe.net. 

The five stages of engineering

I need ...,
you can't ..., do you really have to ...?
I can't believe that ...,
This really sucks, I don't know why we ever ...
Couldn't we just ...,
What if we ...,
Actually ... , no, but ...,
What would happen if ...,
Yeah, now if we ...,
oh shoot, that won't work ...,
but wait, what if we ...,
yeah ....,
yeah ...,
OK, let's look at it again ...,
Did we get it?
Yeah.
Yeah, and now we can do ... too.

Sound familiar?  There is a pattern here

Some one gives you a integration problem.

• First we try to avoid it.
• Then we get angry.
• Then we negotiate (and succeed)
• Finally we get excited.
• And then we accept the requirement.

There's an alternative pathway:

• First we try to avoid it.
• Then we get angry.
• Then we negotiate (and fail)
• We get depressed.
• And we accept that it cannot be solved.

The alternative pathway is exactly the five stages of grief, and is what we'd like to avoid.  The first pathway is what I'm now calling the five stages of engineering.  The simple difference between successful engineering and engineering that comes to grief is how well you execute the 3rd stage.  And more often that not, the key to success in the third stage is simply in how much time and effort you are willing to spend in the third stage before getting to success.  After all, admitting to failure is easy.

   Keith

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

Slacking Off?

Not really.  I've just been finding it hard to write blog posts and code and specifications and go to training and ... all at the same time.  Since Sunday I think I've had an average of 4 hours of sleep a night.

What's going on?

Let's see, IHE just released some profiles that you should comment on.  HL7 and IHE are working on their joint balloting initiative, expect some news soon.  I've been providing some feedback for the HL7 Board about implementer's use of HL7 Standards and Open Source.  The ABBI PULL workgroup has been moving along without me for the past few weeks, but they are still making progress.  I'll get an update on that project tomorrow after I meet up with a few folks in DC to follow up on this meeting.  It's nice not to be the only person writing code on that project, but now I've got a ton of catching up to do to get my code back in shape and shift it to another repository.  HQMF is moving along.  We've been addressing some of the trickier editing bits over the past couple of weeks.  I owe them some text which I hope to get out this week.  I've been dealing with a bunch of questions about Consolidated CDA and QRDA lately as I run into some trickier implementation bits.  One of our engineers found a bug that makes some QRDA templates not possible to be used with some CCDA templates, but that will be addressed in a future release of CCDA, and there is interim guidance on that coming from HL7.  We found another issue in a bit of a model in MDHT, but that bug has been reported (it's an XOR constraint on author/assignedAuthor and author/representedOrganization that should be OR instead).

I just booked my summer vacation to London in the 10 days between delivery of a major milestone in one project, and IHE  Meetings and the HL7 Board retreat (the same week unfortunately, so I'll be missing half the IHE meeting).

That means I need to get my code working for the CDA Harmonization project done by the end of the month and start generating the profile content.  I've gotten to the point that I know I can get the differences between the sections, its just, as a former colleague used to say, a simple matter of writing the code.

I have another major deliverable due for an internal project, also by the end of the month, and a third due for another international project.

I have to finish up my application for attending the Master's degree program.  The two remaining bits are my letter and my transcripts (I took the GRE's last week).  The letter should be done this week, and I should have the transcripts on their way by then as well.

IHE PCC is going to be looking for a new planning cochair this year as I step back for a couple of years to focus on my degree (and address the fact that I've been a cochair for eight years, 4 in technical and 4 in planning).  If you are interested in the position, let me know.

I'm trying to get my house ready to go on the market, because my mother wants to move in with us.  We are thrilled, but there are a slew of small projects that need to be done.  Fortunately, I had a good year, and can do them.

I just accepted a small writing gig to update a chapter in a book that's a few years out of date, and have to figure our where that fits in.  Oh, and send them the paperwork.

I spend last Sunday in DC for the third annual DC gathering of The Walking Gallery.  It was way too short, and while I could have spent the rest of the week in DC, I had training scheduled for Tuesday through Thursday.  I'm bailing on tomorrow mornings training because after I scheduled the training I was asked to attend another meeting, and it was one of those invitations that you don't turn down.

All in all, life is busy, but also good.  I'm certainly looking forward to vacation in England.  We'll be staying at a friend's place a bit more than a hour from London.  I can't wait to get home from this trip.  And I need a nap, but that's what planes are good for.

Anyone heard of any progress on cloning technology?

IHE Profiles for Public Comment

This finally arrived in my inbox. I encourage you to comment, especially on the Internet User Authentication profile (profiling OAuth 2.0), and on the CDA Harmonization (which discussion methodology by which the profile will be created, and how IHE will version templates).

Keith

---

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for public comment in the period from June 3 through July 3, 2013: Document Sharing Metadata Volume 3, Section 4 Redocumentation Document Metadata Subscription (DSUB) Internet User Authorization (IUA)  The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by July 3, 2013 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation version of the supplements. Comments can be submitted at http://www.ihe.net/iti/iticomments.cfm. IHE Patient Care Coordination Technical Framework Supplements Published for Public Comment The IHE Patient Care Coordination Technical Committee has published the following supplements to the IHE Patient Care Coordination Technical Framework for public comment in the period from June 3 through July 3, 2013. CDA Harmonization (CDAH) Early Hearing Detection and Intervention-Workflow Definition (EHDI-WD) Patient Care Plan (PtCP) Referral/Order Linking (ROL) The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by July 3, 2013 will be considered by the Patient Care Coordination Technical Committee in developing the trial implementation version of the supplements. Comments can be submitted at http://www.ihe.net/pcc/pcccomments.cfm. IHE Quality, Research and Public Health Technical Framework Supplements Published for Public Comment The IHE Quality, Research and Public Health Technical Committee has published the following supplements to the IHE Quality, Research and Public Health Technical Framework for public comment in the period from June 3 through July 3, 2013. Data Element Exchange (DEX) Healthy Weight (HW) Research Matching (RM) Vital Records Death Reporting (VRDR)  The document are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by July 3, 2013 will be considered by the Quality, Research and Public Health Technical Committee in developing the trial implementation version of the supplements. Comments can be submitted at  http://www.ihe.net/qrph/qrphcomments.cfm.