Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Tuesday, December 15, 2009

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.