11073-10201 Domain Information Model & Interface Definition Language

1. 11073-10201 Domain Information Model & Interface Definition Language Jeff Plourde CIMIT / MGH / QMDI DRAFT

2. Outline • Introduction • 11073 DIM Refresher • DIM  IDL • Potential Problems • Potential (Extreme) Implementations • Mitigating Factors • Hybrid Implementation • Sourceforge Collaboration DRAFT

3. Introduction • Scope • High Level Goals • References • Background • 11073 • Interface Definition Language DRAFT

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? DRAFT

5. High Level Goals • Code generation in C++ and Java • Especially for static analysis • Encoding Agnostic • Communication Agnostic • Considering Pub/Sub Comm. Architecture • 11073 Based • Use 11073 DIM to “maximum extent” • Please suggest additions DRAFT

6. References • IEEE 11073-10201-2004 Domain Information Model • http://standards.ieee.org/findstds/standard/11073-10201-2004.html • Philips Data Export Interface Programming Guide • https://docs.google.com/file/d/0B9FgXIL2kBW4ZnBUVlMwWGp0eEE/edit?usp=sharing • DocBox prototype IDL definitions • https://docs.google.com/folder/d/0B9FgXIL2kBW4LW96WUl1UHhRZWM/edit?usp=sharing • RTI Connext- Core Libraries and Utilities User’s Manual - Version 5.0 • https://docs.google.com/file/d/0B9FgXIL2kBW4M0NjWVdjV0ZmNXc/edit?usp=sharing DRAFT

7. References • OMG IDL Specification • OMG CORBAmed? • now defunct, any references? • HL7+OMG=HSSP • Healthcare Services Specification Program • 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/upload/IHE_PCD_TF_Vol3.pdf • Draeger ICE Prototype • https://docs.google.com/folder/d/0BwRwV00DEHVbRC1XTGQ0VGNRU00/edit?usp=sharing • 11073 – PHD • 11073-20601/etc • Signove Antidote • Please suggest more! DRAFT

8. Background QMDI ProjectConcept, 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).” DRAFT

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 DRAFT

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! DRAFT

11. 11073 DIM Refresher • Primitives • Object Classes • Objects – Medical Package • Numeric Object DRAFT

12. Primitives • 11073-10201 §7.1.2 defines primitives using ASN.1 notation Mapping of these types to IDL is straightforward DRAFT

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

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 DRAFT

15. Objects – Medical Package • 11073-10201 §7.3 defines objects in the medical package • Next slide highlights inheritance structure DRAFT

16. Top §7.2 Top Virtual Medical Object Metric Numeric DRAFT

17. Numeric Object Begin by examining attributes of a Numeric Top Virtual Medical Object Metric Numeric DRAFT

18. Numeric Object Top Virtual Medical Object Metric Numeric DRAFT

19. Numeric Object • Many Attributes (38) • Most Optional (32) • Attribute data types are all value types Top 5 Mandatory Attributes 32 Optional Attributes 2 Conditional Attributes Virtual Medical Object Metric Numeric DRAFT

20. Attribute Groups DRAFT

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 DRAFT

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

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 DRAFT

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 AttributeValueAssertionscannot be modeled in IDL • Granular Updates • IDL types are published as a whole DRAFT

25. Potential Implementations • “Extreme” Cases • fully denormalized • denormalized but prescriptive • fully normalized • sparse types DRAFT

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 DRAFT

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 DRAFT

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 DRAFT

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 DRAFT

30. Proposed IDL DRAFT Tracy Rausch 3/25/2012 DRAFT

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 DRAFT

32. Example: Medical Package DRAFT

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 DRAFT

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

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 DRAFT

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

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 DRAFT

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

39. Proposed Project Structure http://arvi.mgh.harvard.edu:8080/artifactory/webapp/browserepo.html ICE_IC01 Infrastructure Community nddsjava nddsjava-bin x73-idl rtiddsgen-resource nddsjava-rt rtiddsgen oridion-capnostream x73-idl-rti-dds simulator x73-prototype DRAFT

40. Proposed Project Descriptions Collaborating Groups can utilize IDL at any level (with or without RTI DDS) DRAFT