There's a Reason for That

We set up the IHE Interoperability Demonstration at HIMSS today, and will put the polishing touches on it tomorrow. This is looking to be the best demonstration in the last 6 years that I've been a participant. There will be a lot going on this week and I'm looking forward to it all.  There's a reason for that, and that is pretty much the theme of this blog.  It started this morning...


As I entered the hall this morning and asked directions to the IHE Showcase, someone told me about the shortcut between Hall B and Hall C.  It's the best way to go he said, because we put the Interoperability Showcase at the other end of the hall.  "I know,"  I responded  "you do that every year."  He replied "There's a reason we do that..." and before he could finish I told him what it was.  The IHE Showcase draws something like 10% of the HIMSS attendees to it, and they want to pull people through the exhibit hall, so they put the big attraction at the other end of it.

It sounds like good marketing strategy to me.  This is also the reason that several vendors I know set up their booths around the showcase (even one vocal IHE detractor I know did that for several years).  They realize that is the place to be. 

There is a reason for that.  I watched six years aog as the sole HIE core service that we'd accidentally created attracted all the attention that year (and, yes, I will forgive Bill, someday..)  Five years ago when we demonstrated XDS as a profile instead of an accident, an analyst told one of the profile authors that we'd just invented a $2 billion dollar a year business worldwide.  I've seen that busisness blow past $2b a year in the US alone a couple of years ago (see the HIMSS Analytics database), and heard estimates that it was nearly $12b a year globally a year or so ago.

There's a reason for that:  Show me any other technology that can have such an impact, and that is deployed in so many places around the globe, and is available from so many different vendors.  You can see it right here at HIMSS at the Interoperability Showcase, and around the rest of the world. That map is about to explode again.  There are about 30 different organizations using NHIN Connect, which is based on the IHE XDS profile.  Only a few of them are on that map today, but I have a mission this week to go find them and put them on it.  That will be pretty easy, they are right next to the Interoperability Showcase.

Tuesday will be very busy for me next week. There's a reason for that too.  From 1-2pm I'll be at the IHE Patient Care Coordination Committee informational session.  If you want to learn more about this domain, and what it has to offer, drop by for an hour and hear about the work we are doing, and how you can freely participate.  From 3:30 to 5:00 I'll on one of the several "meet the bloggers" panels along with some other industry notables (some much more well known that I am).  After that, one of the two presentations I'm on for this week will be the PCC update on Tuesday afternoon.  We will do something a little bit different in the presentation this year, but that's because we've done something special this year.  Come find out what we did Tuesday at 4:45 in Theater B at Booth #233 in Hall C.

I hope to see you there.  If I don't see you, I hope you have a good reason for that.

   Keith

Public Comment Period to Close Tomorrow

Tomorrow is the deadline to comment on the last round of HITSP documents.

    Keith

---

Document Number: HITSP 10 N 461

Date: February 1, 2010
TO: Healthcare Information Technology Standards Panel (HITSP) - FOR REVIEW AND ACTION
Public Stakeholders - - FOR REVIEW AND ACTION
FROM: Michelle Maas Deane HITSP Secretariat, American National Standards Institute
RE: Public Comment Period Begins on Interoperability Specifications (IS), Technical Note (TN), Capabilities(CAP) and other construct Documents

The Healthcare Information Technology Standards Panel (HITSP) announces the opening of the public comment period for the following Interoperability Specifications (IS), Capabilities (CAP), Technical Note (TN) and other construct documents:

· IS07 - Medication Management Interoperability Specification
· IS09 - Consultations and Transfers of Care Interoperability Specification
· IS11 - Public Health Case Reporting Interoperability Specification
· IS91 - Maternal and Child Health Interoperability Specification
· IS98 - Medical Home Interoperability Specification
· CAP93 – Scheduling Capability
· CAP119 - Communicate Structured Document Capability
· CAP135 – Retrieve and Populate Form Capability
· CAP136 - Communicate Emergency Alert Capability
· TN907 - Common Data Transport Technical Note
· TP13 - Manage Sharing of Documents Transaction Package
· C28 - Emergency Care Summary Document Using IHE Emergency Department Encounter Summary (EDES) Component
· C80 - Clinical Document and Message Terminology Component
· C83 - CDA Content Modules Component
· C148 - EMS Transfer of Care Component
· C154 - Data Dictionary Component
· C162 - Plan of Care Component
· C165 - Anonymize Long Term and Post Acute Care Assessment Data Component
· C166 - Operative Note Document Component
· C168 - Long Term and Post Acute Care Assessments Component
· C170 - Vital Records Component

The public comment period on these documents will be open from Monday, February 1st until Close of Business, Friday, February 26th. HITSP members and public stakeholders are encouraged to review these documents and provide comments through the HITSP comment tracking system. The documents and the HITSP comment tracking system are located on http://www.hitsp.org/.

As stated at the HITSP Panel meeting and in document HITSP 10 N 459 – No-cost extension to the HITSP contract, there is currently no plan for formal disposition of the comments gathered, and such work will be deferred until the resumption of normal HITSP activity. ANSI will export all comments gathered during the comment period, and publish them on the HITSP public website for broader access by members and industry.

Notes on Certification

One of the questions I get asked a lot is "What version of C32, C83 and C80 specifications" should I be using to meet the certification requirements in the IFR.  The HITSP Care Management and Health Records TC waited to see what the Standards and Certification interim rule would look like BEFORE we finished updates to them.  The HITSP Panel Approved 2.0 releases of C83 and C80 were written AFTER we saw the rule, and contain provisions in them that SUPPORT that rule.  Prior Panel Approved versions (e.g., 1.1) of these specifications DO NOT contain these provisions.  So, if you want the best that HITSP has to offer for certification under meaningful use, use the 2.0 versions of the HITSP C80 and C83 specifications in your CCD implementations.  Take note: the CCHIT Comprehensive Certification still talks about Version 1.1.

The other question I get asked about a lot is what certification will look like, or how it will work.  I still don't know, because we haven't yet seen the promised rules.


Certification is a critical component for HIT products that must be completed BEFORE providers can take advantage of incentive payments.  It's nearly the end of February and we are still waiting on the proposed rule for Certification for Meaningful use.  This has a pretty significant impact in a couple of ways:

1.  The proposed rule will likely have a 30-60 day comment period.
2.  That will be followed by at least a 30 day period to consolidate comments and generate a final rule.
3.  That final rule will likely have a 30 day period before it goes into effect.
4.  Certifying organizations will need to align their processes with the certification final rule...
5.  Which may include certification of the certifiers...
6.  Finally, products will need to complete certification...

If each of these steps is required, and takes at least a month, we are still six months away from having certified products under meaningful use.  That means maybe this summer we could see certified products.
Yes, CCHIT is going to certify products -- twice if it needs to, once to see if they meet requirements under the current IFR, and a second time if needed to address any gaps.  That certification isn't the same without the finished certification process regulation.

We are told to expect a Final Rule based on feedback to the Interim Final Rule this Spring (April - June).  That Final Rule could change certification requirements, although any major changes seem to be pretty unlikely.  Finally, the rule for Meaningful Use Incentives could also be finalized this spring, which could effect any sort of additional certification that goes over and above the Meaningful Use certification requirements.  That means that step 4 will require synchronization with the Final Rules, which could mean certified products would be available in the fall.

At our current rate, EHR products could still be certified before the end of this year, but not if we keep adding delays.   I've heard recently that ONC wants to get public input on certification processes before they even public a proposed rule, which could delay things further.

Because of the way these processes work in government, it's very difficult to get any idea of what is going on.   During the development of regulation, the government basically acts like a black hole for information.  Lots of it may be going in, but nothing comes out until they are done.  I understand the need for this, but I very much wish that a SCHEDULE could be published so that the industry would have some idea what is happening.  A high level schedule with planned (but not promised) dates conveys very little about what is being done, but at least helps the industry to plan. 

At this time, I'm expecting another "Vacation Surprise" from HHS and ONC just like I got for Christmas last year.

Upcoming online Open Forum on ICT Standardization and eHealth

This Thursday I'll be participating on an open forum on Internation Communications Technology standardization as it relates to eHealth.  The forum is being put together by Talk Standards.  You can find the announcement for the forum here.

The forum will be trying to address these questions:

• How can ICT standardization best contribute to the development of eHealth services and systems?
• What important lessons can be drawn from experiences around the world, including Europe and the USA?
• To what extent should governments intervene in the standardization process to reach eHealth objectives?
• Is it feasible that ICT standards enable patient choice and mobility; also across international borders?

I'll be contributing some of my experiences on international standards efforts and government initiatives in the US.  I hope to see you there.

    Keith

What is in a Name?

“	What's in a name? That which we call a rose By any other name would smell as sweet. -- Romeo and Juliet (II, ii, 1-2)

For some reason, naming things seems to be a really important act.  I have far too many years of experience as an engineer dealing with these names to really be offended, when, at the very last minute, marketing changes the name of something in a user interface, and we have to search and replace all occurences of the name used to explain it in all documentation and UI code.  As you can tell, changing the name doesn't change it's behavior, but it often does change the perception.  Engineers often use the duck test when they name things.

“	If it looks like a duck, swims like a duck, and quacks like a duck, then it is probably a duck. -- Various

Names are interesting because how you name something says something about your point of view.  Engineers name things based on how the code works.  We do things like create whole models of the world or significant parts of it (e.g., the HL7 Reference Information Model or the ebXML Registry Information Model) that are made up of reusable parts based on how those things act when we have to code them up.

Other people who have to use these systems are more interested in other attributes of the thing.  How they are used in a specific business context, or what policies and procedures must be developed around them (The business viewpoint).  What information they convey about a thing, and what specific attributes make this thing different from that thing (the informatics viewpoint).

Unfortunately, in just about all software engineering disciplines, all the good names are already being used. So the same names sometimes get used in the engineering viewpoint as in another viewpoint.  This can often create confusion because using the same name doesn't necessarily indicate the viewpoint of the namer.

Discussions around the names of things help when they expose these different viewpoints, and illustrate the different behaviours.  They can become divisive when there is a lack of clarity around which viewpoint is being discussed.  A current discussion in IHE is around the distinctions between a care plan used in nursing, and another plan used to coordinate care for chronic conditions.  There are of course, different points of view, and unfortunately, we aren't necessarily clear about which point of view is being discussed.
 
From my perspective (an engineers viewpoint), the care plan and the coordination plan require a lot of the same behaviours be coded into the expression of the thing.  From the perspective of others, the behaviours are different.  The frequency at which the plan gets updated varies depending upon whether the plan is being used to support inpatient care or to manage care for a chronic condition from a different setting.  The determination of that frequency is a business decision based on policies necessary for appropriate care in each of these settings.  Does that mean I have to change the code I use to manage it?  Not necessarily.  Quite often, business rules are dealt with separately from the rules about representation and storage.  So, I'd like to call it a care plan ... from the engineering perspective.  But if I don't expose that perspective to others, and it doesn't use the same business rules, then its identity becomes confusing.
 
We have a similar problem in HL7 Version 3 constructs.  The HL7 RIM describes things from an informatics viewpoint.  We have acts and observations that describe the bits and pieces that make up a medical record described in a way that makes it easy to compute with things, and to expose similarities between things like problems and allergies.  However, these names in the RIM don't address differences in business rules around them, or perhaps even the engineering viewpoint.
 
A perfect example of where the informatics viewpoint and the engineering viewpoint differ in Version 3 are the distinction between codes and identifiers compared to how those same things are represented in HL7 Version 2.  Version 2 was much closer to the implementor viewpoint, and so a coded concept (CE) and an identifier (CX) both had a component called ID which was the identifier of either A) the concept or B) the thing to be identified.  In Version 3, the coded concept data type no longer calls the code value an identifier, even though it still identifies a concept from a specific coding system, and the II data type uses a term ("extension") completely different from "identifier" to talk about the part we (implementors) normally think of as the identifier part.  When I teach these data types, I start with identifier, explain how the parts map to the things that implementors think about, and then explain code and show the similarities.
 
The purpose of the Micro-ITS is to make HL7 Version 3 easier to implement by exposing names of things using a different viewpoint.  The use of these different viewpoints is important because the implementors of HL7 Version 3 are NOT by and large, informaticists.  They are for the most part, software engineers and interface developers who have some experience with the business viewpoint in healthcare.  Trying to make them conform to the "informatics" viewpoint is proving to be counterproductive.  Informatics is a 2-3 year graduate degree program, but you don't need to have that background to implement an interface.
 
Being able to look at things from different viewpoints is what the thing formerly known as SAEAF, and now known as SAIF (The Services Aware Interoperability Framework) is helping HL7 to do.  Understanding what viewpoints are exposed and when and where they are discussed in the specifications you are working from will help people to better understand what we are talking about.
 
So, when you are discussing names, remember that one of the things in it is an associated viewpoint, and that it is important to expose and understand that also.

Subsets and Value Sets

The HITFACA Blog reports:
On February 23, 2010, the Vocabulary Task Force established by the Clinical Operations Workgroup of the Health IT Standards Committee will hold a public hearing on “Vocabulary Subsets and Value Sets” as facilitators of meaningful use of electronic health records (EHRs).

And then provides a list of questions which I've responded to below:

1. Who should determine subsets and/or value sets that are needed?
   It depends.  Subsets or value sets are needed for implementation guides and for much broader use cases such as Laboratory ordering and Results.  Consensus standards organizations should be responsible for determining which subsets or value sets are needed for their implementation guides.  Broader use cases may be driven by various initiatives at regional or national levels.  An organization responsible for harmonization of standards similar to ANSI/HITSP should also have a role in identifying value sets.
2. Who should produce subsets and/or value sets?
   Consensus based Standards bodies should produce and MAINTAIN them.  Production seems easy, but a value set or subset that has no maintenance process has no life.  
3. Who should review and approve subsets and/or value sets?
   It depends upon what they are used for.  Primarily the concensus groups of the producer organizations, but in some cases, such as value sets used for quality measures, review and approval could also include organizations like NCQA. 
4. How should subsets and/or value sets be described, i.e., what is the minimum set of metadata needed?
   See HITSP TN903: Data Architecture Technical Note
5. In what format(s) and via what mechanisms should subsets and/or value sets be distributed?
   Value sets should be available in a standard format, such as the Rich Release format used by NLM for RxNORM and UMLS.
6. How and how frequently should subsets and/or value sets be updated, and how should updates be coordinated?
   It depends on their use.  Updates for fairly static value sets should be reviewed at least every five years (ANSI rules uses this figure for reaffirmation of Standards).  Value sets for clinical use should be reviewed and updated at least annually.  Some value sets and subsets may need to be updated quarterly, montly or even weekly (e.g., medications).  Updates may be delivered as a subset containing only the changes in more frequently updated value sets.
7. What support services would promote and facilitate their use?
   Value sets should be available from a Web Service, such as that described in the HITSP T66 Retrieve Value Set Transaction.
8. What best practices/lessons learned have you learned, or what problems have you learned to avoid, regarding vocabulary subset and value set creation, maintenance, dissemination, and support services?
   Building a value set requires a commitment to ongoing maintenance of it.  Dissemination should support both manual download automated retrieval and update.  Support services require that there be a feedback mechanism (such as an e-mail list service) to comment on it.  Public input is absolutely necessary in the creation and maintenance of a value set.  Quick response may be needed for clinical value sets to address issues like H1N1 or new medications or treatment options.
9. Do you have other advice or comments on convenience subsets and/or value sets and their relationship to meaningful use?
   Isn't this enough...
10. What must the federal government do or not do with regard to the above, and/or what role should the federal government play?
    The Federal Government should have a role in the coordination of value set deployment activities.  Presently the CDC, NLM and AHRQ (USHIK) all have some role in the development or deployment of value sets, which includes overlapping distribution, delivery and maintenance responsibilities.  Duplication of these efforts is not useful.  It would be better if there was a single coordinated effort, which could include participation from all of these bodies.
    NLM has appropriate infrastructures for manual download, licensing and deployment.  CDC has appropriate infrastructures for some development of public health oriented value sets.  USHIK has appropriate infrastructures for delivery of knowledge about value sets (e.g., metadata).  To my knowledge, none of these provide for automated computer update of value sets using simple web services such as those described in the HITSP T66 Retrieve Value Set Transaction, but I believe CDC is closest to having that capability.

Birthing of a New Standard

Green CDA has been getting a lot of buzz lately, so I figure it's time for me to add my two bits to the discussion.  First of all, this is a research project by HL7 to determine how to simplify CDA.  The first part of this project is to explore what [human] processes can be used to enable simple expression concepts described in the CCD implementation guide.  It's also an 80% solution that doesn't cover all the complexity supported by CDA or CCD.   Getting past the 80% solution to a full solution is the eventual goal, but that IS NOT IN the scope of Green CDA project in HL7.

If "Green" development continues to require human intervention to "Green" other CDA implementation guides, Green CDA will suffer the same problems that other efforts have.  Green CDA is one example of a μ-ITS on some of the CCD templates, but there are over 500 templates that have been developed for CDA alone, an only a 10th of these are CCD templates, and not all of those are found in Green CDA. Green will not scale through manual efforts alone, and the complexity of the information will cause incompatibilities across different "Green" efforts.  Been there, done that, and have no desire to do it again.

So, the other leg of this research is to examine how the manual processes used to develop Green CDA can be automated through the development of a framework (and governance model) for creating a μ-ITS on an HL7 model that uses templates.   Because of the large number of templates involved, we also need a template registry (another HL7 project) to enable access to all of the template development that's been generated over the past 5 years in HL7, IHE, HITSP, Health Story and epSOS, just to name a quick handful. 

In The Standards Value Chain, Glenn Marshall does an excellent job of explaining the process of developing and implementing standards, and the related time frames. Green CDA isn't a solution that's just around the corner.  Gestation of a new standard isn't sped up by setting unrealistic goals or adding new mothers to help give it birth.

The key concept in CDA after human readable narrative is the clinical statement.  This is a sentence in a machine readable language.  It turns out that machine readability of this language is not quite as important as human understandibilty for implementors (it took me three years to learn to speak it).  Fixing that is going to require invention a new language that works for both audiences.  Research and time are required, as well as technology that can simplify the XML and still support the rich information model needed for clinical decision support.  After all, if we can exchange the information, but cannot compute with it, we've defeated the purpose of the computable clinical statement altogether.

Healthcare is hard.  Making hard problems easy to solve is an even harder problem.  Don't expect a miracle this week, this month or even this year.  Just give it some time, and it will happen.  Continue to watch this space if you want to observe some of the birthing pains.