Brian Weiss

About Brian Weiss

CDA PRO Founder

CDA PRO 2015

CDA PRO 2014 – A Retrospective
As I begin to write this post, there are 45 minutes left in 2014 in my time zone… which means the first calendar year of CDA PRO is coming to a close.

We started the year with a bang – from initial launch through the creation of a 200+ article knowledge base, tens of eLearning videos, a very code-intensive CDA PRO Lookup tool, and all the “packaging” of a web site – from home page to news feeds and automated Twitter posts.

As we entered the summer, things slowed down significantly. The main reason for that is that we’ve launched a new healthcare IT startup named Carebox – more on that in a moment.

So, those of you who were accustomed to the “fast and furious” pace of the earlier part of the year, may have wondered what happened…

Carebox is a cloud solution that promises to make it as easy as possible for consumers/patients to collect and organize their electronic health records from wherever they are stored – from provider EHR systems to personal health monitoring devices.

The “easy to collect” part involves a wide range of capabilities – from automated/scheduled patient portal “pull”, to DIRECT protocol “catching”, and more – as well as some supporting services to bridge the gaps that exist today between a consumer’s clear legal right to get an electronic copy of their records from any provider/stakeholder that maintains such records on their behalf, and the realities of trying to exercise that right.

The “easy to organize” part revolves around us fully automating the process of normalizing various available APIs and record formats into MU2-compatible C-CDA documents, and then extracting and processing the discrete structured data elements. We also automatically tag and categorize the contents as much as possible. In addition, we provide document-style access to all the records (including scans and images that we can’t normalize/structure) with optional explicit tagging and notes to help with search, for those who are so-inclined.

However, unlike a typical PHR or patient mobile application, we are seeking to minimize, rather than maximize, “patient engagement” with Carebox. In our vision, consumers have a Carebox that is there when they need it, without them needing to be “EHR-style data managers” who regularly interact with it.

Our business model is based on “sponsorship” of Carebox by trusted healthcare stakeholders that have an established relationship with their community of customers/members/patients – in a win-win model that gives the consumer full control of their own copy of their records and makes the data available to the “sponsor” (and anyone else the consumer chooses).

I can’t yet share everything about our planned pilots and strategic partnerships that we’ll be announcing early in the new year – if you’re interested, you can learn more on our web siteand you can even sign up for our planned Pre-Release Pilot whereby you can be one of the first to get a (free) Carebox to try […]

Jan 1, 2015|Annnouncements|

Where do you indicate the referring physician in a CDA document?

The CDA Header of a CDA document has XML sub-elements of the ClinicalDocument root element to represent the patient (the recordTarget element), the author of the CDA document (the author element), who the document is intended for (the informationRecipient element), and more.

However, it’s not immediately obvious where in the CDA Header the “referring physician” belongs.

The answer is that that the referring physician (or other relevant healthcare provider making the referral) – along with the admitting attending, consulting, and/or discharging physician/healthcare provider – are represented in the encounterParticipant sub-element of the encompassingEncounter element, which in turn can be found by following the path: ClincialDocument/componentOf/encompassingEncounter.

For a referring physician, the typeCode attribute of the encounterParticipant element is set to the value “REF”.

Refer to the article: The encounterParticipant element, for additional information.

Other CDA PRO Know Articles Referenced In This Article

Oct 21, 2014|Encounters & Participants|

The encounterParticipant element

The encounterParticipant XML element in the CDA Header, is used to represent the care providers that participated in the primary encounter in which the clinical acts being documented in the CDA document took place.

Understanding encompassingEncounter
encounterParticipant is a sub-element of the encompassingEncounter element – so before continuing with this article, it is recommended that you review the article The encompassingEncounter Element, which explains what is meant by the “primary encounter in which the clinical acts being documented in the CDA document took place”.

That article, in turn, also references Use of encompassingEncounter in C-CDA document templates – which overviews the use of the encompassingEncounter element in all document templates that are part of C-CDA, including the special case of the CCD document template.

The typeCode Attribute of encounterParticipant
The types of care providers that can be represented by the encounterParticipant element are reflected in the list of allowed values that the typeCode attribute can be assigned:

  • “ADM”: The admitting physician/healthcare provider
  • “ATND”: The attending physician/healthcare provider
  • “CON”: A consulting physician/healthcare provider
  • “DIS”: The discharging physician/healthcare provider
  • “REF”: The referring physician/healthcare provider

Of course, multiple encounterParticipant sub-elements can be present within a single encompassingEncounter element, so as to capture all relevant participants.
Other Attributes and Sub-Elements of encounterParticipant
The encounterParticipant supports the three standard sub-elements and one attribute that are common throughout CDA (the realmCode, typeId, and templateId sub-elements, and the nullFlavor attribute – refer to Three common sub-elements (and one attribute) throughout CDA, for details).

In addition, encounterParticipant supports the assignedEntity and time sub-elements to capture details of the participating provider and the time span during which they participated. The use of these two sub-elements is the same as their use in the performer element – refer to The performer element, and in particular to the last two sections of that article titled “The assignedEntity Sub-Element of the performer Element” and “Other Sub-Element of the performer Element”.

Other CDA PRO Know Articles Referenced In This Article

Oct 21, 2014|Encounters & Participants|

Medication frequency of “once”

The XML syntax for representing a medication frequency of “once” (i.e. “take a single pill one time on a given date”) in a CDA document, is both simple and subtle.

In a CDA document, here is the correct XML syntax to represent a SIG (schedule for taking a medication) of “Take once on October 1, 2014″:

<effectiveTime value='20141001' />

Simple, right? Now let’s understand why it’s not so trivial…

No xsi:type in a substanceAdministration/effectiveTime Timestamp
To express a SIG of “once”, it is sufficient to use a timestamp to represent a moment in time.

Following the pattern for other uses of the effectiveTime element to express a SIG (see below for some references to articles about this topic), we would expect to see an xsi:type attribute that is set to the value “TS” to indicate that a Timestamp is being used. Refer to the article What is the role of the xsi:type attribute in CDA? for additional information about the use of xsi:type.

However, doing so results in a validation error in the TTT validator!

The reason for this error is explained in the article titled Using “combined type” time intervals in the section of the article titled Use of xsi:type Attribute with SXCM_TS Data Type. It is due to a subtle technicality of how the XML Schema definition for SXCM_TS works.

In the XML Schema for CDA documents, the data type name assigned to elements that can represent complex “combined type” time intervals – such as the effectiveTime sub-element of the substanceAdministration clinical act statement, which is used to express a SIG – is SXCM_TS.

An element of type SXCM_TS is actually already of type TS (this is its “base type”), and thus schema validation will fail if xsi:type=”TS” is explicitly indicated.

The correct syntax is thus as shown above, using only the value attribute in the effectiveTime element, without the use of xsi:type.

SIGs with Time Intervals Do Require xsi:type
As noted, the case where a single timestamp is used in the effectiveTime element, is the exception to the rule when it comes to using the xsi:type attribute. For time intervals, the xsi:type attribute must be used.

The article Combining time intervals in CDA, overviews the use of the xsi:type attribute and the operator attribute, within an effectiveTime element, in order to express a SIG involving multiple time intervals.

The article Using “Parenthetical Expressions” in SIGs discusses the further complexity of expressing SIGs such as “three times a week for two weeks, then twice a week for two weeks, then once a week thereafter – starting on Feb 2, 2014″.

In all of the examples in those articles, the xsi:type attribute is correctly used.

Other CDA PRO Know Articles Referenced In This Article

Sep 29, 2014|Dates, Times, & Schedules|

Organizer required even if only one observation

The article The organizer element, describes the usage and XML syntax of the clinical act statement named organizer, which is used in CDA documents to group together other, related clinical act statements, such as observation elements.

In C-CDA, there are five entry templates that are applied to organizer clinical act statements. These templates all have the word “Organizer” in their name:

  • Results Organizer
  • Vital Signs Organizer
  • Cognitive Status Result Organizer
  • Functional Status Result Organizer
  • Family History Organizer

All Five Organizer Templates are Similar
All five of these “organizer templates”, share the same XML hierarchy characteristics. All five of them are nested directly inside a section template (Results Section, Vital Signs Section, Functional Status Section, and Family History Section). All five of them then support within them, a single entry template – that is applied to an observation clinical act statement (Results Observation, Vital Signs Observation, Cognitive Status Result Observation, Functional Status Result Observation, and Family History Observation).

What if There is Only One Observation?
A common question that is asked regarding all five of these templates is: “what happens if there is only one observation?”. It seems like unnecessary overhead to use an “organizing list” structure for a single item. Lists of one are not that interesting as “lists”…

The answer, however, is that the organizer template must always be used in all five of these contexts. It is not allowed to place an observation element directly in the section template, without an intervening organizer.

As explained in The organizer element, in the section of the article titled “More Than Just a List of Acts”, the organizer element is a clinical act statement in its own right. Although its primary purpose is to organize its contained “list” of clinical act statements (such as observations), it has some independent value as well.

Similar Situation With Concern Acts
In Is a single allergy or problem observation wrapped in a concern act?, a similar issue is addressed about the use of a concern act to “wrap” problem or allergy observation elements in the Problem Section or Allergy Section, even when each concern act contains only a single observation.

However, while the use of concern acts is subject to some debate (as noted in the article Is a single allergy or problem observation wrapped in a concern act?), in the case of “organizer templates”, it is broadly accepted that the organizer must be used – and it is an absolute requirement in C-CDA.

Other CDA PRO Know Articles Referenced In This Article

Aug 29, 2014|C-CDA Templates, Clinical Act Statements|

Multiple recordTarget elements in one CDA document

The article The recordTarget element provides an overview of the recordTarget XML sub-element of the ClinicalDocument root element of all CDA documents.

As explained in detail in that article, the recordTarget element is part of the CDA Header, and represents the patient that is the subject of the CDA document.

Usually Only One recordTarget Per CDA Document
In the vast majority of cases, a CDA document will only have one recordTarget element.

Even situations that might seem to require multiple patients to be listed – such as the summary of a group therapy session – really only should have one recordTarget element. If there is a record being maintained for the entire group, then the group as a whole would have an identifier and that single entity/identifier (“the group”) would be captured in the recordTarget element. If, on the other hand, the record was destined for the clinical record of a specific member of the group, that specific patient would be captured in the single recordTarget element for the CDA document.

There Are Some Exceptions
There are, however, situations, where a single CDA document might be intended for filing in multiple clinical records. The case of conjoined twins would be an example.

However, in nearly all other circumstances, the use of multiple recordTarget elements is NOT recommended. Typically, even in situations that appear to warrant the use of multiple recordTarget entries, there is a single primary patient that is the focus of the CDA document – and other parties can be listed in specific contexts via related clinical act statements within the document.

Potential Interpretation Issues
Even if a situation warrants the use of a CDA document with multiple recordTarget elements, there is the question about how likely a recipient of such a CDA document will be to correctly interpret it. Thus, the use of multiple recordTarget elements should practically be limited to CDA implementation guides (e.g. in areas of population reporting, etc.) that explicitly indicate that this should be done, and when/how it should be done for specific document templates.

Multiple recordTarget Elements in C-CDA
C-CDA documents, the use of multiple recordTarget elements is formally allowed, but it should be limited to very specific use cases such as conjoined twins.

Other CDA PRO Know Articles Referenced In This Article

Aug 22, 2014|Encounters & Participants, Entities & Roles|

“Condition” vs. “Disease” in Problem Type code values

There are four C-CDA entry templates which are designed for expressing observations of “problems” (the OID for the template identifier is show in parenthesis, following the template name):

  • Cognitive Status Problem Observation (2.16.840.1.113883.
  • Family History Observation (2.16.840.1.113883.
  • Indication (2.16.840.1.113883.
  • Problem Observation (2.16.840.1.113883.

All four of these templates are applied to the observation clinical act statement (refer to The observation element, for additional information).

Since C-CDA allows the nesting of entry templates inside other entry templates, as well as inside section templates, there are many additional C-CDA templates which contain the four templates above. For example, the Indication template is part of seven other C-CDA entry templates and the Problem Observation template is part of five other entry templates. Those templates, in turn, are nested in other entry templates and section templates.

In all, then, there are many tens of C-CDA templates that describe types of problems using the four core “problem observation” templates, listed above.

Eight Allowed Values for the code Element in “Problem Observation” Templates
In all four of these “problem observation” templates (and, by extension, the tens of templates that use them), the code attribute of the code sub-element of the observation element, is required to be drawn from a specific set of coded concepts from the SNOMED-CT code system (refer to Codes in CDA and Codes and code systems, for additional information about coded elements, coded concepts, and code systems in CDA documents).

Specifically, there are eight allowed coded concepts for use in observations/code/@code in these templates: Finding (404684003), Complaint (409586006), Diagnosis (282291009), Condition (64572001), Finding of functional performance and activity (248536006), Symptom (418799008), Problem (55607006), and Cognitive function finding (373930000).

These concepts are intended to indicate the level of medical judgment used to determine the existence of a problem, and are collectively referred to as the allowed coded concepts in C-CDA for “Problem Type”.

Condition vs. Disease
As noted, one of the eight allowed Problem Type coded concepts has the code value 64572001, and is termed “Condition” (in terms of what should go in the displayName attribute for the code element). However, when looking up the value 64572001 in SNOMED-CT, the description provided for this coded concept is “Disease”, not “Condition”.

This is a rare situation where C-CDA guides to a different descriptive term for a coded concept value, relative to the one recommended by the underlying code system. The reason in this case is historical in nature. The CCD and CCR standards that were commonly in use prior to the publication of the C-CDA standard, used the term “Condition” for what SNOMED-CT refers to as “Disease”, in the relevant equivalent context. So, in order to provide trace-ability back to these earlier standards, it was decided to maintain the use of “Condition” as the […]

Aug 22, 2014|C-CDA Templates, Clinical Act Statements, Codes|

Rendering Time-Zones

The article Moments in time in CDA, overviews the format used to represent a “timestamp” in CDA documents. It also presents several examples of timestamps. For example, the representation of August 22, 2013 6:15pm in a CDA XML element named time (refer to The time element, for additional information) would be:

<time value='201308221815' />

This same timestamp format is used throughout CDA to represent a point in time – including the endpoints of time intervals, as explained in Time intervals in CDA.

The Problem With Time-Zones

To represent time-zones, the timestamp format uses ±ZZzz at the end to express the time-zone as an offset from UTC. For example, this timestamp syntax represents
December 1, 2013 8am, Los Angeles Time (PST):

<time value='201312010800-0800' />

Now consider an application that has to take the data in a CDA document and display it in a human-readable format (on screen, in a printed report, etc.) that needs to translate the attribute value ‘201312010800-0800′.

It of course would not be able to display “Los Angeles” – because -0800 could represent any geographical location where the time was 8 hours before UTC.

It probably could safely assume “PST” because that is almost the only practically used time-zone name that is 8 hours ahead of UTC. But if the time indicated was 3 hours ahead of UTC, that might be the time-zone in Nairobi, Baghdad, or Minsk.

So, the translation from human readable time-zone… to the time-zone format representation in CDA… back to human-readable form… is unlikely to result in the human-readable time-zone display that was present at the start.

Daylight Savings Time
Moreover, when considering Daylight Savings Time, absent a date, the time 0830-0700 might be 8:30 am in California with Daylight Savings Time in the summer or 8:30am Mountain Time in the winter.

Even if the date is present, the logic required to correctly select the time-zone based on the ±ZZzz in the timestamp format is non-trivial. Different time-zones switch into and out of Daylight Savings Time on different days – and in many time-zones the dates of those changes were at different historical times.

Rendering CDA with a Stylesheet
The software used to render a CDA document in human-readable format can potentially use various software language functions and libraries to assist with this translation from “UTC offset” to “time-zone display name”.

However, when using XML Stylesheets to render a CDA document – which is the most common rendering mechanism used for CDA today, the translation is especially challenging. The cda.xsl XML Stylesheet that is included in the HL7 CDA downloadable package of materials, does a very simplistic mapping of UTC offsets to displayed time-zone names. So, for example, the UTC offset -0800 is always translated to PST – even in the summer months when it would correctly be MDT (Mountain Daylight Time).

Other CDA PRO Know Articles Referenced In This Article

Aug 6, 2014|Dates, Times, & Schedules|

The Plan of Care section template

Section Templates
The article What is a CDA Template?, introduces the template concept in CDA. In particular, C-CDA section templates define the rules for sections of the structured body in C-CDA documents. Each section template begins at the XML XPath: /ClinicalDocument/component/structuredBody/component/section.

Section templates are particularly important in the context of MU2. As explained in the article Does MU2 define C-CDA document templates?, the MU2 document types provide CDA Header requirements and guide to which C-CDA section templates are optional or required in the CDA body.

In this article we’ll look at the Plan of Care section template in C-CDA.

The Plan of Care Section Template
The Plan of Care section template is described in the C-CDA specification (more formally, the C-CDA implementation guide, as follows:

The Plan of Care section contains data that defines pending orders, interventions, encounters, services, and procedures for the patient. It is limited to prospective, unfulfilled, or incomplete orders and requests only… All active, incomplete, or pending orders, appointments, referrals, procedures, services, or any other pending event of clinical significance to the current care of the patient should be listed unless constrained due to privacy issues. The plan may also contain information about ongoing care of the patient and information regarding goals and clinical reminders. Clinical reminders are placed here to provide prompts for disease prevention and management, patient safety, and health-care quality improvements, including widely accepted performance measures. The plan may also indicate that patient education will be provided.

Entry Templates Within the Plan of Care Section Template
Within the Plan of Care section template, all of the entry templates are optional (and there can be more than one of each). These optional entry templates include:

  • Instructions: A template for patient instructions that contains unstructured text with the instructions.
  • Plan of Care Activity Act: An entry template that defines a generic act clinical act statement (refer to The act element, for additional information).
  • Plan of Care Activity Encounter: An entry template that defines a generic encounter clinical act statement (refer to The encounter element, for additional information).
  • Plan of Care Activity Observation: An entry template that defines a generic observation clinical act statement (refer to The observation element, for additional information).
  • Plan of Care Activity Procedure: An entry template that defines a generic procedure clinical act statement (refer to The procedure element, for additional information).
  • Plan of Care Activity Substance Administration: An entry template that defines a generic substanceAdministration clinical act statement (refer to The substanceAdministration element, for additional information).
  • Plan of Care Activity Supply: An entry template that defines a generic supply clinical act statement.

Essentially, then, the Plan of Care section template may optionally contain patient instructions and/or any clinical act statements to represent planned clinical acts.

The moodCode attribute of the clinical act statements contained with the Plan of Care section template, generally have the value “INT” (intended for the future) or one of its variants such as “RQO” (a request or […]

Jul 25, 2014|C-CDA Templates|

Why two document OIDs in a C-CDA CCD?

The most common type of C-CDA document is the CCD (Continuity of Care Document). Refer to the article What is a CCD and what is its role in MU?, for an overview of the CCD document, its evolution, and its role in Meaningful Use Stage Two (MU2).

In a C-CDA CCD document, compliance with two document-level templates is generally asserted via two instances of the ClinicalDocument/templateId element.

Why Two ClinicalDocument/templateId Elements?
In a C-CDA CCD document, one of these two templateId elements asserts compliance to the C-CDA US Realm Header template that is required of every C-CDA document. The OID that is assigned to the root attribute of this templateId element is 2.16.840.1.113883.

The other of these two templateId elements asserts compliance to the CCD document template. The OID that is assigned to the root attribute of this templateId element is 2.16.840.1.113883.

Use of C-CDA CCD in MU2
MU2 does not required the use of a CCD document. In fact, MU2 does not require that any specific C-CDA document template be declared. It is sufficient in MU2 to declare compliance with the C-CDA US Realm Header template, alone. However, it is a good practice to always declare a C-CDA document template (to be a proper C-CDA document, compliance with at least one C-CDA document template is required, even though MU2 waives this requirement).

In most MU2 required scenarios and associated document types, the most fitting C-CDA document template to use is the CCD. Thus, the use of a C-CDA CCD document (with its two ClinicalDocument/templateId elements, as described above) is very common in an MU2 context as well.

Note, however, that asserting compliance with (and complying to the requirements of) the C-CDA CCD document template is NOT sufficient to meet MU2 requirements (refer to the article referenced above: What is a CCD and what is its role in MU?, for additional information).

Two Document-Level Template OIDs Can Be Confusing
For those starting out with C-CDA documents, the presence of two ClinicalDocument/templateId elements can be confusing. Which is the correct template ID for this type of document?

It is actually almost always the case in a C-CDA document (again, with the exception of the MU2 context that doesn’t require it) that there are two ClinicalDocument/templateId elements – one to assert overall C-CDA compliance (more specifically, compliance with the C-CDA US Realm Header template) and one to assert compliance to a specific C-CDA document template.

CDA in general (and, thus, C-CDA specifically) supports the declaration of multiple templateId elements at any level of the CDA XML hierarchy where the templateId element is used – at the document, section, and entry level. Refer to The templateId element, for additional information.

Other CDA PRO Know Articles Referenced In This Article

Jul 17, 2014|Overall XML Syntax, The Basics|