Comparing CDA and HL7 V3 id elements in XSLT

One of the more frustrating things I've had to write repeatedly is the XSLT expression that allows me to compare two identifiers in HL7 V3 artifacts (including CDA).  The use case that I was working on was to determine whether the legal authenticator of the document was also an author.  I'm building something which displays the names and contact information for pertinent people described in the CDA header.  I wanted to be sure that I didn't re-display the legal authenticator if that person had already been listed as an author.

Assuming that I have a rule that the identifier of each person is always included, one way to do that would be to compare two identifiers to see if they are equal.  What I want to say is: "Select the legal authenticator if there does not exist an author who has the same id".


In XSLT, this would look something like:
<xsl:template 
  match="cda:legalAuthenticator[if there does not exist an author with the same id]">
  <!-- handle display of the legal authenticator -->
</xsl:template>

The first step in developing the predicate (the expression inside the brackets []) is comparing two identifiers.  If $IDx and $IDy are variables representing two identifiers, I can compare them for equality as follows:
 $IDx/@root = $IDy/@root and 
 ($IDx/@extension = $IDy/@extension or 
  (not($IDx/@extension) and not($IDy/@extension))
 )

That's complicated enough to start with, but it deals correctly with the fact that the extension attribute is optional in an element using the II data type.  The following is much simpler and also works:

 $IDx/@root = $IDy/@root and (string($IDx/@extension) = string($IDy/@extension))

It takes advantage of the fact that string() returns the empty string if the node-set passed to it is empty.

But, both the author and the legalAuthenticator element can have multiple identifiers, which makes this even more challenging.  What I really need to say in my predicate is: Select all legalAuthenticator elements such that for all of their id elements, there does not exist an author with a matching identifier in any of its id elements.  I need a way to find authors with a matching identifier.

Something like this looks like it might work:

    cda:legalAuthenticator[
      (cda:id/@root = ../cda:author/cda:assignedAuthor/cda:id/@root) and
      (string(cda:id/@extension) = 
       string(../cda:author/cda:assignedAuthor/cda:id/@extension)
      )
    ]


This fails because of the way XSLT evaluates the comparison between the node-sets using the equal operator.  So, I cannot compare legalAuthenticator/assignedEntity/id/@root and to author/assignedAuthor/id/@root and legalAuthenticator/assignedEntity/id/@extension author/assignedAuthor/id/@extension in separate expressions like that, because I could have a matching root in one node, and a matching extension in node, and the result would evaluate to true, which would be wrong. This is a subtle error which only shows up in a very limited list of data sets.  The following presents an example of XML that would cause this evaluation to fail.

<author>
  <assignedAuthor>
    <id root="1" extension="1"/>
    <id root="0" extension="0"/>
  </assignedAuthor>
</author>
<legalAuthenticator>
  <assignedEntity>
    <id root="1" exension="0"/>
  </assignedEntity>
</legalAuthenticator>

So, somehow, I have to be able to compare @root and string(@extension) together as a unit.  It would certainly be nice if there was a function I could use to look up an element by a function over a set of attributes.  That is in fact, the key [pun intended] to my solution.

We define a key for author identifiers based on the id/@root and id/@extension values as follows:

  <xsl:key name="authorIDs" 
    match="/cda:ClinicalDocument/cda:author/cda:assignedAuthor/cda:id"
    use="concat(@root,':',string(@extension))"/>

Later, when I want to test the legalAuthenticator element, I write the predicate thus:



    cda:legalAuthenticator[
     not(
      cda:assignedEntity/cda:id[
       count(
        key('authorIDs',concat(@root,':',string(@extension)) )
       )!=0
      ]
     )
    ]



This says: Select legalAuthenticator if there does not exist an assignedEntity/id in the legalAuthenticator such that the key constructed from its @root and @extension attributes that matches any of the keys used for an author identifier.

Done.  And a lot more elegantly than I would have thought, although I gotta say, XPath is a nasty language to think in.  Oh well, power has its own price.

  -- Keith

P.S.  If you want to simplify further, you can eliminate the count(...)!=0.  I leave that in because it helps to document what the code is trying to do.

Automatic Example Generation in CDA

One of the interesting discussions today on the HL7 Structured Documents call was about the requirement for examples inline in CDA implementation guides.  We finally agreed on the call to require examples inline for all new templates (and to permit elision if necessary to reduce the size in the guide).  With my implementer hat on, I'm very much in favor of including inline examples, and have strongly recommended and implemented that where I could in any guide I've ever worked on.  I like the inline examples to be focused on the properties of the document, section or entry that are constrained by the guide, and not on details of other templates that are included.  I do want a fully valid example (or two, or three ...) to be included with the guide, and that was previously agreed to by the workgroup.


One of the concerns expressed on the call was the difficulty in implementing example generation and validation in software (e.g., MDHT) to assist in implementation guide creation.  It is very challenging to figure out what should be generated and/or validated.

A few years back, I developed macros on the IHE Wiki that automatically generates examples from data used to develop CDA templates.  You can see examples of the output of those macros for Documents and for Sections on the IHE wiki.  I never did get around to developing macros for entries because those are a bit more complex (especially for the Wiki based macro language, which didn't have access to the CDA Schema or models).


The automated generation ensured that the document example included all required, recommended and optional sections, and that section examples included all required, recommended and optional subsections and entries.  For the same reasons that I didn't automate entries, I also did not automate examples for all the elements in the document or section.  Again, if I'd had access to the model, I would have done that for those though.

In creating inline examples where a template derives from and further constrains properties, I like the examples to highlight what is different from the derived template constraints (e.g., putting that part of the example in bold), as we did for Vital Signs Observation.

It may not be possible to completely develop example content within tools, but tools can certainly help.  And I don't think we should ever let the limitations of what can be automated prevent us from producing a high quality implementation guides with good examples.  I've personally hand-crafted more than 200 such examples, and I completely understand the tedious (and error-prone) nature of a non-automated process.  But the value of examples to implementers is such that they are a necessary part of any implementation guide, however they are created.

Whose problem?

I had an interesting discussion yesterday regarding a problem that has two inequalities in it:

Viewpoint of the Implementer: Perceived Cost to Implement ≫ ROI

Viewpoint of the Beneficiary:   ROI > Perceived Cost to Implement

This situation is fairly common, especially in cases of secondary use^*.  My first encounter with this inequality was back in the days of HITSP, when the Social Security Administration was trying to figure out a standards-based solution to obtain clinical documentation of disability for a patient.

When you look at this problem from the perspective of the SSA, it's a pretty large one, since it accounts for a significant portion of their work.  When you look at it from the perspective of a small healthcare provider, there's little value because the number of disability cases they deal with doesn't provide sufficient value to invest in an automated solution (or competes with much more valuable workflows where automation could help, like lab orders and results).

One way to resolve this inequality is to piggy-back on existing work.  The SSA took advantage of the NwHIN Specifications to meet their specific needs.  Doing so reduced the cost of implementation to a point where Cost to Implement became less than ROI for organizations with enough of a workload.

It still didn't reduce it the cost enough for smaller organizations.  That's when aggregators can come into play, like clearing houses and health information exchanges.  These organizations can automate because their volume warrants it, whereas for smaller providers, it doesn't.  But this step likely won't work if you didn't take that piggy-back step first, because then you'd need smaller providers to do something different for your "secondary" workflow.

This brings up another point about the "art" of interoperability.  You need to consider the fact that the solution you design today will be used for things other than what you intended tomorrow, but not so much that it becomes so complex as to be unimplementable.  It's a tricky balance.

  -- Keith

^* While that may not be the politically correct term, it does tell you what it is.

I don't care what it is called, tell me what it is!

With nearly three decades of experience writing software, I can tell you that I no longer worry about the names of things nearly so much as I used to.  In my early days, we'd put the names into the product, and almost like clockwork, marketing would change the product name weeks or even days before release of the final (planned) build to QA.  Inevitably, search and replace would fail producing a nonsense phrase, and/or someone would report a bug about bad text wrapping somewhere, or even worse, nobody would spot the problem caused by the name change.

As I grew more experienced, we'd slug the name AND reserve more than the expected amount of space for it in the UI, and design for the inevitable change (or two).  And I'd refuse to put the current name of the product in until Marketing had a) signed off on the product name, and b) spent their own money producing marketing literature using it.  In which case, I felt safe enough to go forward with it.

These days, I'm much more concerned with understanding what it is, rather than what you call it.  I know how to describe something using numerous different names.  There are names that engineers recognize, and other names for architects, and yet others names for marketers and C-levels.  The key is not in naming, but in describing what it is in a way that your audience will understand it.

Case in point: Archetype, Template and Detailed Clinical Model.  Explain the difference between these.  The way I do it for a CEO is fairly straightforward.  These are all essentially the same thing.  The way I do it for practitioners of these black arts is much different.  It's like explaining the difference between cancer, melanoma and tumor to people with various levels of medical understanding.

Yes, the fine details matter.  But only to SOME audiences.

-- Keith

ONC is now accepting applications for membership in new FDA SIA Workgroup of the HITPC

ONC is now accepting applications for potential membership for the new FDASIA Workgroup of the HITPC until March 8, 2013 The Food and Drug Administration Safety Innovation Act (FDASIA) Workgroup is charged with providing expert input on issues and concepts identified by the Food and Drug Administration (FDA), Office of the National Coordinator for Health IT (ONC), and the Federal Communications Commission (FCC) to in order to inform the development of a report on an appropriate, risk-based regulatory framework pertaining to health information technology including mobile medical applications that promotes innovation, protects patient safety, and avoids regulatory duplication. FDASIA indicated that if a workgroup was formed, it should be geographically diverse and include representatives of patients, consumers, health care providers, startup companies, health plans or other third-party payers, venture capital investors, information technology vendors, health information technology vendors, small businesses, purchasers, employers, and other stakeholders with relevant experience. If you are interested in being considered for membership on the workgroup, please register at ONC's Workgroup Application Database. The three agencies will review the applications received by March 8, 2013. Anticipated Focus Areas: Throughout the report's development, the three agencies expect to seek input from the HITPC through this workgroup on various topics associated with what constitutes a risk-based regulatory framework for health IT that can also promote innovation, protect patient safety and avoid regulatory duplication. The FDASIA Workgroup is expected to build on prior work such as the Institute of Medicine (IOM) report, Health IT and Patient Safety: Building Safer Systems for Better Care and ONC's Health IT Patient Safety Action and Surveillance Plan; FDA's mobile medical applications guidance and Medical Device Data Systems Rule; FCC's National Broadband plan and other relevant work. Specifically the three agencies will seek input on issues relevant to the report, which include: ·       Types of risk that may be posed by health IT that impact patient safety, the likelihood that these risks will be realized, and the impact of these considerations on a risk-based approach; ·       Factors or approaches that could be included in a risk-based regulatory approach for health IT to promote innovation and protect patient safety; and ·       Approaches to avoid duplicative or overlapping regulatory requirements. All FDASIA Workgroup meetings and documents discussed at such meetings will be publicly available and will offer opportunities for public comments. Background: Section 618 of the 2012 FDASIA charges the Secretary of Health and Human Services (the Secretary) (acting through the Commissioner of the Food and Drug Administration (i.e., FDA), in consultation with the National Coordinator for Health Information Technology (i.e., ONC) and the Chairman of the Federal Communications Commission (i.e., FCC) to publish a report by January 2014 that expresses "a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health information technology including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication."

Viewpoints

I was reading an article someone had referred me to the other day on patient engagement.  One person thought it was a good article, another thought it to still be too paternalistic.  My own viewpoint is somewhat different from either.

It shows an interesting shift in provider attitudes, and that they've come a long way from previous positions.  Yes, as written, it would piss off many patients.  But it wasn't really written with patients in mind.  The audience was physicians, and I think the authors approached their target audience well.

When I read things like this, I always try to account for the viewpoint of the author or organization writing the article.  It's really difficult sometimes to deal with viewpoints you don't necessarily understand or worse yet, disagree with strongly, but it is certainly worth the attempt.

Of course, reading anything this week is a lot easier.  Mostly because if I'm reading anything at all, it's because I want to rather than have to.

Words at Work

"Equivalating?"  I looked at my daughter dubiously.  "Is that even a word?"

"It is now." she claimed, and promptly ensured that its definition as she used it would be properly enshrined in the library of congress.

Of course we know, dictionaries don't work that way.  There are editors who decide what goes in, and what the definitions of words are.  Right.  Wrong. I worked alongside a dictionary editor for a number of years.  Yes, the editors "decided" what words needed to go into it,  but that was a pretty simple decision based on objective rules: evidence of use.  The more a word was used, the more likely it was to appear.  As to meaning, the way a word is used defines its meaning.  The editors wrote the definition based on how the word was used.  So, no, editors didn't decide what a word means, or how it is spelled.  The users of words do that (unless you live in France).

Awful wasn't always equivalated with wretched.  At one point in time, it meant (and still does) awe inspiring.

Extensive debates on the definition of a term in a standards document isn't all that useful.  It's especially a waste if this is an existing term, with an existing, well understood meaning.  You will do little to clarify your standard if you don't use the commonly accepted definition, rather than rely on nuanced meaning in your carefully crafted definitions.

'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'

We've been down this pathway before.  It wasn't that productive or meaningful then, and it resolves little now.