[Category: Attributes; Original Post: 19-Feb-14]The
operator attribute is used with
XML elements that represent times in a
CDA document. It is used to enable multiple XML elements that represent
dates and time to be "combined" together to form more complex time periods.
For an overview on how this is done and some examples, refer to the article
Combining time intervals in CDA.
Principles for Using The operator AttributeIt only makes sense to use the
operator attribute when there are multiple adjacent XML elements for representing dates/times that support the
operator attribute.
The most prevalent element that has this characteristic is the
effectiveTime element located under
substanceAdministration.
The
useablePeriod element, which is a sub-element of
addr,
telecom, and
reference elements, also supports the use of the
operator attribute (refer to the articles
The addr element and
The telecom element, for additional information).
Dates and times are used in CDA in many contexts. In contexts such as a medication administration schedule (often termed a "SIG"), there is a need to express time periods such as "twice a day for the next seven days". These kinds of time periods can only be expressed using multiple
effectiveTime elements.
So, the
operator attribute is used in these contexts where more than one
effectiveTime element is needed to represent the time period.
Set OperationsThe first of the sequence of
effectiveTime elements does not take the
operator attribute.
Starting with the second one in the sequence, however, all the other
effectiveTime elements must use
operator to indicate how to combine this
effectiveTime elements with those that came before it.
The two primary ways to combine time periods are "union" and "intersection".
In a "union" of two time periods, the resulting time period includes all of the time in each of them. So, for example, the union of "Feb 2, 2014" and "Feb 3, 2014" is the two days "Feb 2 and Feb 3, 2014".
In an "intersection" of two time periods, the resulting time period includes only the time periods that are in both of them. So, for example, the intersection of "every Sunday" and "the month of February 2014" is the four Sundays in February 2014.
Both union and intersection are set operations. Each time period expression can be thought of as representing a "set of instances and ranges of time". It's helpful to think of dates and times as numbers (they are usually represented this way internally in software systems). From a formal mathematical standpoint the "combining" of two time periods is a "set operation" on the sets of times represented in each time period expression.
Although it's not very intuitive, the value
"A" is assigned to the
operator attribute for the "intersection" operation and the value
"I" is assigned to the
operator attribute for the "union" operation.
The
operator attribute is present in every
effectiveTime element (or
useablePeriod - although
effectiveTime will be used as the example in remainder of this article, as it is more prevalent) where it is applicable. It defaults to a value of
"I" (union). Of course, when you have only one
effectiveTime element on its own, there is no meaning to the
operator attribute. The
operator can be left off if the default "union" operation is desired - but it adds clarity to call it out explicitly.
Other OperationsThe
operator attribute can take on additional values in addition to
"A" and
"I". The value
"E" is assigned to the
operator attribute to indicate that the second time period should be excluded from the first. Using this "exclusion" operator to combine "the month of February 2013" with the day "Feb 15, 2013" would result in a time period that includes every day in February 2013 except for Feb 15, 2013.
There are two additional values that the
operator attribute can take (
"H" and
"P") to express more complex set operations called "convex hull" and "periodic hull", but these are not commonly used and are outside the scope of this article.
Cumulative OperationsThe set operations (the "combinations") of the time periods represented in the sequence of
effectiveTime elements is cumulative. You start with the time period of the first
effectiveTime element. That is then combined with the time period of the second
effectiveTime element based on the
operator attribute contained within that second
effectiveTime element. The result is now a "combined" time period (for example, a union or intersection of those first two
effectiveTime elements).
If there is a third
effectiveTime element in the sequence, its
operator attribute indicates how it should be combined with the result of the combination of the first two
effectiveTime elements.
So, if we take the following example:
Note: refer to the articles The effectiveTime element and What is the role of the xsi:type attribute?, for more explanations about the XML syntax of the sample above.The interpretation of this example is as follows: take the entire day of Feb 15, 2012. Combine that via a "union" operator with the entire day of Feb 22, 2012. The results is the two days Feb 15 and 22, 2012. Now combine that with the repeating periodic interval "every 8 hours" (of every day, forever) using an "intersection" operator. The result is "every 8 hours on Feb 15 and on Feb 22, 2012".
From a set operations perspective, we are effectively placing parentheses around the first two expressions, then around that pair and the third. We could express this as:
(("Feb 15, 2012" UNION "Feb 22, 2012") INTERSECT "every 8 hours")This is the model for how all the expressions will be combined: (((...(A ? B) ? C) ? D)...).
Additional InformationRefer to the articles
Combining time intervals in CDA and
Using “combined type” time intervals, for additional information about how the
operator attribute is used.
More Complex OperationsThe article
Using "Parenthetical Expressions" in SIGs, discusses special constructs (the
xsi:type assigned value of
"SPXR_TS" and the
comp sub-element) which can be used to express more complex time period expressions by defining "paranthetical sub-expressions" that can be combined in ways other than the default behavior just described. However, that article also notes that as a practical matter, the use of this construct is not recommended in
C-CDA documents.
Other CDA PRO Know Articles Referenced In This Article
