It’s About Time

Editor’s note: This blog post has been authored by AEGIS’ resident HIE Specifications guru, Joe Lamy (Twitter : @SpecSherpa). It offers a deep dive into a particular corner of the spec world. We are publishing this series as a way to share AEGIS’ subject matter expertise in HIE and hopefully help our colleagues in the industry build better and better health IT solutions for all of us. Enjoy!

 

Exploring clinical time through HL7 C-CDA documents and IHE XDS queries

“I want to see clinically interesting things that happened within a given time frame”. Pretty straightforward, right? Even if what someone thinks is clinically interesting may differ, the basic notion of being interested in a block of time seems simple. Is it?

Let’s consider this question in the following context: an IHE document sharing environment, populated with C-CDA structured documents. This environment is explored in a new white paper[i] I’ve been helping with, produced by the Carequality-CommonWell Joint Document Content Workgroup: “Concise Consolidated CDA: Deploying Encounter Summary CDA Documents with Clinical Notes”. The paper focuses on what it calls “Encounter Summaries” (e.g. Discharge Summary, Progress Note), but also takes a holistic view of providing information about a patient, consisting of encounter summaries and one or more “Patient Summaries” (e.g. CCD). One thing it does is explore the way that time in queries relates to time in the metadata for a document as well in the document itself. It doesn’t try to answer all the questions, specifically for patient summaries, which will be addressed in a future version of the guidance.

This blog post is not intended to be a full review of that paper. What I want to do is examine the role of time with that paper as a backdrop, take the thoughts and guidance all the way through to their conclusions, and see if I can move the ball.

I’ll work from the bottom up, identifying the relevant underlying requirements, looking at the paper’s use cases and recommendations, then finally exploring what is possible and where we might want to go.

This article is the first in a series focusing on CDA and XDS topics touched on by the Carequality-CommonWell Joint Document Content Workgroup:

• Part 1: It’s About Time – Exploring clinical time through HL7 C-CDA documents and IHE XDS queries
• Part 2: Schrödinger’s CDA – Dynamically generating C-CDA Patient and Encounter Summaries

Clinical time across CDA and XDS – The Big Picture

The first thing to recognize is that in order to get at the clinical items we want, there are a few hops to make:

• CDA documents have entries with times
• …which bubble up to overall times in the CDA
• …which should be reflected in IHE XDS metadata about the document
• …which we query on using IHE XDS/XCA mechanisms

We’ll keep this in mind as we deep dive.

Clinical time within HL7 C-CDA and CDA

C-CDA documents are full of time associated information. For example, entries for problems, allergies, results, and encounters have effective times. You can optionally include a section time range (defined in the C-CDA 2.1 Companion Guide), which is recommended by the paper to reflect cases like when the generator has not included all available information in a section, but rather the last 90 days.

We’ll start here: it’s ultimately these items we are interested in, within a given time range.

Two places to record the overall clinical time range

In addition to the entries and section times, CDA gives us two different places in the header to record the overall clinical time range of a document:

• /ClinicalDocument/documentationOf/serviceEvent/effectiveTime[ii]
  • CDA: There can be 0..* serviceEvents, each with 0..1 effectiveTime
  • C-CDA CCD: exactly one serviceEvent with effectiveTime required, covering the entire time range[iii]
  • C-CDA Discharge Summary: no additional constraints
  • C-CDA Progress Note: 0..1 serviceEvents, SHOULD be present. “The serviceEvent/effectiveTime is the time period the note documents”[iv]
• /ClinicalDocument/componentOf/encompassingEncounter/effectiveTime[v]
  • CDA: componentOf is 0..1; if present, encompassingEncounter/effectiveTime must be included
  • C-CDA encounter-type documents (e.g. Discharge Summary, Progress Note): componentOf/encompassingEncounter/effectiveTime required
  • C-CDA CCD: not included[vi]

There are other times in the header (e.g. /ClinicalDocument/effectiveTime, which is the time the document was created), but we aren’t as interested in those for this use case – we want the range in which clinically relevant things happened.

There could be some variations:

• There could be both ranges, and they might not agree exactly.
• There could be multiple instances of documentationOf/serviceEvent.
• There could be some entries (e.g. historical) outside one of these ranges.

But for our purpose, if we just look at the primary date range for each kind of document (e.g. serviceEvent for CCD) that should be good enough.

Clinical time within IHE Document Sharing

IHE ITI XDS: Date related attributes

The IHE Document Sharing Profiles (XDS, XCA, etc.) define what is called “document metadata”, which is high-level information about a clinical document, stored separately from the document itself. It is this metadata that we query on.[vii]

XDS addresses time about a document in the creationTime, serviceStartTime and serviceStopTime XDS attributes on document entries. These are all R2, required if known. For our interest in clinical relevance, we would like to query on serviceStartTime and serviceStopTime. How do these map to the times in the CDA header?

IHE ITI TF Vol 3: section 4.2.3.2.20 defines these as the start and stop times “of the service being documented (clinically significant, but not necessarily when the document was produced or approved)….This may be the same as the encounter time in case the service was delivered during an encounter. Encounter time is not coded in metadata but may be coded within the document.”

Wait – what? If encounter time is not coded in the metadata, how can we query by date range and get back just the encounter documents in that range?

Ok, first, let’s take a step back. This doesn’t sound like a normative XDS-CDA mapping requirement. In fact, no XDS-CDA mapping is required by the Sequoia and CommonWell exchanges, at least not yet. The white paper proposes a partial mapping. Here’s how we got there.

IHE PCC: XDS metadata to CDA content mapping

It turns out that IHE PCC already looked into this and defined such a mapping, in IHE PCC TF Vol 2: section 4.1 Medical Document Binding to XDS, XDM and XDR. Although this mapping is not referenced by Sequoia (or CommonWell?) specs, I think it should be, as it is a missing link between CDA and XDS.

In the table in section 4.1.1, XDSDocumentEntry Metadata, creationTime maps to /ClinicalDocument/effectiveTime, and serviceStartTime and serviceStopTime map to /ClinicalDocument/documentationOf/serviceEvent/effectiveTime low and high, respectively.

Ok, it turns out this is a real roadblock. For an encounter document like Discharge Summary, we aren’t guaranteed to have service times, so there isn’t a surefire way to query by date range and get all documents that fall within that range.

I reached out to Keith Boone for his thoughts. He explained the gap had to do with when the PCC mapping work was done, and suggested the following for populating serviceStartTime and serviceStopTime:

• Use serviceEvent/effectiveTime if present
  • If multiple events, use the earliest effectiveTime/low to the latest effectiveTime/high (in other words, the smallest date range that encompasses all events)
• Else use encompassingEncounter/effectiveTime if present
• Else use effectiveTime of the CDA

The Joint Workgroup, taking advantage of the more constrained C-CDA, was able to collapse this down to a simpler mapping:

• Use serviceEvent/effectiveTime for Patient Summaries
• Use encompassingEncounter/effectiveTime for Encounter Summaries

Date querying within IHE Document Sharing

Date query logic is defined in IHE ITI TF Vol 2a: 3.18.4.1.2.3.3 Date/Time Coding. Each XDS date attribute has two related query parameters so that comparisons may be done, for example:

• Query parameter $XDSDocumentEntryServiceStopTimeFrom matches those document entries where the serviceStopTime is greater than or equal to the parameter
• Query parameter $XDSDocumentEntryServiceStopTimeTo matches those document entries where the serviceStopTime is less than the parameter

Further, if a query parameter is included but the related date is not populated, that parameter should not be used to determine that match.

Note: for brevity’s sake I will use shortened names for the query parameters, e.g. ServiceStopTimeFrom.

Interest in a date range: strict versus loose queries

For our use case, let’s say the date range we are interested in is January 2015. In the diagram below, here’s a common approach to doing date range queries: using the query parameters ServiceStartTimeFrom and ServiceStopTimeTo. Each CDA’s service times are shown by its horizontal position and width, and the CDAs that are matched by the query are shown with “Y”.

What should jump right out at us is that this kind of strict/exclusive query misses a lot of CDAs we are probably interested in. Could we do this a different way? What if we use the other two query parameters for a more loose/inclusive query?

This looks much more like what we want, so these two parameters were the ones we recommended in the white paper.

Periodically querying for new documents

Note, however, that ServiceStartTimeFrom and ServiceStopTimeTo might still be appropriate in other cases. One that has been suggested is where you wish to periodically query a patient using adjacent date ranges, and don’t want to receive the same documents over and over. You could do this by pairing From…To parameters for the same attribute.

For example, basing on serviceStartTime:

You start with Query 1, then later make Query 2, and on and on. CDAs 1, 4, and 7 would be returned in the expected queries – I’ll cover the rest later.

The XDS date logic seems to anticipate this kind of use, as it supports adjacent queries that don’t overlap:

$XDSDocumentEntryServiceStartTimeFrom <= XDSDocumentEntry.serviceStartTime < $XDSDocumentEntryServiceStartTimeTo

This is why CDA 4 that starts exactly on 1/1/2015 would only be returned in Query 2, not both Query 1 and 2.

However, there are some downsides to this approach. Only Query 1 would catch CDA 2, but if you make that query before the document is actually completed and published, then you will never get it. So maybe you lag your queries a bit behind current time. But by how much? You’d have to wait quite some time to get CDA 3.

You could improve things a bit by querying serviceStopTime instead, but even in that case, you could miss updates to documents you had already retrieved. And you would not get an encounter document that is published without an end date, like CDA 5.

I think if you want to do this periodic, non-overlapping querying, your best option is using creationTime. Even that has its issues, as it won’t catch on-demand entries that don’t have a creation time.

But on-demand, now that’s another thing altogether. You’ll have to see part 2 for that.

Endnotes for Further Spec Spelunking

[i] The initial version of the white paper can be found here. A revised version with the date range logic is forthcoming.

[ii] HL7 CDA 2.1: 4.2.3.2 ServiceEvent: Could be used for every act in the document. Useful if non XML body.

[iii] HL7 C-CDA 2.1: 1.1.6.2 documentationOf

[iv] HL7 C-CDA 2.1: 1.1.18.1 documentationOf

[v] HL7 CDA 2.1: 4.2.3.5 EncompassingEncounter: setting within which the acts or service events occurred.

[vi] HL7 C-CDA 2.1 Companion Guide: 4.2.1.3 Encompassing Encounter and Service Events

[vii] The metadata attributes are described in IHE ITI TF Vol 3, section 4, and the queries are defined in IHE ITI TF Vol 2a: section 3.18 (the basic XDS queries) and IHE ITI TF Vol 2b: section 3.38 (XCA queries, based on XDS). By the way, regardless of which version of the IHE ITI Technical Framework you are working with (Sequoia uses 2010), I’d recommend reading the latest version for understanding Document Sharing better. It’s gone through a redocumentation and is much easier to understand, especially Volume 3.