data types, r2: what’s changed? grahame grieve, health intersections pty ltd october 8 2010
TRANSCRIPT
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: [email protected]