Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Friday, March 29, 2013

Another hole in my head

As in, I need another one of those like I need another hole in my head.  And often, when I hear about a new initiative being developed somewhere, I think: "Shoot me now."


I think Daffy has it right.  One of the reasons why there are so many different initiatives is "Pronoun Trouble".  It has to do with fine distinctions between who has "control of the project" and who winds up with "ownership of the result".

In IHE and HL7 both, members are quite accustomed to working on initiatives that are "sponsored" by others.  The end result becomes an IHE profile or HL7 standard or implementation guide. Sponsorship can mean many things.  In some cases, it just means "promoted", and doesn't really involve any contribution of goods or services towards getting the job done, except perhaps contribution of the "problem to be solved".  In other cases, especially where the sponsors have a bit of a clue, it does involve contribution of resources to the project.

ONC S&I Framework projects take a variety of different approaches (one of the challenges of a lack of consistency and governance in S&I activities).  On a few occasions, they've started inside or along-side and SDO process (e.g., Consolidated CDA and LRI for example).  On other occasions, they've made some progress, and concerned initiative members have move things along inside an SDO in support of the process (e.g., Direct, Query Health and ToC).  On other occasions, there was good intent to involve an SDO, but what we are left with is a specification that still has no home (e.g. The Direct Applicability Statement).

I like some of what ONC has contributed as the "impatient convener" in the standards development process, especially in the area of getting interested parties engaged, in running pilots and developing reference implementations, and in contribution of real-world success criteria.  But some of it is still troubling, especially with respect to variable governance, communciation, and coordination.

As S&I evolves, I'd like to see more collaboration across SDOs, and better utilization of the limited resources of the standard community (myself included).  I'm still thinking about how that could work, just as I have been for quite some time:


Hopefully, someday, we'll figure it out together.


Thursday, March 28, 2013

Getting Close = Jinxed Myself

I think we are starting to reach closure on the ABBI PULL Initiative.  I finally got my editing done on the OAuth Workflows and API documentation.  There's a bit more work to be done in the next week.  One of the outstanding challenges is in figuring out how to bind an authorization to a specific patient in both the client application and at the data holder.

It is a pretty easy problem to solve in the if we make the Authorization end-point return a bearer token that is a JWT that contains the authenticated identity of the end-user, plus some other stuff.  Another way would be to communicate between the authorization end-point and the data-holder in some way that is unspecified [I don't like that idea].

More challenging is the case where the same identity can be used to access data about multiple patients, as in the case where I get data about my children and myself.  In this particular case, I think the right answer is to use the scope parameter of the authorization grant in order to communicate to the authorization endpoint who the authorization is for.  When it grants the request, the authorization endpoint can encode the scope in the bearer token, OR communicate it to the data holder in some way that is unspecified [again, I don't like that idea].

The scope token need not be complicated.  It, in combination with the authenticated user identity must uniquely identity the patient whose data is being accessed, but when appearing alone need not do so.  This operates under the assumption that the identity being used to authorize use is provided to the data holder in some way.

The truly critical challenge will be for application developers.  They should take steps to ensure that data from different data holders for different patients isn't mistakenly combined.  In other words, the app shouldn't combine data of my youngest daughter (from her pediatrician) with that of my wife from her ob/gyn, even though they have the same first and last name.

Hmm, that step is going to require both some critical thinking, and a risk assessment.  Oh well, close is never the same as done.


Wednesday, March 27, 2013

ONC seeks input on Consumer eHealth

HealthIT.gov Banner

Provide Your Input to Inform ONC's Consumer eHealth Strategy
On Monday, March 25, 2013, ONC, in collaboration with Cornell University, launched a new web platform for obtaining public input to inform health IT strategic planning. Check out the new PlanningRoom site, and provide your thoughts.

ONCs initial focus is on consumer eHealth. To encourage public input to inform the consumer eHealth strategy, ONC is partnering with Cornell University's eRulemaking Initiative – an academic research group working with Federal agencies to increase public participation in government decision-making.

You can visit PlanningRoom now through May 9, 2013, to participate in discussions and provide comments on specific topics. The site includes discussion topics and questions to help guide the conversation.
The Office of the National coordinator for Health Information Technology
.

Tuesday, March 26, 2013

The Map is not the Territory

I get asked a lot how someone should structure their database to support generating or using CDA documents with some sort of application.  I always find it challenging to answer these questions, because I don't have a one-size-fits-all answer.  It really does depend on what you are trying to do.

The HL7 CDA standard is designed principally to serve as electronic documentation of an encounter with a healthcare provider.  For some applications, that is directly in line with what they do (e.g., EHR systems).  For others, that's not their main purpose.  A Clinical Decision Support application can use CDA to capture and communicate specific data elements to implement its workflow, either as input or output.  An analytics application can survey CDA documents and gather statistics suitable for computation of quality measures and development of dashboarding applications.  Another kind of application could do disease surveillance.  So the CDA Model (the map), may or may not be well aligned with the way you need information to be structured (the territory).

One of my least favorite forms of this question is how can I get JAXB to map the CDA Schema to my database.  My head just explodes.  I understand the desire to get a computer to do the mapping.    But I've mapped CDA, CCR, and numerous other models of healthcare information into existing database structures.  I've also mapped them into brand-new structures that are purpose designed for my application.  I have never been able, except for the simplest of things, to go from exchange format to useful database structures or object models, without significant human intervention.  The introduction of the smallest bit of recursion, or data type dependency leads to the need for manual guidance.

Nor have I ever designed the data structures or models of an application to serve the interchange formats.  I've always preferred to design the model to serve the purpose for which it is being used, rather than around how I get the data.  The reason for this is that data exchange events are generally rare as compared to general use of the data processing internally in the systems I'm working with.

I really don't want to bear exchange (e.g., data marshaling) costs during data processing.  A simple example of what I mean:  It's far more efficient for a CPU to process some data in binary form (e.g., for integer and floating point arithmetic).  However, it can also compute in BCD (Binary Coded Decimal format), and it's much easier to get data into and out of BCD than it is in binary formats for integers or IEEE floating point arithmetic.  Is that a good reason to keep it in that form?

When you look at the efficiency in computation gained by performing calculations in a format that is better suited, the answer is a resounding no.  The number of times that you must convert from compute friendly formats to exchange friendly formats and back is small enough that it is well worth while to go to a compute friendly structure as soon as possible.

So, should you ask me what database structures you should use, don't be surprised if I ask what you are doing, and if my response has nothing to do with CDA whatsoever.




Monday, March 25, 2013

App-in-a-Can

Have you been annoyed by the recent proliferation of web-site specific applications that you can now download for your Android or IOS device?  It seems as if everywhere I go, I have to stop and tell the website I'm directed too to skip the App download.

No.  I do not want your site-specific application to put your website in front of me every day.  That's why I use aggregator Apps and/or RSS feeds.

Today I was appalled to see yet another example of this: Now being pushed on physicians.  For a fee, it seems, some organization (whom I won't even bother linking to) will allow you to create a one or four page referral "App" from a template, where one page is a referral form, and the others could be any content you want to display.

Really?  Really.

In the HTML world, we used to call those things: A web-site in-a-can, and the end result was as bland and boring as most canned vegetables.

In fact, anyone considering having an App created like this, pay attention.  Ask yourselves, why would someone use your "App".  What value does it bring them, other than being able to refer patients to you?  Do you have really great content?  Some cool tools?  Something else?

If the value proposition for the the App just leads towards you, the App supplier, it's not an App that your customers will consider worth having.

And if it looks like it came from a can, I know what can they'll put it in.

Friday, March 22, 2013

On being Strategic rather than Comprehensive

In Meaningful Use, there are several components related to care planning that need to be communicated for transitions of care: The care team, the care plan (as described in CCDA), and patient instructions.  This was a good first start, but there's far more to do.  HL7, IHE, S&I Framework and many others have been working on developing a more comprehensive way to address care plans and care planning for quite some time.

This week, IHE PCC was reviewing content being developed for one of our work items related to care planning.  On the screen earlier this week was a proposal to add the following term to the IHE Glossary.

Care Plan   The synthesis and reconciliation of the multiple plans of care produced by each provider to address specific health concerns.

“You have defined care plan in terms of itself.” I comment.  Others immediately responded that they hadn’t.  “Sure you have: care plan and plans of care.” I chimed back.  I was then told that “Those are two different things.”, and thus began my education into what the current thinking is that's been developing across various groups.

This is what my daughter calls a face/palm (or in this case a head/desk) moment.  Those moments are usually accompanied by a loud noise as my palm (or my desk) comes quickly into contact with my face (or head).  I think the pain helps distract me from the former attack on my senses.

“OK,” I explained, “I’m never going to be able to explain this to anyone.  The way that the English language works, these two phrases mean the same thing.”  I did spend several years developing linguistic and natural language processing software, and managed to pick up a few things from my linguistic colleagues. 

A parse of “care plan” will result in in a noun phrase (a phrase acting as a noun) composed of “care” (noun adjunct = noun used as adjective) plan (noun).  Thus, plan is the main idea, and care is a qualifier that means the plan related to care.  I’m assuming I don’t need to define plan or care (yet).

A parse of plan of care results in a noun phrase, where “plan” and “care” are again nouns, “of” is a preposition, and care modifies/qualifies plan.  It is the plan about or related to care. 

My brain, and if you are reading this blog, likely yours, has been trained to treat “Care Plan” and “Plan of Care” as if they were the same thing.  We can all be indoctrinated to understand that they are different things, but recall what I said a few days ago about social interoperability, and what I said a few weeks before about not caring about what it is called, so long as I know what it is. 

These words fail the grandma test (and the developer test, and the provider test …). Something has to give here.  We need new words, because the ones we have only add to the confusion.  Definitions can be used to override instinct, but I'd much rather rely instincts, rather than circumvent them.  Let’s take a look at the words we have, and a picture to go along with them.

The image to your left shows that there is a first outer ring that encompasses the second inner ring, which has a third subcomponent containing a final inner component.  The image comes from material developed for the Longitudinal Coordination of Care project in the ONC S&I Framework from the Longitudinal Care Plan subworkgroup.  What follows are the words describing these rings that were suggested for the IHE PCC Glossary, and which are derived from the S&I Activities.




What it is called
What it is
Care Plan
The synthesis and reconciliation of the multiple plans of care produced by each provider to address specific health concerns.
Plan of Care
A concept some clinicians use to focus on discrete problems, the specific interventions to address the problem, and achieve a certain goal related to the problem.
Treatment Plan
A concept developed by a provider in collaboration with the individual to address an individual’s health concern under the purview of a single provider.
Instructions
Information or directions to the patient and other providers including how to care for the individual’s condition, what to do at home, when to call for help, any additional appointments, testing, and changes to the medication list or medication instructions, clinical guidelines and a summary of best practice. This is provided as a list of action steps given to a team member or patient to address health concerns.

The important part of what you see above is not the words on the left, but rather the words on the right.  The only notion of the “Care Plan” that I have ever seen is what my mother used to carry in her head for my step father, aided by her notes.  This concept exists rarely in the real world, but I have seen enough real world examples to know this isn’t a unicorn.  But it is rare enough to be a zebra (at least in my part of the world).

The second and third items are often confused, and in fact, IHE a few years back agreed that the code for the TREATMENT PLAN section in LOINC was the right place to put the CARE PLAN information (which has resulted in further discussions about change proposals to some existing profiles).  It’s confusing enough to experts, and healthcare providers certainly don’t agree on it either.  Instructions is perhaps a bit broader than I would expect, but seems to fit in with current notions.  And there seems to be agreement among healthcare providers that instructions are part of the care plan (at least those given to patients are).

The definition of the outermost object seems to be missing an important participant, the patient.  This is especially true when the phrase “Care Plan” is used with a definite article.  The only individual that has any chance of having access to “The Care Plan” is the patient or other care giver who has access to all the information available.  You can see why Care Plans are zebras.  You need an engaged patient or caregiver who wants to coordinate all this data, and they have to have access to it as well. 

My mother’s care plan  for my step father was flawed in that she did not have access to all the data, but that’s wasn’t for lack of trying. Using the definite article for a care plan ("The Care Plan") that is owned or developed by anyone other than the patient or their care giver is a mistake.  In the provider’s mouth, those words better be something like “this is the care plan that I’d suggest for you”, or “let’s go over your care plan”.  If “you” are not part of the care plan when your healthcare provider discusses it, then it’s probably his or her plan, and he or she shouldn’t be surprised when you change it to suit your needs.


In the battle for health and against disease, the commander-in-chief needs to be the patient.  They should be setting the objectives and goals, and approving the strategies used to reach them.  They may override some decisions where they feel necessary to in order to balance the priorities for each objective.  In the above definitions, I see the word “goals” used once, and the words “objective” and “priority” never appears.  The “plan” is what you do to meet goals.  The terms “goal” and “objective” are synonyms, and are often used interchangeably. 

I’ve been trained to specify objectives in a broad way, and to derive goals from objectives.  Goals allow you to measure whether the objective is being reached (in fact, if you work this way, the objective is often stated subjectively, and the goals are objective statements -- I never said social interoperability is easy).  If we talk about, and deliver goals and objectives together, I don’t think anyone will mind, and it’s still pretty easy to explain that goals need to be measurable.
"The key to strategy... is not to choose a path to victory, but to choose so that all paths lead to a victory." — Cavilo, The Vor Game
In a complex situation, there is never a single comprehensive plan which leads to success, but rather a collection of plans and alternatives in which enough plans succeed to result in the desired outcome.  Has your doctor ever told you: our plan is to try this (e.g., PT), and if that doesn’t work, then we will do that (Steroid injection), and finally, if necessary we will do the other thing (surgery)?  These represent the alternative paths (in a plan related to a knee problem).  I love this  doctorial we, but only when used collaboratively, that than in the royal fashion.

Planning is done at different levels, starting from principals, moving to strategies related to goals and objectives, and then on to tactics, which are executed via orders and instructions.  In developing a strategic plan for any purpose, you have high level principles and priorities, which lead to objectives and goals.  Each objective and goal can become the foundation of a tactical plan to achieve the objective.  In delegating the objectives from the strategic plan to others, the planner will often provide additional information and instructions about how to maneuver to reach the objective.

Strategic objectives and specific tactics are dynamic, responding to the changing system (thus, the need for alternatives).  I have never seen an overall comprehensive plan for patient care, such as would be describe in the “Care Plan”.  No organization I have ever worked with ever has an overall comprehensive plan in one place to reach its objectives.  Leaders can speak to the strategic objectives, and can often tell you what others are doing to achieve them at a high level.  The details of those tactics are delegated to experts in each objective.  If you want to know the detailed tactics, you have to speak to those experts.  The process is dynamic, as the tactics often change when alternatives are activated.

Rather than think about a comprehensive Care Plan as described above, I would prefer this view of the care planning process.

Strategic Care Plan:  This is an overview, containing the patient’s objectives and goals for overall care.  It identifies the patient’s principals and priorities that the care must meet.  It synthesizes and is used to reconcile differences between individual tactical care plans, but summarizes rather than contains all of them, although it should reference them in some way.  It most closely resembles the “Care Plan” described above.

Tactical Care Plan: This is a plan designed to achieve one (or more related) objectives.  It combines features of the Plan of Care and the Treatment plan above.  In the continuum between strategy and tactics, high level tactical plans will reference other, more detailed tactical plans.  My provider’s overall plan to control my blood pressure includes tactics that he is responsible for, and those he has delegate to others (e.g., a dietitian and me).  Those delegates may have tactical plans of their own.  Delegation is often represented through orders (e.g., medications, referrals and consultations) and instructions.

Orders and Instructions:  This component represents the orders and instructions in a tactical plan and most closely resembles the Instructions described above.  Orders and instructions in the tactical plan provide can provide links to those others who may have their own plans, and may provide alternatives to address changing conditions.  Advance Directives are nothing more than orders and instructions from the patient to the provider for care and treatment that are based on their principals and priorities.  They belong in the mix for care plans as well.


The "Care Planning" process should be less about comprehensive planning, and more about collaboration and objectives.  Yes, it is important to understand the steps to achieve an objective, but those plans need to be more agile and dynamic, coordinated through self-organizing care teams.

As I think about how my mother manages care, she is the commander-in-chief.  She doesn't have to know everything, but she does know where to go to get the details when she needs them.  In the mountains of data that healthcare can generate, it's not necessarily about what you know, but what you know about how to find out (Dr. Google is so powerful because of that).  Health IT can help, but we should not assume that all of the data will or must ever reside in one place.  It needs to be strongly linked together though, so that the generals can pull together the information they need, in order to carry out the hopes of the commander-in-chief.

-- Keith

Wednesday, March 20, 2013

The Journey of 4000 Miles could have been 20

I don't know which is more amazing, that I may actually come back from Italy with a solution that may work to solve my million registration problem (which could just be a 10,000), that I had to travel 4000 miles to talk to a person who lives just 20 miles from my house (I've already walked that far this last week), or that the solution I may have coming out of an IHE meeting is clearly out of IHE's scope for its profile of OAuth 2.0 in IUA, even though it aligns quite well with other IHE profiles for security and privacy (I may write a post about that later).

Here's the solution in a nutshell:

  1. Application Developers obtain a certificate that enables them to sign other certificates.
  2. Application instances obtain (are provisioned with during or after installation) a certificate signed by the application developer.
  3. Application instances provide an attestation of their instance identity that is signed by the application instance's certificate in a normal authorization workflow that does not require a separate registration.

The authorization endpoint can verify the identity asserted by the application instance by verifying the signature of the identify assertion and the certificate chain. If an application instance misbehaves at some point, the authorization endpoint can be configured to reject the identity of that application instance, locking out only one installation. If a pattern of behavior appears where many instances of an application misbehave, the application developers certificate can be blacklisted, preventing any instance of that application from being authorized.

This is the level of security that has been deemed to be suitable for the ABBI PULL protocol. It allows a single bad actor to be rejected, and also allows all applications from a particular developer to also be rejected if deemed necessary.

The Direct protocol as specified by ONC already has a mechanism to white-list certificates through the Trust Bundle. The trust bundle is the collection of certificates that are considered to be trusted. A certificate chain is considered to be trusted if during the verification process, the certificate at the root of the trust chain (or earlier) appears in the trust bundle. This very same mechanism can be used by ABBI PULL to establish the chain of trust for certificates. It could be the same trust bundle as is used for the Direct trust bundle, but there are probably good reasons to keep these two bundles separate.

I was pretty close a while back, when I suggested that the application instance be provided with a signed identity assertion. What changes is that it is provided not with a signed identity assertion, but rather a signed certificate, which is nothing more than an signed identity assertion with the addition of a public and private key.

This is why I don't claim to be a security expert. I can understand this stuff when it is explained to me by experts, but couldn't have devised this on my own. Rob Horn (co-chair for IHE IT Infrastructure) was the person who did explain it to me, but he didn't invent the idea. It's the same mechanism used to sign Linux distributions from various suppliers.

The only difference in what I previously proposed (using a signed identity assertion), is in which certificate is used to sign the identity assertion. In this case, the certificate used is the certificate that the application instance is configured with. How this configuration is performed is completely under the control of the application developer, and becomes outside of the scope of the ABBI PULL specification.

The key to proving out this solution is whether I can make it work with existing OAuth 2.0 libraries, using signed identity assertions.

For what it's worth, the act of the authorization endpoint of verifying the signature on the asserted application identity is essentially the same as authenticating the installed application. So even when the implicit grant type is used, the application identity could still authenticated by the authorization endpoint.

Strengths:

  1. Reuse of existing "Trust Bundle" mechanism to support identification of "trusted" applications instead of trusted Direct addresses.
  2. Addition of client authentication even in implicit grant flows (by virtue of verifying signatures on the asserted identity).
  3. Simplifies Authorization endpoint responsibilities since they no longer have to be identity providers for applications, but can rather defer application identity management and provisioning to application developers, and use the signed identity assertions and a trust bundle to manage client authentication.

Weaknesses:

  1. Unproven with existing OAuth 2.0 libraries currently available.
  2. Doesn't follow the common used patterns for Twitter, Facebook or Google for OAuth 2.0.
  3. Use of an unproven and likely to be changed IETF Draft for JWT Bearer Tokens.

For a pilot, the IETF work seems to be close enough.  I'm not terrible worried about weakness #2, since that can be addressed by adequate developer documentation.  Also, when you are Google, Facebook or Twitter, conforming to what others do isn't necessarily part of your business model or concern.

That leaves weakness #1, which means I may have my work cut out for me. I just have to find a few OAuth 2.0 libraries to play with. Any thoughts on which ones I should look at (Java/JavaScript only please)?

As always, feel free to poke holes and deflate my currently inflated sense of accomplishment.

   -- Keith

P.S.  In trade for this solution, Rob got my entire text from the ABBI work on OAuth 2.0, in the hopes that he, as editor of IHE's IUA profile will find it useful.  In this, I hope that what IHE emerges with, and what ABBI starts with, eventually wind up in the same exact place, the IHE IUA  profile of OAuth 2.0.

Sailing to RHIO: The mHealth Value Proposition

Today I presented at the Sailing to RHIO Conference organized by Arsenál.IT in Treviso.  The aim of this meeting was to review eHealth Issues and Telemedicine problems important to develop a RHIO for the Veneto region.  John Moehrke also presented at this event on Security and Privacy.

While John covered IHE profiles, I discussed the standards that emerging from HL7, IHE, OMG, and Continua Health Alliance related to Mobile Health.  If you attended my presentation at the mHealth Summit last year, you might recognized some of the content, but I did make several updates and trims for this audience.

You can find the presentation below:






Tuesday, March 19, 2013

Negotiating the Protocol

I'm in Treviso, Italy this week for IHE meetings.  As always, when I'm in a country that speaks a language other than my own, I make an attempt to use what I know of the language in speaking to others, at least for greeting them.  However, I noted that in both Italy, and when I was in Paris previously, my greetings were inevitably responded to in English when the speaker was able to use that language.

The protocol the listener used to fall-back to English was fairly straightforward.  They detected something in my accent that made it clear to them that I was not a native speaker.  In the case of Italian, it was my failure to prounounce buon giorno correctly.  I was missing the initial DJ sound in giorno (pronouncing it with a softer J sound), and failing to roll my R's (a failing that caused me great problems in my high school Italian class as well).

In IHE PCC, we are working on creating version aware templates as part of our ongoing work on harmonization with the Consolidated CDA.  One of the things that developers routinely ask me for is how they can tell what set of templates are used in a document.  This is especially important in the context of versioned templates.  In this case, a developer wants to know if it is even worth their time to process a document that may contain something they don't understand.

The solution that we finally came upon is quite similar to what a Java compiler does when it creates class file.  You can tell the compiler to create a class file that works with a particular version of a JVM.  Newer JVM's can process class files that were compiled for older ones, but if an older JVM encounters a class file that reports itself as being built for a newer JVM, it will refuse to load it.  We will enable such marking in the TF.

A content creator of a CDA document that is produced using templates from the PCC Technical Framework has a responsibility to mark the minimum version of the Technical Framework that is required to be understood.  This mark will appear in a <templateId> element appearing in the header.  Presence of that identifier is an indicator to the receiver that if they do not understand templates in that revision of the technical framework, they might not be able to understand the content of the document.  It's not an absolute statement that they won't work, just a warning that they may not work.  To parallel with the Java case, there are new structures and/or JVM operations that may appear in the class file, that older JVMs will not understand.

In this fashion, a receiver of content can examine the <templateId> associated with TF version.  It can then take appropriate actions based on the root and extension values found, and as necessary (as with me to an Italian speaker), fall back to something that both parties understand, or indicate that it cannot understand the content, or determine that it will try to understand anyway (much more like my wife), and only when it fails to understand, abandon the conversation.

To actually be able to (safely) understand something even though it is written to a later version of the technical framework than the system is designed for is built into how we mark versions.  Templates have a major and minor version number.  The major number changes when the new template cannot be understood (safely) by a system designed to understand a previous version.  Only the minor number changes when the template changes in a way that is backwards compatible, and only adds new information.

The intent of the distinctions we have created for major and minor change is to address issues of correct interpretations and thus patient safety in those interpretation of exchanged content.  However, I use the term (safely) in parenthesis above, because there is no way for IHE to determine what consumers can do with exchanged content safely. We can simply advise that something may not be safe (which the major/minor change distinction does).  It is, and must always be up to individual products to determine what is safe for patients based on their existing risk assessment processes.



Friday, March 15, 2013

Promoting Laboratory Result Exchange through CLIA

Last week, ONC announced an RFI (Request for Information) on Advancing Interoperability and Health Information Exchange.  Comments are due by 4/22 (my youngest daughter's birthday).  There are nine questions for which they ask for detailed answers, and each question is in several parts.  Question 9 included the following:
What specific HHS policy changes would significantly increase standards based electronic exchange of laboratory results?
This has been an interesting challenge for interoperability, since labs aren't given any incentive dollars to use standards under the Meaningful Use regulation.  In my naive world view (which includes the technical, rather than political issues), I think there's a pretty straight-forward solution.

Currently, laboratories covered under CLIA do not receive incentives for using standards specified under meaningful use. One of the requirements of clinical laboratories under CLIA is the production of a test report that meets requirements under 42 CFR 493, subsection 1291.

One possible way to promote use of the standards would be to providing a deeming clause in subsection 1291 such that if transmission of test results is performed with Health Information technology that has been certified to conform to the criteria in 45 CFR 170, subsection 314(b)(6) (see below for text) could be an incentive for laboratories to use those standards.  A similar approach was used in the Stark Relaxation rule with respect to interoperable Health IT a few years back.  In that regulation, an EHR that had been certified was deemed to be interoperable.

My suggested addition to 42 CFR 493.1291(d) would be:

(d) Electronic Health Technology that has been certified as conforming to 45 CFR 170.314(b)(6) and is connected to a receiving system that is electronic health technology certified as conforming to 45 CFR 170.314(b)(5) is deemed to be an adequate electronic system to ensure test results and patient specific data are accurately and reliably sent from the laboratory to the receiving system.

That deeming clause could greatly simplify for CLIA covered laboratories what they need to do to ensure that test reports are accurately and reliably sent to receiving systems.  It wouldn't eliminate their need to certify interfaces for those providers who aren't using certified EHR's, but it would make it easier for them to deal with providers who are using certified technology, and could greatly reduce the interfacing and certification costs they bear in order to comply with the CLIA regulations.  That might just be the incentive that they need.


Thursday, March 14, 2013

Defining Errata

One of the issues we discussed on the HL7 Structured Documents workgroup call this morning was  a comment I made on the Consolidated CDA guides with regard to constraints on Guardian.  The issue was that the code identifying the guardian relationship to the patient only included family members (most of the codes), a friend or neighbor (two codes).  In fact, for most cases where their is a legal guardian relationship outside of the norm (and for which documentation facilitates care), are cases where those codes come from another set of values (ResponsibleParty).

There was some debate about whether we could address this as errata or not in the workgroup.  The common definition of errata is errors that originate through the publication process, whereas errors caused by authorship are corrigenda.

According to the HL7 Publishing guidelines:  Publication of corrections as Errata is used when it has been discovered that there is an error in the publication of a standard or DSTU, but it does not specifically identify the cause or reason why the error is present.  This is a case of where knowing what was meant is more important that what it is called.  Pulling out our process documentation helped my cause.


In this particular case, the error predates the Consolidated CDA guide.  It was in fact caused by the merger of the Guardian relationship with other relationships (where family member, friend, and neighbor are sensible values).  In that situation, a value set constraint associated with one participation was merged with another participation without appropriate inspection (I know how it happened because I chaired the committee where it happened).  So, call this one a corrigendum, rather than an erratum.


We agreed on the call to address this as an errata with respect to publication, regardless of the cause.  It's pretty clearly an error when the most common case needed for documenting guardianship comes from outside the set of allowed values.  From the implementer perspective, what we really care about is that it be fixed, and I'm pleased that HL7 is doing so.


Wednesday, March 13, 2013

Navigating Standards and Regulation

Compare four different use cases with me:

From an IHE IUA (Internet User Authentication a.k.a. OAuth) profile discussion: to authorize the patient's application to access health information.

From the ABBI Charter: Allowing a third party application of the consumer’s choosing to privately and securely access personal health data on demand.

From the Omnibus Final Rule:
if requested by an individual, a covered entity must transmit the copy of protected health information directly to another person designated by the individual. In contrast to other requests under § 164.524, when an individual directs the covered entity to send the copy of protected health information to another designated person, the request must be made in writing, signed by the individual, and clearly identify the designated person and where to send the copy of the protected health information.

From the HITECH Act (see subsection (e) at the top of page 7748):
the individual shall have a right to obtain from such covered entity a copy of such information in an electronic format and, if the individual chooses, to direct the covered entity to transmit such copy directly to an entity or person designated by the individual, provided that any such choice is clear, conspicuous, and specific;

In each of the above: individual, patient, consumer also includes in some way their authorized representative, although that may be variously defined (e.g., parent, guardian, holder of a power of attorney, et cetera) and implemented, and may be stated or implied in the use case.

In each use case, we talk about authorizing an application, in others, an entity, and in others, designated person as the recipient of the electronic information.

In the IHE use case I described above (which is really just one example of many similar use cases), it mentions the "patient's application", as if we are discussing an application the patient owns (or licenses).  But in the IHE profile, that could also be an application developed by a third party that the consumer authorizes.  I can see uses where a patient could use this same capability to authorize an application devised by the SSA to access data on a to enable adjudication of disability for example.

In the Omnibus Final Rule, it clearly states: the request must be made in writing, signed by the individual, and clearly identify the designated person 
However, I would note, that writing does not mean "printed on paper", signed by the individual can be represented by some form of electronic signature, and clearly identifying a designated person need not mean "by name", but could also be by role (e.g., privacy officer, licensed healthcare provider, et cetera).

By paying attention, one can navigate all of these use cases to produce one common solution that meets the needs for all of them.  But it truly isn't easy.  Welcome to my world.


Tuesday, March 12, 2013

HIMSS13 in a word: Exhausting

One of the things I like about HIMSS is connecting with people and events that I only get to see once each year.  It's like the friend's child you see infrequently; growth and change is so much more obvious.  At the same time, the frenetic pace and the challenge to see everything is totally exhausting.  And I missed all the good stuff, like Eric Topol's keynote, and most of Bill Clinton's speech.

A few key observations from the show:  Nobody seems to know what patient engagement is, but there are plenty of folks out there hawking solutions.  That annoys many, but I'm not surprised that in coming to a trade show, people engage in trade. Nor does is astonish that companies try to capitalize on current trends.   In fact, the HIMSS focus on Patient Engagement seems to have raised it up to be a point of conversation, and this is good sign.  Everyone was talking about it, and there were a number of engaged patients (and technologists) around to take it in.  Current reality is that patient engagement is too new for many to understand, especially at the institutional level.  All too often, the discussions about patient engagement at HIMSS were missing the very people that needed to be engaged.

Another of the big trends was analytics and business intelligence.  It's always been there, but BI emerged from the background to take on at least a supporting role on stage, if not trying to usurp the lead role.  Platform, platform, platform.  Everyone has a platform, and wanted to showcase it.  What I really want to see here is not the platforms for, but rather the exercise of business intelligence in healthcare.

On the interoperability side of the show (in fact, the Interoperability Showcase is a show within a show), the message seemed to be a bit different from prior years.  ePatient Dave was in the house, and presented to a standing room audience in the showcase theater, and giving showcase tours. Everything felt a bit more real.  On the ONC program side, there was a lot more focus, on just a few topics:  CCD Exchange, Exchange using Direct, Exchange using NwHIN, and Blue Button and Blue Button Plus were the key messages, with multiple participants showing each.  Regina Holliday was just next-door for a day, painting and participating all day in discussions about patient engagement.  The conversations are starting, and this is good.



Wednesday, March 6, 2013

Social Interoperability

Every now and then a string of words will get put together, and peoples ears perk up, and you realize that you've created a new meme.  That happened to me today at the HIMSS Standards and Interoperability panel presentation.  We were talking about how to make it easier for patients and providers to communicate about how to get their data.  One nurse in the audience talked about how, when patients ask for their CCD, the person at the other end of the conversation wouldn't know what they are talking about.  CCD and CCDA are geek speek.  Another audience member explained that giving every provider an EHR shouldn't come with the expectation that they would all become computer geeks.  I completely agree.  We need a better way to talk about this.  A way that grandma, or my 10-year old can understand.

The benficiaries of interoperability are patients, and yet we still haven't given them a way to communicate how to get their data.  This is where the notion of social interoperability comes in.  It's your data, ask for it is a short commercial I wrote a script for back in 2010.  The idea behind it was that we need to educate patients about how to ask for their records in a way that everyone, patients, providers, and vendors understands.  What they mean is give me my CCD and/or CCDA, but we geeks don't really need for everyone to understand that's the secret sauce.  

It's what marketers would probably call a brand awareness problem.  What is the brand for patient engagement?  Is it CCD/CCDA?  BlueButton?  BlueButtonPlus? VDTNow? Meaningful Use?  None of the above?  We need to agree on, and communicate that to patients and consumers, and then we need to educate vendors and providers what that means.

Social Interoperability, the ability to communicate with normal human beings, will create the demand for and use of technical interoperability.  And that will get us all where we want to be.  After all, it isn't just providers we want to be meaningful users of data and technology, it's for patients too.

Tuesday, March 5, 2013

Patient Declined to Answer

Meaningful Use requires EHR systems to be able to record language, race and ethnicity, or whether the patient declines to answer the question for any of these demographics.  You can find the text in the regulation here and also below:
(3) Demographics. (i) Enable a user to electronically record, change, and access patient demographic data including preferred language, sex, race, ethnicity, and date of birth.
(A) Enable race and ethnicity to be recorded in accordance with the standard specified in § 170.207(f) and whether a patient declines to specify race and/or ethnicity.
(B) Enable preferred language to be recorded in accordance with the standard specified in § 170.207(g) and whether a patient declines to specify a preferred language.
How would you record that the "patient declined to specify" any of these in a C-CDA document.  If you look carefully in C-CDA and/or QRDA, you do find that there are ways to express "Patient Reason" as the reason why something wasn't done (e.g., an immunization), but that's not the answer here.  These are simply special cases of "I don't know", where you asked the question but didn't get an answer.

In CDA, you represent "I asked and still don't know" as nullFlavor="ASKU" on any code attribute. So, you'd record it as:

<languageCode nullFlavor='ASKU'/>
<raceCode nullFlavor='ASKU'/>
<ethnicGroupCode nullFlavor='ASKU'/>

If you find any other flavor of null, you don't have evidence that the question was asked, and so the reason may be other than "patient declined to answer".


Monday, March 4, 2013

Displaying a NonXMLBody in HL7 CDA LateNightAtHIMSS

While I'm at HIMSS, I'm planning on doing some catch-up.  While my days and evenings will be filled with HIMSS13 stuff, I expect that the hours between arriving back in my room, and when I finally head to bed will include a bunch of standards work that I've been lagging on.  As usual, I try to include that in blog posts as I can. These will be tagged with LateNightAtHIMSS.  Here's the first:

One of my to-dos from the HL7 Working Group Meeting back in January was to write some text for the claims attachment workgroup on how to display the non-XML body in CDA.  I'm just getting around to that now, and have realized that I'll probably need to radically shorten the content for the HL7 specification, but didn't want to lose the thinking that went into it, so I'm putting it out here.  It's not a complete how-to, but it should give you some ideas about how to accomplish the task.


Display of CDA is usually a matter of transforming the narrative content using an XSLT style sheet. However, when exchanging information using the unstructured document using a <nonXMLBody>, this mechanism does not work without additional engineering. The header can be readily transformed using a stylesheet. However, the body of the document must either be made reference-able by the browser in a URL scheme it recognizes, or separately decoded into its binary format.  All content must be rendered using an appropriate viewer for the MIME type of the document.

This requires several steps, including configuring the browser to display the non-HTML content if needed (e.g., for application/pdf, application/msword or text/rtf content), linking to externally referenced content, or linking to and decoding the embedded base-64 encoded content.  In addition, you must address security concerns that might be introduced by displaying content such as application/pdf, application/msword, text/rtf or text/html which could include scripts.

Configuring the Browser

In order to display the content of the <nonXMLBody> element within a CDA document, the browser component must be configured to support display of the various MIME types that are allowed within the unstructured document. While displaying the CDA header of such a document can be done using an XLST stylesheet, displaying the body content is not just a simple matter of transforming it using XSLT.

The mediaType attribute of the <text> element identifies the type of content. The following types are supported in the unstructured document for word processing/text formats:
  • application/msword
  • application/pdf
  • text/plain
  • text/rtf
  • text/html
The following MIME types are supported for graphic formats:
  • image/gif
  • image/tiff
  • image/jpeg
  • image/png
Most modern browsers can display text/plain, text/html, image/gif, image/jpeg, and image/png without any difficulty. However, they must be configured (e.g., with plugins or other software) in order to property display application/msword, application/pdf, text/rtf and/or image/tiff files. The browser component used by your application must be configured to properly handle the display of these files. Files in the image/tiff format are often challenging because there is a great deal of variation in how that standard is used (e.g., multi-page tiff images), and few plugins handle all the variations well.

In addition to configuring the browser, you must also address other issues. There are two ways that content can be included within the CDA document: by reference or by value.

Linking to Content Included By Reference

The unstructured document can reference the narrative text via a URL, or embed base-64 encoded content directly into the <text> element of the CDA document. When the content is referenced via URL, the URL appears in a <reference value="URL"> element inside the <text> element of the <nonXMLBody>. This can be transformed into an <iframe src="URL"> in the XSLT transformation. Transformations may be needed on the URL to correctly point to the location of the referenced content. The URL used inside the CDA document may use links that refer to part of the transfer package used to encode the CDA document and its referenced files. However, these could use a URL scheme or syntax not supported by the browser being requested to display the content.

For example, CDA Release 2 describes a a way in which a CDA document can be sent using the multipart/related MIME type.  The first component is the CDA document, and subsequent parts include the resource used to contain the nonXMLBody.  Each component of the multipart can be given a URI in the Content-Location: header associated with it.  That URL applies within the context of the multipart resource itself, but  those content locations will not be understood by common web browser components.  So, the application software needs to address how those URLs will be translated to enable access to each component as a separate resource.

Linking and Decoding Content Included By Value

The content of the unstructured body can also appear base-64 encoded in the CDA document. The <text> element will have a mediaType attribute indicating the type of content, and a representation attribute (set to the value B64 to indicate that the content is base-64 encoded. The <text> element will contain the base-64 encoded content as text as in the following example:

<text mediaType="text/rtf" representation="B64">e1xydGY...</text>

Embedded base 64-encoded content cannot be reliably be transformed to HTML via an XSLT stylesheet for all content types in all browsers. One mechanism that works to some degree with image formats is use of the data: URL scheme.  This URL scheme allows base-64 encoded data to be sent to a browser in an URL in the form:

data:[<mediatype>][;base64],<data>

Most modern browsers support the data: URL, but many (especially those in common use), limit either the size of the that can appear, or the type of content that can be shown (for example, some versions of Internet Explorer only allow use of image formats in an <img> tag, which prevents it from being used to support application/msword, application/pdf, text/plain, text/plain and text/rtf.

One way to display these is process the content of the CDA body twice.   The first pass renders the header, and generates an appropriate <iframe src="URL"> link to call the second pass.  When the browser attempts to render the content of the <iframe>, it calls back on the server to get the contents of the specified URL.  That URL is encoded during the first pass to initiate the second pass.  The second pass base-64 decodes the binary content and returns it to the browser as a binary stream of data, which it (or its plug-in) renders appropriately.

Security Concerns with the NonXMLBody

The nonXMLBody of CDA can include application/msword, application/pdf, text/rtf and text/html. Each of these formats can include script which could be run by the plugin running in the browser.  It may not be easy to disable scripting in commonly available plugins, or in some cases (such as when displaying base-64 decoded text/html), it may not be possible to turn off scripting (because it may be used by the browser to enable other parts of your application.

Friday, March 1, 2013

Breaking: HL7 Opens Ballot to confirm FreeIP Policy Changes in its Bylaws

You may recall a few months ago that I reported about HL7's policy change to make its IP free to non-members.  Today, HL7 announced to its members the opening of an administrative ballot to change the organization's bylaws to enable that policy to be made effective.  This is but one of the many things the organization has been working on between then and now to achieve that goal.

The ballot itself is open now to HL7 Members only, and will close on March 31st.  The announcement to members was accompanied by a three page summary of changes, which I will further summarize below:

  1. Separates HL7 IP Policy into a separate, board approved document, from the Bylaws, to enable future adjustments of IP Policy without requiring a membership-wide vote.
  2. Removes prohibitions on use of HL7 IP for certain classes of members from the current bylaws.
  3. Clarifies some procedures around revision of bylaws.
  4. Clarifies the rights of student and health professional members.
The new IP Policy proposes that:
  1. Affiliate rights are governed under their affiliate agreement.
  2. Grants of rights on "specified material" as designated by the board is as follows:
    1. Organizational members are granted the right to use and incorporate "specified material" into products and services without additional license fees, and to incorporate portions of the protocol specification (defined in the policy document) into implementation guides and/or product documentation, and to share the specifications within the organization.
    2. Other members (individuals, students, and providers) and non-members are granted the right (on agreeing to abide by the HL7 IP Policy) to use and incorporate the "specified material" into products and services without additional license fees, but may not incorporate portions of the specification text itself into their product documentation or to share the specifications with others.
At present, the information that has been made publicly available about "specified material" is that HL7 standards and other IP will be freely available.  I can probably safely tell you that the intent is to include implementation guides (e.g., CCDA) in other IP.  Don't ask me for more than I can say, as I've probably already said too much.

NOTE: This isn't a done deal.  The membership has to agree to these changes before they can be made effective.  If you are an HL7 member, I urge you to vote FOR these changes.

  -- Keith

A HIMSS13 Calendar of Events

Like just about everyone else in the HealthIT world, I'll be headed off to HIMSS13 next week. There's plenty going on.  Here's just a few of the places I'll be (or which might be of interest to you).  I'll be buzzing around a number of locations, including the Interoperability Showcase, the HL7 Booth (#4235, especially 9:30 to 10:30 Tuesday the 5th -- where I'll be one of the "experts"), and of course GE's booth (#1341).  If you are trying to find me, and cannot, just shoot me an e-mail.


e-Patient Dave: Let My Data Go

Session Information:
Title: Let My Data Go
Date: Monday, March 4, 2013
Time: 4:00 - 4:30 p.m.
Location: HIMSS13 Annual Conference, Interop Showcase

If you’re a data geek, or if anyone you know consumes medical services, this issue is important to you. Come give it up for interop – to let my data go!

Followed immediately by:

Tweetup GMDD: The new Standard for Interoperability
Session Information:
Title: GMDD
Date: Monday, March 4, 2013
Time: 4:30 - 5:00 p.m.
Location: HIMSS13 Annual Conference, Interop Showcase

Meet e-Patient Dave and go on a tour of the Interop Showcase led by me showing how IHE is making it possible for patient to get their data.



#HITsm Live Tweetchat

Session Information:
Title: HITsm Live Tweet Chat
Date: Tuesday, March 5, 2013
Time: 11:00 a.m. - 12:00 p.m.
Location: HIMSS13 Annual Conference, Social Media Center

Participate in the leading health IT-focused tweetchat—#HITsm—in person. Join live or by logging in to the TweetChat room for an educational and entertaining discussion on health IT trends and observations from HIMSS13.


CMS and ONC Discussion
Beyond Certification: Making Meaningful Use Stage 2
Exchange Requirements Work in the Real World

Session Information:
Title: Beyond Certification: Making Meaningful Use Stage 2 Exchange Requirements Work in the Real World
Date: Tuesday, March 5, 2013
Time: 3:30 p.m. – 5:30 p.m. CT
Location: HIMSS13 Annual Conference, Room 293

The agenda for this session will include:
  *   Understanding and leveraging MU Stage 2 optional transports – a roundtable discussion with EHR vendors and health information service providers (HISPs)
  *   Creating scalable trust for Direct – an overview and discussion of the conceptual and technical approach to enabling cross-vendor/cross-HISP exchange for patients and providers using Direct


ABBI Meet and Greet
Date: Tuesday, March 5 @ 4:30 pm Central
Location: Wolfe’s (in the Warehouse Bar at the Marriott, 1 block down from the Convention Center)
Followed immediately by:


S&I Framework Meet and Greet
Date: Tuesday, March 5 @ 5:30 pm Central
Location: Wolfe’s (in the Warehouse Bar at the Marriott, 1 block down from the Convention Center)