Data Types R 2 What s Changed Grahame Grieve

Data Types, R 2: What’s Changed? Grahame Grieve, Health Intersections Pty Ltd October 8 2010

DT R 2: What’s changed? 1. New semantics in data types 2. Fixing mistakes/issues in the R 1 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 • R 1: SET, BAG, LIST - SET: A value that contains other distinct values in no particular order • R 2: 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 to COLL • 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 original. Text 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 etc. • Best guess date should still be filled out – or a null. Flavor provided

New Properties HXIT. control. Act. Id. Ref refer to the system event that changed a property ED. description alternative text description of the media ED. translations into a different language or a different media. Type CD. value. Set(Version) Record value set which was used CD. Source + CD. coding. Rationale 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 • R 1 Name uses had “Legal”, “License”, “Official Registry” • No one was sure quite what this meant • Unclear how to represent names from various cultures • R 2: • 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 • R 1: HL 7 provided syntax, code was a simple symbol • Qualifiers for post-coordination • Qualifiers only “qualify code” • This didn’t match many real world use cases • R 2: code is symbol or expression • Expressions only used where code system defines them • HL 7 may define expression syntaxes • Qualifiers are removed • Not backwards compatible • Need custom logic per code system to interconvert

2. Fixes/Issues from R 1 • • • Rework GTS completely CD translations (no nested) & display. Name EIVL code CD. display. Name Missing Narrative definition Document ANY flavor. Id & update. Mode

GTS • R 1: GTS definition is obtuse • GTS implementation in XML is worse, and completely different – cause of much implementer angst • R 2: GTS becomes QSET. 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 • R 1 confused: root code is the chronological first, and the one required for translation- Not always true • Nested translations are difficult to handle • R 2: Any code can be root code • If dependency tracing is required, use source property • coding. Rationale helps specify why root/translation is provided • Definition of original. Text clarified- only one per concept cluster • Not backwards compatible • Need to understand specification carefully

EIVL. code • R 1: • XML ITS confused about whether EIVL. code is attribute or element • R 2: • Clarifies this: event is an attribute • Backwards compatible with the schema, not the spec

CD. display. Name • R 1: • CD. display. Name simplified to an XML attribute (xsd: string) • But some users need language • R 2: • CD. display. Name 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 • R 2 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: flavor. Id and update. Mode • These were implied in R 1, but not document • Have been documented explicitly in R 2

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 • R 1: Abstract & XML ITS form • Left most users hanging: where’s the computational view? • R 2: 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 • R 1: • XML defined BXIT_ and SLIST short form • Inclusive attribute on IVL. low and IVL. high • Collections always a series of elements (not element for the collection) • R 2: • BXIT & SLIST short form removed • Inclusive attribute moved to IVL. low. Closed and high. Closed • Since COLL specialises any, a full form with an element of it’s own (it’s own null. Flavor, etc) with item elements inside • Not backwards compatible • BXIT & SLIST need to represented long hand • IVL – move inclusive (low/high)Closed

Collections with Elements • R 1 • Only defined non-element form • Collection types simplified to UML equivalent • A problem on Observation. value sometimes • R 2: • 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 R 1: • Map SET/BAG/LIST to multiple elements • ITS Structures R 2: • 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 • R 1: • Mixins (HXIT, PPD, UVP) implemented using complicated schema generation tools so they only appear where desired • Object implementations put them everywhere anyway • R 2: • 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 • R 1: ED content model a problem • (text /base 64 or XML) • cannot be described by schema, published schema wrong) • Difficult to work with (whitespace issues) & Generated Code odd (mixed content) • R 2: 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 V 3 • 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. display. Name • 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 R 1. 1 • Change that is not backwards compatible is a problem • XML ITS R 1. 1 was produced to allow adoption of the R 2 features that are possible without breaking change • Can be adopted by trading partner agreement

What’s in ITS R 1. 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. display. Name • 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, R 2: What’s Changed? • Many changes • Fix mistakes • Add Features • Work with other communities • Make it easier for implementers • Email: grahameg@gmail. com