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.

   Keith

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.

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.

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.10.20.22.4.1) (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.10.20.22.4.1 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. 

Principle Driven Development of Standards

One of the things we did for the C-CDA DSTU 2.1 project was identify a number of principles we would use to make decisions about how to modify templates written in C-CDA DSTU 2.0 to support backwards compatibility with C-CDA DSTU 1.1.  So long as we agreed upon the principles (and we've tested them out), we can simply do the work using these principles to guide us.  Those principles have become invaluable as a means of determining what needs to get done.

Principles come in a variety of forms.  They can be:

1. part of your methodology or process.
2. derived from the scope of your project.
3. based upon best practices.

Using principles to guide the development makes it easier to make decisions.  All too often in development, we wind up answering the same kinds of questions repeatedly (and in the same way). If you find yourself doing that, you've probably found a place where you should be defining a principle.

   Keith

Security is also about Accessibility

This morning's supposedly quick stop at my bank safety deposit box reminded me of this point which sometimes needs clarification.  I left the house early to go to my bank to get my motorcycle title from my safe deposit box (I'm upgrading from a 650 to an 1100 later this week).  After getting into the safe, we couldn't get the safety deposit box keys to work.  There were two challenges:  First, the bank manager didn't know which of his keys he needed to use because there's a separate one for each of the sets of boxes, and they aren't labeled.

Secondly, no matter which of his keys we tried, with his and my key we still couldn't open the box. He called a locksmith, and after they showed up, we were able to get in.  Unfortunately, I didn't get to see the locksmith drill the box, because he was able to find the right key just by looking at them, and then jiggle the key and the door just right to open it.  The problem was that the box just next to mine had recently been reinstalled incorrectly, making it just slightly ever so inaccessible.  That delay cost me several hours of my time.

Security is about protecting assets, but an asset is useless if you cannot use it.  So a key which locks everyone out, including the people who need to use the asset is almost as bad as leaving the asset unsecured.  In fact, given the risk profile I'm dealing with (what I store and what it needs to protect against), a good fireproof safe in my house would probably be a better investment than a safety deposit box.

The same is true about patient records.  The HIPAA Privacy and Security regulation today is very much like my safety deposit box was today.  It does just as much (or more in fact) to keep me away from my health records as it does to secure me against others accessing them inappropriately.  A delay accessing those records could cost a lot more than time.

   Keith

P.S. As a reminder, today is the last day to comment on MU Stage 2.  See Regina Holliday's blog for her comments on NoMUwoME.

FHIR and BlueButtonPlus for Newbies

This one is for ePatient Dave, who asks:

Hey all - I need a good newbie *overview* (not weeds) on the #FHIR and #BlueButtonPlus combination. Google has failed me - help??

— Dave deBronkart (@ePatientDave) June 12, 2015

---

Blue Button Plus (BB+) is an initiative that started at a White House sponsored meeting several years ago (I got to attend with my daughter).  I've written a number of posts about this particular effort, and participated in the Blue Button Plus Pull initiative of the ONC Standards Initiative project.  That workgroup produced an API based on an early draft of the HL7 FHIR Standard.  Integrating the Healthcare Enterprise further developed that into a specification called Mobile Access to Health Documents (MHD for short).  BB+ Pull and MHD are specifications that meet the requirements of the ONC Certification and Standards regulations for EHR systems to support View and Download. A sister specification BB+ Push uses a different protocol (call Direct) based on e-mail to support the "Transmit" requirement of that regulation.

BB+ Pull and VDT capabilities allow you to access the same kinds of clinical data at nearly the same level of fidelity that healthcare providers have in their EHR systems.  This allows patients to use this data in ways of their own choosing, including sharing the data with other healthcare providers, or tracking and using it in applications on their own computers and mobile devices.

As a standard, FHIR has really taken off, reaching awareness heights in the trade press, academic organizations, and medical professionals that many standards organizations would drool with envy over.  HL7 and its creators have much to be proud about in this.  I've awarded several of the developers with an Ad Hoc Harley award, including Grahame Grieve, its chief Architect, and Josh Mandel (who was also very involved in the BB+ work).  However, FHIR is also still in the early adoption stages.  Several vendors are supporting its development and incorporating it into products, but it will take some time for those versions of the products to reach a doctor near you.  From product release to mainstream deployment across a customer base can take several years.

While FHIR has really taken off, Blue Button Plus still has yet to reach similar dizzy heights.  The Blue Button Connector page lists 140 hospitals, 9 pharmacies, 4 labs, and 39 payers who provide BB+ access, but few of these allow you (as BB+ Pull does) to send those records to your favorite application.  There are also about 13,000 physicians who have attested to MU Stage 2 which provide some access for download, but likely don't provide the BB+ Pull capabilities.

Both of these specifications have a lot to offer patients, and we are likely to see even more utilization of FHIR, Blue Button Plus, and IHE's Mobile Access to Health Documents, as well as another FHIR related ONC initiative; the Data Access Framework, which will provide access to granular health data instead of documentation of encounters in the future.  However, at the current rates of development and deployment, it will probably be five years or more until I, as a resident in a rural community, can have a nearby physician who uses a system that supports these standards.  If I were to drive an hour to a Boston-based physician, I might have to way only three years for wide-enough deployment to be readily able to find a physician that could give me my damn data.

   -- Keith