General timing specification is a primitive data type that is conceptually an arbirary set of points in time. It is any combination of (1) a point in time, and (2) an interval of time. This includes uncertain points and intervals of time. At this point, values are defined in terms of a literal expression syntax. Regardless how comples the literal definition of a GTS value is, it will always decompose into an ordered sequence of points or intervals of time.
ExtRef: The specification of the semantics and literal expression is found elsewhere. Should it, can it be included in the RIM description field?
Rationale: For a more complete discussion of the problem and approach to arbitrary time schedules, refer to the attached material
- HL7 v3 Data Type Specification, version 0.95, p. 146 ff
- The Unified2 Service Action Model Proposal (USAMP-II) revision 2.3, part A, section 2.5.3, p. A-34 ff.
- Open letter to Mead Walker, about the rationale of the current literal approach to GTS.
To summarize: the v3 data type specification document includes a semantic model of all time schedules that is based on the following ideas:
- Singular time intervals as continuous sets of time points, specified through low and high boundary or width (in case no boundary is known.)
- Periodic time intervals as discontinuous sets of time points, specified through a period duration and a time offset (phase) interval.
- The set-operations intersection and union on such continuous and discontinuous sets of time to form arbitrary sets of time.
- The reduction of any arbitrary set of time into an outer bound interval and a sequence of occurrence intervals, no matter how complex the definition of this arbitrary set is.
- The use of probability distribution data types to account for the uncertainty in scheduling and time orders, or, in other words, to allow "fuzzy" constraining of time sets.
- Time can be specified in terms absolute even flow of time, or aligned to calendars
Since the mathematical approach to the timing specification may not be very well appreciated among the HL7 users and implementers, and since calendars add to a considerable inherent complexity, we assumed that hiding the semantic model behind a literal expression syntax may be easier to handle for most technical committees and demo implementers at this time. Therefore we encapsulated the entire semantics of the arbitrary sets of time behind a literal expression syntax.
We do offer the semantic model in the HL7 v3 data type specification, but we do not force it upon users and implementers in general.