Up at 5AM: The 5AM Solutions Blog

ISO 21090

Posted on Tue, Nov 10, 2009 @ 12:58 PM

Over the past 1.5 years, a project we have developed has been required to utilize the ISO 21090 Healthcare Datatype specification. This requirement has been challenging for our team and our partners throughout the project lifecycle. However, I didn't spend much time thinking about root causes for these problems because the requirement was non-negotiable. That changed when I read Adam Bosworth's Healthcare XML standards post a couple weeks ago. His points about good standards provided the structure to talk about our 21090 challenges.

Keep the standard as simple as possible. This is a major criticism of 21090. Casual observation and our experience with this standard shows that it is not simple. As two examples, consider that the BL (Boolean) datatype has no fewer than 8 attributes, and that address (AD) takes 11 pages to detail such things as "delivery installation type" and ideographic address use. Still, is it as simple as possible? I don't know. The USPS address standard is some 200+ pages long, and doesn't consider international addresses. But I've yet to see a more elaborate logical (boolean) datatype in any language or specificaiton. I think this is because....

Keep standards focused. There is poor separation of concerns in 21090. When I send a BL, I can communicate not only the truth value, but whether this BL is a change from the previous value or the start and end times for which the value will be valid. I believe that such considerations should not be part of a datatype, and instead should be explicit fields of a containing class. Another example is telephone numbers, where the spec includes not only how to encode a number ("+12125551212") , but how that number should be used (mobile, home, pager, etc.) and time information (use this number only between 8-5pm). Address is particularly bad. The standard is so unfocused that its own examples appear completely different from each other.

Percise encoding. 21090 is fine in this regard. There is little like an HL7 2.x Z segment to be found.

Real implementations. Note that 21090 is in the ISO "Approval stage" today. During most of our implementation period, relevant google searches' top hits were our team's wiki pages. No one had implemented these datatypes before – our team's questions were generally escalated to the author of the specification, because no community expertise existed. Even the downloaded XSD was invalid syntactically. This particular standard evolved from other datatype standards that are in more widespread use, but there is still a need to vet the standard via a real end-to-end implementation. Even today, top hits for 21090 are teams asking questions about how the spec might work, rather than discussion about how it is or is not working.

Free, publicly available spec with examples. Nope. Costs money to buy.

While I think there's a lot of good in standardizing datatypes, I think the above discussion should give pause to others considering the value of adopting this particular specification as an enterprise standard.


Diagnostic Tests on the Map of Biomedicine


Download the ebook based on our popular blog series. This free, 50+ page edition features updated, expanded posts and redesigned, easier-to-read maps. 

FREE Biobanking Ebook

Biobanking Free Ebook
Get this 29 page PDF document on how data science can be used to advance biorepositories.

 Free NGS Whitepaper

NGS White Paper for Molecular Diagnostics

Learn about the applications, opportunities and challenges in this updated free white paper. 

Recent Posts