Data Types, R2:
What’s Changed?
Grahame Grieve, Health Intersections Pty Ltd
October 8 2010
DT R2: What’s changed?
1. New semantics in data types
2. Fixing mistakes/issues in the R1
definitions (semantics and
implementation)
3. Changes to the XML: consistency
for automated processing
requirements
4. ISO harmonization issues
1. New Semantics
• COLL/DSET changes
• Original Text on QTY/QSET
• New properties on HXIT, ED, CD, II, IVL,
PIVL
• New Mixins EXPR & URG
• Flavors
• Rework Name Part Types and Qualifiers
• Change CD.code and remove CD.qualifiers
New Semantics: Collection
• R1: SET, BAG, LIST
- SET: A value that contains other distinct values in no
particular order
• R2: QSET <- SET -> DSET <- COLL -> BAG, LIST
• SET: A value that contains distinct values in no
particular order
• COLL: A collection of values which can be enumerated
using an iterator
• DSET: An unordered collection of values that contains
discrete distinct values
• QSET: An unordered set of distinct values which are
quantities
New Semantics: Collection
• Split apart mathematical sets (QSET) and
enumerated sets (DSET)
• Use QSET for quantities
• Use DSET for everything else
• Introduce COLL – Collection – in RIM
• Change attributes from BAG<T> to COLL<T>
• COLL is abstract, so either design or runtime
must use DSET, BAG, or LIST
• This had an unfortunate consequence
considered later
New Semantics: Original Text
• Add originalText to QTY and QSET
• This lets the instance carry something like
“Around about Easter” along with
20110427 as the actual date
• Can be used with PQ, TS, IVL<PQ> etc.
• Best guess date should still be filled out –
or a nullFlavor provided
New Properties
HXIT.controlActIdRef
refer to the system event that changed a
property
ED.description
alternative text description of the media
ED.translation
translations into a different language or a
different mediaType
CD.valueSet(Version)
Record value set which was used
CD.Source +
CD.codingRationale
For tracking which cd comes from which in
translations
II.scope
Mark the scope of the identifier
CO.value
Actual value for coded ordinal
II.reliability
Mark how well an identifier is known
IVL.any
some particular value that lies within the
interval
PIVL.frequency
Inverse of frequency
New Mixins
• EXPR
• used to specify an expression that can be used
to derive the actual value of T given
information taken from the context of use
• (e.g. Prescriptions by body weight)
• URG
• the value comes from a range of possible
values of an ordered base data type
• Usually for prescriptions – take between 3 and
5 tablets/day
Flavors
• CE, CV, BN, PN, ON, TN: These types didn’t define any
new properties or semantics, only constrained existing
usage
• We changed these to flavors: sets of reusable constraints
• Model refers to flavor, but schema uses underlying class
• Anyone can use flavors
• You don’t have to know about flavors
• just use the underlying classes (CD, BL, EN)
• But do conform to their rules
• Lots of new flavors added
Rework Name Parts
• R1 Name uses had “Legal”, “License”, “Official Registry”
• No one was sure quite what this meant
• Unclear how to represent names from various cultures
• R2:
• Name uses: “Customary” and “Official Registry Name”
• Switch Prefix / Suffix to qualifiers & Title to part types
• Add new uses & qualifiers for misc. purposes
• Not backwards compatible
• New code systems for underlying code
• Need code to map from one to the other
CD.Code / qualifier
• R1: HL7 provided syntax, code was a simple symbol
• Qualifiers for post-coordination
• Qualifiers only “qualify code”
• This didn’t match many real world use cases
• R2: code is symbol or expression
• Expressions only used where code system defines
them
• HL7 may define expression syntaxes
• Qualifiers are removed
• Not backwards compatible
• Need custom logic per code system to interconvert
2. Fixes/Issues from R1
•
•
•
•
•
•
Rework GTS completely
CD translations (no nested) & displayName
EIVL code
CD.displayName
Missing Narrative definition
Document ANY flavorId & updateMode
GTS
• R1: GTS definition is obtuse
• GTS implementation in XML is worse, and
completely different – cause of much
implementer angst
• R2: GTS becomes QSET<TS>. Expression tree and
building blocks directly in UML
• Implementation matches abstract exactly
• Not backwards compatible
• Need code to interconvert forms
• Can’t round trip to identical XML
CD.translations
• R1 confused: root code is the chronological first, and the
one required for translation- Not always true
• Nested translations are difficult to handle
• R2: Any code can be root code
• If dependency tracing is required, use source property
• codingRationale helps specify why root/translation is
provided
• Definition of originalText clarified- only one per
concept cluster
• Not backwards compatible
• Need to understand specification carefully
EIVL.code
• R1:
• XML ITS confused about whether
EIVL.code is attribute or element
• R2:
• Clarifies this: event is an attribute
• Backwards compatible with the schema,
not the spec
CD.displayName
• R1:
• CD.displayName simplified to an XML attribute
(xsd:string)
• But some users need language
• R2:
• CD.displayName changed to an XML element
(ST)
• Has a language element
• Not backwards compatible
• attribute  element
Missing Definitions
• Narrative
• CDA Narrative schema was provided, but never
defined or documented anywhere
• R2 defines the narrative form in UML and XML,
and documents it properly
• In a separate package from the rest of the data
types
• Infrastructure Root: flavorId and updateMode
• These were implied in R1, but not document
• Have been documented explicitly in R2
3. XML Consistency
•
•
•
•
•
Completely rework XML definition framework
Modify Set/Bag/Interval attributes around
Define Mixins in base classes
Rework ED & ST content handling
Completely rework GTS form to match abstract form directly
Rework XML definition
• R1: Abstract & XML ITS form
• Left most users hanging: where’s the computational
view?
• R2: Define a PIM
• UML – computational view of the data types
• XML is an algorithmic transform of UML
• Except in narrative, uses standard web services
techniques
• Simpler better Types for implementation
• Validation moved out of schema into OCL/schematron
• Not backwards compatible (attributes  elements)
Set \ List \ Bag \ IVL
• R1:
• XML defined BXIT_<T> and SLIST short form
• Inclusive attribute on IVL.low and IVL.high
• Collections always a series of elements (not element for the
collection)
• R2:
• BXIT & SLIST short form removed
• Inclusive attribute moved to IVL.lowClosed and highClosed
• Since COLL specialises any, a full form with an element of it’s own
(it’s own nullFlavor, etc) with item elements inside
• Not backwards compatible
• BXIT & SLIST need to represented long hand
• IVL – move inclusive  (low/high)Closed
Collections with Elements
• R1
• Only defined non-element form
• Collection types simplified to UML equivalent
• A problem on Observation.value sometimes
• R2:
• Also defines element form
• Provides a choice to Structures ITS that didn’t
previously exist
• Doesn’t use element form internally (continues to
simplify collections to UML equivalent)
• Expected use: Observation.value (not backward
compatible)
Collections with Elements
• ITS Structures R1:
• Map SET/BAG/LIST to multiple elements
• ITS Structures R2:
• RIM attribute types changed to COLL
• Must specify type of Collection
• Use full element form instead of simple form
to get xsi:type for element
• Not Backward Compatible: Painful &
Controversial
Mixins
• R1:
• Mixins (HXIT, PPD, UVP) implemented using
complicated schema generation tools so they only
appear where desired
• Object implementations put them everywhere anyway
• R2:
• Mixins (HXIT, PPD, URG, EXPR, UVP) defined directly in
schema on base class
• Appear everywhere, but constrained by
OCL/schematron where not appropriate
• Not backwards compatible
• Order of elements changes slightly
ED / ST Content
• R1: ED content model a problem
• (text /base64 or XML)
• cannot be described by schema, published schema wrong)
• Difficult to work with (whitespace issues) & Generated Code odd
(mixed content)
• R2: Content model clarified
• separate text, base 64 and XML into different places
• Schema is simple and accurate
• Generated Code is what is expected
• Easy to work with
• Not backwards compatible
• text  attributes & elements
4. ISO Harmonization
• CD.code / qualifiers change
• SC.code as full CD
• Abstract: SC.code = CV
• ISO: SC.code = CD
• SC.code constrained to CV in V3
• CO as specialization of QTY
• Computational model & XML Changes
Not Backwards Compatible
• Changes to CD.code / qualifier
• Only one too hard for an xslt?
• Changing CD translation rules
• Changes to Name Parts, Use, and qualifiers
• Change to CD.displayName
• Changes for XML consistency
• Changes to Set, List, Bag and Interval (Collection form)
• Reworking GTS completely
• Change to how Mixins are done
• Change to ED content model
XML ITS R1.1
• Change that is not backwards compatible
is a problem
• XML ITS R1.1 was produced to allow
adoption of the R2 features that are
possible without breaking change
• Can be adopted by trading partner
agreement
What’s in ITS R1.1
• Changes to Name Parts, Use, and qualifiers
• Changes to CD.code / qualifier
• Only one too hard for an xslt?
• Changing CD translation rules
• Change to CD.displayName
• Changes for XML consistency
• Changes to Set, List, Bag and Interval (Collection form)
• Reworking GTS completely
• Change to how Mixins are done
• Change to ED content model
Data Types, R2: What’s Changed?
• Many changes
• Fix mistakes
• Add Features
• Work with other communities
• Make it easier for implementers
• Email: grahameg@gmail.com