1. 11073-10201 Domain Information Model & Interface Definition Language Jeff Plourde CIMIT / MGH / QMDI 4/15/13DRAFT1

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

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

4. 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

5. 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 4.11073 Based – Use 11073 DIM to “maximum extent” 5.Please suggest additions 4/15/13DRAFT5

6. References IEEE 11073-10201-2004 Domain Information Model – http://standards.ieee.org/findstds/standard/11073-10201- 2004.html http://standards.ieee.org/findstds/standard/11073-10201- 2004.html Philips Data Export Interface Programming Guide – https://docs.google.com/file/d/0B9FgXIL2kBW4ZnBUVlMwWGp 0eEE/edit?usp=sharing https://docs.google.com/file/d/0B9FgXIL2kBW4ZnBUVlMwWGp 0eEE/edit?usp=sharing DocBox prototype IDL definitions – https://docs.google.com/folder/d/0B9FgXIL2kBW4LW96WUl1U HhRZWM/edit?usp=sharing https://docs.google.com/folder/d/0B9FgXIL2kBW4LW96WUl1U HhRZWM/edit?usp=sharing RTI Connext - Core Libraries and Utilities User’s Manual - Version 5.0 – https://docs.google.com/file/d/0B9FgXIL2kBW4M0NjWVdjV0Z mNXc/edit?usp=sharing https://docs.google.com/file/d/0B9FgXIL2kBW4M0NjWVdjV0Z mNXc/edit?usp=sharing 4/15/13DRAFT6

7. References OMG IDL Specification OMG CORBAmed? – now defunct, any references? HL7+OMG=HSSP – Healthcare Services Specification Program – http://hssp.wikispaces.com http://hssp.wikispaces.com IHE – Technical Framework for Patient Care Device – http://www.ihe.net/Technical_Framework/index.cfm#pcd http://www.ihe.net/Technical_Framework/index.cfm#pcd – http://www.ihe.net/Technical_Framework/upload/IHE_PCD_TF_Vol3.pdf http://www.ihe.net/Technical_Framework/upload/IHE_PCD_TF_Vol3.pdf Draeger ICE Prototype – https://docs.google.com/folder/d/0BwRwV00DEHVbRC1XTGQ0VGNRU00/edit?usp=sharing https://docs.google.com/folder/d/0BwRwV00DEHVbRC1XTGQ0VGNRU00/edit?usp=sharing 11073 – PHD – 11073-20601/etc – Signove Antidote Please suggest more! 4/15/13DRAFT7

8. Background QMDI Project Concept, System, and Architecture Review “The IEEE 11073 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 11073 DIM necessary to achieve QMDI project goals.” QMDI Year 3 Architecture “Fundamental encoding of data for both platforms will be derived from the 11073 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

9. Why 11073-10201? 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 11073-10101 nomenclature avoids (or perhaps delays) maintaining our own – NIST Rosetta Terminology Mapping Management Service NIST Rosetta Terminology Mapping Management Service 4/15/13DRAFT9

10. 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

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

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

13. 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

14. 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

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

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

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

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

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

20. Attribute Groups 4/15/13DRAFT20

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

22. 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

23. 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

24. 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

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

26. 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

27. 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

28. 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

29. 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 3.8.3 of RTI_CoreLibrariesAndUtilities_UsersManual.pdf 4/15/13DRAFT29

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

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

32. Example: Medical Package IEEE 11073 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

33. 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

34. Mitigating Factors Optionality – For 11073 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

35. 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

36. 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

37. Mitigating Factors Granular Updates – 11073 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

38. A Hybrid Model 11073 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

39. 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 http://arvi.mgh.harvard.edu:8080/artifactory/webapp/browserepo.html 4/15/13DRAFT39

40. 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 11073-10201 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