Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Data Types, R2: What’s Changed? Grahame Grieve, Health Intersections Pty Ltd October 8 2010."— Presentation transcript:

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

2 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

3 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

4 New Semantics: Collection R1: SET, BAG, LIST - SET: A value that contains other distinct values in no particular order R2: QSET DSET 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

5 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

6 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 etc. Best guess date should still be filled out – or a nullFlavor provided

7 New Properties HXIT.controlActIdRefrefer to the system event that changed a property ED.descriptionalternative text description of the media ED.translationtranslations 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.scopeMark the scope of the identifier CO.valueActual value for coded ordinal II.reliabilityMark how well an identifier is known IVL.anysome particular value that lies within the interval PIVL.frequencyInverse of frequency

8 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

9 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

10 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

11 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

12 2. Fixes/Issues from R1 Rework GTS completely CD translations (no nested) & displayName EIVL code CD.displayName Missing Narrative definition Document ANY flavorId & updateMode

13 GTS R1: GTS definition is obtuse GTS implementation in XML is worse, and completely different – cause of much implementer angst R2: 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

14 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

15 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

16 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

17 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

18 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

19 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)

20 Set \ List \ Bag \ IVL R1: 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) 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

21 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)

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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


Download ppt "Data Types, R2: What’s Changed? Grahame Grieve, Health Intersections Pty Ltd October 8 2010."

Similar presentations


Ads by Google