Quick hit: approaches for standardized healthcare data

When my brother, Rob and I get together it often brings our wives to tears with boredom as we often get deeply engrossed in long conversations about computers, software and technology in general. Super Bowl weekend was no different. Rob and I started talking about strategies for connecting various pharmacy systems to other hospital systems and the issue of a lack of standardized information in healthcare came up. I mean we have standards, right? Of course we do. There’s SNOMED-CT, RxNorm, ICD-9, ICD-10, LOINC, GLNs, GTINs, NDC, bar-code “standards”, HL7, NCPDP SCRIPT standards and so on and so forth ad infinitum. I realize the list above includes a hodge-podge of standards that don’t really belong in the same category, but I did it to illustrate my point. And that point is that we have too many stinking standards. Trying to figure out which standard to use is an exercise in futility. Standards typically make sense to the people that invent them or study them, few others. And someone always has an idea for a better standard, hence the plethora of standards.

As healthcare inches forward interoperability of systems will hold a key role in the success of the government’s plan for electronic health records. So as Rob and I discussed how to integrate various services and products we pondered how one goes about creating a standard that everyone can live with. Well, how does one create a standard that everyone will use? Heck if I know, but we decided that there are basically two approaches. The first is to create a standard and try to cram that standard down everyone’s throat. Microsoft has been fairly successful with this approach. With that said, few people have the resources that Microsoft has to throw at a problem. The second approach is to offer the standard as part of a free solution that comes with your product; this way people can use your product and use your free, open-source solution to tie the systems together. I assume this is the smart approach for companies that have limited resources; kind of a grassroots approach. Of course it would be wise to build this free, open-source solution on top of an existing standard that’s prominent in the market, otherwise you’re trying to re-invent the wheel. And we all know what happens when someone re-invents the wheel. Uh, you get a wheel. We don’t really need any more of those. Both approaches have pros and cons.

Now the question becomes which standard makes sense as you design your solution. If only I had a crystal ball. We’re at least a decade away from having a truly inter-operable healthcare system; optimistic, I know.  Ultimately, the standard of choice won’t be driven by what makes sense, but rather will be driven by adoption rates. Things often become a standard without even trying.