1 Binding DAMs to HL7 Abstract R2 vs. the ISO For the ARB April 18, 2012 Lisa Schick and Wendy VerHoef, ScenPro

2 Background Guidance for development of LS DAM was to stay aligned with BRIDG Current LS DAM aligned with BRIDG 3.0.2, bound to ISO Actively working on next version of LS DAM to be published mid-May As part of this version want to align to BRIDG 3.1, published Feb 2012 BRIDG 3.1 bound to HL7 Abstract Data Type Release 2 (HL7 ADT R2) LS DAM would need to bind to this data type specification in order to align Lloyd McKenzie (BRIDG SCC) joined a meeting to present the BRIDG SCC reasoning for the change IRWG has generally agreed to make this change, barring different direction from the ARB, with some questions

3 BRIDG Data Type Binding BRIDG 3.1 (Feb 2012) bound to HL7 Abstract Data Types R2 with knowledge of BRIDG BoD BRIDG 2.0 declared binding to ISO spec (June 2008) But not truly 100% “legal” ISO syntax BRIDG 1.x bound to HL7 V3 ADT Spec What motivated the BRIDG SCC to propose move to the HL7 ADT R2? BRIDG really using a hybrid of ISO data types + a few HL7 ADT R2 types because of some limitations imposed by ISO DTs: Ratio (RTO) doesn’t allow specification of the DT of the numerator and denominator as it does in HL7 ADT R2 Uncertain Range is an attribute of the Quantity (QTY) subtypes and can’t be referenced as a DT itself as it can in HL7 ADT R2 Expression is an attribute of the Quantity (QTY) subtypes and can’t be referenced as a DT itself as it can in HL7 ADT R2 BRIDG is not meant to be an implementation model, but rather a domain model, so the abstract data types are more appropriate than the implementable ISO DTs

4 ISO One implementation of HL7 ADT R2 Conforms to HL7 ADT R2, ie., one valid Implementable Technology Specification (ITS) for HL7 ADT R2 of many possible There is an established, clear, automated process to go from HL7 ADT R2 to ISO DT Not truly technology independent, but not specific to one technology Design decisions have been made that make implementation easier for a defined set of technologies [XML and (most) object-oriented technologies] Same decisions may not be best for implementation technology outside of that set Decisions could make implementation in another technology more challenging Decisions cause loss in expressivity in the ISO data types 3 examples from previous slide Goal for the DAM to capture the domain semantics regardless of how those semantics will be implemented Favored technologies will come and go over time Doesn’t seem right to be creating DAMs as technologies (IT) come and go Domain semantics may change too (life sciences), but that is different and speaks to changes in the DAM

5 IRWG Questions What is the impact of binding to the HL7 ADT R2 to implementers? Are we pushing more work down on them by raising the level of abstraction in the data type binding? We don’t want to do anything that will cause barrier to adoption. If want to implement as ISO 21090, it’s available for use (assuming a CBIIT funded implementation or they have license) Commercial adopters of BRIDG who are implementing BRIDG-based solutions have not questioned the change or raised concerns If don’t want to implement ISO 21090, binding the DAM to ISO may be problematic anyway Are there licensing issues with HL7 ADT R2? Spec is publicly available on HL7 site, but, does that really mean anyone can use it? Licensing issues with ISO also, doesn’t seem this can be discriminating factor Is stability of HL7 ADT R2 of concern? Up to this point, no changes have impacted the subset of data types used in BRIDG Seems ISO changes as well, doesn’t seem this can be discriminating factor Questions about whether NCI implementation of ISO up-to-date?

6 IRWG Questions LS DAM team wants to follow-up with analysis on subset of data types used in the LS DAM, to confirm no underlying issues Possibly leverage analysis done by BRIDG SCC or CTR project? Data types used in LS DAM are subset of data types used in BRIDG Don’t suspect there will be issues, but, want to cover all bases Is the decision (whether DAM should be HL7 ADT R2 or ISO 21090) linked to the purpose the DAM fulfills? Purist view that DAM is truly conceptual and technology independent OR can we take some liberties with this definition and build something that is more easily adopted by implementers? We do this when making representational choices for domain semantics Creating a specialization with no distinct attributes or associations in order for the SMEs to find themselves in the model Restricting to a specific set of technologies seems like it might be a different set of concerns

7 IRWG Questions NCI CBIIT direction that information models to be bound to ISO Perhaps guidance can be modified so that implementable models will be bound to the ISO data type specification? Allowing conceptual models to be bound to the HL7 ADT R2 ie., the data type specification to be used is dependent on the level or view the model represents RM-ODP informational view ("concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information") vs. the RM-ODP computational view ("concerned with the functional decomposition of the system into a set of objects")

8 Practical Implications to LS DAM The UML model for the ISO is part of the LS DAM EA project A class defined for each data type Value of “data type” for each LS DAM attribute tied to those classes though this is not conveyed by looking at the model Change value of data type for each attribute to the HL7 ADT R2 type that corresponds to the current ISO type Instead of ISO PQ, use PQ Remove the ISO Data Type package from the LS DAM EA project BRIDG 3.1 does not include a package with the HL7 ADT R2 specification so LS DAM will not either Will be transparent to someone looking at the model

9 Ratio Data Type ISO supports the implementation of any kind of quantity data type in the numerator and denominator in a ratio, but does not allow the specification of which data type should represent the numerator and denominator thus limiting how accurately we can represent the semantic in BRIDG. In HL7 Abstract Data Types R2, RTO is a parameterized data type, so it does allow specification of the data type of numerator and denominator thus supporting semantic accuracy.

10 Uncertain Range Data Type ISO supports the implementation of uncertain range as an attribute of any kind of quantity, but does not allow the specification of that as a data type thus limiting how accurately we can represent the semantic in BRIDG. In HL7 Abstract Data Types R2, uncertain range is a parameterized data type, so it does allow specification of an uncertain range of a specific type of quantity as an actual data type thus supporting semantic accuracy.

11 Expression Data Type ISO supports the implementation of expressions (e.g. formulas*) as an attribute of any kind of Quantity, but does not allow the specification of that as a data type thus limiting how accurately we can represent the semantic in BRIDG. HL7 Abstract Data Types R2 does allow specification of an expression (formula) using a specific kind of quantity as an actual data type thus supporting semantic accuracy. * Expressions allow us to say there’s a formula to evaluate that uses contextual information to derive data, such as determining a dosage based on body mass index (BMI) or body surface area.