# Presentation: 120634

## Integrating the Healthcare Enterprise, IEEE 11073 and NISTMedical Device CommunicationTest Effort1 May 2007

## Medical Device Test EffortNIST Team Members

**John Garguilo** (_[john.garguilo@nist.gov](mailto:john.garguilo@nist.gov)__,     _
- 301-975-5248)
**Sandra Martinez** (_[sandra.martinez@nist.gov](mailto:sandra.martinez@nist.gov)__, _
- 301-975-3579)
- Rick Rivello (_[richard.rivello@nist.gov](mailto:richard.rivello@nist.gov)__,    _
- 301-975-3519)
- Maria Cherkaoui (_[maria.cherkaoui@nist.gov](mailto:maria.cherkaoui@nist.gov)__ _
- Guest Researcher)
- Richard Theimer (_[richard.theimer@nist.gov](mailto:richard.theimer@nist.gov)_
- CENTECH Group, Inc.,  Contractor)

## Meeting Goals

- NIST Test Tools
*ICSGenerator* Update
- Capabilities and Enhancements (since January WG meeting...)
*ValidatePDU*
- Next Steps...
- High-level IEEE x73/IHE-PCD test focus areas
- NIST 11073 DIM XSchema (PAR)
- Status,  Enhancements, Characteristics, Approach
- PAR Project Plan
- Next Steps...
- DIM Open Issues and Status
**http://www.nist.gov/medicaldevices**

## NIST’s ICSGenerator and XSchema 

**NIST’s *****ICSGenerator *****and***** XSchema***

**Notes:**
Primary Capabilities of ICSGenerator
Implementation Conformance Statements
Device Profile (XML)
HL7 OBX Segments
Compare Device ICSs
Device UML Diagram

## ICSGenerator Capabilities

- Generates Implementation Conformance Statements (ICSs)
- Required in conformance section of DIM x73 document
- Ensures common format for ICS generation
- Builds Device Profile (XML)
- Generates an electronic (XML) version of device data model based strictly on the IEEE x73 DIM
- Includes private or manufacturer-specific extensions
- Provides validation against DIM Schema
- A device data model generated using this tool can be validated against an updated version of the DIM XSchema
- Provides high level semantic interoperability
- Ensures correct containment relationship and terminology at the object class and related attribute, notification, and behavior level
- Compare Device ICSs
- Device ICSs **comparison** capability aids in identifying potential interoperability issues
- Generates HL7 OBX Segments
- Generates Device UML Diagram

## ICSGenerator Enhancements(since last WG meetings [San Diego, January 07])

- Added “Polling Mode” Application Profiling capability
- Added “ICS Project” capability
- Save by project (associated ICSs, XML, and other related files)
- Open (prior saved) projects
- Value/Data type association
- Created a DIM data type library
- Added value input dialog
- Allows entry of a value(s) of a particular attribute based on the attribute data type
- Mapped observation values to HL7 OBX segments
- OBX-2, OBX-3, OBX-4, OBX-5, OBX-6, OBX-7
- Updated *ICSGenerator* code to compile and run under Java 1.5
- Updated Users Guide to include latest *ICSGenerator* changes
**http://www.nist.gov/medicaldevices**

**Notes:**
Added Capability to describe a device in XML based on the polling mode application profile.

Enter a value(s) of a particular attribute based on the attribute data type.

## ValidatePDU                         (Based on 11073 DIM Schema)

*ValidatePDU*                         (Based on 11073 DIM Schema)

_***ValidatePDU***_
- Provides a basic syntax and structure check for a set of captured messages (APDUs).
- Provides low level semantic check (associates Term Code to attribute ID)
- Future Enhancements (next several months) w/ ICSGenerator
- Extending ValidatePDU to validate message semantics (content):
- Check attribution (mandatory, supported, attribute information (handle, term code, etc.)
- Value ranges for the appropriate attributes.
- Check if MOC behaviors and notifications are supported as specified in the profile.
- Check MOC information (term code, handle, etc.) and hierarchy.
- Check if services are supported by attributes as specified in the profile.
- (e.g., the validation would fail for “get” attribute (such as numeric observed value) which was not defined by user (ICSGenerator) as part of supported profile)

**Notes:**
Since the ICSGenerator generates service ICSs the ValidatePDU tool can validate against the supported services
(e.g., get attribute (such as numeric observed value) which was not defined by user as part of supported profile, the validation would fail)

##  IHE-PCD Year 2 Profile ProposalPCD-Real Time Plug-n-Play

- Validate APDUs against Standard
- Determine if APDUs meets device profile (defined using *ICSGenerator)*

## NIST x73 Medical Device TestingYear 2 of IHE-PCD Cycle

*ValidatePDU*
**(APDU Syntax and **
**Semantic Validation)**

*ICSGenerator*

- MDER2XER
- Decode MDER
- Encode XER

- Asn.1Translator
- (XML ->Java)

- X73 ASN.1 lib
- (Java)

- X73
- ASN.1

- X73
- APDU

- Validation
- Report

- Device Profile
- (XML)

- XML
- Schema

- APDU
- (XML)

- From ??

- ASN2XSD

**Notes:**
Given an X73 APDU, NIST can:
Validate APDUs against Standard
Determine if APDUs meets device profile (defined using ICSGenerator)

APDU message is encoded into XER using NIST MDER2XER tool.
Validate APDU message through ValidatePDU to check for syntax and structure 
Data types are well defined and structurally correct
Performs low level semantic validation at the attribute id level
Validating attribute-id (term codes) against  attribute values at the data type level
Validation performed in both polling mode and baseline profile type devices
It does NOT check for high level message semantics (content)
ValidatePDU + ICSGenerator
High level message (APDU) semantic validation against the Device profile (generated by ICSGenerator)
(e.g., mandatory attributes, containment relationship, services, etc.)

## X73 Medical Device Testing

- APDU message is encoded into XER using NIST MDER2XER tool.
- Validate APDU message through *ValidatePDU* to check for syntax and structure
- Data types are well defined and structurally correct
- Performs low level semantic validation at the attribute id level
- Validating attribute-id (term codes) against  attribute values at the data type level
- Validation performed in both polling mode and baseline profile type devices
- It does _**NOT**_ check for high level message semantics
*ValidatePDU* + *ICSGenerator*
- High level message (APDU) semantic validation against the Device profile (generated by *ICSGenerator*)
- (e.g., mandatory attributes, containment relationship, services, etc.)

## NIST x73 Medical Device TestingPotential Future Enhancements (beyond year 2)

*ICSGenerator*

- Device Profile
- (XML)

- X73 TestGenerator

## ISO/IEEE 11073 
Medical Device Communications

DIM XSchema
(Part 10202)

April/May 2007
Sandra Martinez, NIST

- Medical Device Communications
**DIM XSchema**
**(Part 1020**_***2***_**)**
**April/May 2007**
**Sandra Martinez, NIST**

## Outline

**Background**
**Status/Enhancements**
**DIM Schema Characteristics**
**Approach**
**Project Plan**
**Next Steps**

## XML representation of the X73 Data Information Model (DIM) including:
Common data types
DIM object definition (MOC, attributes, behaviour and notification)
Object Inheritance 
Containment Relationship
ICS Tables
Service Model

- XML representation of the X73 Data Information Model (DIM) including:
- Common data types
- DIM object definition (MOC, attributes, behaviour and notification)
- Object Inheritance
- Containment Relationship
- ICS Tables
- Service Model

## 
Added capability to associate attributes values with data types
Developed Polling Mode schema using MOC definitions from MOC_Defs.xsd
Created components to define Composite_Single_Bed_MDS 
Modularized DIM Schema to make it more manageable and accessible
DIM.xsd 
DIM_Values.xsd 
DIM_Data_Types.xsd
MOC_Defs.xsd 
MOC_Attr_Behav_Notif.xsd

- Added capability to associate attributes values with data types
- Developed Polling Mode schema using MOC definitions from MOC_Defs.xsd
- Created components to define Composite_Single_Bed_MDS
- Modularized DIM Schema to make it more manageable and accessible
- DIM.xsd
- DIM_Values.xsd
- DIM_Data_Types.xsd
- MOC_Defs.xsd
- MOC_Attr_Behav_Notif.xsd

## 
Optimized Schematron rules in DIM.xsd

Applied XML Schema best practices for optimization purposes in different areas of the DIM.xsd
XML Schema best practices: http://www.xfront.com/BestPracticesHomepage.html

- Optimized Schematron rules in DIM.xsd
- Applied XML Schema best practices for optimization purposes in different areas of the DIM.xsd
- XML Schema best practices: http://www.xfront.com/BestPracticesHomepage.html

## DIM XML Schema Architecture

## Component Definition General Approach
Namespaces: All DIM Schemas share same targetNamespace
Versioning: Version attribute in schema element
Expressing Constraints: Schematron Rules added to:
Solve co-occurrence constraints (cardinality) on MOC elements
Solve the ASN2XSD mapping of ASN.1 “ANY DEFINED BY” 
Object Inheritance: 
Existing approach: Re-defines inherited attributes in object definitions
New approach:  use the “group model” grouping elements with the <choice> unbounded compositor and applying Schematron to recover the uniqueness property of the elements (DIM attributes)

**Component Definition General Approach**
**Namespaces:** All DIM Schemas share same targetNamespace
**Versioning: **Version attribute in schema element
**Expressing Constraints: **Schematron Rules added to:
- Solve co-occurrence constraints (cardinality) on MOC elements
- Solve the ASN2XSD mapping of ASN.1 “ANY DEFINED BY”
**Object Inheritance: **
**Existing approach:** Re-defines inherited attributes in object definitions
**New approach:**  use the “group model” grouping elements with the <choice> unbounded compositor and applying Schematron to recover the uniqueness property of the elements (DIM attributes)

**Notes:**
These are several of the  characteristics of the DIM Schema which were not discussed at the January WG HL7 IEEE meeting.

## Venetian Blind Design 
Used to define most of the components
 In this approach we utilize named type definitions (simple or complex) on a global level  instead of element declarations 
Advantages:
Maximize reuse of schema components,
Maximize namespace hiding (Element declaration nested within types),
Coupled components (generates a set of components which are interconnected).

- Venetian Blind Design
- Used to define most of the components
-  In this approach we utilize **named type definitions (simple or complex) on a global level**  instead of element declarations
- Advantages:
- Maximize reuse of schema components,
- Maximize namespace hiding (Element declaration nested within types),
- Coupled components (generates a set of components which are interconnected).

## DIM XSchema ApproachNamespaces

- Separating the schemas into several schema files raised the issue of Namespace approach
- DIM XSchemas are conceptually related  they should share same targetNamespace
- Alternatives for implementing targetNamespace:
- Homogeneous design approach
- Chameleon design approach

**Notes:**
Every time we deal with XML Schemas we must address the namespace issue to avoid naming conflicts and maintain the identity of the schema.

## DIM XSchema ApproachNamespaces (cont.)

- Homogeneous Namespace Design – give all schemas the same targetNamespace:
- When all schemas are conceptually related
- When schemas have no name conflicts (No need to identify in the instance documents the origin or each element/attribute).
- Chameleon Namespace Design – give the “main” schema a targetNamespace and give no targetNamespace to the “supporting” schemas
- Included Schemas such as MOCDefs.xsd  have no use  by themselves unless they are part of another Schema such as DIM.xsd.
- Selected Approach: Homogeneous Namespace Design
- Maintains Schema identity
- Avoid name conflicts when imported to another schema

## XML Schema does not capture all DIM constraints
Alternatives:
Supplement with another Schema Language.
Schematron, TREX, RELAX, SOX, XDR ...
Write code to express additional constraints
Java, Perl, C++, etc.
Express additional constraints with an XSLT/XPath  Stylesheet

- XML Schema does not capture all DIM constraints
- Alternatives:
- Supplement with another Schema Language.
**Schematron**, TREX, RELAX, SOX, XDR ...
- Write code to express additional constraints
- Java, Perl, C++, etc.
- Express additional constraints with an XSLT/XPath  Stylesheet

**Notes:**
Because the XML schema can not address possible constraints, supplemental schema languages or traditional languages or stylesheets are used.

## Selected approach: Schematron

Schematron rules are embedded within the XML schema
Easy to learn and use
Supports the expression of DIM schema constrains; No need for additional schema languages
Schematron will be supported as long as there are XSL processors. The same can’t not be said about the other schema languages
Uses XML technologies - no need to go though the compiling, linking, and executing effort.
Is in the process of becoming an ISO Standard.

- Selected approach: **Schematron**
- Schematron rules are embedded within the XML schema
- Easy to learn and use
- Supports the expression of DIM schema constrains; No need for additional schema languages
- Schematron will be supported as long as there are XSL processors. The same can’t not be said about the other schema languages
- Uses XML technologies - no need to go though the compiling, linking, and executing effort.
- Is in the process of becoming an ISO Standard.

## Schematron Rules added to:

Solve co-occurrence constraints (cardinality) on MOC elements
<all> compositor was the choice but it does not allow elements (MOC) with unbounded cardinality.
<sequence> compositor was not used to avoid adding an order constraint not defined in the standard.
<choice> unbounded compositor + schematron is the solution that  allows unbounded elements in elements with variable cardinality and does not imposed an order.

Solve the ASN2XSD mapping of ASN.1 “ANY DEFINED BY ” 
 An “objsys:OpenType”  was defined allowing any component to be defined instead of any component defined by the specified type.
<sch:report test="attribute-id=2305 and name(*[2]/*)!='LimitSpecList'">The attribute-id is 2305 therefore the first child of attribute-value must be LimitSpecList NOT <name path="*[2]/*"/></sch:report>

- Schematron Rules added to:
- Solve co-occurrence constraints (cardinality) on MOC elements
**<all> compositor was the choice but it **does not allow elements (MOC) with unbounded cardinality.
- <sequence> compositor was not used to avoid adding an order constraint not defined in the standard.
**<choice> unbounded compositor + schematron is the solution that  **allows unbounded elements in elements with variable cardinality and does not imposed an order.
- Solve the ASN2XSD mapping of ASN.1 “ANY DEFINED BY ”
-  An “objsys:OpenType”  was defined allowing any component to be defined instead of any component defined by the specified type.
- <sch:report test="attribute-id=2305 and name(*[2]/*)!='LimitSpecList'">The attribute-id is 2305 therefore the first child of attribute-value must be LimitSpecList NOT <name path="*[2]/*"/></sch:report>

## DIM XSchema ApproachVersioning

- Alternatives:
- Create a schema version attribute on the root element.
- 	<xsd:element name="DIM">
- 	... <xsd:attribute name=“**version**" type="xsd:string"/> ...
- Change the Schema's Target Namespace
- Use the version attribute in schema element.
- 	<xsd:schema targetNamespace="http://www.nist.gov/x73DIM" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sch="http://www.ascc.net/xml/schematron" xmlns="http://www.nist.gov/x73DIM" elementFormDefault="qualified“ **version=“1.0**”>
- Selected approach: Version attribute in schema element
- Use change history to record changes.
- Make new and previous versions of the schema available
- Advantage: XML Instance documents would not have to change.
- The XML parser ignores the version attribute, therefore it is not an enforceable constraint

## Current approach: 
Re-defines inherited attributes in object definitions.
Example :
	<xsd:complexType name="VMD_Attribute_InfoType">
		<xsd:annotation>
			<xsd:documentation>This complex type defines attribute information for VMD</xsd:documentation>
		</xsd:annotation>
		<xsd:all>
			<xsd:element name="VMD-Status" type="VMD-Status_Type"/>
			<xsd:element name="VMD-Model" type="VMD-Model_Type" minOccurs="0"/>
			<xsd:element name="Instance-Number" type="VMD_Instance-Number_Type" minOccurs="0"/>
			<xsd:element name="Production-Specification" type="VMD_Production-Specification_Type" minOccurs="0"/>
			<xsd:element name="Compatibility-Id" type="Compatibility-Id_Type" minOccurs="0"/>
			<xsd:element name="Parameter-Group" type="VMD_Parameter-Group_Type" minOccurs="0"/>
			<xsd:element name="Position" type="Position_Type" minOccurs="0"/>
			<xsd:element name="Operating-Hours" type="Operating-Hours_Type" minOccurs="0"/>
			<xsd:element name="Operation-Cycles" type="Operation-Cycles_Type" minOccurs="0"/>
			<xsd:element name="Measurement-Principle" type="VMD_Measurement-Principle_Type" minOccurs="0"/>
			<xsd:element name="Locale" type="Locale_Type" minOccurs="0"/>
			<xsd:element name="Type" type="Vmo_Type_Type"/>
			<xsd:element name="Handle" type="Vmo_Handle_Type"/>
			<xsd:element name="Label-String" type="Vmo_Label-String_Type" minOccurs="0"/>
			<xsd:element name="Class" type="Top_Class_Type"/>
			<xsd:element name="Name-Binding" type="Top_Name-Binding_Type"/>
			<xsd:element ref="Private-Attributes" minOccurs="0"/>
		</xsd:all>
	</xsd:complexType>

**Current approach: **
- Re-defines inherited attributes in object definitions.
- Example :
**	****<xsd:complexType name="VMD_Attribute_InfoType">**
**	****	****<xsd:annotation>**
**	****	****	****<xsd:documentation>This complex type defines attribute information for VMD</xsd:documentation>**
**	****	****</xsd:annotation>**
**	****	****<xsd:all>**
**	****	****	****<xsd:element name="VMD-Status" type="VMD-Status_Type"/>**
**	****	****	****<xsd:element name="VMD-Model" type="VMD-Model_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Instance-Number" type="VMD_Instance-Number_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Production-Specification" type="VMD_Production-Specification_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Compatibility-Id" type="Compatibility-Id_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Parameter-Group" type="VMD_Parameter-Group_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Position" type="Position_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Operating-Hours" type="Operating-Hours_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Operation-Cycles" type="Operation-Cycles_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Measurement-Principle" type="VMD_Measurement-Principle_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Locale" type="Locale_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Type" type="Vmo_Type_Type"/>**
**	****	****	****<xsd:element name="Handle" type="Vmo_Handle_Type"/>**
**	****	****	****<xsd:element name="Label-String" type="Vmo_Label-String_Type" minOccurs="0"/>**
**	****	****	****<xsd:element name="Class" type="Top_Class_Type"/>**
**	****	****	****<xsd:element name="Name-Binding" type="Top_Name-Binding_Type"/>**
**	****	****	****<xsd:element ref="Private-Attributes" minOccurs="0"/>**
**	****	****</xsd:all>**
**	****</xsd:complexType>**

## XML Schema alternatives:
“Derivation by extension” – consists of a complex type extending another complex type using the <xsd:extension> element
To implement,  we must use the <sequence> compositor which imposes an order in the elements 
	 not a requirement in the standard
	 difficult to maintain by an application such ICSGenerator

Using “group models” for  grouping elements with:
“<sequence> compositor”  which imposes an order
OR
“<choice> unbounded compositor” which disables the uniqueness property of each element.

New Approach:  
“Group Model” used for grouping elements with the <choice> unbounded compositor (from above)
Apply Schematron to recover the uniqueness property of the elements (DIM attributes)

**XML Schema alternatives:**
- “Derivation by extension” – consists of a complex type extending another complex type using the <xsd:extension> element
- To implement,  we must use the <sequence> compositor which imposes an order in the elements
- 	 not a requirement in the standard
- 	 difficult to maintain by an application such ICSGenerator
- Using “group models” for  grouping elements with:
- “<sequence> compositor”  which imposes an order
- OR
- “<choice> unbounded compositor” which disables the uniqueness property of each element.
**New Approach:**
- “Group Model” used for grouping elements with the <choice> unbounded compositor (from above)
- Apply Schematron to recover the uniqueness property of the elements (DIM attributes)

## Project Plan

## DIM XSchema Project Plan

- PAR Project Plan
- Create PAR
- Create Project Plan (Draft V1.0)
- Submit Project Plan to NESCOM
- NESCOM Acceptance
- "Minor Revision (prior to Cologne, Germany F2F Meeting)"
- Present V0.1 of Plan (Apr/May 07 Meetings)
- Update Plan V0.1
- Review and Accept Plan V1.0
- "Present, Review, Update Plan (Sept 07 Meeting)"
- "Present, Review, Update Plan (Jan 08 Meeting)"
- "Present, Review, Update Plan (May 08 Meeting)"
- IEEE Approval and/or Balloting Cycle
- F2F Meetings (~3x per year)
- Recycle Ballot 1 (If Necessary) Each 14 Days
- Recirculation Ballot (As Needed)
- Development of IEEE 11073 DIM Schema document
- Develop Initial, Second, and Final Drafts

## DIM XSchema Project Plan (cont.)

- Requirements Gathering
- Object definitions (textual and UML representation)
- Service Model
- Common data types
- Implementation Conformance Statements (ICS)
- Nomenclature
- Identify Schema Best Practices and Approach for Implementation
- Identify approach for object inheritance
- Identify approach for content  model extensibility
- Mapping Requirements to Schema
- UML Model
- Object containment relationship
- Object Inheritance
- Cardinality
- Encapsulation
- Textual Definitions
- Manage Object Class Definitions
- Attribute Definitions
- Attribute Groups
- Behavior Definition
- Notification Definition
- Private Extensions

## DIM XSchema Project Plan (cont.)

- ASN.1 Common Data Types
- Map ASN.1 to Schema using ASN2XSD Tool
- Revise 11073-10201 DIM document to identify invalid ASN.1
- Identify inconsistencies discovered in code development (ValidatePDU Tool)
- Re-map valid ASN.1 to schema
- Proceeding ASN.1 fix
- Include common data types schema to associate attribute values to corresponding data types
- Service Model
- ICS Tables
- Implementation, Validation and Testing
- XML instance file
- Schematron rules
- Schema validation
- Schematron validation
- XML/DIM schema validation through ICSGenerator
- Maintenance
- Determine Future Needs

## Review and Agree upon Project Plan
Formalize a Breakout Working Group
How do you get involved?
Numbers needed to meet voting and balloting requirements for IEEE balloting
To Update plan 
To accomplish tasks in project plan
To Establish review process for DIM XSchema
Document format using IEEE Guidelines
Document template (style sheet)
Some clauses/parts should follow the DIM
Develop first draft
Establish review process

- Review and Agree upon Project Plan
- Formalize a Breakout Working Group
- How do you get involved?
- Numbers needed to meet voting and balloting requirements for IEEE balloting
- To Update plan
- To accomplish tasks in project plan
- To Establish review process for DIM XSchema
- Document format using IEEE Guidelines
- Document template (style sheet)
- Some clauses/parts should follow the DIM
- Develop first draft
- Establish review process

## Questions?
Break-Out Session?

Thank YOU!

- Questions?
- Break-Out Session?
- Thank YOU!