11073-10201 Domain Information
Model & Interface Definition
Language
Jeff Plourde
CIMIT / MGH / QMDI
4/15/13
DRAFT
1
Outline
• Introduction
• 11073 DIM Refresher
• DIM  IDL
– Potential Problems
– Potential (Extreme) Implementations
– Mitigating Factors
– Hybrid Implementation
• Sourceforge Collaboration
4/15/13
DRAFT
2
Introduction
•
•
•
•
•
•
Scope
High Level Goals
References
Background
11073
Interface Definition Language
4/15/13
DRAFT
3
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/13
DRAFT
4
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/13
DRAFT
5
References
• IEEE 11073-10201-2004 Domain Information Model
– http://standards.ieee.org/findstds/standard/11073-102012004.html
• Philips Data Export Interface Programming Guide
– 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
• RTI Connext - Core Libraries and Utilities User’s Manual Version 5.0
– https://docs.google.com/file/d/0B9FgXIL2kBW4M0NjWVdjV0Z
mNXc/edit?usp=sharing
4/15/13
DRAFT
6
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!
4/15/13
DRAFT
7
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/13
DRAFT
8
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
4/15/13
DRAFT
9
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/13
DRAFT
10
11073 DIM Refresher
•
•
•
•
Primitives
Object Classes
Objects – Medical Package
Numeric Object
4/15/13
DRAFT
11
Primitives
• 11073-10201 §7.1.2 defines primitives using ASN.1 notation
Mapping of these types to IDL
is straightforward
4/15/13
DRAFT
12
Primitives
• Further compound types are defined
This mapping is also fairly obvious. Although the “efficiency” of things like BCD
encoding
is debatable.
4/15/13
DRAFT
13
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/13
DRAFT
14
Objects – Medical Package
• 11073-10201
§7.3 defines
objects in the
medical package
• Next slide
highlights
inheritance
structure
4/15/13
DRAFT
15
Top
Top
§7.2
Virtual
Medical
Object
Metric
Numeric
4/15/13
DRAFT
16
Numeric Object
Begin by examining attributes of a Numeric
Top
Virtual
Medical
Object
Metric
Numeric
4/15/13
DRAFT
17
Numeric Object
Top
Virtual
Medical
Object
Metric
Numeric
4/15/13
DRAFT
18
Numeric Object
Top
• Many Attributes (38)
• Most Optional (32)
• Attribute data types are all
value types
5 Mandatory Attributes
32 Optional Attributes
2 Conditional Attributes
Virtual
Medical
Object
Metric
Numeric
4/15/13
DRAFT
19
Attribute Groups
4/15/13
DRAFT
20
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/13
DRAFT
21
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/13
DRAFT
22
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)
4/15/13
DRAFT
RDBMS Equivalent Schema
23
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/13
DRAFT
24
Potential Implementations
• “Extreme” Cases
1.
2.
3.
4.
4/15/13
fully denormalized
denormalized but prescriptive
fully normalized
sparse types
DRAFT
25
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/13
DRAFT
26
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/13
DRAFT
27
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/13
DRAFT
28
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/13
DRAFT
29
Proposed IDL
DRAFT
Tracy Rausch
3/25/2012
4/15/13
DRAFT
30
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/13
DRAFT
31
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/13
DRAFT
32
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/13
DRAFT
33
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/13
DRAFT
34
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/13
DRAFT
35
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/13
DRAFT
36
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/13
DRAFT
37
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/13
DRAFT
38
Proposed Project Structure
http://arvi.mgh.harvard.edu:8080/artifactory/webapp/browserepo.html
ICE_IC01
Infrastructure
Community
rtiddsgenresource
x73-idl
oridioncapnostream
4/15/13
x73-idl-rti-dds
DRAFT
x73-prototype
nddsjava
nddsjava-bin
nddsjava-rt
rtiddsgen
simulator
39
Proposed Project Descriptions
Component
Description
nddsjava
RTI JNI Bindings
nddsjava-bin
RTI shared objects for many platforms
nddsjava-rt
MDPnP deployment shortcut for RTI DDS
rtiddsgen
RTI Code Generator
rtiddsgenresource
Resources for RTI Code Generator
x73-idl
IDL definitions for IEEE 11073-10201 types
x73-idl-rti-dds Java types built from IDL defs for RTI DDS
oridioncapnostream
Device protocol implementation
simulator
Software device implementation
Collaborating
Groups can
utilize IDL at
any level (with
or without RTI
DDS)
x73-prototype Experimentation with emitting device data with x73-idl types using
RTI DDS
4/15/13
DRAFT
40