Wednesday, July 1, 2015

CCDA 2.1 DSTU Update Available for Comment

I was quite please to see this cross my desk this afternoon.  It is the announcement of the request for comments on the C-CDA 2.1 DSTU Update.  As you may recall, this project was initiated at the May working group meeting.  We are now at the first of July, some six weeks after we initiated this project, and have knocked down our third duck (there are about three more to go).  We've done our best to make sure that there is plenty of time to get this into the Meaningful Use Stage 3 regulation, and now it is time for HL7 members to do their part.  Please have a look at the new material and provide your comments before June 13th.



The Consolidated CDA R2.1 DSTU update is available for member review.

SDWG will follow the review process outlined here:

Comment submission deadline: 7/13/2105 11:59 PM ET
Updates open for comment are identified by yellow highlighting.
·         Volume 1 - If the heading is highlighted, the entire section is open for comment.
·         Volume 2 - The specific conformance statements updated are highlighted. Templates that are only updated to reference a contained template that have been versioned (extension="2015-08-01") are not open for comment. Figures with updated conformance statements are open for review.

There are 3 methods to find edits:
2.     High-level change-log in Volume 1 (page 43)
3.     Excel comparison files (CDA R1.1 vs 2.0 Reviews) included in the review zip

All 3 methods should bring a reviewer to the same changes. Comment submission deadline: 7/13/2105 11:59 PM ET

Note, several R1.1/R2.0 errata are fixed in this release  -- all marked with 8/1/2015 (C-CDA R2.0/2.1) on our DSTU comments page (R1.1 / R2.0). SDWG is developing an R1.1/R2.0 errata summary which will be available prior to final publication of R2.1.


Brett Marquard
River Rock Associates

A Protocol for Interactive Services in FHIR

In developing Health IT software, it's fairly common to develop solutions that have to interact with interactive web sites.  When all that is needed is for those web sites to interact with a user, this is fairly easy to work out.  However, when the interaction also needs to communicate to the "back end" to convey the outcome of what the user did, it is a bit more complicated.

There are several use cases for this kind of interaction that I've seen in the past, and one that most recently came up in the context of the Guideline Appropriate Ordering profile from IHE.

The first of the use cases is patient selection:
In this use case, a patient is registering or being admitted for care to an institution.  In this case, the patient name, date of birth, and gender are provided at the time of registration.  One or more pre-existing patient records are located by the system.
The user has a few choices:

  1. Select and confirm the appropriate record (if only one record is found, the selection step is skipped and that record is simply selected, if no records are found this option isn't available).
  2. The user can search again using different information.
  3. The user can create a new patient record.
  4. The user can cancel the registration process.

The second of these is document searching and viewing.  In this case, document search criteria are used to identify candidate documents.  Pretty much the same options are available to the user, with a different end result:

  1. They can select a particular document to view (If one document is found, it may be automatically selected; if no documents are available, this option isn't available).
  2. The user can search again using different criteria.
  3. The user can cancel (this use case doesn't have the create option).
The third of these use cases is clinical decision support on the appropriateness of the order.  In this case, the following options might be presented:
  1. The order might simply be approved, in which case the user may simply be asked to confirm the order details.
  2. The user might be asked for more information about the patient for whom the order is being made (e.g., for a MRI where the indication is headache, the CDS system might ask if this is the worst headache the patient has ever experienced).
  3. The order might not be approved, in which case the user may be requested to use a different service, or to override the CDS result.
  4. The user can cancel.
The previous may not seem to be obvious use cases, so I'll toss out another one that is pretty much accepted across the IT spectrum: User Authentication.  In this case, a user authenticates with an external system and the external system conveys a token back to the "back end" requesting the authentication.

For the IHE GAO Profile (the third use case above), we borrowed some design features from specifications that support authentication.  
  1. The client makes a request to an interactive service through a known (preconfigured or returned in some previous interaction).  It also passes in a URL to which the interactive session will be redirected when the server has finished interacting with the user.
  2. The interactive session continues as a normal web interaction.  
  3. When the server has finished interacting with the user, it passes back a redirection request using that URL, and some URL parameters to tell the page that it was redirected to what the status of the request was (canceled, completed, error, et cetera), and where to get the full details of the result.
It occurs to me that this could become a general pattern for interactive services that might be specified somewhere in an Implementation Guide.  What do you think?  Would this be a good pattern to specify for FHIR?  Or more generally?  What other features should be considered in this interactive framework?

Tuesday, June 30, 2015

Allergies, Severity and Criticality in HL7 CCDA

A rather long document wound up in my e-mail this morning, sent to Structured Documents cochairs, HL7 Leadership and several other individuals (myself included).  The e-mail addresses concerns from the HL7 Patient Care Workgroup about a patient safety issue with the current C-CDA templates for Allergies, specifically in how these templates address Criticallity of an allergy, vs. Severity of a reaction.  C-CDA does NOT in fact relate criticallity with an allergy, only severity.  BTW, that concept of allergy severity goes back to 2005 and before, and was adopted in CCD, and forward into subsequent releases.

The Patient Care Workgroup has been working on these topics for a number of years, and believes that they should be addressed in the HL7 C-CDA DSTU 2.1 Update Project.  I could readily be convinced that is the case.

The concern of the Patient Care Workgroup is that the existing templates do not appropriately address how allergies should presented to a clinician, and as a result, produce a patient safety concern that should be addressed as soon as possible.

I'm pleased to see HL7 having to take on this kind of challenge, and look forward to see how this changes our processes going forward.  In this case, we have a "conflict" between two governance groups over something that could affect patient care.  Arguably, there should be a process to address this sort of issue.  Today, medical device manufacturers also have processes to address patient safety issues in the technology they produce, I think HL7 will need to adopt similar processes.

We saw a somewhat similar issue (addressing security rather than safety) crop up last year with CDA stylesheets.

Friday, June 26, 2015

Pedantry has its place

A couple of recent vocabulary discussions on HL7 Working group lists made me reflect on the topic of precision in the definitions in standards.  We (standards developers) spend a great deal of time being very precise in our definitions.  Often making very fine distinctions about things that people who wind up using them in the real world aren't aware of, and for the most part, don't need to be.

We need this degree of precision in our processes, but we have to remember that the precision is for our own use, not necessarily for that of the developer.  What developers who implement the standards need is something that is clear and obvious and makes sense.  If we cannot take our very precise definitions and describe them to a developer, then as Richard Feynman would say, we don't really understand it ourselves.


Thursday, June 25, 2015

He was always my manager...

Sad news came to me yesterday about the best manager I never had.  Kirby Mansfield was the Director of Software Development at the Software Division of Houghton Mifflin, and one of the people principally responsible for my being hired by Houghton Mifflin and coming to work in Boston.

It was the summer of 1992 (I think) when I came up to Boston to visit my best friend Tom (one of the reviewers of the CDA Book) and also a software development colleague whom I've worked with at three different companies, and spend time with him and my soon to be girlfriend and later my wife. Tom brought me into work with him at One Memorial Drive (now Microsoft NERD Center) one day to meet his buddy Win, and his boss Kirby.

When he introduced me to Kirby, we started talking about what I was doing, and Tom made some excuse about having to go to a meeting, and I found myself in a job interview I never expected with one of the kindest and gentlest people I would ever meet in life.  It was so subtle that it took me about 15 minutes to discover what Tom had contrived. While I wasn't in the mood for a new job at that time, my situation changed about 3 months later, and I called Kirby back.  "About that job you were talking about?" I said to him, "I'm interested."

Kirby had just been promoted up the chain, and so I would now be talking to his replacement.  We did a short phone interview, and I was hired within about 48 hours. Kirby made sure I got a good relocation package and a good salary.

Over the next decade (yes, I worked for the same company for that long), Kirby would never be my manager.  I always reported to someone else, and he migrated quickly to the top.  I never quite caught up with him.  But what I remember most about him was that he was always on the floor talking to people up and down the chain, he always sought the opinions of others.  He would patiently explain our business strategy to anyone who asked, and always encouraged everyone to do their best.  Kirby listened, and when appropriate, he also changed his mind.

Kirby was the kind of manager everyone always dreams about.  He was considered to be a mentor to about a half dozen different people I know, all of whom became excellent managers under his tutelage.  That's a pretty significant achievement when you think about it.  Being a mentor is a very special relationship.

I caught up with him every now and then over the years, but never frequently enough -- at least as I look back at it now.  Kirby was never my manager, but in my heart, he will always be my manager.

Friday, June 19, 2015

Remember When?

Remember how almost nobody had a PC, and now everyone does?  Remember how nobody had a word processor or spreadsheet, and now everyone does?

How many of you remember what it took to install an interface card in an IBM PC or compatible system?  You remember jumpers, IRQ settings, port addresses?  Do you remember configuring drivers?  And then the various changes to the technology came along, and after a few years, we just plugged it in and it worked.  Well, mostly.  Some cards didn't live up to the standards.  Some had some configuration jumpers for different features anyway.  And some pairs of cards just wouldn't work together anyway.

Do you remember what it was like in the days of setting up printers with your favorite word processor?  Especially when it needed a custom driver?  And then, when Windows came along, we no longer had to configure every application, but now we needed to install a driver from the manufacturer for our printer when we hooked it up?

And then Windows 95 came along and got rid of all of that with Plug and Play.  Well most of it.  OK, some if it.  And it got better over time.

And cables? Remember having to build serial cables?  Or getting long parallel cables.  Now we have USB, or even WiFi and BlueTooth.

So, now, you can just plug something into your PC, and it works, mostly.  Drivers are automatically installed, downloaded or even updated over the Internet.  How long did that take?

Let's take a look why don't we:

The IBM PC was Announced in 1981
Windows 3.0 was Announced in 1990
Plug and Play came with Windows 95
USB 1.0 was announced in 1996 but didn't reach general adoption until USB 1.1 in 1998
WiFi came out as 802.11a in 1997, but it took 801.11b in 1999 before it became widely adopted, and then the WiFi Alliance was born.
BlueTooth showed up at the turn of the century.

These days, nearly 35 years later, you just plug it in, and it works. Well, mostly.  Sometimes you still need to deal with those crap consumer driver disks that the manufacturers like to give you for home use products.  And sometimes it still doesn't work.

Some of you reading this blog never had to deal with this OLD stuff, it was simply before your time. But for those folks in DC that think major technology advances happen in 3-5 year increments, I wish they'd think back to the days before the Internet, and remember how long ago that was.  It didn't happen overnight.  A baby born on the day the IBM PC was announced is barely old enough to hold office in congress, but still isn't old enough to run for President.

Yes, we've all got a long way to go for Interoperability in healthcare.  But at the same time, we also aren't in the enviable position of having only two or three vendors near monopolies on the applications and platforms to choose from (and get to adopt the standards). No, it's more like two or three thousand vendors, and the standards that I'm referencing are about 3-4 layers higher up on a stack of standards that got us where we are today plugging in a printer.

When's the last time someone just connected major infrastructure components in any business's enterprise with the expectations that some have put forth in Healthcare?  Never. Think about it. What other industries technology infrastructure has received so much attention?  Forget banking.  Anything that requires nothing more than a 2400 baud modem to communication a single transaction isn't on the same footing as healthcare.  If you have to ask why this is so, you probably aren't qualified to be making major decisions about technology infrastructure.

So, do me a favor Senators, get out of my way and let me work.  I get the need, and unlike many, I actually know what to do about it.

Thursday, June 18, 2015

HL7 Template Versioning Rears its ugly head ... again

One of the challenges we've discovered in the C-CDA 2.1 DSTU Update project is the process needed to update templates that reference updated templates.  This involves what we've grown to know as the "ripple effect".  A change to one template, such as the Result Observation requires new versions of templates all the way up the chain, resulting in changes being required to 13 other templates.  Each of these changes requires six additional steps according to a list provided by Brett Marquard, my co-lead on this project:
  1. Update the Title
  2. Update the Identifier
  3. Update the conformance binding to the new template extension
  4. Re-add the figure and update since versioning does not carry forward
  5. Update the contained entity
  6. Update the containing entity
  7. (my addition to the list) Update the examples!
I had proposed today on the SDWG call that we consider that version specific references to a template are really an errata.  The point of changing to the new versioning strategy was to allow a version non-specific reference to be made to a contained template in a conformance constraint.

A contained template reference can be rewritten from:

Results Section (entries optional) (V2) (optional)1. SHALL contain exactly one [1..1] Result Organizer (identifier: urn:oid:2.16.840.1.113883. (CONF:15516).
to the following:
Results Section (entries optional) (V2) (optional)1. SHALL contain exactly one [1..1] Result Organizer (identifier: urn:oid:2.16.840.1.113883. or later revision) (CONF:15516).
Pros for this proposal:
It eliminates the necessity to ripple. Because this would be deemed errata, this change DOES not require a change to anything using Results Section, and Results Section can use a later version in other guides calling on it.

Note: The guide itself can have a conformance constraint that indicates that all referenced templates must conform at least to the versions of the referenced templates present in the guide.  This turns into a single Schematron constraint that might be complex, but can certainly be developed easily from a list of template identifiers present in the guide.

Cons raised on the call:

  1. The specificity of the guide is reduced.
  2. The tooling would need to be changed to support this.
  3. There are concerns that this means all versions of a template would need to be backwards compatible in the future.

While I agree that this reduces the specificity of the guide, the present degree of specificity is what causes this ripple effect, and this is, as one person put it: "... a bad bad problem ...".

With regard to the tooling, yes, we would need to address it in the tooling at some point.  However, we could automatically correct the output of the tooling by making a list of the necessary template OIDs that would require this change, and automatically address making the changes in the Word Document.  Later changes would be needed to address the binding change, but those could be made after the publication.  This is, of course, not ideal, but better perhaps than further delays.

Finally, with regard to backwards compatibility, I would argue that if there are major changes to the way a template is modeled (such as was done for problem and allergy status), the appropriate way to handle those changes is to DEPRECATE the old template, and create a new one if need be (we didn't need to do that for those templates, because we handled it differently).

Yes, this would ALSO require some changes to the automatically produced Schematron in the tooling, but I can automate many of those changes as well.  I would also note that tooling issues, while important, should be secondary if a viable workaround exists.  I'm getting really discouraged about how proprietary HL7 tooling are preventing standards work from progressing the way it needs to.  If this were Open Source, at least I could work on fixing the tooling issues.

The HL7 Templates DSTU recognizes containment of another template as one of the possible kinds of constraints on a template (See section 2.10.2).  It also recognized static or dynamic bindings associated with the containment constraint (see section 2.10.5):
... an artifact is bound to an element either as
  • STATIC, meaning that they are bound to a specified version (date) of the artifact,
  • or DYNAMIC, meaning that they are bound to the most current version of the artifact. 
Value set bindings adhere to HL7 Vocabulary Working Group best practices.
A STATIC binding is a fixed binding at design time whereas a DYNAMIC binding implies a need for a look-up of the (most recent) artifact at runtime.
It can also be found in practice to “freeze” any binding defined as “dynamic” to the most recent artifact at the time of the official publication, making “dynamic” bindings actually “static” for the most recent version. This makes the publication stable with regards to the binding of artifacts.
I'm proposing this as ONE possible solution to the ripple effect.

Another possible solution is to be able to automate making some of the changes to the templates. When we originally made these version number changes, I worked with Lantana to make the changes using an XSLT on a download of the templates in the guide (including fixing examples), and then the material was re-imported into the guide.  I could do this again.