Thursday, February 28, 2013

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:
  match="cda:legalAuthenticator[if there does not exist an author with the same id]">
  <!-- handle display of the legal authenticator -->

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:id/@root = ../cda:author/cda:assignedAuthor/cda:id/@root) and
      (string(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.

    <id root="1" extension="1"/>
    <id root="0" extension="0"/>
    <id root="1" exension="0"/>

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" 

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

        key('authorIDs',concat(@root,':',string(@extension)) )

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.

Tuesday, February 26, 2013

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.

Monday, February 25, 2013

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

Thursday, February 21, 2013

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

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.


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."


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.

Tuesday, February 19, 2013

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.


Friday, February 15, 2013

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.

Wednesday, February 13, 2013

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 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.


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.


  • 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.

Tuesday, February 12, 2013

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.

Monday, February 11, 2013

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.

Friday, February 8, 2013

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.


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".


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.


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

Thursday, February 7, 2013

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 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/ 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:
  • 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?


  • 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?

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.


  • 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.


  • 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?


  • 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:

  1. Anonymous: On Q1, I see there is a placeholder page here but no details. I suspect that if you were participating, you might be able to get more details. With regard to readyness for prime-time, I'm not qualified to comment, since I don't used it. I believe that several state HIE's and agencies are using it, but it depends on what you mean by "real". These are all good questions.
  2. Hi Keith, I'm looking for some solid examples of Pathology and Radiology Text reports that have been published in the clinical statements of a CDA HITSP C32 CCD. I cannot seem to find any updates to the HL7 CDAR1A1S0004R021 Clinical Reports Document that would help our engineers. The HITSP C83, while helpful, does not address how one should deal with a transcription as a result.
  3. Keith: I would be interested in your comments on the HHS/VA Blue Button initiative and their choice of a very simple ASCII text document format -- essentially a succession of 'tag: value' pairs on successive lines. They explain their motivation quite clearly, but it occurs to me that the effort is promising (for the intended use cases) precisely because of the standardization that HL7 has been driving behind the scenes. That is, the tag sets and value formats (and vocabularies) will have a fairly high level of consistency across organizations right out of the box because of their prior work on adopting a variety of standards internally, and especially HL7 standards.
  4. Lou, see my second ever post. Transcription is unstructured data. C32 and C83 are structured data.

    1. In this connection, I might mention the work being done by one of the major players in automated medical transcription, Nuance Communications, to bridge the gaps at issue here — verbal dictation to transcription output (unstructured text) to structured clinical data. Their emphasis is now on the second gap. They are partnering with IBM on the Watson project, specifically for applications to healthcare, largely because they bring this kind of expertise and interest to the table.

      From Nuance's website, see Clinical Language Understanding (CLU™) and the resource links in the navigation sidebar. Among those, see the linked article by Nuance's director of medical informatics, The problem with problem lists (November 2010).

      (NOTE: I have no connection with Nuance.)
    2. I'm quite familiar with the original product line from that division, as I used to work for Dictaphone many years ago. Natural Language processing and CDA are pretty good fits, as I've mentioned previously. VA has also done quite a bit of work using NLP and CDA, and M*Modal also has a product that supports it.
  5. Keith, can a custom, though registered with HL7, OID be used in the templateId element to further define a result entry in the result component of the CCD? My understanding is that the "new" templateId is still declaring conformance to the component itself.

    1. Douglas,

      You can certainly add a template ID to assert application of additional business rules, but you will also need to use any of the required templateIds to ensure conformance. IHE and HITSP did just this with the CCD.
  6. Keith-

    I'm a student in the Health IT certificate program. I have an assignment to interview someone who has had a bad experience with interoperability and then analyze how standards could have improved that experience.

    May I please have your permission to use your post "HITsm T1: To what extent should patient involvement influence the advancement of HIE?" as the interview portion? I would quote directly and attribute.

  7. Hi Keith,

    I've got a question about how I represent a non-numeric value for a lab result in the C32. All of the examples and documentation I have only shows how to display numeric values in the observation template:

    But let's say I have a result for Appearance of urine output that has a value of YELLOW. How do I represent that? Which xsi type should I be using in this case? My apologies if this has been answered before, I just can't find an example of it anywhere.


    1. Mike, in this case, its either a code, in which case xsi:type would be CD, and you'd use this form (and an appropriate code system, such as SNOMED):
      <value xsi:type='CD' code='263935005' codeSystem='2.16.840.1.113883.6.96' codeSystemName'SNOMED CT' displayName='Yellow'/>

      Or, it is a string (no code), in which case, you would use this form:
      <value xsi:type='ST'>YELLOW</value>
    2. Whoops, codeSystemName is missing an = after it. I think you get the idea.
    3. Hi Keith,

      I have a followup question for you. I have some lab results in our system that came back with numeric data but the uom was never sent with it. The validation requirements for a PQ value require the unit attribute to be present, and it can't just be left blank. In this particular case is there an unknown UCUM unit that I can use (I couldn't find one in my search) like UNK or should I be sending that value as ST instead of PQ?

      Thanks again,
    4. Mike,

      If you don't have the units, and you know it is a numeric result, the first thing to do is insist that they send you the units, which you could then translate using this table.

      If you cannot get them to fix their broken interface, then I would report the value using the ST data type like this:

      <value xsi:type='ST'>5</value>

      There is no "unknown" unit in UCUM.

  8. Hello - I was referred to you by W. Ted Klein. Our hospital is in the process of trying to implement Meditech’s CCD (Continuity Care Document) module to meet our meaningful stage 1 requirements. Meditech needs an OID number from us, but unfortunately we have not had a lot of experience with this. I have read that there are sometimes several identifier numbers that hospitals already have, such as a provider number, all of which we have. Do we have to have this separate HL7 OID number in order to meet the ARRA requirement? I am not sure if you will have the answer to this, but you may be able to direct me to someone else. I have read over the OID website, but I am still not sure exactly how to determine if we already have an HL7 OID number, and if not how to get one.
    Thank you for your help.

    1. I had already routed Ted's e-mail to me to the right person within your Vendor organization. I believe you should be getting a response from them shortly. I'll be putting together a longer post to address the general details for ARRA/HITECH and the need for OIDs in the next day or two.
  9. I'm working on a third-party patient portal that is meant to interoperate with multiple PMS/EHR systems. This portal will support patient self registration forms including, but not limited to, patient demographics, next of kin, guarantor, insurance, medical history, social history, current medications, and chief complaints. In fact, it must be flexible enough to handle questions required for specific specialties and so on. The current strategy is to generate a CDA file for import by the other system.

    Is there a document type or template available for delivering all of this information in a singe file? Could you direct me to resources and examples that are similar to this? Is there a problem with presenting patient-provided data as fact?

    Any help would be greatly appreciated.


    1. Healthy diets will contain foods from all food groups, and most of the foods you eat will come from fresh fruits and vegetables.Healthy diet plans encourage nutriment and energetic lifestyle choices.Hypnotherapy Chelmsford
  10. Everything you just mentioned except "chief complaints" is supported in the HL7 CCD. If by "chief complaints" you mean the problem list as I suspect, that is supported as well. If you are looking for a specification for use in the US, see the HITSP C32 (see the Payers section for Insurance details). Internationally, try the IHE XPHR profile (which C32 is based on).

    1. Thank you for your quick response.

      By "chief complaints," I meant the reason the patient is giving for his/her visit that day. I would also need to deliver responses to any specific questions a physician might want to have the patient answer.


  11. Hi Keith,

    What is your recommendation for how to include radiology and microbiology results into the C32? All of the examples I have seen show diagnostic lab results with quantitative data. But our microbiology and radiology results come back as long narratives that are not directly tied (like our regular labs via loinc) to our orders. Just wondering what would be a good way of me going about adding those results to the results section, since a single result may be connected to multiple test orders, and that the data is just a long narrative rather than quantitative results.

    Thanks again,

    1. First of all, C32 is a summary, not a detailed report. So in the results section, you could include a result that summarizes the details. For reference, see my second post which was the reason I started this blog in the first place. If you want to communicate the details, send the complete report in the appropriate document type, which isn't, in either of the cases that you mentioned, a C32. I expect to see more document types supported in Stage 2, and at least one that supports radiology.
  12. Hello Keith

    I'm working on clinical valuesets for a decision support system project, using SNOMED and HL7 CDA.

    When I have to choose a code for a possible Observation.value, does this code need to include some information about the observation identifier ("observation.code") itself ?

    "cervicovaginal cytology result" = "112662005 ^ Low-grade squamous intraepithelial lesion (morphologic abnormality) ^ SNOMED CT"
    "cervicovaginal cytology result" = " 416030007 ^ Cervicovaginal cytology: Low grade squamous intraepithelial lesion (finding) ^ SNOMED CT

    As our system will probably structure our electronic medical record database, maybe it's important to do with the more complete observation.value code ?
    But for others values without such complete pre-coordinated code, it would signify doing post-coordinated code such as "28899001 : 418775008 = 416107004 ^ | squamous cell carcinoma | : | | finding method | = | cervical cytology test | ^ SNOMED CT " debatable and difficult to implement....
    ...or just do the more complete way when an existing pre-coordinated code permit it ?

    Thanks a lot for your response
    (sorry for my bad english)

    Meilleures salutations

  13. Few EHR applications today are capable of supporting complex SNOMED CT Post-coordination that you just described. The best that you can work with across the most number of systems is to be able to apply a code to the question and the answer. If code is the question, value is the answer. When working with CDA, you might get a little more complicated, because things like observation have a methodCode (which is the method by which the observation was made = Finding method).
  14. Hi Keith,

    something that I find lacking in the CCD arena (HITSP C32 or just plain HL7 CCD) is examples of real world uses that are actually in play and have had some sensible analysis of assumptions - e.g. duplicate detection for allergies or results from multiple CCD sources, binding of clinical events to the presentation of a CCD - e.g. a discharge summary, a referral, a longitudinal patient healthcare record.

    Do you know of public discussions anywhere involving people actually using CCD in anger? or alternatively and lessons you have overheard that would be useful to share?


    1. I don't know of "public discussions", but CCD is certainly being used "in anger" as you put it in several Beacon programs, e.g., for care management. Details aren't available, but overviews of what is being done are being shared through the Beacon program.
  15. Hi Keith,

    thanks for your opinion on real world uses. I have another question about update modes in CCD documents. It seems to be difficult to figure out what update mode to use in CCD for specific acts without a clear understanding of the business process that produced the CCD.

    For example, if I get an on-demand CCD from Source A for Patient X - say doc1 - that has a set of allergies for a patient, and then later I ask for another on-demand CCD from Source A for Patient X, but this time there are two allergies missing, how should I interpret those records that are now missing? Looking at act attributes I'd expect the two missing ones to still be present but with a status code of "added in error". And because this is a snapshot, not a cumulative update record, then those "added in error" records would need to exist for all time now from that source. Alternatively a "amendment" could be published for that document, but since this is a generated document, and perhaps pulled by a consumer, there is nothing to indicate that there is an amendment - unless one inspected an XDS registry entry - perhaps. Amendments don't seem to make sense for on-demand documents, since their I thought their document id was supposed to remain constant.

    Do I really trust a source system to publish records with a record status of "added in error"? I don't know - it does not seem to be something that is required by CCD.

    Alternatively, for a particular source, I could set allergies that are now missing to a record status of unknown - since there is nothing really to qualify them now as active or inactive or added in error etc.

    The same question applies to other sections of CCD.

    Is there a recommendation somewhere on how to interpret updates - especially on-demand documents?


    1. You are right that "Added in Error" is not something that CCD requires a system to report on. But it doesn't prevent that from being done either. This was the point behind the IHE Reconciliation profile.
  16. What is the difference between CCD 1.0 and 1.1? You have mentioned these in table comparing the Stage 1 and 2 Meaningful Use standards.
  17. Hi Keith,
    I currently try to make use of RFID-Tags to automatically identify persons for telemonitoring purposes. A simple mapping mechanism (PID to RFID) won't do. I would rather find a way to save the RFID within the patient's EHR and then search for the patient by RFID using PDQ. Is there a way to do so?

  18. I see last week you posted links to the new IHE specifications related to importing/reconciling images. I am trying to locate what I believe exists similar to that for the common data sets in the CCD/CDA documents (i.e home meds, allergies, etc.) Have you posted anything related to the guidance for importing/incporprating/reconciling that data from an IHE specification standpoint?

    1. What are your toughts on this in correlation to the Stage 2 idea of "incorporating" data from a summary of care record? This obviously wasnt called out in the certification criteria at all - and typically nothing gets added per se between the interim anf final... so you anticipate they will leave it pretty generic in teh way of how one would implement import essentially but just define data elements that need to be imported? I know - it's somewhat of a guess at this point...
  19. Keith,
    Thanks for the CDA book, I've found it very helpful in my journey in creating CCD and CDA documents. I have a question for you about medication effectiveTime. I have a couple scenarios I haven't been able to figure out how to create.

    The first is timings such as 5 times a day or 3 times a week. For 5 times a day it doesn't work out into an even number of hours so i'm not exactly sure how to handle that. I could break it down into minutes but that feels wrong to me.

    The second issue I have is a timing that is expressed as 'while awake'. An 'EIVL_TS' effectiveTime with an offset seems like the most likely scenario but the only applicable 'EIVL_TS' code that seems to work would be 'HS' with an offset. But as you pointed out in your book there is no implied direction for the 'the hour of sleep' offset.

    Any help or insight into these problems would be greatly appreciated.

    1. I work with Dave: I asked this same question on Stack Exchange's Healthcare IT site. As of now it hasn't been answered yet. Here's the link:
    2. On your first question: 5 times per day could be represented as every 4.8 hours, and three times per week could be represented as every 56 hours. You certainly can use decimal representations in , as it is of the PQ data type.

      The more detailed challenge about simplicity of representation has been addressed in datatypes release 2.0, which will be supported in the CDA Release 3.

      With respect to the "While Awake" issue, the EIVL_TS data type uses the CS data type, which means that you cannot express anything not in the code set. I'd implement that as an annotation in the SIG.
    3. Thanks for the quick reply. I thought about doing the 4.8 hours and the 56 hours solution but for some reason it felt off to specify 3 times a week in hours. But if it works then i'll go with it.

      I'm confused on what you mean by expressing "While Awake" as an annotation in the SIG, would you mind being a little more specific?

      I really appreciate all your help, the CDA can be a little overwhelming at times.
  20. Keith,

    My organization follows the standard CCD pattern. For one of our current implementations, we were discussing a small change in the results section of the CCD (described as follows).

    Our product provides an acknowledge option for the Clinicians to review the lab results. What we want to do is to include the lab results information in CCD only upon acknowledgement and not immediately upon their availability. Can we make this change? Or do you see any issues with this? Really appreciate your inputs. Thanks.

    1. CCD says to include relevant and pertinent data in it. It doesn't say what IS relevant and pertinent, as that is clinical judgement. So you certainly could do this.
  21. I want a sample CCD document. Can you pls send it?


    1. You can find sample CCD documents in the download packages for the NIST CDA Validator (see )
  22. Are you aware of another validation tools available today for the CCDA
  23. Hello Keith,

    We have a question regarding the way you have presented requirements for meaningful use in one of your spreadsheets labelled 'MUSCR-2.xls'. There are two requirements we are trying to understand how to implement and have following questions:

    1. the referring or transitioning provider's name and contact information

    For this rule, your suggested implementation is to use an ecompassingEncounter/responsible party. However in looking at the encompassingEncounter we find that this section uses encounterParticipant, typeCode="ATND" must always be set. typeCode="ATND" is for attending physician. How would we use this typeCode and provide information for referring physician?
    Is the encounterParticipant not required and if so how would we differentiate who the referring physician vs who an attending physician is?

    1. x_EncounterParticipant also includes REF for Referrer.
    2. As I answered elsewhere, x_EncounterParticipant also allows for REF, to identify the referring physician.
  24. Hi Keith,

    I am currently working in a EHR company. Looking forward to work on core HL7 Standards and HIE's and Interoperability. Currently i am working on Point to point Lab and Custom(Pa)Interface between various Health care Organizations. I am looking forward to work with GE Healthcare and have applied in various sectors but i am not finding proper path on how i can apply in exact Domain. I am located in India. I did attended your Webinar on Meaningful Use Stage 2.

    Let me know on what would be the best way to approach from over here.

    Your help is greatly appreciated.

    Thank You.

    1. Send me an e-mail using the contact me link, so that I can hook you up with the right folks. Please provide me with details on what you are trying to do.
  25. Hi, Keith.

    I’ve been struggling a bit with CDA particularly this notion of packaging all the contents of a CDA document so that it can be rendered by any recipient, images especially (see CDA R2 section 1.2.3). The problem comes down to two parts: how to represent the image in the CDA document so that the image is IN the document rather than be a reference to a file and how transform that it into HTML that can be rendered by common browser rendering engines.

    (1) Content—I started by changing something like



    This seems like the way to do it based on my reading of your book and the XML ITS, but I can’t find any examples. I did note that Figure 6.1 from your book did not use a “value” element, but instead embedded the base 64 encoding directly in the “observationMedia” element—that confused me.

    (2) Rendering—This is actually a two part problem. The first, has to do with what the HTML would look like and second the use of the generic style sheet provided with CCDA. In the first case I thought, that I could simply use data URI, but it has a number of problems: not supported by all browsers and IE8 (a necessity for me) severely limits the encoding length. I’ve tried fooling around with getting MIME to work, but just can’t seem to make it happen.

    In the second case, the generic (presumably non-normative style sheets) won’t convert the above encoding. It’s very telling that the one provided with the CCDA DSTU doesn’t even transform PNG content, much less embedded base 64 encoded images.

    I’m planning on embedding my own custom style sheet for the type of content I’m producing, but I’m aware that all content should be renderable with a generic style sheet (see again, CDA R2 section 1.2.3). The problem is that there’s no normative way for me to ensure this.

    I’m really stuck here and definitely would appreciate some guidance and some examples.

  26. Ooops. Look like the XML didn't come through. Substituting...

    [observationMedia classCode="OBS" moodCode="EVN" ID="Hgb-A1C"]
    [id root="C06E4A43-13AB-4A5D-8A72-ABF887D915CD"/]
    [value xsi:type="ED"
    representation="B64"][reference value="images/Glucose-Metformin.jpg"/][/value]


    [observationMedia classCode="OBS" moodCode="EVN" ID="Hgb-A1C"]
    [id root="C06E4A43-13AB-4A5D-8A72-ABF887D915CD"/]
    [value xsi:type="ED"

    1. Packaging a CDA and Rendering it from within a browser is something I tried a while back. You could use the data: URL format with B64 encoded data, but it only works well in Opera and Safari. IE has handicapped it for some formats. See and for some pointers.
  27. Would really appreciate if you can clarify my questions.It is very urgent

    I have been assigned a project whose requirement is to convert files in other formats to XML files that conform with the specifications in ( HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component).
    I would like to know how to proceed.

    1)How do I get the XML schema files for HITSP? Are they readily available or do I need to generate them.
    2) What is the process to follow, i.e how to convert the file to the XML standard, how do I validate?
    Are there any tools available etc.I need to do coding in C#.


    1. You need the XML Schema for CDA if you want to validate against Schema, but that doesn't cover all the constraints in the HITSP C32 (they aren't "schemifiable", see

      To check those constraints, you want to use the NIST Validator

      On how to convert the files to XML, it depends on the format they've started in. If it's an XML format, I recommend XSLT. If it's HL7 Version 2, check out chapter 17 of The CDA™ Booke.

      In terms of tooling, there are plenty of open source tools in Java, but I'm not aware of any that support C#. MDHT has code generation capabilities that could generate C# that would support the C32, but the project has nobody with time and experience in C# to create the generator. You could start there.
    2. Thankyou very much for the quick response.
      Will look into what you have suggested
  28. Hi Keith,

    The HL7 OID registry doesn't seem to contain all the templates OIDs used in the different Implmentation guides. Are there specific rules that to govern the decision to register vs not register OIDs in HL7 OID registry ? Should we register only Document Templates and not the other template types (Header, Section, Entry) ? Should the different countries register their Template OIDs under their own Country OIDs (for example in Canada, register template OID within HL7 Canada ?


    1. Ideally, all templates would be registered in the OID Registry. Unfortunately, the infrastructure doesn't make it easy to register a batch of OIDs. With regard to how you get OIDs to register a template, what you suggest (to use a country specific OID) makes sense for national programs. That's what HITSP did years ago when it created a number of templates for use in the US.
  29. Keith,

    I have had an observation about the Administered Medications section in the CCD that my organization provides to the patient. Irrespective of what the order status is (in progress or discontinued or cancelled or completed), we always display the status as completed. Is this correct?

    I have referred to this link and even that says all the orders should have a status "Completed".

    The status of all elements must be "completed". The act has either occurred, or the request or order has been placed.

    I do not understand why we have to display such an order status for an in-progress or discontinued item. Am I missing something here? Please help.

    1. statusCode in an act describes the status of the act (with respect to the mood it is recorded in). In a document, this is almost always completed, because the act (ordering, intent or event) has been completed. That status code is part of the RIM, and deals with the act state machine. Moving beyond the Act class state machine, you can record the status of the med (e.g., discontinued, active) using a different structure. That's more often what folks want for medication status.
    2. Thanks for the reply. I have a follow-up question though.

      There are 2 sections in the CCD. The status in "Medications" section displays as Active or Inactive While the status in "Administered Medications" section is always "Completed". So, are we saying that this is correct? Please help.
  30. Keith,

    Should the Administered Medications section in CCD always show the order status as completed? (I have observed that even the in-progress/ discontinued items are displayed as completed). And the link ( also says that 'all elements must be "completed". The act has either occurred, or the request or order has been placed.' Am I missing something here? Please help. Thanks.

    1. See my response to the comment above.
  31. NZ is moving to CDA for discharge summaries and looking at adopting XDW. I an attempting to get my head around using XDW. The use case I have is that a discharging clinician creates a discharge summary and discharges back to the GP he creates a task for the GP to accept the transfer. The GP refuses because it is not their patient do the task is not completed. All that is fine but we have a requirement to attach a reason for the refusal. If the XDW contains no information what do we do with the reason?

    1. Peter,

      It would be good to make that comment on the IHE PCC eReferral profile that is presently out for public comment.
  32. C32 v2.5/C83 v2.0 Medication section (Table 2-12, HITSP/C83 version 2.0) has the concept of a “Ordering Provider” (8.31). I’m having a difficult time matching this up to a similar concept in the “"CDA Consolidation (December, 2011)". There is a performer (CONF 7522) for the medication section in the Consolidation CDA (CCDA), but there is not much for a definition in the specification. Are these equivalent or is there another concept in the CCDA that would match up to the “Ordering Provider” (8.31) for C83?

    1. See conformance statement 7438 under Medication Supply Order.
    2. Thanks. What is the performer (CONF 7522) represent?
  33. Hi Keith,

    Your site is a great help. What other resources are there, like discussion groups, on the web that focus on implementation questions for the "CDA Consolidation (December, 2011)" and/or MU2?

    1. For discussions on consolidation, I'd sign up for the HL7 Structured Documents Workgroup list serve (see top right), or the S&I Framework Transitions of Care Implementation Guidance Workgroup.

      The SDWG list serve doesn't focus on CDA Consolidation, but there are some discussions on it there (including on current ballot reconciliation), and you can certainly ask implementation questions there. The S&I Framework project is developing guidance, but that is still a work in progress.
  34. In the “CDA Consolidation (December, 2011)”, Table 167: Instructions Constaints Overview the code (CONF 7394) element is now a SNOMED code. What would be the SNOMED equivalent to the previous C83v2.0 code of code= PINSTRUCT, codeSystem =, codeSystemName = IHEActCode?

    1. The closest I can find would be something like "Instructions from the Pharmacy" (423201001). Others could be appropriate depending on the type of patient instructions. Typically, this field was meant for instructions like "take with food", which would often be instruction coming from the pharmacy (and perhaps also the provider).
  35. Hi Keith,
    In case of Physicians with more than 50% of patient population at Ambulatory Surgery Centers, is it mandatory for the Ambulatory Surgery Centers to have a Certified EHR technology to capture & send required data to Physician's office EMR to enable physician to apply for MU. If yes, what would be the necessary modular certification criteria's that apply for the ASC to be able to capture send the information to Physician Office EMR.

    Warm Regards,

    1. For Stage 1, the applicable criteria are found in: §170.304(i). Related criteria are §170.304(f) and §170.304(h).

      For Stage 2, the proposed criteria are found in: §170.314(b). To see the citations for the standards, check out this page.
    2. Hi Keith,
      Thank you for your reply. One follow up question though is, if the ASC wants to share images that were taken during a particular procedure with the physician, are there any applicable standards to share the same with the Physicians EMR ? Appreciate your help in this regard.

      Warm Regards,
    3. On sharing images with the EMR, there are a couple of ways that you can do this. From a specialist's perspective, where the EMR is designed for specialist use, you'd want to look at IHE's Image Enabled Office profile.

      That capability unlikely to be available on non-specialist's EHR system. What you can do in that case is send an ORU message with a link to the image from a web-enabled viewing application (e.g., a WADO URL).
  36. Hi Keith,

    For Encounters in a History of Encounters section in HITSP C32 2.5 documents, what would be your recommendation for conveying:
    1. the specialty in which an encounter was performed - e.g. cardiology, general medicine
    2. the discharge diagnosis

    I don't see these concepts referenced in any of the HITSP C83, IHE PPC profile, or HL7 CCD, so I gather we should drop back to a CDA R2 recommendation?


    1. for discharge diagnosis I was thinking of something like:

      under problems section

      entry/act[problem]/entryRelationship/encounter with the identifier of the encounter for which this problem was established
      entry/act[problem]/problemTypeCode = diagnosis

      I also considered an entryRelationship[@typeCode='SUBJ'] directly on the encounter with a problem observation, but I am not sure the statement made by this is obvious.
  37. ,Keith, I am now working with a really innovative multispecialty practice and we were looking through IHE and ran across the Care Plan spec. Are you aware of anyone using the spec? IHE PPOC?

    Thanks Andrew W.

    1. I'm not aware of any particular deployments, but you can see who has implemented and tested at connectathon here
  38. I see you have a host of HQMF posts... but I didn't see a definition and introduction to what "H" "Q" "M" "F" means...
  39. Hi Keith,

    I have a question on the MDM^T02 HL7 messages, we are using MDMs with a CCD payload to populate our XDSb repository and we do patient discovery of the MDMs(no ADT feeds). Our current implementation handles MDM^t02/MDM^t09 , is there a way to do Merges(like A40, A36) using MDM^t02/T09? Any input is greatly appreciated. Thanks

    1. Yes, there is a way to do a merge. Just process the ADT^A40 or ADT^A36 messages. Oh wait, did you want to use the MDM messages to do patient ID management? Sorry, no. That's what ADT messages are for ;-)
  40. Hi Keith,
    Our company provides DICOM archive and study viewing services for several hundred G.P.-s and doctors from the many hospitals. We are planning to go XDS with all the bells and whistles but so far the problem is that all hospitals are completely separate and have no XDS. But first (any day now)
    I need to publish a tender for DICOM web viewer software but I'm not really sure what to ask for.
    One thing is the user authentication - I would like to all the user logins to be handled by hospitals so that we all users from one hospital use one login to vew the DICOM studes and reports (then we have to handle only the GP-s that work privately).
    I'm planning to requre XDS.b Document Consumer conformance but can XDR help with use auth or should I go for XUA? And where does LDAP user auth/directory stand in XUA?
  41. Hi Keith -
    Being a standards-kinda-guy, I was wondering if you would happen to know if there exists any good document templates for writing all them custom HL7 interface specifications that we as HL7 vendors tend to do?
  42. Hi Keith-

    I'm curious if you know of a CCDA XSLT that is available online? Could you point me to it if you know where I can find an good XSLT example?

    Thanks very much!
  43. Hi Keith,

    Quick background of what I am trying to do... I'm trying to parse the HL7 medication RXO or RXE to extract the medication code and name and store that into our exchange repository, also parsing CCD ang store it into our exchange repository.

    When it comes to CCD generation, I am not sure what is the best way to determine if that medication code and name parse from HL7 can be specified in either CCD Medication Coded Product Name or Coded Branded Name. Also when parsing out the Coded Product Name and Coded Branded name from CCD, which code would fit to send out in an HL7 RXO\RXE Give code. Would a terminology service be needed to address this different use cases?

    I have your CDA book and I really find it helpful the mapping it provided for Labs between HL7 messages and CDA.

    Thank you!
  44. In the CDA Consolidated Rel 1 use for ARRA Stage 2, the Allergy reaction requires a coded value (CONF 7335). Unfortunately, we have quite a bit of data that is not coded and we believe is important to include. By using the Lantana Validation Tool, we have found the following two options will work:

    1) <value xsi:type="CD" code="UNK" codeSystem="2.16.840.1.113883.6.96" displayName="Hives"/>

    2) <value xsi:type="ST">hives on arm</value>

    Option 1 seems bad to me because this does not contain a valid snomed in the code attribute. Option 2 seem more in line with the CDA policies. Are either of these options acceptable for ARRA Stage 2, or is there other better options for this?

    Thank you

    1. Neither of the forms you show are acceptable. The Lantana Validator doesn't check for valid SNOMED codes

      The CD data type allows this form:

      <code nullFlavor='UNK'><orginalText>hives on arm</code>

      Or better yet:
      <text>...<content id='reaction1'>hives on arm</content>...
      <code nullFlavor='UNK'><orginalText><reference value="#reaction1/></orginalText></code>

      In terms of what is acceptable for Stage 2, I suspect that either of the formulations I show will work, but we don't have either the rule or the test suites from NIST as of yet.
  45. Keith,

    I'm hoping you might have some input for my organization. (if this has posted twice forgive me)

    We need to include an annotated comment for an observation result in our C32 CCD. We are using the Comment Module to include this comment that corresponds to a NTE segment from an HL7 v2.x result. We would like to include this at the observation or OBX level within the structured xml of the CCD. Including this comment at the section or component level seems to work but when moved to attempt to have it associate with the observation result itself is proving a bit difficult for development.

    Thank you,

  46. Keith,

    Love your website - what a great resource!

    I'm trying to appreciate what is "standard" and what is variable among CCDs. In my experience, the section template headers ( i.e.
    2.16.840.1.113883. for medications) are well implemented but other standards for entries i.e. 2.16.840.1.113883. for (Vital Signs ) are not. It seems that the world has decided to accept one level of granularity at the section level and then abandoned this concept at the entry / leaf level. I have accepted this as the current state of the world.

    My question is about intra-product variability. For example, if company X delivers product Y that is installed at facility A and facility B, will the format for a CCD from facility A and B follow the same intra-section format? Will the table structure that contains the actual data look the same between these installations or will it differ?

    If this is more appropriate for the website, let me know and I'll post it so that others will have a chance to follow.


    - Rich

    1. Rich,

      Usually, the CCD's produced by the same EHR system will have the same capabilities. However, those capabilities are often configurable, which means that you might not always get the same set of sections. Also, code (e.g., SNOMED vs. ICD) use can vary between different sites. It really depends on the EHR, and the amount of customization that it enables. In general though, you can expect limited variation "intra-section" variation when you've controlled for the EHR variable.
  47. Hi Keith,
    I'm working on the CDA Release2 and Have a question on the validation being done by the Lantana Validator tool. I'm referring to the

    1) PDF "CDAR2_IG_IHE_CONSOL_R1_DSTU_2011DEC.pdf"
    2) page 227 "Hospital Discharge Instructions Section" and
    3) table on page 228 "Figure 103: Hospital discharge instructions section example".

    My understanding is that unstructured part of these section that is content of the "section/text" are not being validated. But, for this section, the content inside the "section/text" is being validated and if I have any other HTML tag, the Lantana validator errors out.

    What do you think about these,
    1) Do we need a validation for the HTML content of the this section “Hospital Discharge Instructions Section”?
    2) Should Lanatana be validating this HMTL section? or not


    1. I don't know the details of what you are putting in your section/text, however, given the number of times you mention HTML, I suspect that is your problem. CDA uses it's own XML in section/text, not HTML.
    2. Thanks for your response.I mean HTML tags in XML, sorry about that. I'm able to get these done for other CDA sections though, this is only section where the content of section/text is being validated, should it be validated?
  48. Hey Keith,

    On page 73 of the HITSP C83 documentation (, there's an example of a Results section, but it doesn't seem to cover the full entry. It just starts at the result's 'observation' tag instead of the tag directly under the 'entry' tag like the other.

    Is there anywhere I can see what tags belong above it?

    1. I was able to find the information I'm looking for here:

      ..although I'm not sure if this is the latest copy of this specification or the best one to use.
    2. This page from NIST contains some downloadable samples which might help. See the first link.
  49. Hi Keith,

    We have a need to use some DT R2 in our CDA documents. will this make our documents not CDA R2 compliant even if we add the new data types in datatypes-base schema file using the extension tag ?


    1. You can add extension elements or attributes to support Data Types Release 2.0. You should look at what Data Types Release 1.1 did, and add the new attributes using an extension namespace. However, note, that most implementations will ignore these, or even fail to parse since the extensions won't be in their schema. However, the documents will be CDA R2 compliant (according to the standard) if you add an extension namespace.
  50. Hi Keith,

    Running into some trouble when trying to export a CCD from a patient chart from a meaningful use certified EHR. The EHR allows me to free text problems, allergies and medications but this means that there are no codes associated with them. When I export the CCD, it requires me to have codes like ICD 9 or RxNorm. Is it allowed to NOT have codes associated with these problems, med and just populate the "Display Name" in the CCD, or is there some generic "user generated" code I could use for all of these items?

    Would love to get advice on how to export user generated free text clinical data into the meaningful use CCD.


    1. It's allowable to NOT have codes (e.g., H5N1 didn't have a code at first, nor did SARS or Legionaire's disease when they were initially discovered as illnesses). To do that, you generate a code element referencing the free text like this:

      <code nullFlavor='NI'>
      <originalText><reference value='#free-text-problem-1'/></orginalText>
    2. Awesome .. did not know this.
  51. Hi Keith,
    My question concerns the Consolidated CCD in Meaningful Use Stage 2. The "Transition in Care" and "Data Portability" CCD requirements (per the Final Rules) include Activities of Daily Living, Cognitive Status, and Disability Status. Do you have any guidance on where to place this information in the CCD and what data elements should be included?

    1. They should go into the Functional Status section found in the CCDA 1.1 specification.
  52. Hi Keith,

    Will CCD that is C32 v2.5 MU version pass validation if using HITSP/C32 v2.5 Summary Documents Using HL7 CCD (using HITSP/C83 v2.0) to validate?

    Thanks in advance.

    1. Not necessarily. The MU Requirements are a little more stringent than the HITSP C32 V2.5. Having said that, NIST does provide an online validation tool that validates against the MU requirements.
  53. Hi Keith,

    With the need to collect race as a multiple, how does that need to be represented in the CCDA? It's currently listed with the constraint of only 1. Is this a case where the Final Rule requiring this to be multiple supersedes the CCDA constraint?

    Thank you.

    1. CCDA describes an extension element to support the recording of multiple race codes.
  54. Hello Keith,

    My dev team is working through the QRDA Category I specs for CQM esubmission as required for MU 2014 certification. I have been tasked with finding the answer to this question: "Is QRDA I a "dump" of the patient visit record?".

    Thank you

    1. No, it's not really a dump of the patient visit record. Instead, it is a dump of data relevant to a particular quality measure or quality measure set over a period of time, containing data suitable for computing the quality measure.
  55. Thank you Keith-so please let me give a more specific example so that I know that I am on the right page. If measure NQF XXX is looking for a patient on aspirin and that patient is also on lipitor and plavix and digoxin. Can we send the lipitor, plavix and dig along with the aspirin?

    1. While it won't hurt to send the additional information, it doesn't help anything either.
  56. Is it your understanding that when EHR data is printed, copied, and queried the info needs to be tracked in the audit log? I recall under MU Stage 1 (2011 Edition) that printing was included in the Proposed Rule but then specically dropped in the Final Rule. The Proposed and Final Rules for MU Stage 2 (2014 Edition) didn't mention the addition of print, copy, query but did reference the ASTM E2147-01(2009) standard.

    For the first specific capability related to actions involving electronic health information, we
    have required that the data elements specified in sections 7.2 through 7.4, 7.6, and 7.7 of ASTM E2147-01(2009) be captured.

    7.6 Type of Action (additions, deletions, changes, queries, print, copy)—Specifies inquiry, any changes made (with pointer to original data state), and a delete specification (with a pointer to deleted information).
  57. Keith - This blog is awsome; thanks for doing it.
    Question: the ONC Stage 2 final rule seems to indicate that ICD-10 is the required vocabulary for Encounter Diagnosis. That would require that an EH attesting for 2014 would need to be live on ICD-10 prior to the 2014 implementation date since they report on the FY. Is that accurate or have I missed something (I hope).

    1. Yes. Look carefully at the definition of Encounter Diagnosis:
      Both here:
      and here:
      it describes encounter diagnosis as:
      The standard specified in § 170.207(i) or, at a minimum, the version of the standard specified § 170.207(a)(3)

      The former is ICD-10-CM (see and subequently see 45 CFR 162.1002), and the latter is SNOMED CT (see )

      So your choices are use SNOMED-CT, or use ICD-10-CM. I'd go with the former, since you already have to use SNOMED-CT for problems.
  58. Hi. I have been researching CCD and CCDA specs and regarding non-med allergies, there appears to be a conflict for the coding standard between UNII and SNOMED-CT. Do you know if this has been settled? Is there significant risk with just going with SNOMED-CT? Thanks.

    1. I'm not sure what you mean by conflict? UNII is to describe allergens, SNOMED-CT types of allergies (food, drug, environment). These are different. With regard to significant risk, there are challenges using any single controlled vocabulary to cover the allergy space, as none are complete. This is why CCD and CCDA used a variety of value sets to describe allergens.
  59. Hi. I have been researching a complete CCDA sample but I had no luck so far. The ones that I have found or created based on the guide failed the validation tool. Is there anywhere that we can find full sample of CCDA for Clinical Office Visit Summary? Thanks.
  60. Hi, is there any direction on being able to include Blood Bank Products or tests on the CCDA?

    1. It isn't prohibited, so you could include them, but the area hasn't been delved into by HL7 Structured Documents. So the answer is yes, but if you are going to ask me next how this would be done, my answer is I don't know.
  61. Hi. I have been reading about 2012 PQRS Medicare EHR Incentive Pilot program and wanted to confirm my understanding. Simply put
    EPs have 2 options:
    1. EHR Data Submission Vendor-Based Reporting Option ->
    Submit existing CQMs for MU stage 1 in XML format + PQRS Measures in QRDA Category 1 format(DSVs submit on behalf of EPs through a certified EHR)
    2. Direct EHR-based through Vendor-based Data Submission Reporting Option -> Submit CQMs for MU Stage 1 QRDA category 1 format + PQRS Measures in QRDA 1 category format(EPs submit the data through a certified EHR)
    Is there anything else that I need to understand?

    1. I have to spend a bit more time with the PQRS regulations, but so far, that's my understanding. This post might also be helpful to see how these standards relate to Meaningful Use.
  62. Hi Keith,

    I am having trouble finding examples of embedding image data in lab results observations in CCD. Is it possible to use the following as a value in a result observation?

    <value xsi:type="ED" mediaType="image/jpeg" representation="B64">the data</value>

    1. If you want to include an image in a CDA document, you would use the observationMedia element as an entry (or a component of another entry). The value element in observationMedia would be represented as you have shown above.
    2. So, for example, if we were translating the equivalent of an ORU/ORC+OBR into a results organizer, any OBXs that had ED type data would be represented by an observationMedia element inside a component element of the organizer?
    3. It also seems, according to your CDA book, that ED is a perfectly valid type for the value element of an observation, which was my first analysis of the situation. Is there a reason why we would use observationMedia over this? What I prefer about being able to use an observation element is that I can represent the test the image is a result for using the observation/code
    4. To your first response, that sounds right, I'd have to look at it to be sure.

      To your second one: It is perfectly valid to use ED in Observation. ObservationMedia is purpose designed to support this use case, whereas Observation is the more general approach (and would be indistinguishable from a RIM perspective).

      The critical point is in the definition of the renderMultimedia tag that is used in the narrative with observationMedia:

      The <renderMultiMedia> element ... contains a required referencedObject attribute (of type XML IDREFS), the values of which must equal the XML ID value(s) of ObservationMedia or RegionOfInterest CDA entries within the same document.
  63. Hi Keith-
    I am reviewing the Query Format (HQMF) Implementation Guidance v0.5 and trying to match up with the finalized eCQMs that we downloaded last week. I see from the document appendix no work is planned on Greening the HQMF until 2013. Is there any more specific timeline on that? What is the best way to stay in tune with that?
    Thanks for your guidance.

    1. Thanks for your info. I have certainly bookmarked the QH website.

      What are the chances of the easier to read HQMF version becoming the standard for MU2 eMeasures?

      Thanks and great post on the abbreviation soup and clearing that all up.
    2. Zero. The standards for MU2 have already been identified, and standards for quality measure definition were not included. NQF or the subsequent maintainer of the Measure Authoring tool could choose to use HQMF Release 2.0 when it becomes available, but substantial work will be needed. I'm told that MITRE has done some testing of a transform from the old form to the new form and been somewhat successful.
  64. Hi Keith,

    I am really interested to know if you have come across the ability to extract CCD information into a database through an automated solution. If you can point to a source that would be great. Thanks.

    1. There are plenty of commercial solutions that do that, and a number of integrators and interface engines who would support your efforts. But what I think you mean is something that would make it easier for you to role your own code. For that, check into MDHT for reading CCD documents. You'll still have to do the database back-end.
  65. Hello Keith,
    I am trying to figure out how the following abbreviations are connected - NQF's QDM, HQMF, eMeasures, Query Health, QRDA, QDM based QRDAs, others.

    Rather than individual definitions, I am a bit in the dark around how each of these are interconnected.

    Appreciate your help.

    Warm Regards,
  66. Kieth:
    In the Lab Results section of the CDA document, the validator (the one available online on the NIST website), requires us to provide the procedure along with the battery->Test Results collection. Is there documentation that you can help me point to that could further describe the requirements for the procedure section? We are not sure if a procedure refers to a CPT or the specimen collection procedure.
    Second question:
    The sample documents that I've seen refers to SNOMED CT codes in the battery & procedure sections of the document.. Is it allowed to provide the lab order codes (belonging to the Labs that we interact with) in place of the SNOMED CT codes? If it is allowed, what coding system should be specified? Thanks in advance.
  67. Your examples for "How to say no" and "Smells like I dunno" are great models for building the empty entries required by CCD when no records exist for these sections. In particular, it's nice to have decent "generic" codes documented SOMEWHERE out there to use (like 413477004 - Allergen or 410942007 - Drug or Medication).

    However, now that CCDA requires RxNorm for meds/allergies (or NDF/UNII), do you know of any equivalent "generic" code in these systems? I hate to do the following just to pass validation:

    <code codeSystem="2.16.840.1.113883.6.88" codeSystemName="RxNorm" nullFlavor="UNK">
    <translation code="413477004" codeSystem="2.16.840.1.113883.6.96" displayName="Allergen or Pseudoallergen" />
  68. Hello Keith:
    Can you share how the patient identification type (whether it is an SSN, Clinic Generated Id, MRN etc.) be represented in the CDA patient header?
    Thank you
  69. Hello Keith:

    I would like to know on the various interoperability challenges/issues faced while integrating the HC products with external entities in HCIT.
  70. Hello Keith,

    Does the Meaningful Use Stage 2 final rule have a requirement that EHRs must be able to import QRDA Category 1 documents?
  71. hi, what is the terminology and value set for CG pedigree that was defined in the meaningful use stage 2?
  72. Keith,
    The NIST XDS Test Facility is no longer available. Is there a replacement or another service for XDS testing?
  73. Hello Keith,
    for MU Stage 1, CDA entries with codes(level 3) was required for Allergies, Medication, Labs, Patient Problems.. What additional sections need to have entries(level 3) for MU stage 2 when generating c-CDA? It's not clear from the final rule. Also, other than the above 4 sections, what others need to be parsed for MU Stage 2.


    1. You'll still need to be able to "parse" problems, allergies, meds and labs to incorporate them into the EHR. There's other data that you might also want to use, but no "incorporate" clause that requires you to do much more than display it.

      With regard to what you need to put into your C-CDA, it's the common data set (defined in the rule) plus a few other things. For that, I suggest you have a look at the testing procedures.
  74. Hi Keith,
    Does the top validation tool at
    Name: CDA R2
    Description: HL7 CDA R2 (with no extensions)
    test the latest consolidated CDA (CCDA) corresponding to the Dec 2001 implementation guide?
    Thank you