Building Code and Building Standards

Spending a day writing code makes me feel younger.  Writing code well into the evening and next morning makes me remember I'm not so young any more.  I code like I write, getting out the raw ideas on the page, and then going back and neatening up afterwards.  What is most important is the raw concept.  I often start out with a high level outline of what I want the code to do, especially if it's implementing a complex algorithm.

Modern tools make it easier to go back and refactor my code, which I do rather often.  When I wind up doing the same thing twice or three times in different places, I usually copy and paste the first one or two times.  The third or fourth time, I create a method to do it, often in the class I'm writing.  After a while, I collect a bunch of these methods that are helpers, and put them somewhere else.

Modern tools also make it very easy to document my code.  Sometimes I start with the documentation, at other times, I start with the code.  I leave a lot of bread crumbs, little TODO markers about things I haven't finished, or things I'd like to do differently later.  These are things I can do in later iterations, but often aren't essential to the raw idea I'm trying to finish right now.

As I finish each task, I check my code back in to a source repository.  Most of the time I'm not working with others, but when I am, that also means that I have to be careful to merge my changes back in.  Coding has a necessary build and test component.  When I make changes, I have to be sure they work.  After I've merged changes back, I have to make sure that a) my changes still work and b) that the code I've merged back with still works.

There's nearly nothing like this when writing Healthcare standards, but it is certainly changing.  One of the nice things about what Grahame Grieve has done with FHIR is develop a great set of tools that produces the standard.  There are a variety of resources that you can create and edit, and when you are done, there is a build process that generates the standard.  If there's a problem, the build tells you what is wrong.

He's even gone so far (and at this point I'm guessing), as to take the data from the standard, and turning it into code automatically.

The same thing is true for tools like MDHT.  You build a model, based perhaps on an existing one (e.g., like CCDA is on CDA).  From that, you generate the guide.  And the testing tools.  And a reference implementation in one or more programming languages.  While it's taken us nearly two decades to get from the clunky compilers and code development tools we had to where we are today with modern IDE's, FHIR and MDHT have done so in a lot less time (a year, and a few years respectively).  MDHT builds on some of the same modern tools we use to write code.  No, there isn't really a FHIR IDE environment.  That's much closer to my ideal of simple things put together in really interesting ways to produce a complex result.

I haven't done much standards development with FHIR or MDHT, and should really be doing more.  If I did, I'm sure I could figure out a way to make it possible to build some kinds of IHE profiles much more quickly.  For example, a simple spreadsheet containing the actor transaction table written in a certain way could be used to automatically generate the Actor/Transaction diagram.  Some of the IHE Connectathon tools do this using GraphViz (an open source graph generator).  I've done similar things using a database of IHE Actors and Transactions.

The challenge with this is that this kind of change impacts standards developers who are familiar with the current way of doing things pretty radically.  Some will never use new tools, because they are already quite comfortable with what they've been using.  And new tools take time to develop and make their impact felt.  They usually don't start out solving the whole problem.  In order for them to be adopted, they have to address enough of the existing problems better than existing tools, and not create enough new issues that cause more pain (the whack-a-mole problem).  You also need to have a cadre of people who have enough interest in trying out a new way of doing things to make it take hold.  And they have to be willing to deal with change and potential of the new way of doing things.

To have time to build these tools, other urgent problems might have to wait.  That makes it even more challenging, especially now when so many things are going on.  This is where you need to step back and thing about what your priorities are.  If you can't ever reduce the rate of production to increase later capacity, then you have a critical challenge.  Someone else is likely to figure out how to automate your process and will eventually be able to outpace you.

What is really scary about this is the end result.  If the current pace of standards development is impacting you severely, increasing it yet further is not something you might be willing to consider.  You have to move beyond scary, and realize that even though the pace of innovation might increase, the amount of effort could decrease quite dramatically.  I'd be happy producing twice the output with two thirds of the existing effort.

The one thing that we aren't automating is the review stage of standards.  MDHT and FHIR both rely dramatically on using data to generate standards.  They make it relatively easy to generate hundreds of pages of text (and thousands of lines reference code) from a dozen or so models.  Reading hundreds of pages of text to ensure that it is right is still a daunting task.  I'll write a bit more about that later.

   -- Keith

P.S.  Just to show you how my mind works, I started writing this post without any idea where it was headed.  The first two sentences were on my mind, so I wrote them down.  The rest of the post wrote followed from there.

Learn about ONC-Sponsored Model-Driven Health Tools Project

I love it when the Government gets involved in something worthwhile. This is definitely one of those cases, and I've been an MDHT fan-boy for quite some time...

---

ONC-Sponsored Model-Driven Health Tools Project A government/private sector open source collaboration was recently formed between the Office of the National Coordinator for Health Information Technology (ONC) at the U.S. Department of Health and Human Services (HHS), Veterans Health Administration (VHA), IBM Research (NYSE: IBM), and Open Health Tools. This project focuses on simplifying standards-based health information exchange.   The Model-Driven Health Tools (MDHT) project leverages models of existing standards to produce integrated and accessible guides along with actual working and tested software supporting the standard.  This approach replaces current industry practice requiring each participating company or organization to interpret the standard and independently develop the standards.  The result lowers both cost and hurdles preventing organizations from participating in electronic health information exchanges. Additionally, MDHT supports a full lifecycle standards development process providing a solution that allows standards designers and implementers to actively collaborate.  The agile process enables designers to quickly validate all aspects of the standards rules as practical and feasible before they become normative standards. ONC's participation, which began in January 2011, was spearheaded by Dr. Doug Fridsma, Director of the Office of Standards and Interoperability within ONC. The MDHT Project 1.0 release was a response to a 2008 request for initiation by the VA and VHA. This release is the first of many sets of standards the group intends to create. MDHT currently supports the Meaningful Use Standard, Healthcare Information Technology Standards Panel (HITSP) Patient Summary Document (C32) and the Consolidated CDA Project. MDHT also provides support to other ONC S&I Framework Initiatives, including the Transitions Of Care and the Consolidated CDA initiatives. For more information about MDHT or to get involved, please visit https://mdht.projects.openhealthtools.org. .

UML/OCL or XML/XPath ... which is best

The HL7 / IHE / HealthStory CDA Consolidation project will be submitting the "Meaningful Use" sections for ballot today.  The ballot opens today and can be found on the ballot site under the title: HL7 Implementation Guides for CDA® Release 2: IHE Health Story Consolidation, Release 1 (US Realm), and is available for signup until May 2nd.  If you've signed up, you have until May 9th to submit your comments.

Over time, HL7 has developed a new pattern for conformance statements for CDA Implementation guides based on the following principles:

We use XPath expressions because they are easy for developers to read and understand.  XPath expression have their context (are rooted) at the XML element containing the templateId element.  The keywords SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT and SHALL NOT are highlighted and indicate whether content must, is recommended or simply allowed to be present (or negated in these same forms).

The number of times that things are required or recommended to be present are given in both english text (only one, at least one, one or more, zero or one, zero to many) and in bracketed form [0..*] for commonly used cardinalities.

One of the challenges in developing this guide has been bridging the gap in MDHT between UML and OCL,  where the constraints are represented; and XML and XPath, the way we want to express them to developers.

Here is an example constraint with the associated OCL:

24. SHALL satisfy: At least one [1..*] patientRole element is present in recordTarget (CONF-CONSOL-21)
• [OCL]: self.recordTarget->size() > 0 and self.recordTarget->exists(target : cda::RecordTarget | not target.patientRole.oclIsUndefined())

The same constraint in XPath (assuming the ClincialDocument element as context) is:
count(cda:recordTarget/cda:patientRole) > 0.
That XPath expression will be true if there is at least  1 patientRole element.

I spent 4 hours yesterday writing (manually) conformance statements for the IHE Reconciliation profile following a similar pattern as the CDA Consolidation project.  The manual exercise allowed me to find common patterns which I'd like to share:

1. A template applies only to certain classes represented in the CDA R-MIM (e.g., a section, act, substanceAdministration, et cetera).
   Template X applies to cda:section elements.
   XPath: self::cda:section
2. A structural attribute (e.g., moodCode, classCode or typeCode) of the class is fixed to a single value.
   The @classCode attribute of the act element shall be set to the value ACT.
   XPath: @classCode="ACT"
3. A specific identifier must be used for one of the class attributes.
   The @root attribute of the id element shall be X and
   The @extension attribute of the id element shall be Y
   XPath: @root="X" and @extension="Y"
4. An identifier from a specific namespace must be used for one of the class attributes.
   The @root attribute of the id element shall be X.
   XPath: @root="X"
5. An element may be null
   The effectiveTime/@value shall be precise to the day.
   The @nullFlavor attribute may be used on the effectiveTime if the information is unknown.
   XPath: string-length(cda:effectiveTime/@value)>8 or cda:effectiveTime/@nullFlavor
6. An element shall/should not be null.
   The @nullFlavor attribute shall/should not be present be used on the effectiveTime.
   XPath: not(cda:effectiveTime/@nullFlavor)
7. A coded class attribute shall/should/may be coded using a specific terminology.
   The @codeSystem attribute shall/should/may of the code element shall be set to the value X.
   XPath: cda:code/@codeSystem="X"
8. A coded class attribute shall/should/may be used from a specific value set.
   The code element shall contain a value drawn from the X value set.
   XPath: document(ValueSetServiceURL + "?valueSetID=X&code=" + cda:code/@code + "&codeSystem=" + cda:code/@codeSystem)//isValid
   (Note: This is an example using the document() function to call on a RESTful URL that returns XML contain the element isValid if the code and codeSystem given are part of the value set.  The IHE Sharing Value Sets profile is one example of such a service that could be used, but this example doesn't use that syntax.  There's about 10 ways to skin this cat).
9. A specific data type must be used for a class attribute.
   The value element shall be reported using the PQ datatype.
   XPath: contains(concat(":",cda:value/@xsi:type,":"),":PQ:")
   (Note: This is not quite a perfect.  If matches cases that are wrong because it assumes that if you use cda:PQ that cda:  is the correct namespace declaration.  Better tests can be written but this one would catch most failures to conform). 
10. A time stamp must/should have a certain precision.
    The effectiveTime/@value attribute of the ClinicalDocument shall be precise to at least the day.
    XPath: substr(@value, 1, string-length(@value) - string-length(substring-after(concat(translate(@value,'+-','|'),'|') ) > 7
    (Note: This one removes any time-zone suffix found by translating the + or - delimiter to a |, adds a | to be sure that a | is ALWAYS present, computes the length of the time-zone suffix, removes it from the string and then checks the lenght of the date.
11. A name or address component shall/should be present.
    At least one [1..*] family element must be present in the name element.
    XPath: count(cda:name/cda:family)>0
12. The class shall/should/may contain some number of classes conforming to another template.
    The act shall contain at least one [1..*] observation conforming to Template Name (templateId: 2.16.840...)
    XPath: .//cda:observation[cda:templateId/@root = X]
13. The class shall/should/may directly contain some number of classes conforming to another template.
    The act shall directly contain only one [1..1] observation conforming to Template Name (templateId: 2.16.840...)
    XPath: ./cda:observation[cda:templateId/@root = X] 

A single constraint addresses a class and attribute in the UML/OCL representation of the CDA content and the templated element  and one or more subordinate attributes or elements and their attributes in the XML/XPath representation.

There's also a couple of different ways to combine constraints:

1. Disjunction of two or more constraints:  Constraint A OR constraint B or both must be followed.
   The act shall contain at least one of the following:
     only one observation conforming to Template Name (templateId: 2.16.840...)
     one or more observations conforming to Template Name (templateId: 2.16.840...)
2. Exclusive disjunction of two or more constraints:  Constraint A OR constraint B but not both
   The act shall contain only one of the following:
     only one observation conforming to Template Name (templateId: 2.16.840...)
     one or more observations conforming to Template Name (templateId: 2.16.840...)
3. A conditional constraint, where if one condition is met, another shall/should be (or not be) met.
   If the birthTime/@value is less than a day in the past, then birthTime/@value shall be precise to the hour.

As presently designed, MDHT represents all constraints as OCL.  I would change this in certain ways.  Rather than use OCL directly, I would rather have a mechanism to store the data needed for the few handfuls of constraints shown above, and a method to translate those into either an OCL or an XPath (or other expression).  If a constraint couldn't be represented in one of these common ways, then I would represent it as either an UML/OCL or XML/XPath constraint.

So, my answer to this question is NEITHER.  What is best is representation of constraints based on common patterns, and only afterwards, translation into the appropriate language.  After all, just because you have a hammer doesn't mean every problem is a nail.

Publishing Standards using Standards

Yesterday, Dave Carlson presented on how the Model Driven Health Tools will be used to generate the guide being produced by the CDA Consolidation project.  It was like someone turned on the way-back machine for me.  Before I entered the field of Healthcare (a decade ago now), I used to work for a company (now defunct) that produced technical documentation tools working with SGML and XML.

These days there is an OASIS XML-based standard for designing, writing, managing, and publishing many kinds of information in print and on the Web: The Darwin Information Typing Architecture or DITA.  The DITA standard has several open source implementations, including DITA-OT, which MDHT is using as an output format for the model.

DITA can be readily transformed to standard formats like XHTML and PDF, or proprietary formats like RTF, or other output combinations like JavaDoc, Eclipse Help, et cetera, using a common set of inputs.

Dave is using ANT, another Java based open source component to support the documentation build process.

There's plenty of content uses in the CDA Consolidation project that needs to be created manually.  This is incorporated into the documentation using topic maps to build the "Table of Contents" of the guide.  Getting this content from an editor into DITA format would clearly be a concern.  However, most word processors these days generate XML output, often in a standard format like OpenDocument or DocBook, or at least in a well documented proprietary variants of a standard format .  It's pretty easy to write XML transforms from these formats to DITA to capture the necessary documentation structure, so that editors can continue to use their favorite word processes.  There are also commercial products that support editing of DITA directly.

There's plenty of proprietary solutions that support complex documentation development applications, many of them using DITA these days as well.  What the MDHT and CDA Consolidation projects have done has been to develop tools which could support standards developers using open source tools, generating very high quality output.

It's all still very much a work in progress, but as I think about next generation publishing tools, I'm hoping that HL7, IHE, DICOM and other standards organizations consider the MDHT tools as a very strong starting point.  Who knows, maybe there will even be a GIT integration someday that will make one of my IHE colleagues happy.