Tweet

I've been using twitter for quite a while now to communicate with close friends in the standards world. Because I like to see what's going on elsewhere in Healthcare standards, I also started following several healthcare standards tweets and newsfeeds. That's gotten me a number of requests to follow me on twitter, except that my tweets on that account are intended to be personal and to a select group who understand my humor and sarcasm.


So, just like I have a private and public blog, I now also have a private and a public twitter account. If you want to follow my public twitter posts, just follow me here: http://twitter.com/motorcycle_guy. You'll get links to my latest posts from this blog, as well as the occasional short message.


The number of different ways that I communicate electronically:

1. Work e-mail
2. Personal e-mail
3. Public Blog (http://motorcycleguy.blogspot.com/)
4. Private Blog (I use Live Journal)
5. Private Twitter
6. Public Twitter (http://twitter.com/motorcycle_guy)
7. Facebook (used just so I can view others Facebook posts)
8. Work Blog
9. IHE Wiki
10. HL7 Wiki
11. Work Phone
12. Cell Phone
13. Home Phone
14. Skype (while traveling only)
15. Linked In
16. Google Groups


Can you say information overload.

IHE Profiles and HL7 Conformance Testing Tools

This week I'm reviewing a new introductory HL7 Version 2 class that we've been developing for internal staff and our customers. We've had quite a bit of help from staff and volunteers at HL7 in the development of this class, thanks to Karen Van Hentenryck of HL7 and Peter Rontey of the Veterans Administration.

One of the tools we run through in the class is the HL7 Messaging Workbench. This tool can be used to sniff and parse HL7 messages and validate them against an HL7 Conformance profile. It can also be used to create a conformance profile. One of the things that I'd like to see the IHE Testing and tools committee do is to develop appropriate conformance profiles that can be used inside this tool to validate instances of HL7 messages. This would enable people to use the common HL7 Version 2 tools to test implementations of IHE profiles. Numerous profiles from IHE use these messages, including PIX and PDQ from the IT Infrastructure Domain, LWF (Laboratory Workflow) from the Laboratory domain, and SWF (Scheduled Workflow) from the Radiology Domain.

After we create the conforming message profiles in IHE, we could also register them with the HL7 Version 2 Conformance profile registry. This would enable people to quickly find and download the material and use it to test IHE profiles.

Finally, we can make use of the NIST developed Message Maker tool to support generation of test messages according to the published conformance profiles.

If you haven't looked at these tools, and you need to test HL7 messages, you probably should. You can find these fairly easily on the new HL7 Web Site. At the new home page, click on Tools in the Participate box. On the Tools and Resources page open V2 Tools in the tree. By the way, if you are looking for Messaging Workbench, you can find it under the name "Project Workbench".

A triangle has three sides

A triangle has three sides and three angles. Because of several properties, It is necessary and sufficient to know only:

• The lengths of the three sides, or
• the lengths of two sides and the measure of the interior angle, or
• the length of one side and the measures of two other angles and their relationships to that side.

Which of the above is the best model for the triangle? This question has no correct answer.

The complete model of a triangle includes the measure of the three sides and of the three angles. Any model which functionally supports the exchange of sufficient information to determine these features is an adequate model, and functionally equivalent to any other model. The only value one model has over another is its ability to be expressed and exchanged based on available information. If I tell you the three sides of a triangle, can you readily compute the three angles? If you remember more trigonometry than I do, possibly, but if not, then no. If I gave you two sides and the interior angle, and you remembered the formulae for cosine, sine, and tangent, you might be able to derive the formula for the third side, and the two other angles. So, given the context of a limited amount of trigonometric ability, the better transmission might be two sides and the interior angle.

A similar example appears in the expression of the Interval data type. An interval has a start, end, middle and width. It is only necessary to know two of these to establish the correct values for the other two. What is the best model for transmission of this information? This question also has no correct answer without some sort of context. If start and end are commonly available data items, then why transmit anything else. In fact, I find it rare to see information system that deals with intervals as anything other than start and end point in time. The second most common model I find is start and width. I use the convention that all intervals are communicated using start and end, UNLESS only width is known, in which case, that is the only attribute transmitted. This leads to very clear and unambiguous communication. Computationally, I only need to do arithmetic, so I don't even care about how much math is necessary.

Moving one layer up, a similar case appears when dealing with the patient, subscriber and payer participants in a policy act. This is another case where we have a three way relationship. The patient is related to the payor through a subscriber by virtue of the policy. There are implicit or explicit relationships between each of these entities. The patient is a member of the policy. The subscriber is related to the patient. The payer has relationships with both. It is only necessary to know: The relationship between the patient and the subscriber, and the subscriber and the payor to determine the third relationship, between the patient and the payor. Once again, the question of which model is best is specious. The complete model includes all three relationships connected by the policy.

Most HL7 models do not typically include all of these relationships. However, this is extremely useful domain knowledge. This is not just a flaw in HL7, but appears within other standards as well, including those competing standards.

It would be useful to show these relationships within HL7 models more completely. I'd like HL7 D-MIM diagrams to reflect this domain knowledge directly. This would enable more complex decision support because the domain knowledge could be used to infer relationships that can be determined by available data.

At the rim of the dam or the edge of a precipice?

One of the joys of HL7 Version 3 are the many different ways that you can say the same thing depending upon the context of your message. Let's look at a laboratory test result for example. Using the HL7 RIM, this will be encoded as an observation. Using the 2008 Normative Edition there are at least 7 ways within the published standards to say the same thing. These seven different ways appear in the following HL7 Version 3 standards:

1. Care Record
2. Clinical Genomics Pedigree
3. Clinical Document Architecture
4. Clinical Statement
5. Common Message Element Types
6. Public Health Reporting: Individual Case Safety Report
7. Periodic Reporting of Clinical Trials Laboratory Results

The picture below shows how these HL7 standards support this concept slightly differently in each case.



I've shown how the names of the XML Element, and the constraints on the content of the Observation class vary using a bold red font, or where the RIM attribute is missing, a red background. You can get view the same thing here in this PDF.

Each standard has constrained the HL7 RIM Observation class differently. Arguably, there's a reason for this, but I challenge anyone to determine why. I can certainly accept that each of these standards had different requirements, and therefore constrained the model of observation differently. But nowhere in the standard are these specific requirements expressed.

One conclusion that you could draw from this collection of variances is that no one body is in charge of HL7 standards. Another conclusion that you could draw is that the development process doesn't enforce concistency across HL7 domains. Another is that by failing to document requirements, we are allowing our modeling efforts to introduce unnecessary inconcistencies across domains. All of these are fair challenges to the HL7 development process.

I would propose two changes to the HL7 development process to improve the situation:

Provide Architectural Oversight

HL7 has an Architecture Review Board that was reconstituted a bit more than a year ago. The group's charter can be found here. The Technical Steering Committee was also restructured not too long ago, and it's charter is here. From my perspective, the TSC provides strategic direction, the ARB tactical. I would hope that both these groups would be involved in helping to move HL7 in a direction where these kinds of inconcistencies eventually either dissapear from our work products, or can be explained based upon requirements.

We are currently in the process of some strategic realignment within HL7 (i.e., the thing formerly known as SAEAF). I'd like to see some of that realignment pay some attention to how different views and levels allow us to bring more consistency to the HL7 standard. We have to many artifacts pushing towards implementable messages that should be a a higher level of specification.

DICOM has Working Group 6 whose role is to "maintain the overall consistence of the DICOM standard". While working group 6 it is arguably a choke point on the development of the DICOM standards, I am not one to argue that having more standards is better. I'd rather have better standards. I think we need something more like that within HL7.

Make requirements Mandatory (or at least strongly recommended)

I've seen other standards organizations include a stage for formal requirements definition in their process. We could certainly ballot requirements in HL7 as informative documents prior to undertaking any large project. The HL7 Templates work group is presently developing Business Requirements for a template registry. I'm finding that effort to be very interesting, and the end results will be extremely useful.

None of us would undertake a 6-18 month software development effort without requirements. Yet all too often I see our own standards development efforts do exactly that. We mistakenly assume that usecases (storyboards) will cover it, or that the D-MIM is sufficient. The D-MIM should be a realization of the domain analysis model. The domain analysis model should be a reflection of the requirements of the domain. If we don't understand the requirements of the domain (or at least the subset we are playing with), then we don't have any business trying to develop standards for it. If we do understand these requirements, then documenting them should not be difficult.

All too often engineers want to get right to coding, or in the HL7 world, into modeling. Having stated and agreed to requirements will help to set the scope for the development effort. If the models are derived from and expressions of requirements, let's see the requirements. It would be a lot easier to validate a model if I understood the requirements that drove it. Most of the time that I have negatives on a ballot it is because the model doesn't meet my requirements. So, let's put in more effort up front. If we do it right, developing the model should be a cake walk.

Requirements are reusable design artifacts. Having developed and documented them once, you can use them over an over again for similar cases. Having them documented means that you don't have to have the same arguments over again about why X, Y or Z should be included into a representation. I would be able to look at inconguencies in the use of the Observation class in the above standards and trace these back to specific requirements.

SOAP vs. REST and Common Data Transport

Recently there's been several discussions across many fronts on Common Data Transport which has re-energized the SOAP vs. REST debate. Although I don't specialize in infrastructure, I have developed both SOAP and REST-ful web services and would like to add my observations.

Arguments for both abound:

For REST-ful web services:

• can be called by a web page
• can be called from an XSLT Stylesheet (a restatement of the above, but with really useful ramifications)
• are easy to implement using off-the-shelf programming languages and libraries. A REST-ful webservice call can be implemented in a page or less of Java code in a single class.
• Can also be implemented using web page technologies such as ASP, JSP, PHP, et cetera.

SOAP Web Services:

• Have standards based and machine readable interface definitions (WSDLs) that can guide code generation. Most application development frameworks support SOAP.
• Support strong data typing in the information exchange.
• Support routing of web-service calls.
• Layers security into the protocol (e.g., WS-Security)
• Supports reliable messaging
• Are already supported by many healthcare standards

As usual when selecting tools, I would suggest that you select the right tool for the job. Let's take a specific example. Recently IHE created a specification for Sharing Value Sets. This specification is intended primarily to support an EHR's access to a collection of coded terminology. The profile oroginally suggested SOAP, and for various reasons, continues to include SOAP as part of profile. Some of these reasons are based upon the strengths of SOAP, which include the standards-based interface definition, strong data typeing and layering of security that are not readily addressed by REST.

However, there is one use case where this service can strongly support testing efforts that demands a REST-ful interface. IHE uses Schematron to test conformance of content to a specification. Many schematron implementations rely on XSLT. The interfaces defined by the SVS profile cannot easily be called if they support only a SOAP interface. The resolution by IHE was to support both REST and SOAP in the profile, and in noting that this was a "secondary" use of the profile, made REST an option. This was an easy decision because we obtained the benefits of both protocols for the different use cases, and the requirements of the two use cases were in fact different. The latter use did not have as strong a need for security or routing of the request. Testing efforts are done in a very different environment as is loading of vocabulary subsets into production EHR systems.

Yes, SOAP is more complex than REST, but with that added complexity comes added capability not present in the REST-ful framework.

My own answer to this debate is similar to the answer I give on any "religious war". My father told me regularly to pick the right tool for the job. Not everything is a nail, screw or bolt, so you need to have a toolbox that contains hammers, screwdrivers and wrenches. The guidelines I learned from my father were Hammer to nail, screwdriver to screw and wrench to bolt. Yes, you can hammer in a screw, or use a wrench to pound in a nail, but I've rarely been successful in tightening a bolt with either a screwdriver or a hammer -- for that I need at least a pair of pliers, and if I want it to stay fastened, a wrench.

The whole notion that there is "one-best-way" to communicate information flies in the face of everything I've learned over the last 40 years about tool selection. What is needed is not a common data transport, but rather, a common set of guidelines that we can use to understand how to best select a transport method for the problem at hand.

Coordination?

There are days when I feel as if I'm at the butt of some massive Federal joke. This is one of them. My day started early to work on completion of some pending IHE publications, when I recieved an e-mail titled CORE Problem List Subset of SNOMED CT® Now Available the content of which you can find in the link. This is great work, but isn't coordinated with the national agenda around interoperability.

ANSI/HITSP has already selected the VA/KP Problem List Subset of SNOMED CT® which contains the controlled terminologies identifying problems used for medication labeling. This was felt to be a good subset by ANSI/HITSP since it clearly identified a set of problems required for patient care.

If you've clicked both links you probably can understand my frustration, given that these overlapping subsets are both available through the National Library of Medicine.

The rationale for creating the CORE subset was, I understand, to create a smaller subset of SNOMED CT® that could be used by institutions that want to get started with SNOMED CT®, but did not want to deal with the entire terminology. I'm pleased with the rationale, however, the end result is that now there are two subsets of SNOMED CT®, both created with the assistance of Federal Agencies (VA and FDA for the first, and NLM for the second), which overlap. This creates a massive interoperability problem in the use of SNOMED that ANSI/HITSP will spend in my estimate at least 400 committee member hours of time upon.

How is one to harmonize these two within ANSI/HITSP? I see two options: 1) create a new subset that is the union of both, and 2) create a new subset that is the intersection of both. Neither of these is desirable. The former creates a bigger subset that does not meet the requirements of institutions that wanted as smaller subset to begin with, and the second creates a subset that is about 70% smaller in size that the CORE subset, and doesn't allow the full detail of problems associated with medications to be exchanged.

Why should ANSI/HITSP be required to resolve these issues. Don't we have an office somewhere nationally that can coordinate these activities? This should not be a problem that ANSI/HITSP needed to solve. Instead, this should have been coordinated as part of a national strategy for the use of SNOMED CT®.

I realize that the current Office of the National Coordinator under HHS is not responsible for creating this problem, but I would certainly like that office to resolve it.

Here is my back of the napkin proposal:
1) Create an NLM Project to support the maintenance of the SNOMED CT® subsets used for federal programs.
2) Include within this project the requirement for managing the subset used for medication labeling.
3) Include within this project the requirement for managing a smaller subset that can be used for healthcare interchange.
4) Ensure that the entire subset is available under the same terms and with the same ease of distribution as the VA/KP subset is presently.
5) Ensure that the technical interoperability issues between the two subsets are addressed (for example, the smaller subset should be able to accurately but less precisely code everything in the larger).

Keith

ARRA: Short Term Tactics or Long Term Strategic Plan

Today I gave a brief presentation to a class covering "Key Standards in Health Informatics" at Northeastern University. While the capstone of my presentation was meant to be the HITSP Capabilities of IS 107, I spent far too much time on my "Brief History" slide to do the HITSP capabilities justice. However, I found that I really enjoyed putting the History slide together and presenting on it. The slide covers some key events over the past 10 years that help to formulate where we are today. My timeline is not complete, I'm missing key dates (e.g., the ONCHIT-1 through 4 RFP dates), and there are significant gaps in other areas, and I could go back even further if I hadn't placed a self imposed 1-decade limit on it. However, it's enough to fill a Slide at 12 point type, which argues that it is already too much. I reproduce the content of that slide below:

Nov 1999

IOM: To Err is Human: Building a Safer Health System

Nov 15, 2001

NCVHS: Information for Health: A Strategy for Building the National Health Information Infrastructure

Jul 18, 2003

HL7 EHR System Functional Model Draft Standard for Trial Use Begins

Jul 31, 2003

IOM: Key Capabilities of an Electronic Health Record System

Apr 27, 2004

EO 13335: Incentives for the Use of Health Information Technology and Establishing the Position of the National Health Information Technology Coordinator

Jul 2004

HL7 EHR System Functional Model Draft Standard for Trial Use Published

Jul 2004

CCHIT Formed by AHIMA, HIMSS and NAHIT (The Alliance)

Jul 21, 2004

The Decade of Health Information Technology: Delivering Consumer-centric and Information-rich Health Care

Nov 9, 2004

ONCHIT RFI: Development and Adoption of a National Health Information Network

Jan 17, 2005

13 Member Collaborative Response (AHIMA, AMIA, ANSI/HISB, CITL, CfH, eHealth, HIMSS, HL7, EHR(V)A, IHE, Internet2, Liberty Alliance, NAHIT)

Sep 13, 2005

American Health Information Community formed as Federal Advisory Committee

Sep 2005

ONCHIT-1 – ONCHIT-4 Awarded

Oct 2005

ANSI/HITSP Founded by ANSI, HIMSS, Booz Allen Hamilton, and the Advanced Technology Institute

Aug 22, 2006

EO 13410: Promoting Quality and Efficient Health Care in Federal Government Administered or Sponsored Health Care Programs

Oct 26, 2006

CCHIT Recognized as a Certifying Body

Jan 2008

HITSP Specifications Recognized

Jan 2009

HITSP Specifications Recognized

Feb 17, 2009

ARRA Passes

Jul 8, 2009

HITSP IS 107 EHR-Centric Release for Implementation

Jul 17, 2009

Meaningful Use Defined

Jul 21, 2009

Standards Committee Meets to Identify Standards for Meaningful Use

I spent a good 20 minutes on this slide showing how we got to meaningful use today. Going through this history you can see how

The IOM 8 functional areas are tied to the HL7 EHR Functional Model, CCHIT Certification Critiera, and the ARRA 8.

The National Health Information Infrastructure became the National Health Information Network

Programs such as CHI and HISB were rolled into ANSI/HITSP.

Executive Order 13335 and 13410 become keys points in ARRA and HITECH, to the point of using almost the same language.

You might find it instructive to go back through some of this historical material for yourself and see where we've been and how it's influenced (or failed to influence) where we are today, and more importantly, where we will be tomorrow. I reread various pieces of these documents today, and found the review to be very illuminating.

Keith

P.S. One of the students remarked during her presentation on ICD-10 that followed mine that "... the costs exceed $1B dollars, but that doesn't sound like so much after hearing Keith speak." I'm not sure what she meant, but I thought it significant enough editorially to include the comment here.