A while back I reported on several issues with the CDA Consolidated Release 2.0 efforts, and we got an answer sort of back in October (more than 8 months ago). Since then, the CCDA Release 2.0 still hasn't been finished, and Templates is nearly done. So we successfully reopened the discussion at the last HL7 Working Group meeting. And after several rounds of discussion, I was pleased to hear that Lantana Group was willing to invest in changing the Trifolia tool which is used to create the CCDA specification to support the change. So we seem to be all set to move ahead with the new Template version recommendations from the Templates Workgroup, and that appears to line up well with other efforts at the International level.
As a result, there is one more discussion to have within the HL7 Tooling workgroup to approve the changes, some QA work I've volunteered to perform (along with a George Cole of Allscripts), and we should soon be ready to use versioned templates.
The solution to the problem goes back to how the tooling manages template identifiers. Since they are opaque strings for the most part, folks at Lantana put a bit of structure around them, making them URNs. That allows the tool to detect the type of template ID. An unversioned template ID uses a straight OID, and a versioned template ID uses one of the HL7 URN formats for II that Grahame Grieve mentioned earlier this week (and now you know why Rick and Austin were looking into that format and why there are two).
When the template ID is unversioned, the previous generation code is used. When the template ID is versioned, some small changes are made to the generation code to use @root and @extension, and to apply constraints appropriately, in the guide, in examples, and in schematron.
How will these be tested? It's a simple process really. I'll use template ID patterns to produce a list table of output patterns containing template IDs in the various artifacts. The number of columns in the table depends on how big patterns can get, but usually 5 columns is sufficient. A row in the table is populated with the sequence of N whitespace-delimited tokens which the central token contains a pattern. After you produce the table, you sort it in various orders alphabetically, and find matching patterns.
For each matching pattern, you then describe what the new output would look like, repeat the search on the new output, and then see if you get what you expect. If you do, it passes, if you don't you log a bug. This is an text processing pattern I've used for many years to develop NLP pattern matching and restructuring scripts, and it works to either develop those scripts, or to test the execution of them. And that is exactly what we are doing, testing the execution of text processing scripts.
I look forward to finishing this pretty quickly, and Kudos to the folks at Lantana Group for supporting this effort, including Rick Geimer, Sean McIlvenna, and Liora Alshuler!
Keith
0 comments:
Post a Comment