Where in the world is XDS

This post isn't for my usual audience, nor is it complete, and I need your help.  Most of you have seen or heard the information I'm about to present, but many of you know more details.

The post itself is sparked in part from a comment made at a recent US Federal Advisory Committee meeting on Healthcare IT where one person was reported to have asked:  "Where is XDS used?", and in part from an industry analyst who asked the same question.

I went back through several slide presentations that have been given by myself and others over the last four years.  Most of you have probably seen some iteration of this slide over the past 5 years, I know I have at least 8 different versions of it.  It's probably one of the most reused slides in IHE.  Note that these slides do not show every XDS implementation in the world, they just highlight some of the more well known ones.  Following the slides are some of the notes that I have on these implementations.  These notes are dated, as I don't follow up on each of these sites from year to year.  I'll also note that there are a lot of places where you won't even know that XDS is in use, which is exactly as it should be.  I know of several implementations of XDS across the country where the users of the system aren't even aware of the technology underneath, which also makes it difficult to track deployments.

In addition to the material below, HITSP gave two webinars over the past year talking about real world HIE sites that are useing the HITSP specifications, and the work of the NHIN implementation projects (see the May 2008 slide below).

And last but NOT least, in fact my most favorite implementation is at South Shore Community hospital (about 250 beds) about 5 miles from where I live.  This is using an early implementation of XDS.a and XDS-MS between the hospital and one the group practices in the area.  For details on that see this slide.

Finally, in order to better capture this information, I've started a Google map containing XDS implementations that I'm aware of.  I'll be posting that link early next week after.

So here is what I'd like you to do:

1. Write a comment on this blog with details of XDS implementations you know of or send me an e-mail.
2. Update the Google map using the URL that's been circulating in standards circles (or send me an e-mail to get it)

I hope to polish this post early next week, but just in case you are out there this weekend, have at!

   -- Keith

August 2009

May 2008

December 2006

XDS Around the World

Italy - Genoa Region
In service since January 2006 in 4 Hospitals and 500 physician offices. EMRs import and export documents from their local records. All products required to pass the IHE European connectathon in April 2005. Patients chose to join through one of their care providers

Built by a work group composed of:

• Asl 4 Chiavarese;
• The Diagnostic Medicine and Special Therapies departments of the University of Padova
• IHE – Italian National Commission

Companies expert in e-health solutions:

• Rasna Medical Systems
• Soluzioni Informatiche (Information Solutions);

Creating an open-source implementation of the IHE XDS profile.

Infrastructure includes:

• XDS Registry
• XDS Repository shared at the regional level
• PIX for patient Id linking
• Doc content is CDA with PDF content. Plan in place to move to CDA Release 2 with structured data. IHE (XD*-Lab) CDA Lab primary candidate.

Austria (Lower Region)

Lower Austria Region (near Vienna). Operational as of 2007 with 1.5 Million patients on-line and 11 connected hospitals.

IHE profiles in use: XDS, PIX, XDS-SD, ATNA, XUA, BPPC.

Austria (National Project -- ELGA)
First region to be deployed in one year

Roll-out includes:
Ministry of Health backing of IHE conformance through the IHE-European Connectathon

• Extending to Ambulatory Physicians in 2008
• Step-wise introduction of structured and coded content with HL7 CDA based IHE Content Profiles.

China - Ministry of Health

Ministry of Health selected XDS and XD*-Lab (CDA) for lab info sharing. Two pilots planned for 2008.
China - Shanghai
XDS-I
Israel, Jordan, Palestinian Authority
Public Health Info Affinity Domain (XDS, ATNA, XD*Lab)
Middle East Consortium for infectious Disease Surveillance

Italy/Denmark/Spain
3 Hospitals, operational since mid 2005

Japan - Nagoya region
Network project operational late 2007. XDS, XDS-I
Japan - Kobe
Imaging information sharing

Netherlands
Three regional network projects live in 2008.

Norway

Sharing radiology images between four different vendor products, Implementation in 2006/2007

South Africa

National project launched in 2007. Tender awarded. Operational in 2008.

Canada
Canada Health Infoway: Pan-Canadian commitment to XDS/XDS-I for imaging sharing

3 infrastructure tenders awarded in 2007 and 1 more in 2008 resulting in over 1/3 of Canadian patients covered:

• Toronto East Network - Ontario
• Montreal McGill - Quebec
• Alberta
• British Columbia

Includes XDS, ATNA, PIX and XDS-I.

United States
Philadelphia Exchange
Philadelphia Health Info Exchange in service since 2005. Focused on images and reports sharing.

5 Hospitals + Imaging Center + Public Health

• The Hospital of the University of Pennsylvania
• Thomas Jefferson University Hospital
• Children’s Hospital of Philadelphia
• Presbyterian Medical Center
• Pennsylvania Hospital
• UPHS Community Radiology
• Philadelphia Department of Public Health

Migration to XDS, ATNA, PIX and XDS-I completed in 2007.

• Demonstrated live at RSNA-Chicago Nov 2007

Kaiser Permanente
Operational as of 2008

Vermont Information Technology Leaders
Operational see HITSP webinar for details

Boston Medical Center
Operational

KeyHIE/Geisinger Health Systems
Operational see HITSP Webinar for details

If it ain't broke, don't fix it

A very long time ago, during the start of my software development carear, I had two quotes from my boss written on the chalkboard in my office at the University.

“	Two rules of software development Just get it to work If it ain't broke, don't fix it.

These became a sort of test for people walking into my office.  If they looked at these two statements and questioned the implications of them on the software generated in that office, they passed. More than 70% of the cost of software is not in the development of it, rather, it is in the maintenance and support of it.  Applying these two rules might get it done quick, but won't result in something that you (or I for that matter) want to maintain.

In the realm of laboratory ordering and reporting, we are in a situation that is the result of applying these two rules.  We have numerous laboratory order and reporting interfaces installed across the country that "work", and since they aren't "broken", there are concerns that we shouldn't be spending a great deal of time fixing them.  This results in debates in the HIT Standards and Policy committees over the need to specify standards now or later, or allow early adopters a "buy" for the first round.

The question is whether you want to drive a more expensive vehicle that is reliable, or if you just want a clunker that spends a good bit of time in the body shop. The just get it to work attitude results in driving around a lot of lemons that have high maintenance costs, but the other approach is expensive in the short term. And if you've already got a lemon that's running, you may not be ready to purchase that new car just yet.  It might require some planning and adjustment, but when that lemon dies, you should be ready to get something that will last.

My thoughts in this are fairly straightforward. 
1.  If it ain't broke, don't fix it. 
2.  When it does break, fix it right, or get a new one that won't break like that again.

The same principle was applied to Federal Health IT infrastructure under the Bush administration via Executive Order 13410, and should be applied to laboratory standards for meaningful use.  In essence it says that new, upgraded or newly developed HIT, use the recognized standards.  Basically, if it isn't being replaced, don't change it.  I know, telling this adminstration to pay attention to what the last one did probably won't fly, even if it was a good idea.  So, instead, look to what section 13111 of ARRA has to say about federal spending on HIT.  What's good for the gander in this case, should be good for the rest of the geese.

If a provider has a working electronic laboratory interface, let it count for the first two years, but ensure that they are planning to update it to support the required standards by 2013.  That will avoid unnecessary expenditures on fixing what "isn't broken", but it will also indicate that we are serious about the use of standards.  It won't leave early adopters out in the cold over what is needed for laboratory interfaces.

Laboratory results are very important in quality measures and clinical decision support.  Avoiding standardization of the laboratory results interface will delay other factors of meaningful use that aren't being debated.  So, it's important to push for standardization and make it clear that we will move forward.

One of the key features of CDA that makes it so implementable is "incremental interoperability".  Let's use that principle for laboratory interfaces as well.

Vocabulary

Healthcare IT products need to deal with terminology for ICD-9-CM, ICD-10-CM, ICD-10-PCS, SNOMED-CT, RXNORM, LOINC, NDC, CPT, HCPCS, UMLS, the Healthcare Provider Taxonomy and a number of proprietary vocabularies as well.  Most of these use different file formats to exchange the data about the vocabulary.

What I'd really like to see is everyone use standard format to exchange this information.  Preferably I'd like that format to be XML-based to make it easier to process.  But I'd also like that representation to be fairly compact, so I might be able to live with a text delimited format.  I can readily create an XML reader that will import common text delimited formats in an XML document for processing, so it's not a huge problem if the format isn't XML-based.

Finally, I'd like everyone to agree on some very common concepts (e.g., "is a") that need to be expressed so that these concepts have the same meaning across terminology.  Ensuring that we have a set of commonly accepted (standard) relationships will certain help us get to a point where we can reason across terminology boundaries.

The US Federal government is responsible in some way for maintenance, delivery or mandated use of some of these vocabularies (RXNORM, UMLS, ICD-9 and 10 variants used in the US, NDC, HCPCS and the Healthcare Provider Taxonomy), and yet almost all of them require different file formats for distribution.  It's what I've come to expect from my government, but I wish it would stop.  At least the work done by NLM (RXNORM and UMLS) have a common file format.  The Rich Release Format is used for both of these and uses | as a text delimiter to separate columns.  In fact, it might even be worthwhile to have a number of SDOs get together and agree to use that format (or perhaps a modification of it) to deliver vocabulary information.

Some of the vocabularies I mention are published in books with a lot of ancillary material that should also be part of the downloads.  For example, the ICD-9-CM vocabulary contains a rather large index which is incredibly valuable, along with a number of inclusions and exclusions.  But to really make good use of the vocabulary you need the data associated with these additional parts incorporated into the downloads.

Finally, I'd like to see some of the hierarchical relationships in some of these terminologies be formally expressed within them.  LOINC for example, contains numerous concepts describing clinical documents, but the LOINC data itself doesn't actually include some of the important relationships between the different types.  For example, the Admission History and Physical Note (47039-3) doesn't show up as being related in the document hierarchy with the Cardiology Hospital Admission Note (34094-7).  The same is also true for relationships between the various laboratory results. 

As we in the US continue to talk about simplification and debate some of the really hard IT topics, this seems like a really simple problem to solve that could be addressed with just a little bit of the right attention.

Healthcare IT Standards and General IT Standards

A recurring theme of this blog is using the right tool for the right job, and is one of my father's favorite aphorisms.

I am struck by the number of times that I hear others discuss healthcare standards problems as if they are different from problems that others in the IT field have addressed.  The current case has to deal with modeling of consents to share or release private information for use by others.  This is NOT a healthcare specific problem, it appears in multiple business contexts (e.g., credit reporting and credit checks).  It should be a matter of profiling appropriate industry standards (and I admittedly don't know which those would be, nor do I have a personal preference) to use appropriate healthcare terminology (regarding occupation and licensure, healthcare specific purpose, et cetera).

For some reason though, there seems to be this need to apply HL7 modeling to this problem (and perhaps every other problem encountered in the healthcare context).  The HL7 RIM is extraordinarily powerful and you can model almost anything you want with it.  I know, I've modeled 100 bottles of beer on the wall with it to teach RIM modeling for Claims Attachments.  Does that mean it should always be applied?  In this particular case, I'm not certain that it should.

This particular issue is a general problem that should have a general solution available from the IT space.  It just needs to be customized to address  healthcare specific issues.  If it was correctly modeled to begin with, that should be a straight-forward prospect.  If not, then it seems the right answer might be to go back to those bodies and get them to fix it rather than perpetuate the proliferation of perplexing products purported to puzzle out the problem.

I think that there are two issues here:
1. Using a solution provided by someone else isn't necessarily sexy or cool. 
2. Inventing new solutions provides product or consulting opportunities.
Neither of these is a requirement.  I want solutions, I want them to be commercially available and easily integrated into my current suite of tools.  Ideally, I'd like it to be something I can buy a book on or take a class on, and a skill-set that I can hire for from the existing pool of experienced IT  people. 

To be fair, using solutions built by others is hard, and building it yourself always seems to be easier, better and/or faster.  You have to read all the existing work and understand it, and apply creativity sometimes.  But the people building standards for healthcare are bright people.  I expect them to be able to take on that task.  On the easier/better/faster to build it yourself, well, most of the time, that's just an illusion.  Yes, what you do may be easier/better/faster, but does it really provide enough incremental value to justify all that work?  You could be spending your time on harder and more interesting problems that are much more valuable to solve.

I'm all for standardization, and I like HL7 and all the rest ..., but frankly I'd rather go to a mechanic when my car is broken than a doctor.  They charge better prices and the problem seems to stay solved longer.

UTC in HL7 Version 3

The timestamp data type is used in a variety of standards to mark the time at which an event occured.  Most standards (including HL7 Version 3 and W3C XML Schema) rely on ISO 8601 as the base standard which is then constrained in different ways.

Marc de Graauw asked a question about how one would represent Universal Coordinated Time using the HL7 Version 3 standards (see How to express UTC time in TS).  I did a bit of research on this and was somewhat amused with my findings:

The HL7 V3 Datatypes schema allows [0-9]{1,4} for the pattern following the + or - so that doesn't help much.

Section 4.2.5.1 of ISO 8601 states:
When it is required to indicate the difference between local time and UTC, the representation of the difference can be expressed in hours and minutes, or hours only. It shall be expressed as positive (i.e. with the leading plus sign [+]) if the local time is ahead of or equal to UTC of day and as negative (i.e. with the leading minus sign [–]) if it is behind UTC of day. The minutes component of the difference may only be omitted if the time difference is exactly an integral number of hours.

The key phrase ahead of or equal to UTC indicates that +00 or +0000 are the only ways to represent UTC other than Z. I know that zero is neither positive or negative but those terms are in reference to the leading + or - sign. The statement "equal to UTC" is what makes the point, which means that -0000 isn't valid (according to 8601).

Standards using 8601 disagree: 
The W3C use of 8601 in XML schema recognizes +00:00 -00:00 and Z as legal representations of UTC, with Z being the canonical representation. See http://www.w3.org/TR/xmlschema-2/#dateTime

Abstract Datatypes Release 1 and 2 say pretty much the same thing for the literal form of a time stamp:
In the modern Gregorian calendar (and all calendars where time of day is based on UTC), the calendar expression may contain a time zone suffix. The time zone suffix begins with a plus (+) or minus (-) followed by digits for the hour and minute cycles. UTC is designated as offset "+00" or "-00"; the ISO 8601 and ISO 8824 suffix "Z" for UTC is not permitted.

The ITS: XML Datatypes, Release 1 specification has nothing to say other than by reference to Abstract Data types.

Pragmatically, any user of HL7 V3 schemas should recognize any of +0, -0, +00, -00, +000, -000, +0000 and -0000 as a UTC time zone, but should only record UTC as +00 or +0000 (my own preference). These are all legal representations of time zones using the HL7 TS data type according to the (non-normative) schemas provided by the XML ITS.
So, there you have it.
 
Keith
 
P.S.  This is book fodder...

Don't Panic

DON'T PANIC

Unlike the Hitchhikers' Guide to the Galaxy, the HITECH ACT of ARRA does not contain the words "Don't PANIC" printed in big bold text on the front cover, but it should. 

The HITECH provisions describing meaningful use are principally concerned with motivating healthcare providers to use electronic medical records wht the anticipated goal of reducing the costs of care. They do so through INCENTIVES.  See the definition below from wiktionary for the term:

incentive (plural incentives) Something that motivates, rouses, or encourages. I have no incentive to do housework right now. A bonus or reward, often monetary. Management offered the sales team a $500 incentive for each car sold.

As we all anticipate the pending regulation my current frustration is with various people who are panicing about there being "too much, too fast" for providers to adopt, or that the standards are not ready.  If the standards aren't ready, then how is it that 47% of the hospitals responding to the AHA Most Wired survey are already able to support CCD, or that 84% of the most wired can (see Connecting all Your Docs)? 

HITECH is nothing like HIPAA in what it requires of providers.  HIPAA regulation basically stated that you had to use certain standards if you wanted to use electronic claims transactions, and that you had 2-3 years to do it, and there was no money from the Federal government to help it along.  HITECH basically says that if you want to recieve incentive payments, then you have to do certain things over five years, and you'll be ahead of the game, and after five years, there will start being penalties for non-conformance.

Yes, this results in a great deal of craziness as everyone tries to ensure that they get as big a piece of the pie as they possibly can.  But...

If you aren't ready, slow down.  The world won't end tomorrow (or in the next two weeks), nobody is poised to bulldoze your practice.  You have some time to make reasoned and good decisions.  The incentives are structured so that the biggest payouts will be in the first years of technology adoption.  Waiting a little bit won't cut a huge chunk off the potential incentives you can recieve, just read Page 354 of ARRA.  In fact, you'll see that waiting a year (being a meaningful user in 2012) is just as good as starting in 2011.

That doesn't mean I don't want you to start now, because I do, but do so in a thoughtful way, and if you need more time, by all means take it.

What I want for Christmas

From HL7:  A new ITS that makes it easier to implement Version 3 specifications and a US Realm.
From W3C:  A binary XML that reduces the footprint of XML on the wire and an updated Schema specification that enables HL7 to build that new ITS.
From HITSP:  A week or two off and some infrastructure to build better specifications.
From IHE:  Actually, I think I've gotten that one already, a full slate of active leaders in PCC.
From ONC:  Some forethought and an RFP to continue the standards harmonization process that includes some of the other streamlining of standardization that I've asked for.
From ISO and the US TAG:  Some time to play in that sandbox.
From NIST: Open sourcing of validation tools.
From a book publisher: A contract.
From Congress:  Health Reform

What I'm giving for Christmas:
To HL7: Some easy ballot comments to address.
To W3C: Feedback on that new Schema specification they have.
To HITSP: 25 hours a day.
To IHE:  Antepartum Workflow Draft -- Really, I promise this time.
To NIST: Comments on testing tools.
To Congress:  A new senator.  It'll be a little late, but...

It's just a short list really, and I've been such a good boy...