Observation of the Week

What's wrong with this list:

Vehicle Type:

• 4-Cylinder
• Commercial Truck
• Motorcycle
• Hybrid

One of the problems is that the value set for this data element covers five different axes for classifying the vehicle: Number of engine cylinders, use and body style of the vehicle (in one term), skills needed to drive it, and type of engine.

These are accentuated by the fact that the data element itself isn't well described. If it had said "vehicle cylinder count", "vehicle use", "body style", driver's license type, or engine type, it would be much more clear how this particular data element was to be used.

I have had four separate discussions with different groups on data elements that use the word "type", "kind", "category", "classification" or "code" in the name, where the only other piece of information given was what was being classified. Most things can be classified more than one way, and we usually know in a class diagram what class the attribute applies to. Most of the time I spent with these different groups was in understanding what the definition of the data element meant. By the way, on at least one occasion, drilling into the definition yielded something like: "the XYZ type describes the kind of XYZ that is being used". That's not very helpful ;-(

My design observation for this week is that if you are naming a data element to classify a thing, think not about what it applies to (vehicle), or that it classfies it (type), but rather, how you are classifying it. The implementers of the system you are designing may never notice, but then you'll probably never have to field questions about what "XYZ type" means either. It may save you some time, and it should certainly save them some.

Freely Available Standards

One of the discussions that I routinely have in HITSP meetings lately is about the cost of the standards to implementers. The assumption seems to be that standards HITSP selects should be available for free to the implementers, and this has been raised as an issue for a number of standards that HITSP has selected. When HITSP reviews the standards it selects (in what we call a Tier 2 evaluation), one of the factors is indeed cost for use of the standard. HITSP does recognize that standards aren't always free, but that reasonable costs shouldn't be a barrier to selection. I reproduce the guidance given for tier 2 evaluation below:

"6.7 Favorable intellectual property and licensing terms

The standard produced by the organization should be readily available to
entities for implementation and usage. The standard should be available to most
stakeholders at no or reasonable cost. Code sets or terminologies should have
licensing arrangements, which do not pose a barrier to usage. This
availability should include a willingness to share necessary standards with the
HITSP and its Technical Committees for use in evaluation and, based on further
agreement, in HITSP Interoperability Specifications. When necessary,
evaluation of favorable IP and licensing terms may be applied to individual
standards if the standards organization maintains different terms for different
standards (see 3.0)"

I can see the point being made by those arguing for free access to the standards. This is especially important those in the open source community who do not have a revenue stream to support purchase of standards. However, I also understand why standards development organizations need to charge for their standards. Developing standards is not without cost, and somehow that cost needs to be recovered, or their simply won't be any new standards to use.

One of the proposals that has been suggested is that the Federal government purchase the rights for implementors to use standards that it mandates for use within electronic transactions through various regulations (e.g, ARRA, eRX and HIPAA). The government has already done this for SNOMED CT. This would make the standards freely accessible to implementors and users of the standards, and would also do something to reduce the costs of implementation of Healthcare IT.

Perhaps ONC should consider using some of the funds that it hasn't allocated yet to ensure that the necessary standards are available. Another important aspect of this would be that it would also allow the American public free access to the technology that is being used to support the provision of healthcare. This brings up several questions, including how each license would be negotiated, how value would be fairly apportioned to the copyright holders, and how access to the standards would be provided.

I think these are all interesting topics, and I frankly don't have an answer to any of them, but I do have another related idea that might be part of the framework for resolving these issues. A lot of what we wind up doing within HITSP which naturally flows outwards to the various SDOs is similar to what Canada InfoWay does with their Standards Collaborative. It might be interesting to review the Canadian model, and to think about what a public-private collaborative organization serving a similar purpose here in the US might do to make the standards more available.

It's just a thought...

IHE Public Comment Period Opens

IHE Community,

The following Technical Framework supplements and white papers have been published for public comment.

IT Infrastructure (ITI)
The IHE ITI Technical Committee has published the following supplements and white papers for public comment:

• Document Metadata Subscription (DSUB)
• Multi-Patient Queries (MPQ)
• Retrieve Form for Data Capture (RFD)
• Cross-Community Patient Discovery (XCPD)
• White Paper: Access Control
• White Paper: A Service-Oriented Architecture (SOA) View of IHE Profiles

Patient Care Coordination (PCC)
The IHE PCC Technical Committee has published the following supplements and white paper for public comment:

• Antepartum Record (APR)
• CDA Content Modules
• EMS Transfer of Care (ETC)
• Labor and Delivery Record (LDR)
• Patient Plan of Care (PPOC)
• Request for Clinical Guidance (RCG) and Immunization Care Plan (ICP)
• White Paper: Waveform Tracings
  

Patient Care Devices (PCD)
The IHE PCC Technical Committee has published the following supplement for public comment:

• Implantable Cardiac Device Observation IDCO

The documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments may be submitted to the online forums at http://forums.rsna.org/. To be considered for incorporation in the trial implementation versions of these supplements, comments must be submitted by July 1, 2009.

Of Moon Shots and Progress

I've previously described George Bush's executive order 13335 issued in early 2004 as the initial step in moon-shot for healthcare. In announcing this order, he called for most Americans to have secure, interoperable electronic health records by 2014. I'm not sure his announcement was as stirring and Kennedy's in 1961, but it's still been a tumultuous and exiting time for those of us involved in healthcare.

If you've been tracking what's been going on at the national level for the past five or six years, you are fairly aware of many of the things that have occured since that order, including the creation of ANSI/HITSP as a body selecting standards, CCHIT certifying EHR products, multiple NHIN projects demonstrating the ability of those standards to connect the nation together, HISPC activities to rationalize policy, recognition of selected standards, testing of those implementations, and their actual use in real world projects. The incorporation of much of what was championed by that executive order, and executive order 13410 which followed it into the HITECH legislation enacted under the America Reinvestment and Recover Act of 2009 is yet another significant step forward for all of us.


As we move forward, I've heard several complaints about the "lack of progress", the gist of which are that "we aren't there yet". We still have a ways to go before we are done, as was anticipated when this was originally outlined as a 10-year goal. We are at the mid-point of that goal, and I ask you to look at the successes we've already seen. Many of the HITSP specifications not just prototyped, tested, or piloted, but put into real production and use, and available in real-world products. We'll be hearing later this year from some of those HIEs in the real world who have already implemented HITSP specifications. This year, the CCHIT certification criteria includes several HITSP specifications for the first time. I fully expect to see numerous systems that have already demonstrated their ablilty to implement HITSP specifications become certified for the first time.

NASA took six and a half years from Kennedy's commitment to land men on the moon before the first unmanned launch of the Saturn V rocket into low earth orbit. HITSP's managed to accomplish a similar feat in only 4 years since it's inception.

So in response to "Are we there yet?" I answer "No, we are about halfway, but be patient. We will arrive in due time."

What is HITSP Doing?

The American Recovery and Reinvestment Act (ARRA) has a number of provisions and deadlines which need to be completed by the end of this year. One of these is the publication of a proposed regulation by December 31st of this year. The Office of the National Coordinator (ONC) realized that many of the requirements of ARRA are already supported by publications from ANSI/HITSP, but that these need to be restructured to support the ARRA requirements.

HITSP has been asked by ONC to produce an interoperability specification to support the needs of that office in obeyance of the ARRA law. The accepted publications produced by HITSP to date (those referenced by IS01 through IS12 and IS77) are expected to be used within this specification. The end result is intended to be a simpler publication that addresses the interoperability requirements needed for meaningful use of EHR systems.

As a result, HITSP has formed five tiger teams to quickly produce this information for the HITSP Panel approval by July 15th. The tiger team leadership was selected from existing HITSP Co-chairs and Staff, and approved by John Halamka, chair of ANSI/HITSP. We recieved notification today of who was selected to co-chair the teams.

The five tiger teams are:

Tiger Team	Cochairs
EHR-Context IS	Manick Rajendran, Eze Care LLC Corey Spears, McKesson Mike Nusbaum, HITSP
Data Architecture	Don Bechtel, Siemens Keith W. Boone, GE Healthcare Don Van Syckle, HITSP
Exchange Architecture and Harmonization Framework	Steve Hufnagel, DOD Mike Lincoln, VA Ed Larsen, HITSP
Security and Privacy	John Moehrke, GE Healthcare Glen Marshall, Grok-a-lot Jonathon Coleman, HITSP
Quality Measures	Floyd Eisenberg, NCQA Lori Fourqet, HITSP

The EHR-Context IS team will be developing a new implementation specification, focused on the EHR.

The data architecture team will be focusing on describing the information requirements of interoperable exchanges used by the new IS.

The Exchange Architecture and Harmonization Framework team will be addressing the exchange services and underlying base standards used by the new IS.

The Security and Privacy team will be addressing the Security and Privacy services needed in interoperable exchanges used by the new IS.

The Quality Measures team will be addressing how to exchange quality measures in the new IS.

This is all happening rather rapidly, and new information is coming to light daily. Calls will be held tommorrow and Thursday to kick off the new work for each team. If you are interested in participating in any of these teams and are already a HITSP member, I urge you to contact the leaders of the technical committees that you are a member of to see where you might best assist. If you aren't a HITSP member but want to contribute, please see http://www.hitsp.org/membership.aspx, as we would welcome your assistance in this new work.

I'm especially urging those with experise in data elements used in HL7 Version 2, CDA Release 2, NCPDP and X12 standards, as well as those with expertise in vocabulary, including SNOMED, LOINC, RxNORM, et cetera to participate in the Data Architecture tiger team.

Connectathon Day 4

I didn't keep a log of activities for today, since I was rather up to my ears. So, I'm going to take a few minutes to talk about the Connectathon in general.

One of the best things about connectathon in my experience is the collegial, problem solving atmosphere. We are here to make our products interoperate with each other. It's not about making ourselves look good, or the other guy look bad. The connectathon monitors don't care. If two parties in a transaction cannot make it work, neither one gets credit for it. The people working here truly do work together on solving their interoperability problems.

At connectathon we run into the same kinds of problems that we don't want to appear in the field. Here we have the people that would normally be providing Tier 3 support on such an issue present from all sides of the problem. The only danger here is in failing to pass a test, not dealing with irate customers or losing contracts. This environment is extremely condusive to problem solving, and most of the time before any customer would ever see an interoperability issue in the real world.

Another incentive is that many of us will be going on to demonstrate our work at HIMSS. This is an opportunity for many engineers to appear in one of the most high profile booths on the HIMSS showcase floor. Traffic at HIMSS through the showcase booth has exceeded 8% of attendees for the past four years, and has gone as high as 12%. If these numbers seem small, realize that an Anchor booth is doing good when it draws 3% of the attendees. The IHE showcase at HIMSS is sigificantly smaller than those booths, and has traffic all week long. It also recieves quite a bit of high profile traffic, many in key decision making posts and government policy positions.

I offer the following picture as proof that connectathon makes interoperability a priority over everything else (reproduced with permission of those present). These engineers were working late into the evening making sure their systems worked together.

Connectathon Day 3

Dinner last night was down the street from the hotel after a brief reception honoring the current Director of IHE for HIMSS. After dinner and a short cab ride back to my hotel, I spend several hours catching up on the "day job" and e-mails. I spent fifteen minutes trying to VPN to the office before figuring out that my network card was still configured for connectathon. That was at 2 am. As usual this week, I've stayed up too late.


So, now it is 9:04, and time to reset the network connection for the connectathon.


Just to give you an idea of the processess I have running on this laptop for connectathon:

• Microsoft SQL Server -- Hosting a database I have containing a lot of standards information.


• Oracle SQL Server -- Hosting my EHR application's data


• 2 different Copies of Eclipse -- One used for the web services I'm testing, the other used for interfacing.


• My favorite XML Editor -- which supports XSLT debugging and Schematron validation. I do a lot of both. I used to work with one of the the co-chairs of the XSL workgroup in the W3C, and in the office next to an author of XPath. It has an Eclipse plug-in, but I've found I run out of memory in Eclipse a lot sooner if I use that.


• Acrobat Standard -- Viewing the IHE profile and some JSTL documentation


• A web browser (with about 3 tabs open) -- Connected to NIST's CDA document validator, this blog, and the IHE PCC Web page.


• Microsoft Word, Outlook and Excel -- more documentation, my e-mail containing various connectathon communications, and a spreadsheet I'm using to track testing.

I upgraded the memory from 1Gb to 3Gb last year just so I could get through testing without waiting forever for processes to swap.


9:22 Hmm, I seem to missing some data. Ah, it's the Change proposal we applied this year to address sections that have nothing to report (e.g., no allergies). Need to go fix that.


9:45 "Does a section require a title?" gets fired at me from a connectathon monitor. "Yes, I believe so, let me look it up... wait is this a section defined in CCD?" "Yes." "All CCD sections require a title." However, I note that we need a Change proposal for the PCC Technical Framework to include that requirement for all sections it defines, because not all of them come from CCD.


9:46 "How many PIX consumer tests do we need to do?" "Three." "Ok, I've already done two, I'll go work with ...", "Nope, you can do that later, go work with ... to get them going."


9:50 Overheard: "I basically blew up vendor A's actor B because I didn't have an (indecipherable technobabble)"

10:15 I've usually done this weeks in advance, but this week I'm still writing code for my stretch goal. You aren't supposed to be doing that at connectathon (as one of my mentors observes). However, in my own defense, I was going to drop this profile. Someone asked me to stay in so they can get credit for it. I've been in similar situations before, so I'm going to do what I can.

12:12 Over lunch we discuss the structure of the Public Health Alerting scenarios for the demonstration. The CDC is obviously very interested in this scenario.

1:13 I argue HITSP terminology changes with one of my co-workers. I like simple words that engineers already understand. He thinks that other terms are better. We agree to disagree.

By mid-day, I have my stretch goal done (with one retest required). Since it's a CDA document, and I helped write the profile there's a lot of laughter that I got failed the first time through. Read the free manual...

2:02 This afternoon it's time to do T81 (InfoButton testing) for the public health alerting scenarios. I wrote the test spec, so now I have to follow it. But... but. There's some things I forgot about when I wrote it back in November. We'll deal with that tomorrow. For now, I just update the argument table and resend.

2:45 One of my test partners for this test just got back. He had to take a call (common), and also hadn't realized that connectathon is a casual dress event (unless you are a docent for the connectathon conference which was yesterday), so came back in his jeans. We test our scenario. After about ten code changes (most on my side, and a couple on his), we get it working. It took all of fifteen minutes. We both mispelled Notificiation the same way, but I had corrected it earlier when starting my T81 testing. On my side, it was a copy and paste error from the spec I wrote several months ago. I fix the spec too.

3:43 An engineer asks me what value should go in a particular message. It's in a profile I don't know, so I ask him what the profile says. "I don't know". Well, read the profile, then ask me... I follow up with him later to point him to resources that will know if he's not able to figure it out.

5:00 Time for the HIMSS demonstration meeting. I listen in from the other end of the hall. Technically I'm supposed to be there, but someone else is covering for me, and its the same sort of thing that I've heard countless times before. We also see again the unveiling of the dreaded scenario spreadsheet that will likely be updated several times before the end of the week. It's pretty solid by now so I need to look at it.

7:20 Still here, working through some other problems. One of the systems that we've been having problems with all week was misconfigured. The engineers worked it out and are on to the next issue...

Dinner tonight is at Brasserie Jo. They have a nice collection of Belgian beers, and some interesting food. I had the Shrimp Bag. It's shrimp and vegatables in a lobster sauce, wrapped in Philo dough and baked. Yum!

2:29 AM. Time for bed. Need to get up for an early Domain cochairs meeting.