DCM datatypes

Data Type use in DCMs

Clinical data has some features which are not often surfaced in the existing CMETs and templates. With DCMs, the added precision and detail of the specification allows for greater flexibility.

On area where this is needed is defining which Data Type can replace another in a model.

Substitution in HL7 Detailed Clinical Models (DCMs)

One of the principles of Object Oriented Programming and/or Design (OOP/OOD) is the ability of a subtype of given class to used in place of the class (subtype polymorphism). This implies a given heuristic for sustainability. However, in the case of the ISO 21090 Healthcare Datatypes/HL7 v3 Data Types Abstract Specification r2 additional detail is needed, as there are times when a type, particularly a templated class (either a collection or mixin) could also be a consideration, in order to meet real-world expectations.

The following list includes those data types used in DCMs, as well as explicit indication of which data types are substitutable. This effectively defines a localized TYPE.implies(TYPE that) truth table. I.e. anytime a model uses a given data type (e.g. AD) the implied types are valid substitutions, unless explicitly prohibited. (e.g. any time a DCM uses an AD, it will be understood that a HIST<AD> is an equally valid data type in an instance.)

For example, it is often useful to know when the last time someone took a given medication. In the outpatient setting, documentation of the exact time (TS) isn't common, so the real answer is most likely an uncertain range (which may have a high degree of precision of the actual time values, e.g. if someone's alarm wakes them at 6 a.m. every morning and they start work at 8:30 a.m., they can be quite certain that the medication they took with breakfast was at some point between 6 a.m. and 8:30 a.m.

Uncertainty is a routine factor in clinical care, and as such, many attributes should be considered candidates for modeling as one or more uncertain types. In addition, nearly all physical quantity measures have aspects of uncertainty, often thought to be reflected in the number of significant digits. This is not correct--certainty and precision are different components of accuracy.

The Data Types r2 DataType ( BL TYPE.implies(TYPE that)) states that a type implies another if it is a specialization of that type. There are discussions for specific types (e.g. promotion()/demotion()) where information may be lost in substitution. There are cases where a given model may list a type and either accept a more 'simple' case (e.g. a DSET<CD> when only a single CD may be applicable) where non-specialized classes can substituted.

More detailed implementation guidance will need to follow. Implementations need to be able to process the following types in an ITS and adapt to.

For example, the indication for a procedure (Observation.value [1..1] CD) is the health concern which a given procedure is intened to diagnosis, stage and/or treat. While this is most often a single coded value, it may be that the exact diagnosis isn't known at the time and the best answer is a differential diagnosis, in the format form of a NPPD. Similiarly, it should be expected that uncertainity is an often unexpressed but ubiquitous factor, which may need explicit representation at any given time.

The following data types, and the indicated substitutable type, are allowed in DCMs:

Data Types and required substitutions for DCMs

AD AD --> HIST<AD> ADXP BL BL --> BN CD CD --> NPPD<CD> CD --> UVP<CD> CD --> SC CO CO --> IVL<CO> CO --> URG<CO> CO --> CD COMP COMP --> CEQ CS CS --> CV NOTE: In instances of models (but not of messages) all structural codes (i.e. those attributes with CS datatypes in the RIM) SHALL convey the codeSystem and code. DisplayName and codeSystemName MAY be included as well. This is needed to facilitate automation and validation. DSET<CD> --> CD DSET<CO> --> CO ED.IMAGE Note: DICOM images mediaType of application/dicom ED.SIGNATURE ED.TEXT ED.TEXT --> ST ED.TEXT --> ST.NT ED.TEXT --> ST.SIMPLE EN EN --> HIST<EN> ENXP EXPR EXPR<T> --> T II INT INT --> INT.NONNEG INT --> INT.POS INT.NONNEG --> INT.POS IVL<CO> IVL<CO> --> URG<CO> IVL<PQ> --> URG<PQ> IVL<PQ> --> QSET<PQ> IVL<QTY> IVL<QTY> --> URG<QTY> IVL<TS> IVL<TS> --> IVL.WIDTH IVL<TS> --> PQ.TIME NPPD<CD> NPPD<CO> NPPD<PQ> NPPD<TS> NPPD<REAL> NPPD<T> NPPD<T> --> DSET<UVP<T>> OID ON --> EN PN --> EN PPD<REAL> PPD<PQ> PPD<TS> PQ PQ --> URG<PQ> QSET<PQ> --> PQ QSET<CO> --> CO QSET<TS> --> IVL<TS> QSET<TS> --> PQ.TIME RTO<PQ,IVL<TS>> RTO<PQ,PQ> RTO<PQ,PQ.time> SC SC --> SC.NT SC --> ST.SIMPLE ST ST --> ED.TEXT ST --> ST.NT ST --> ST.SIMPLE ST.NT ST.SIMPLE TEL TEL --> HIST<TEL> TEL --> TEL.EMAIL TEL --> TEL.PHONE TEL --> TEL.URL TS TS --> URG<TS> UID --> OID UID --> UUID URG<REAL> URG<T> --> URG.HIGH<T> URG<T> --> URG.LOW<T> URG<REAL> URG<REAL> --> IVL<REAL> URG<PQ> URG<PQ> --> IVL<PQ> URG<TS> URG<TS> --> IVL<TS> URG<TS> --> TS URG<CO> --> IVL<CO> UUID UVP<CD> UVP<CO> UVP<TS> UVP<PQ>