The importance of examples

Mar 26, 2014

On an HL7 mailing list, there’s a rather active discussion that is happening about a particular feature in CCDA (allergy lists). It turns out that one of the bits of the CCDA specification is somewhat obtuse (surprise!), and there’s more than one opinion on what it means and how it’s supposed to be used. I’ll probably end up posting on the specific subject when (if) there’s closure to the subject. But it’s not the first time, in fact, it’s happened in the Australian PCEHR too - something that seems self evident to the authors of the specification, but actually turns out to have more than one interpretation when the CDA document is being populated (actually, it’s not about CDA, this can happen with any specification). So when you discover that, the natural question is, well, what have the existing implemented systems been doing about this? And very often the answer is… we don’t know, and we have no way to find out either.

Any big program that is integrating multiple systems should include the following in their integration testing / approval process:

  1. Integrating systems should have to produce several different documents, each corresponding to a pre-defined clinical case
  2. The documents should be manually compared against the defined case
  3. The instance examples should be posted in a repository available to all the implementers, along with the assessment notes (because approval is never a binary thing)
    • if the project is a national project, that means a public repository

It’s hard to state how important this is once in you are in the close out stages of the project. Want to know if some proposed operation is safe, and it depends on what feeder systems are doing? You can just go look. Want to know if someone has already done something wrong? you can go look (supposing, of course, that the test cases provide coverage, but often they do).

Examples: they’re really important for a specification, and they’re just as important for a project. If I was allowed to change only one thing about the PCEHR implementation project, I’d pick #3 (we already do 1 and 2).