Data Types, R2:What’s Changed? Grahame Grieve, Health Intersections Pty LtdOctober 8 2010

DT R2: What’s changed?

1. New semantics in data types2. 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 PropertiesHXIT.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