2010 Standards Calendar

As we start the new year, we also start a new calendar of standards activities.  The calendar below contains most of the important meeting dates for standards activities impacting standards geeks like me.  Fortunately, I don't have to be at all of these meetings, but I do at least need to be aware of them all because I have to interact with others who do.  It is my sincere hope that non-SDO bodies scheduling related work will take this schedule into account when coordinating their standards related activities.

For those of you waiting for my thoughts on the IFR and NPRM, you can expect that later this week.

2010 Standards Calendar
	Mon	Tue	Wed	Thu	Fri	Sat	Sun
					1	2	3
Jan	4	5	6	7	8	9	10
	11	12	13	14	15	16	17
	IHE Connectathon – Chicago, IL						HL7
	18	19	20	21	22	23	24
	HL7 – Phoenix, AZ						X12N
	25	26	27	28	29	30	31
	HITSP DC	DICOM WG-6, NEMA
	X12N – Seattle, WA
Feb	1	2	3	4	5	6	7
			NCPDP – Austin, TX
	IHE – Location TBD
	8	9	10	11	12	13	14
	15	16	17	18	19	20	21
	22	23	24	25	26	27	28
						HIMSS
Mar	1	2	3	4	5	6	7
	HIMSS – Atlanta, GA
	8	9	10	11	12	13	14
	15	16	17	18	19	20	21
	WoHIT–Barcelona, Spain					WG26 DC
	22	23	24	25	26	27	28
	DICOM WG-6, NEMA
	28	30	31	1	2	3	4
Apr	5	6	7	8	9	10	11
	12	13	14	15	16	17	18
	IHE Connectathon,
	19	20	21	22	23	24	25
	26	27	28	29	30	1	2
	IHE – Oakbrook, IL						NCPDP
May	3	4	5	6	7	8	9
	NCPDP - Phonix, AZ
	10	11	12	13	14	15	16
	ISO TC-215 – Rio, Brazil						HL7
	17	18	19	20	21	22	23
	HL7 – Rio, Brazil
	WEDI – Austin, TX 20
	24	25	26	27	28	29	30
			AsiaPAC – Beijing
	31	1	2	3	4	5	6
							X12N
Jun	7	8	9	10	11	12	13
	X12N – Addison, TX
	14	15	16	17	18	19	20
	21	22	23	24	25	26	27
	DICOM WG-6, Barcelona
	28	29	30	1	2	3	4
Jul	5	6	7	8	9	10	11
	12	13	14	15	16	17	18
	IHE – Oakbrook, IL
	19	20	21	22	23	24	25
	28	27	28	29	30	31	1
Aug	2	3	4	5	6	7	8
			NCPDP – Baltimore, MD
	9	10	11	12	13	14	15
	16	17	18	19	20	21	22
	23	24	25	26	27	28	29
	DICOM WG-6, NEMA
	30	31	1	2	3	4	5
Sep	6	7	8	9	10	11	12
	13	14	15	16	17	18	19
	20	21	22	23	24	25	26
	27	28	29	30	1	2	3
							HL7
Oct	4	5	6	7	8	9	10
	HL7 – Cambridge, MA						TC215
	11	12	13	14	15	16	17
	ISO-TC215 – Netherlands						X12N
	18	19	20	21	22	23	24
	X12N - Cincinnati, OH
	26	26	27	28	29	30	31
Nov	1	2	3	4	5	6	7
			NCPDP – Portland, OR
	DICOM WG-6, NEMA
	8	9	10	11	12	13	14
	WEDI  – Reston, VA
	15	16	17	18	19	20	21
	22	23	24	25	26	27	28
							RSNA
	29	30	1	2	3	4	5
	RSNA – Chicago, IL
Dec	6	7	8	9	10	11	12
	13	14	15	16	17	18	19
	20	21	22	23	24	25	26
	27	28	29	30	31
		IHE PCC/ITI/QPHR
		HL7 Working Group
		HITSP Board/TC/Panel
		ISO TC 215/US TAG
		Industry Conferences
		IHE Connectathon
		DICOM
		NCPDP
		WEDI
		X12/X12N

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.