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.

Continuous Improvement

You'll need to find your own metaphor in this one, given that my family and I are on vacation this week.  We spent yesterday at the water park.  They have one of those continuous Wave machines where you can "surf" on one of those boogie boards.  A turn lasts as long as one fall (two if you fall early in the ride).  In order to keep the ride moving, there's a lifeguard at the bottom who guides the rider through various skill tests.  The rides last about the same amount of time for each rider even though riders are of various skill levels, and the reason is that nobody ever gets to rest on their laurels on this ride.  Even the experts are pushed to the point that they take a fall every now and then, which means that everyone gets a chance to ride. Everyone has fun, and everyone is constantly pushing to improve.

\

Sharing Savings with Patients

The other day, my wife and I had to make some choices about a piece of DME equipment that she needed.  I spent a good bit of time researching various options, and we wound up choosing a piece of equipment that was half the price of other options presented.  It wasn't just the cost that helped us to make that decision, it was also recommendations based on quality and reliability, and we didn't choose the cheapest unit.  But still, we spent about half of what we could have.  We spent all of this time because I want to optimize my use of my HSA.  This has a real financial benefit, but it isn't an obvious one for many.

In thinking about the Medicare Shared Savings program, a thought occurred to me that healthcare providers are getting the opportunity to share savings.  What would happen if in addition to sharing savings with providers, insurers (including Medicare) shared savings with patients.

How would this work?  Payers would need to establish and share with patients the costs they expect to have with respect to care for a specific condition or injury.  They'd also have to share with patients the costs of various care options.  At the end of each year, for each condition or injury experienced by the patient, where the patient's treatment cost the payer less than the expected amount, the patient would be reimbursed a portion of the saved amount.  This is a much more obvious financial incentive that would very likely have a much larger impact on patient behavior.

It would take a heck of a lot more transparency and information than patients have today about the costs of care.  Most insurance calculators that I've seen don't cut it.  What I've seen is that they compute the cost based on the treatment that they expect providers to give, rather than what we as patients get.  My favorite story is the $44 dollar ice bag that we were charged for for one of my wife's PT visits.  After we got the first bill, she told them she'd do that at home during the next visit.  And the insurance calculator never figured that into our (or their) costs.

Imagine what could happen if patients had such an obvious financial incentive to take a more active role in their care.

Simple Math Expressions

Time to get back to the technical stuff.  One of my outstanding work items is to finish up Simple Math for inclusion in the QDM-based HQMF guide as we agreed to at the HL7 Working Group meeting.  I spent some time with Marc Hadley on the phone a few weeks back, and we firmed up what it would consist of, which I report here:

Simple Expressions

Simple expressions is a language for expressions based on JavaScript, whose purpose is to enable simple computations in HL7 specifications such as HQMF.  It allows elements of the model found in a standard or implementation guide to be accessed and computed with.  The language is based on JavaScript to formalize the behaviors of the computation model, but it need not be implemented using a JavaScript interpreter.

Note: We should likely be more specific as to what version of JavaScript it is based upon.  I'd propose ECMAScript 5.1 would be a good starting point.

Note: Strings needed to be added to support dynamic construction of messages for HeD, so this is now "Simple Expressions" instead of Simple Math.

Identifiers

Identifiers in Simple Math follow the rules of JavaScript identifiers with a few simplifications to make them more usable in other implementation environments.

identifier ::= [a-zA-Z][a-zA-Z0-9_]*

Data Types

The data types of Simple Math are the Date and String objects and numbers and Booleans.  Literals for null, strings, numbers and Boolean values are represented as in JavaScript.  Regular expressions and function declarations are not supported.  The Date object will be wrapped to support additional member operations supporting date arithmetic, and we'll need to evaluate that further.

Regular expressions are not supported.

We will add support for a limited set of HL7 data types: IVL_TS, IVL_PQ, PQ and perhaps CD seem to be the most likely.

Operations

The language does not support assignments or side effects, thus, there are no assignment operators, nor post- or pre-increment/decrement operators, nor a delete operator.  Bit operators (~, &, |, ^, <<, >> or >>>) are also not supported.

The strict equivalence === and !== are not supported.

Given the lack of side effects in this language, there is no need for a comma operator, since it serves to order expressions, and evaluates to the last expression.  If you would write an expression as expr1, expr2 in JavaScript, then in Simple Expressions, all you need write is expr2.

The instanceof and typeof operators are allowed.

Note: We hadn't come to a conclusion on the ternary operator ?:.  This is rather useful, but not readily supported in other implementation environments.  One of the challenges is that according to the rules of ECMAScript, only one of the two expressions after the ? is evaluated, and this may not be readily implemented elsewhere.  I think we allow it, and simply note that some implementations may not be able to fully implement the semantics as specified.  It's therefore a warning to users to use the ternary operator sparingly if they want their expressions to be computable on the widest number of platforms.

Note: We also haven't come to a conclusion on whether arrays are needed or not.

Miscellaneous

• Comments within expressions aren't supported because they can be included in the surrounding XML where the expression is used.
• There are no multi-step expressions.  Line breaks are treated like white space in an expression, and there is no need to terminate an expression with a ; because it is terminated by context.
• String expressions force conversion of numbers to strings, just as in Java Script.

Implementing the Language

One of my design goals for implementing this language was that common expressions in the language should be readily converted to another implementation language through an appropriate sequence of regular expression substitutions.   As the language is currently specified, this amounts in C, C++, C#, Java and JavaScript to being an identity transform (or nearly so).  

My test case for success would be to build an implementation that converts common expressions in Simple Expressions to SQL.

Engagement means stop treating patients like Children

We've been having a discussion about what patient engagement means over on the S4PM mailing list in the past week.  Here's a story I thought I'd share:

My wife's C-PAP machine is in need of replacement.  The fan now keeps us both awake (even with ear-plugs).  The unit we have is fairly old, and while my wife is pretty happy with that model, that unit is no longer manufactured (in fact the company that makes it has been acquired and then spun-off since).

When we originally acquired that unit, my wife researched a number of units online, and found the one she wanted, with the features she wanted.  In order to get it, she had to go through a DME supplier in my state, who had to special order it because they don't usually provide that unit (it's not pricey enough, apparently).  In case you've never experienced this, a C-PAP is a medical device that is only available through prescription (at least in my state), and even though it is very easy to set up, can only be configured by an authorized person to the setting prescribed by the healthcare provider.  Oh, and the company that we originally got it from is not in business any more.

So she called the doctor's office today because she needs the prescription information so she can get a new device.  Just to replace the device, we have to jump through all those hoops again.

My wife spent more than ten minutes explaining to the staff at our Doctor's office her problem with the current machine, and that she doesn't need another sleep study, that she's had one recently, that the settings for the device are X and Y, and that she needs the prescription to be communicated to a company that will provide a new device.


We finally managed to get someone to understand what we needed, yet it took more than 15 minutes of her HCP's staff time for her to get halfway there.  We're now waiting on a call back from the company that my HCP contacted with the prescription information, and we'll see what they have to offer, or if we need to go through that special order process.  What a royal pain this has been.

She's had sleep studies every three years, and her settings haven't changed.  She doesn't need another test.  She doesn't need a prescription other than to get the equipment she needs.  She doesn't even need advice on what kind of equipment to purchase, or how to use it.  In fact, she knows how to adjust the settings on several models of CPAP (as do I).  When you live with a piece of durable medical equipment like that, you often know more about it than some of the folks who are supposed to know how to sell and service it.

This is one of those times when I wish our healthcare system stopped treating patients like they were children.

Getting Unburied

I spent a great deal of Saturday digging out my driveway.  Given the amount of snow that dropped here (in excess of two feet), it was no surprise that the town's plow did a barely adequate job on my street.  In fact, I had to dig out an extra eight feet (almost a car length) to get to the part of the street they had plowed.  I guess it shouldn't amaze me how my government manages to get me to do so much additional work on their behalf.

I have a four (six in a pinch) car driveway, but only two cars.  One of my optimizations was to cut a one-car width path through the snow at the end of the driveway, so there would be a way to get both cars out, but only if the efforts to get the cars out of the driveway were coordinated.  By sharing the results, both cars could take advantage of the same path.  We arranged the cars in the driveway to take advantage of this ahead of time.

This morning I cut a narrow path from the driveway to the back door so we could accept an oil delivery (just in time as it were).  I did just the amount of work necessary to solve this problem.  Keeping the scope very narrow here enabled me to finish the job in a remarkably short period of time.

I'm taking the first approach with Health eDecisions and HQMF.  By combining the efforts to create the standards, I've reduced significantly the amount of work I'll have to do for either.  This is a case where sharing the path makes for less work.

I'll be taking the second approach with some other efforts, doing the minimal amount that I can to keep things moving forwards.


Applying these approaches is going to help me get unburied metaphorically later this year.  I'm just hoping that ONC doesn't pull another Nemo on me later.  But that may be too much to wish for.

I'll take it as it comes, just as I did with this storm.

ABBI - The Pitch

When developing a standard, there are two audiences you have to pitch it to: The developers who will use it, and the organizations that are making decisions about whether or not they are going to implement it.  I've spent quite a bit of time talking to the former, but not enough to the latter.

Assumptions

First of all, I'm going to assume that you already know a little bit about Meaningful Use, and the Nationwide Health Information Network (NwHIN), and maybe the fact that there are two standards for exchange specified for the NwHIN: Direct and Exchange.  Direct is the simplified on-ramp using e-mail, and NwHIN Exchange is a bit heavier, but also widely deployed set of standards used to support communication of healthcare data between Federal agencies and mostly larger healthcare provider systems.

A Quick Overview

What is ABBI?

ABBI stands for Automate the Blue Button Initiative.  The project came out of a White House sponsored meeting which both I and my 14-year-old daughter (named Abby) attended.  The point of this project is to develop a technology (actually a set of standards that technology can be developed to implement) that will enable patients to set up a way to get their healthcare data once, and it will simply happen.

What kind of Healthcare data?

The same data that is required to be given to patients in the same electronic format as is specified under the View, Download and Transmit requirements of Meaningful Use Stage 2, using the exact same standards.  Plus, any additional documents a provider wants to make available through the API.

I've got enough to deal with for Meaningful Use Stage 2, why do I need ABBI?

One of the key goals of the ABBI project is that providers could use these specifications to meet the View/Download/Transmit requirements of Meaningful Use.  A patient who downloaded their documents using an application supporting the ABBI API, would qualify in the numerator of patients who have used the View/Download/Transmit capability of the Certified EHR.

How does it work?

The way that it works is pretty straightforward (although many of the details still need to be ironed out).  Here are the essentials:

1. Patient obtain Application(s)
   Patient obtains or is provided access to an application that will facilitate communication of patient data to them.  This could be a portal, a PHR, a cloud-based repository of health information (e.g., Health Vault), or an application running on a laptop, tablet or smart phone, or an NwHIN Direct address.
2. Agree on the patient identity
   The patient supplies an identity to their healthcare provider, that the provider can be used to securely identify them.  This could be an NwHIN Direct address, a username/password combination, or any number of commonly available identities on the Internet by which the patient will identify themselves.  The provider authorizes the patient identity to access the data within their system.

At this stage, the choices bifurcate, depending on whether the patient data is being pushed to or pulled by their application.

Push Model

The push model utilizes NwHIN Direct.  The provider's EHR communicates to the patient by sending NwHIN Direct messages whenever new information is available:

1. Provider's EHR is configured to "push" patient data to the selected NwHIN Direct address.
2. As new encounters occur, the encounter summary is pushed to the patient's NwHIN Direct address.

Pull Model

The pull model utilizes the ABBI Pull specifications, which are based on RESTful specifications developed using the HL7 FHIR protocol, and which can work with the NwHIN Exchange specifications.

1. Patient authorizes "subscriptions" to that data by the application described above (using OAuth 2.0).
2. As new encounters occur, the encounter summary is made available in the EHR (e.g., through the patient portal).
3. Application requests (from the EHR/portal) either the current "Patient Summary", or a list of current documents available for the patient, and downloads those documents as needed via the authorized "subscription".

Security

All communications in either model are encrypted using web encryption standards, and the patient identity is assured through other web security standards (e.g., S/MIME or OAuth 2.0).  For push, ABBI uses NwHIN Direct, and thus uses S/MIME and TLS to secure and encrypt communications.

For PULL, the ABBI efforts are being coordinated with other efforts in the Internet Engineering Task Force (IETF), and with Integrating the Healthcare Enterprise's Internet User Authentication profile currently under development, in order to establish a secure way for patients to authorize applications to access their health data.

Standards

The ABBI Protocol is being implemented in Open Source for the Pull Model described above, and is hosted in Google Code.  A test server has been created and is hosted in the cloud (it may be down from time to time).

The basics of the ABBI PULL Protocol make use of the HL7 FHIR xdsentry resource.  FHIR is a new RESTful standard being developed by HL7 that supports simple XML and JSON representations of healthcare data.  This same work is being considered as the basis for other Healthcare standards efforts, including IHE's Mobile Access to Health Documents profile.

The advantage of using this standard is that it is closely aligned with other standards (IHE's XDM and XDR used in NwHIN Direct, and XCA used in the NwHIN Exchange specification, and supported by the CONNECT Open Source project.

As FHIR evolves, it expects to produce clinical resource specifications that would support access to fine-grained patient data, including problems, medications, allergies, immunizations, lab results, vital signs, et cetera.  By starting with the FHIR infrastructure resources for documents, we enable access to existing health data in CDA documents, while paving the way for future, targeted access to patient data in later phases.  This data could be packaged together in document form (as is done today with the CDA standard), or used in other services.

Finally, FHIR provides a mechanism for patients and providers to store data as well.

A Last Word from Abby, on ABBI

HL7 MeaningfulUse Webinar Answers to Questions

Yesterday I gave another webinar on HL7 Standards and Meaningful Use Stage 2.  The presentation and recording links will be posted here and on the HL7 Web site as soon as they are available.  As promised, here are the answers to questions I didn't get to during the call.

Finding the blog and other Resources:

• Can you show the bit.ly address again? Could you go back to the link to the blog again?
  If you found these answers, then you've found the right blog.  The link/bit.ly address was to this post.  I e-mailed and/or tweeted these two querants so that they could find it.
• This is a little overwhelming, especially since there is so much competing "noise" in this domain -- can you recommend a book or other resource that helps communicate the big picture and component parts?
  Do you work for my publisher?  See The CDA Book for one.  Fred Trotter also has a great book called Hacking Healthcare, A guide to Standards, Workflows and Meaningful Use
• Where can one get the Consolidated CDA Guide and is there a fee?
  The Consolidated CDA Guide is available to HL7 Members from the DSTU Web Site [member login required] or from the HL7 Store for $50.  Eventually, this will be freely available to all once HL7 implements the new IP policy.  Stay tuned here for more information on that when it becomes available.
• Does there exist a Consolidated-CDA validation tool?
  For Meaningful Use Stage 2, you want:  http://hit-testing.nist.gov:9100/ttt/
• It's a great presentation. Thanks!
  Thanks for attending.

HL7 2.5.1

• How are you looking MU 2 implementation of HL7 will be? (a) mandatory to upgrade to 2.5.1 for basic few events(transferring to other audiences like Immunizations, labs, cancer registries, surveillance  (b) Compatible to 2.3.1 and 2.5.1. (c) Complete transition to 2.5.1 for all. Here we are considering Outpatient professionals who wont be willing to shift to higher version.
  My expectation is that meaningful users must use the certified EHR technology to qualify, and that technology must use HL7 2.5.1, so (a) or (c) is the answer you are looking for.  You've covered all of the activities for which MU requires use of HL7 2.5.1, anything outside those isn't covered.

Clincial Decision Support

• Do you see a trend to have Clinical Decision Support Modules to be ONC Certified or perhaps under FDA?
  The Certified EHR must enable the provider to enable a clinical decision intervention.  I don't see any more "certification" than that from ONC.  With regard to FDA, I hesitate to predict what they will do.  They have certainly been looking.  There is ongoing work in ONC to develop standards for exchanging clinical decision support artifacts in the Health eDecisions Project, but I suspect they won't be certifying specific artifacts, but rather the use of those standards in the future.

Programming Languages

• Which programming language you recommend for Desktop application programming for implementing HL7
  I've used C, C++, Java, Javascript, HTML, XSLT, PERL, SQL and numerous other programming languages for working with HL7 standards.  You can also use C#/.Net, and just about any other language you like.  What's your preference?

C-CDA

• Any recommendations for someone rendering C-CDA entry elements to add Infobutton links that do not have a clinical background? i.e. any resources for understanding the content in the entry elements.
  Great minds think alike.  I've already implemented this in one of my stylesheets. 

• MU requires to send/receive C-CDA and 'incorporate'. What does incorporate mean? Incorporate means to include the information in the EHR.  It's deliberately vague, because there are a lot of different ways that could be done.  Usually, it means adding the discrete data in the C-CDA to the tables in the EHR's database.
• Can more than one document be included in a single Consolidated CDA "envelope", Clarification - for one patient but more than one type of document
  Each C-CDA document is just that, 1 document.  You can package multiple documents via the various transport methods specified via meaningful use.  In general, you should only need one document to meet the requirements to generate a patient summary and/or transfer of care document.  It's mostly a matter of picking the right one.  See my second ever post.

• All the summaries mentioned in MU2 can be built on top of a CCD given we add the required sections to CCD as required by each summary. Is this understanding correct?
  Not quite, but you have the right idea.  Any of the summaries mentioned in the C-CDA (except the unstructured document), can be used to support Meaningful Use Stage 2.  You can add any section in the C-CDA specification to any document in the C-CDA specification to achieve the MU 2 requirements.
• So is a Transition of Care Document a construct of MU2 that hasn''t been addressed by HL7?
  See above.  Basically, the transition of care is a set of data requirements in MU 2 that can be met by any of the document types in C-CDA (with the exception of the unstructured document), by simply adding the necessary sections to capture the additional data.
• Of all the data elements that are required for MU stage2 which of them are Encounter based and which are entire chart based?
  When generating content for Data Portability, the expectation is that the C-CDA produced would be "chart-based."  For Patient Summaries/Transfers of Care, the document would likely be "encounter-based", but could include data from prior encounters if relevant.  See here.
• CCD document type seems to have everything needed for MU Stage 2 EXCEPT for Reason for Referral section. How do we add Reason for Referral to CCD document type? Other option for Transitions of Care is a Discharge Summary but it is missing Medications (and possibly others)
  You can add any section to the CCD document type that has been specified elsewhere in the C-CDA specification.  There is intentionally no rule that says this cannot be done, for exactly this kind of reason. 
• When you are reviewing the CMU data elements, does it mean these are data elements that customary for healthcare institutions to share with one another as patient summarys?
  Yes.

LOINC and Lab Tests

• Are clinical lab tests still included in the C-CDA list of clinical documents?|
  I covered this during the call, but I'll repeat here.  There is no CDA based document used for reporting of laboratory test results from a lab to a provider specified in Meaningful Use.  IHE developed the XD-LAB profile that could support this use, but it isn't called out in meaningful use.
• It's not feasible for small providers to map lab to LOINC codes
  Arguably, it's easier for everybody to use a single national standard, than it it for everyone to use different vocabularies.  The latter is far more expensive.  Yes, there is a burden, but it impacts everyone.  Talk to your lab vendor.  It may well be that they can generate LOINC codes (since they must already use those codes for electronic laboratory reporting to public health).
• For the LAB reporting do all the Labs have to be reported or only specific ones?  The provider should be able to choose the pertinent and relevant lab results (and any other data exchanged).  See here.
• Is the use of LOINC codes a requirement for the laboratory sending the results, or the EHR, or both?
  Meaningful Use covers eligible providers and hospitals (including to some degree, hospital lab functions, such as transmission of lab results to ambulatory providers).  But it does not cover independent laboratories.  So, the use of LOINC codes is a requirement of the EHR (including the Hospital EHR which has a requirement to be able to send using LOINC codes).  Many labs have the ability to use LOINC, but need to be asked to turn it on, according to several of my standards colleagues in the laboratory space.
• What about lab results we receive from labs that do not have LOINC codes?
  I expect you will need to map thos.
• For Lab reporting if the Lab codes are changed from Local to LOINC codes on the inbound interface as mentioned by Keith, is the message sent by the hospital/provider still MU complaint
  If inbound to the hospital, and sent by an independent lab, it isn't relevant to meaningful use.  The outbound message from the hospital uses LOINC codes (and the HL7 2.5.1 LRI guide), then it can be MU 2 compliant.  Outbound communications from an EP or Hospital, in general, must use LOINC.  Exceptions can be used when there wasn't a LOINC code for a test, but the excuse that you don't have a LOINC code is one that I'd question.
• Having worked with HL7v3 Lab Results and now CCD there seem to be significant differences in the approach to refinement and conformance. In HL7v3 there was much more focused on refinement of the RIM whereas CCD seems to be focusing on refinement and restriction through templates / schematron. can you please explain the reason for the difference in approach?
  Yep.  CDA has a fixed schema.  V3 does not.  So, we use templates to constrain CDA, rather than modeling and schema generation.  Templates are simply another way to apply restriction.

Modular Certification

• I have heard some interface engine vendors are being certified for MU2. What is this certification? Is it required that an engine be certified or just meet certan criteria? Thanks.
  Products that providers use to obtain MU incentive payments must be certified to meet the functionality and standards.  So, if an interface engine is being used to send an HL7 V2 lab message to public health, it can be certified, and that has benefit to providers using it to meet MU requirements.  If some other certified component is being used to generate the message, and it goes through the interface engine, providers don't need the engine to be certified.

QRDA

• Where is CMS Certification reported in qrda file? Is it is the custodian section?
  According to the ballot, it appears in documentationOf/serviceEvent/performer/assignedEntity/representatedOrganization.
  This representedOrganization id/@root coupled with the id/@extension represents the organization's Facility CMS Certification Number (CCN).  Find CONF:16595 in the specification, and that should be what you are looking for.

Vocabulary

• Are the vocabulary mandates strictly enforced - i.e. are nullFlavor/translations still allowed?
  You have to make a distinction between functional testing (e.g., certification), and real world use.  In the real world, there are cases when a code isn't available, and C-CDA allows for that.  Having said that, don't use that as an excuse not to send the required vocabulary codes.  That could get you into trouble.
• What is the vocabulary for allergies? not only RxNorm, right? (RxNorm, NDF-RT, ingredients vocab (name escapes me))
  UNII is the name of  the vocabulary for ingredients.  As far as Meaningful Use goes, only RxNORM has been specified and only for Drug Allergies.  The C-CDA specifies those other vocabularies for Drug Classes, and ingredients and environmental allergies, and those are the vocabularies that should be used for reporting other kinds of allergies.
• We are updating our systems to accept new vocabularies. However, old information has old vocabularies (e.g., existing prescription have NDC instead of RxNorm). Can we send old data using old vocabularies?
  As far as Meaningful Use goes, you should be using the new vocabularies (as part of the new product capabilities) in order for providers to qualify for the incentives.
• How does RxNorm compare with product information that conforms to the IDMP (identification of medicinal products) standards?
  

Miscellaneous

• S&I LCC is working on a comprehensive care plan. It is hoped to be included in stage 3.
  Thanks, yes, see the Longitudinal Coordination of Care Workgroup in the S&I Framework site.
• XDM and XDR are listed as optional. If we support these methods, but we choose not to demontrate them during certification, can our clients meet the attestation requirements if they must use XDR or XDM rather than Direct?
  XDM is used WITH Direct, rather than "instead of".  XDR gateways THROUGH Direct, and is an alternative way to connect to a HISP.  If you work with someone providing an XDR to Direct gateway, and their product is certified, then I'd say, likely yes, but you haven't eliminated Direct.  The key to exchange with Direct is that you have to be able to get the message on the wire at some point via Secure e-mail (S/MIME and SMTP). CMS also changed one thing with respect to transitions of care.  Unlike anywhere else, where they require the certified EHR capabilities to be used, they do not so require them for exchange of Transfer of Care Summaries.
• When do you see HL7 version 3.0 implemented?
  V3 is implemented, as CCD and CDA are HL7 V3 standards.  That's probably not what you meant.  Some HL7 V3 standards (e.g., the Clinical Genomics Pedigree, and the HL7 InfoButton standard) are listed as Stage 2 requirements.  Other V3 standards have been implemented in the NwHIN Exchange (e.g., XCPD uses HL7 V3 Patient Administration Messages).

2012 Answers Archive

Periodically, I archive the answers from Ask me a Question.  Below are the answers from 2012:

---