Domain Information Model & Interface Definition Language Jeff Plourde CIMIT / MGH / QMDI 4/15/13DRAFT1

Outline Introduction DIM Refresher DIM  IDL – Potential Problems – Potential (Extreme) Implementations – Mitigating Factors – Hybrid Implementation Sourceforge Collaboration 4/15/13DRAFT2

Introduction Scope High Level Goals References Background Interface Definition Language 4/15/13DRAFT3

Scope For this discussion – Include the “nouns” Data elements that will require representation data “schema” or “model” Define primitives and build them into complex types – Exclude the encoding Data model might be encoded in many different ways (XML, DDS Common Data Representation, binary, etc) – Exclude the “verbs” Specific messages and their semantics we will defer Is this possible? Are some requirements of the data model derived from the communication architecture? 4/15/13DRAFT4

High Level Goals 1.Code generation in C++ and Java – Especially for static analysis 2.Encoding Agnostic 3.Communication Agnostic – Considering Pub/Sub Comm. Architecture Based – Use DIM to “maximum extent” 5.Please suggest additions 4/15/13DRAFT5

References IEEE Domain Information Model – html html Philips Data Export Interface Programming Guide – 0eEE/edit?usp=sharing 0eEE/edit?usp=sharing DocBox prototype IDL definitions – HhRZWM/edit?usp=sharing HhRZWM/edit?usp=sharing RTI Connext - Core Libraries and Utilities User’s Manual - Version 5.0 – mNXc/edit?usp=sharing mNXc/edit?usp=sharing 4/15/13DRAFT6

References OMG IDL Specification OMG CORBAmed? – now defunct, any references? HL7+OMG=HSSP – Healthcare Services Specification Program – IHE – Technical Framework for Patient Care Device – – Draeger ICE Prototype – – PHD – /etc – Signove Antidote Please suggest more! 4/15/13DRAFT7

Background QMDI Project Concept, System, and Architecture Review “The IEEE DIM will be re-used to the maximum extent possible. Those definitions of data elements are both valid and widely adopted. Re-using the DIM will enhance adoption by manufacturers. QMDI has identified, and will identify more additions to the IEEE DIM necessary to achieve QMDI project goals.” QMDI Year 3 Architecture “Fundamental encoding of data for both platforms will be derived from the standard. We will find a common way to express data encoding that can be shared in both platforms. The current candidate under consideration for the common expression of data encoding is Interface Definition Language (IDL).” 4/15/13DRAFT8

Why ? Credible Domain Information Model – Extending this work eases adoption Our data model must be at least as functional – Omissions and additions should be documented Nomenclature – Utilizing the nomenclature avoids (or perhaps delays) maintaining our own – NIST Rosetta Terminology Mapping Management Service NIST Rosetta Terminology Mapping Management Service 4/15/13DRAFT9

Why Interface Definition Language? Abstract definition of data types Simplifies data structures … more concise definition Can be common among ICE platforms that are otherwise quite different Numerous code generators already exist for integrating IDL defined data types IDL is a natural way to express data types used in DDS middleware IDL is usable in AADL modeling Please suggest more! 4/15/13DRAFT10

11073 DIM Refresher Primitives Object Classes Objects – Medical Package Numeric Object 4/15/13DRAFT11

Primitives §7.1.2 defines primitives using ASN.1 notation Mapping of these types to IDL is straightforward 4/15/13DRAFT12

Primitives Further compound types are defined This mapping is also fairly obvious. Although the “efficiency” of things like BCD encoding is debatable. 4/15/13DRAFT13

Object Classes Clause 7 - Object classes are specified by – attributes – behavior – notifications Organized into packages – Here we will focus on the medical package Follow an inheritance model – Attributes, behaviors, and notifications are inherited by descendant classes 4/15/13DRAFT14

Objects – Medical Package §7.3 defines objects in the medical package Next slide highlights inheritance structure 4/15/13DRAFT15

4/15/13DRAFT16 Top §7.2 Numeric Metric Virtual Medical Object Top

Numeric Object Numeric Metric Virtual Medical Object Top Begin by examining attributes of a Numeric 4/15/13DRAFT17

Numeric Object Numeric Metric Virtual Medical Object Top 4/15/13DRAFT18

Numeric Object 5 Mandatory Attributes 32 Optional Attributes 2 Conditional Attributes Many Attributes (38) Most Optional (32) Attribute data types are all value types Numeric Metric Virtual Medical Object Top 4/15/13DRAFT19

Attribute Groups 4/15/13DRAFT20

DIM Data Schema The organizational structure of fields (primitives) Impart some meaning to those primitives (short of nomenclature) We can borrow some terms from the relational database world. Please suggest any superior (or more general) terminology 4/15/13DRAFT21

DIM Data Schema Borrowed Terms – Normalized Similar data are gathered and relationships established to other dissimilar data – Denormalized Related data are gathered regardless of their similarity. * I’d like to focus on these characteristics. Data normalization is a rich subject and I’m not asserting that all the characteristics of normalized data apply here. 4/15/13DRAFT22

DIM Data Schema Denormalized – Objects are defined as buckets of (mostly optional) attributes – efficient and flexible (pro) – premature optimization (con) – not amenable to static analysis (con) RDBMS Equivalent Schema 4/15/13DRAFT23

DIM  IDL Potential Problems 4 inter-related themes predominate – Optionality a priori specification of field optionality – Nullity expression of absence at runtime – Polymorphism Heterogeneous lists of AttributeValueAssertions cannot be modeled in IDL – Granular Updates IDL types are published as a whole 4/15/13DRAFT24

Potential Implementations “Extreme” Cases 1.fully denormalized 2.denormalized but prescriptive 3.fully normalized 4.sparse types 4/15/13DRAFT25

DIM  IDL (1) A literal mapping of the denormalized DIM to IDL – Solves all core problems – Does not utilize the expressive power of IDL 4/15/13DRAFT26

DIM  IDL (2) Denormalized & Prescriptive Dissimilar data grouped into a common structure based on relationship Core Problems No way to express “optionality” of fields a priori No way to express absence (nullity) at runtime No granular updates 4/15/13DRAFT27

DIM  IDL (3) Normalized & Prescriptive Similar data grouped Relationships defined How? Where are these maintained? Core Problems declared optionality would be delegated perhaps to a device model Nullity can be achieved by the absence of a an attribute for a particular object_id Polymorphism still an issue Updates can be granular to specific fields 4/15/13DRAFT28

DIM  IDL (4) Sparse Types – Types defined only at runtime with the DynamicData API – No code generation from common IDL – Key implementation difference is the transfer of “member ids” to allow position-agnostic transfer of data fields. – Refer to section of RTI_CoreLibrariesAndUtilities_UsersManual.pdf 4/15/13DRAFT29

Proposed IDL DRAFT Tracy Rausch 3/25/2012 4/15/13DRAFT30

IDL Strategy Overview Utilize OMG IDL as the data types Utilizes Components of has the IDL Structures Subset of IDL Structures will be: – Static – Dynamic – Observed Value 4/15/13DRAFT31

Example: Medical Package IEEE Object Metric.Numeric Metric.Numeric.Static Metric.Numeric.Dynamic Metric.Numberic.Metric Observed Value Metric.Sample Array.Time-SA Metric.Sample Array.Distribution-SA Metric.Sample Array.RealTime-SA Metric.Enumeration Metric.Complex Metric PM-Store.PM-Segment 4/15/13DRAFT32

Next Steps Provide Draft IDL of Numeric and Sample Array-RT Provide Draft of the IDL Structures Review Period Create Examples Implement on various platforms 4/15/13DRAFT33

Mitigating Factors Optionality – For was a practical decision – Mandatory fields are preferred Stereotyping – devices that implement differing options effectively become new devices and may require special handling A device that opts out of providing data is not useful to an ICE … where apps are written expecting those data from devices of that class. 4/15/13DRAFT34

Mitigating Factors Nullity – Similar to optionality a device must emit all the data expressed in its device model to be useful – If sensor data is unavailable that is itself data that should be communicated affirmatively by the presence of an indicator and not via the absence of data 4/15/13DRAFT35

Mitigating Factors Polymorphism – Demanded primarily by AttributeValueAssertion and external nomenclature references. We believe the data emitted by the device should be fully described by its device model. This type of alternation is not desirable… especially where all alternatives are not known to the receiving entity. 4/15/13DRAFT36

Mitigating Factors Granular Updates – Attribute Groups Static – these data will be published once … perhaps as a component of the device model itself Dynamic – these data can be published together at a moderate frequency Observed Value – each observation type should be published at an independent rate as a function of sampling rate 4/15/13DRAFT37

A Hybrid Model types described denormalized and prescriptively. Grouped together for publication based upon their attribute group All data will be pre-specified and mandatory. 4/15/13DRAFT38

nddsjava nddsjava-bin nddsjava-rt rtiddsgen- resource rtiddsgen ICE_IC01 Infrastructure Community x73-idl x73-idl-rti-dds oridion- capnostream simulator x73-prototype Proposed Project Structure 4/15/13DRAFT39

Proposed Project Descriptions ComponentDescription nddsjavaRTI JNI Bindings nddsjava-binRTI shared objects for many platforms nddsjava-rtMDPnP deployment shortcut for RTI DDS rtiddsgenRTI Code Generator rtiddsgen- resource Resources for RTI Code Generator x73-idlIDL definitions for IEEE types x73-idl-rti-ddsJava types built from IDL defs for RTI DDS oridion- capnostream Device protocol implementation simulatorSoftware device implementation x73-prototypeExperimentation with emitting device data with x73-idl types using RTI DDS Collaborating Groups can utilize IDL at any level (with or without RTI DDS) 4/15/13DRAFT40