http://adambosworth.net/2009/10/29/talking-to-dc/
Talking to DC Warning. This is a rare nerdy technical post more for. It is about Healthcare XML standards. I¹ve was kindly asked to testify at a meeting in DC <http://healthit.hhs.gov/blog/faca/> this week about standards at an hour when I¹m normally not awake. But despite a deep aversion to not getting enough sleep, I was up and on the phone. What made me do such a thing? Well, the discussion was about what actually will work in terms of making health data liquid. What standards should be used for the integration of such data? Somewhat to my surprise and usually to my pain, I¹ve been involved in several successful standards. One was used to exchange data between databases and consumer applications like spreadsheets and Access. It was called ODBC and worked surprisingly well after some initial hiccups. Another was the standard for what today is called AJAX, namely building complex interactive web pages like gmail¹s. Perhaps most importantly there was XML. These are the successes. There were also some failures. One that stands in my memory is one called OLE DB which was an attempt to supplant/replace ODBC. One that comes close to being a failure was/is the XML Schema specification. From all these efforts, there were a few lessons learned and it is these that I shared with DC this Thursday. What are they? 1. Keep the standard as simple and stupid as possible. The odds of failure are at least the square of the degrees of complexity of the standard. It may also be the square of the size of the committee writing the standard. Successful standards are generally simple and focused and easy to read. In the health care world, this means just focus first on that data which can be encoded unambiguously such as demographics, test results, medicines. Don¹t focus on all types of health data for all types of health. Don¹t focus on how to know if your partner should have access to what (see points 2,3, and 4 below). 2. The data being exchanged should be human readable and easy to understand. Standards are adopted by engineers building code to implement them. They can only build if they can easily understand the standard (see above) and easily test it. This is why, in the last 15 years, text standards like HTTP, HTML, XML, and so on have won. The developers can open any edit editor, look at the data being sent/received, and see if it looks right. When Tim Berners Lee first did this on the internet, most of the ³serious² networking people out there thought using text for HTTP was crazy. But it worked incredibly well. Obviously this worked well for XML too. This has implications. It isn¹t enough to just say XML. The average engineer (who has to implement these standards) should be able to eyeball the format and understand it. When you see XML grammars that only a computer can understand, they tend not to get widespread adoption. There are several so-called XML grammars that layer an abstract knowledge model on top of XML like RDF and in my experience, they are much harder to read/understand and they don¹t get used much. In my opinion Hl7 suffers from this. 3. Standards work best when they are focused. Don¹t build an 18 wheeler to drive a city block. Standards often fail because committees with very different complex goals come together without actual working implementations to sanity check both the complexity (see point 1 above) and the intelligibility (see point 2 above). Part of the genius of the web was that Tim Berners-Lee correctly separated the protocol (HTTP) from the stuff the browser should display (HTML). It is like separating an envelope from the letter inside. It is basic. And necessary. Standards which include levels or layers all jammed into one big thing tend to fail because the poor engineers have to understand everything when all they need to understand is one thing. So they boycott it. In health care, this means don¹t include in one standard how to encode health data and how to decide who gets it and how to manage security. If all I, as an engineer, want is to put together a list of medicines about a patient and send that to someone who needs it, then that¹s all I should have to do. The resulting XML should look like a list of medicines to the me. Then, if it doesn¹t work, I can get on the phone with my opposite number and usually figure out in 5 minutes what¹s wrong. Also I can usually author this in a day or two because I don¹t have to read/learn/understand a spec like a telephone book. I don¹t have to have to understand the ³abstract data model². The heart of the initial XML spec was tiny. Intentionally so. I heard someone say indignantly about the push to simplify Health IT standards that we should be ³raising the bar on standards² not lowering them. This is like arguing that we should insist that kids learn to drive an airplane to walk to the next door neighbor¹s house. All successful standards are as simple as possible, not as hard as possible. 4. Standards should have precise encodings. ODBC was precise about data types. Basic XML is a tiny standard except for the precise encodings about the characters of the text, Unicode. That is most of the spec, properly so, because it ensures that the encodings are precise. In health care this means that the standard should be precise about the encodings for medicines, test results, demographics, and conditions and make sure that the encodings can be used legally and without royalties by all parties. The government could play a role here by requiring NPI¹s for all doctor related activities, SNOMED CT for all conditions, LOINC for all labs, and some encoding for all medicines (be it NDC, rxNorm, or FDB) and guaranteeing that use of these encodings is free for all use. 5. Always have real implementations that are actually being used as part of design of any standard. It is hard to know whether something actually works or can be engineered in a practical sense until you actually do it. ODBC for example was built by many of us actually building it as we went along. In the health care world, a lot of us have built and used CCR as we go, learning what works and what doesn¹t very practically and that has made it a good easy to use standard for bundling health data. And the real implementations should be supportable by a single engineer in a few weeks. 6. Put in hysteresis for the unexpected. This is something that the net formats do particularly well. If there is something in HTTP that the receiver doesn¹t understand it ignores it. It doesn¹t break. If there is something in HTML that the browser doesn¹t understand, it ignores it. It doesn¹t break. See Postel¹s law <http://en.wikipedia.org/wiki/Robustness_principle> . Assume the unexpected. False precision is the graveyard of successful standards. XML Schema did very badly in this regard. Again, CCR does fairly well here. 7. Make the spec itself free, public on the web, and include lots of simple examples on the web site. Engineers are just humans. They learn best by example and if the standard adheres to the points above, then the examples will be clear and obvious. Usually you can tell if a standard is going to work if you go to a web site by the group and there is a clear definition and there are clear examples of the standard that anyone can understand. When you go to the HL7 site <http://www.hl7.org/implement/standards/index.cfm> the generality and abstraction and complexity are totally daunting to the average joe. It certainly confuses me. And make no mistakes. Engineers are average joes with tight time deadlines. They are mostly not PhD¹s. Let¹s be honest, a lot of standards are written for purposes other than promoting interoperability. Some exist to protect legacy advantages or to create an opportunity to profit from proprietary intellectual property. Others seem to take on a life of their own and seem to exist solely to justify the continued existence of the standards body itself or to create an opportunity for the authors to collect on juicy consultant fees explaining how the standard is meant to work to the poor saps who have to implement it. I think we can agree that, whatever they are, those are usually not good standards. Health data interoperability is far too important an issue to let fall victim to such an approach.
_______________________________________________ opencpi_dev mailing list [email protected] http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
