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.

1 comment:

  1. Over the past few years, it has become increasingly clear that the boundary between what is "healthcare" and what is not has become very porous. Yet we still have IT systems that do what many feel is wrong with healthcare, i.e., focus on diseases and the processes with minimal regard to patients and families.

    In the future, we probably can expect tools that help us *not* be patients as much... lifestyle coaching, stress relief, safety devices to prevent injuries, more understandable product labeling, etc. And in using those tools we can expect people to have preferences about who knows which data and who can do what.

    For example, I exercise regularly at the local Y. The equipment automatically captures what I have done and charts the progress I've made. I have opted to share this with a fitness trainer (not a healthcare provider). Now, it would be nice if I could correlate the exercise data with my health records and opt to share it with my primary care provider. And my fitness trainer needs to know about my health status, at least relative to exercises. Maybe I want a massage therapist to see both data sets. Other people probably have similar examples in their lives.

    As another example, I pay for my Y dues, my medical bills, groceries, clothing, and automobile expenses with the same credit card. Does that have some personally identifiable health-realted data? Yes. Is it protected in the same way as the data for my health insurance plan? Why not?

    How can with give people -- at the focus -- simple one-stop-shopping control over the data about themselves that is shared? Let's do that. Let's work with non-healthcare SDOs to arrive at a common solution.