# Presentation: 172057

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

## Medical Device Test EffortNIST Team Members

- John **Garguilo** (_[john.garguilo@nist.gov](mailto:john.garguilo@nist.gov)_,
- 301-975-5248)
- Sandra I. **Martinez** (_[sandra.martinez@nist.gov](mailto:sandra.martinez@nist.gov)_,
- 301-975-3579)
**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 Update
*ICSGenerator*
*ValidatePDU *
- NIST 11073 DIM XSchema (PAR)
- PAR Project Plan
- Status,  Enhancements
- Next Steps...
- DIM Open Issues and Status
**http://www.nist.gov/medicaldevices**

**Notes:**
In today’s presentation I will provide with an update of the NIST Test tools including the DIM Schema and some open issues related to the DIM.

## NIST’s ICSGenerator and XSchema 

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

**Notes:**
This diagram is just to re-iterate the capabilities of the ICSGenerator.
As you can see the ICSGenerator:
Generates Implementation Conformance Statements (ICSs) 
Builds Device Profile (XML) 
Provides device profile validation against DIM Schema
Compare Device ICSs 
Device ICSs comparison capability aids in identifying potential interoperability issues
Generates HL7 OBX Segments  (1-7)
Generates Device UML Diagram

## ICSGenerator Enhancements(since last WG meetings [Cologne, April 07])

- Added capability to capture a “Top Level”, “General Interoperability , Baseline Profile, Polling Mode”  ICSs.
- Added capability to select the type of device specialization (**Manager/Agent)** .
- Added capability to id attribute fields as static, fixed or dynamic.

**Notes:**
The ICSGenerator tool was enhanced to add the capability to capture General Interoperability, baseline and polling  ICS’s. This enhancement was done to provide further device specialization following  the requirements for applications profiles in CENT ENV 13735. Also, the ability to specialized a device as an agent or a manager was added to ICSGenerator. A device could be modeled as an agent or a manager implementing either a polling mode or a baseline application profile. 
Therefore, if a user wants to generate a new device profile, he must first  select a  device type (Agent or Manager) and then select the application profile he wants to implement.
The capability to identified attribute field as static or fixed was also added to the tool. This requirement is part of the MOC Attribute ICS table in the DIM.  

## ValidatePDU 2.0 (ValidatePDU 1.0 Re-designed)

**ValidatePDU 1.0:** Performs APDU **syntax/structure** validation using XML.
**ValidatePDU 2.0:** Performs APDU **syntax/structure and semantic** using a MDER Coder.

**ValidatePDU**

**(APDU Syntax and Semantic Validation)**

- Device Profile
- (xml)

- Validation
- Report

- ROSEapdu
- (MDER)

- APDU
- (XER)

- (MDER + XER Coder)

**Notes:**
A new version of ValidatePDU has been developed. This version is basically a re-design of the previous version. The previous version expected and APDU in XER format as input, with the idea of  validating its syntax against an XML Schema. During the process of developing  a MDERCoder and XERCoder application to decode/encode MDER and decode/encode XER, it was realized that validation was performed at parsing time. The XML schema was used to re-validate the ASN.1 library, containing all DIM data type definitions, and vice versa, the schema was also validated. Therefore, we decided to incorporate the MDERCoder into the new version of ValidatePDU, which allows ValidatePDU to process an MDER instead of and  XER. Since the Coder was incorporated into the tool,  ValidatePDU also provides the capability to encode APDUs into XER. The XER generated is intended to be consistent with the standard XER, where applicable.

## APDU

**Notes:**
This a representation of the PDU level that we are addressing in ValidatePDU. We validate starting from ROSE layer all way to the MDIB layer.

## ValidatePDU 2.0  Capabilities

- Validates APDU syntax against X73 DIM specifications and the X73 Application Profiles – Base Standard
- ASN.1 data types syntax.
- Object hierarchy, cardinality, acceptable behaviors, notifications and attributes in compliance with X73 Standards.
- Relationship between ROSE and CMIP data types.
- Validate APDU semantic/content against device profile (object, attribute, behavior, notification and services implementation)
- if a MOC, attribute, behavior and notifications  identified in a message is implemented by the device profile.
- if attributes identified in a message are implemented as part of a MOC in the device profile.
- if the message contains the attribute as required by the device profile (missing or unrecognized attributes).
- if the message contains valid MOC information, such as handle and context-id according to the device profile.
- if the message contains valid attribute information, such as fixed values and value ranges according to the device profile.
- if a behavior identified in a message is supported by the device profile.
- if MOC objects hierarchy complies with device profile specifications.
- if the message contains the MOCs as required by the device profile (missing MOC or  unrecognized MOCs)

**Notes:**
ValidatePDU validates the syntax in the following areas: ASN.1 data types syntax, object definitions and the relationship between ROSE and CMIP data types.
ValidatePDU also validates conformance against a device profile. Semantic validation basically check if : (list information in the  bullets).

## ValidatePDU 2.0  Capabilities

- Decodes MDER PDUs and build ASN.1 object instances.
- Provides an interface to display a parsed message in the following formats:
- XER (in compliance with the standard XER where applicable).
- MDER binary
- Enhanced view (JTree representation)
- Generates Validation Reports.
- Highlight incorrect fields in enhanced view.
- Associates report messages with *Test Assertions*.
**Note:** ValidatePDU 2.0 functionalities are captured in a ValidatePDU Software Requirements Specification document. (Reviewed by some members of the WG)

**Notes:**
Test assertions are basically requirements extracted from the standards, which becomes the basis for validation. 

## Assertions

- <?xml version="1.0" encoding="UTF-8"?>
- <!-- edited with XMLSpy v2007 (http://www.altova.com) by NIST (NIST) -->
- <Reports>
- 	<Report id="0" message="3334" type="syntax">
- 		<Assertion>Message must be confirmed</Assertion>
- 		<ValidMessage>Message type checked</ValidMessage>
- 		<UnvalidMessage>MDS-create-notification must be confirmed</UnvalidMessage>
- 	</Report>
- 	<Report id="1" message="3334" type="syntax">
- 		<Assertion>MOC must be either Simple MDS, Hydra MDS, Composite Single MDS or 		Composite multi Beds MDS</Assertion>
- 		<ValidMessage>MOC checked</ValidMessage>
- 		<UnvalidMessage>MOC is invalid, it should be MDS, Simple MDS, Hydra MDS, Composite Single Bed MDS or Composite multi Beds MDS</UnvalidMessage>
- 	</Report>
- 	...

## ValidatePDU 2.0 Restrictions

- ValidatePDU performs message structure validation on all agents and manager APDU’s message type, but it only applies full validation (semantic and syntax) to the following message types (later versions may incorporate more messages) :
- MDS messages
*MDS::Mds-Create-Notification Event Report *
*MDS::Mds-Create-Notification Event Report *Result
*MDS::Mds-Attribute-Update Event Report*
*MDS::Mds-Attribute-Update Event Result*
- Context Scanner Messages
*CREATE Context Scanner Invoke*
*CREATE Context Scanner Result*
*Context Scanner Object Create Notification Event Reports*
*Context Scanner Object Create Notification Event Report Confirmation*
- Episodic Configurable Scanner Messages
- Episodic Scanner Unbuffered Scan Event Report
- Episodic Scanner Unbuffered  Event Report Confirmation
- Periodic  Scanner Messages
- Periodic Scanner SET Operational-State
- Periodic Scanner SET Operational-State Confirm
- Periodic Scanner Buffered Scan Event Report
- Periodic Scanner Buffered  Event Report Confirmation
- Alert Scanner Messages
- _GET Messages_
- _SET Messages_

**Notes:**
The current version of ValidatePDU only validates this type of  messages. Later versions of the tool will incorporate additional messages.   

## ValidatePDU 2.0 Restrictions (cont.)

- Performs semantic validation at the device profile level (as constrained by the user) only.
- Device profile must be an instance of the NIST DIM Schema.
- Processes only ROSE apdu ASN.1 type encoded in MDER.
- This restriction excludes BER encoded ACSE messages.

**Notes:**
Just list them.
We are in the process of expanding the ASN.1 library to be able to support BER (Basic Encoding Rules) encoding and decoding. 

This version only processes semantic validation against a baseline agent profile. (Enough to validate identified messages)

The tool will be enhanced to add validation against manger/agent polling profiles and manager baseline profiles.

This version is not  validating devices implementing polling mode. Future versions will. Especially when we incorporate other message types.   

## ValidatePDU 2.0

**Notes:**
Message Information:
The message was generated by the Agent issuing a remote operation invoke, the service used was a confirmed Event Report. The notification was sent by the MDS object. 

## ValidatePDU 2.0 (XER view)

**Notes:**
This is the message displayed in XER format.

## ValidatePDU 2.0 Future Enhancements

- Add support for  FastBufScanReport PDUs for waveform reporting
- Add support for behavior type messages.
- Add support for Rose RORJapdu – Remote Operation Error
- Add support for Rose RORLIVapdu – Linked Invoke
- Add semantic validation against polling mode agent/manager device profile.
- Update the Message Information display to include event type and action type.

**Notes:**
 just list them.

ROIVapdu and RORSapdu are supported.

## Plug-n-Play Real Time Profile Test Tool Validation

**Notes:**
This slide shows how our tools fit into the  IHE/PCD Real Time Plug and Play testing process. In this process an agent profile is created using ICSGenerator, which is then used to configure the agent an manager simulators. The interactions between  the simulators are going to be captured using ValidatePDU to generate a validation report.

## 
Quick XSchema Component Review 
Characteristics
Update
Object Inheritance
Project Plan

- Quick XSchema Component Review
- Characteristics
- Update
- Object Inheritance
- Project Plan

**Notes:**
Tied to IEEE standardization process, where Jan will be the lead. We will be supporting the effort. NIST role is to support industry in standard development.

## DIM XML Schema

**Notes:**
As I mentioned in the last working group meeting, the schema was re-compartmentalized to facilitate maintenance and reusability. We added an additional schema to capture the definitions that model manager type devices supporting baseline application profiles.

## 
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 

**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

**Notes:**
This also a re-iteration of the main characteristics of the DIM Schema.

## Implemented new approach for representing  object inheritance.
Previous approach: Re-defines inherited attributes in object definitions.  

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  

Selected approach: “group model” approach to represent object inheritance.

using the “group model” grouping elements with the <choice> unbounded compositor and applying Schematron to recover the uniqueness property of the elements (DIM attributes)

**Implemented new approach for representing  object inheritance.**
**Previous approach:** Re-defines inherited attributes in object definitions.
**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
**Selected approach: “group model” approach to represent object inheritance.**
- using the “group model” grouping elements with the <choice> unbounded compositor and applying Schematron to recover the uniqueness property of the elements (DIM attributes)

**Notes:**
In the meeting in Cologne, I presented the approaches and best practices applied in the development of the DIM Schema. I also mentioned, that the representation of object inheritance needed to be re-evaluated to consider a different approach. We spent some time reworking this area of the Schema to  implement the “group model” alternative with the <choice> unbounded compositor. Schematron rules were added to recover the uniqueness property of the elements (DIM attributes).

## Previous Approach: Re-defines inherited attributes in object definitions.

<xsd:complexType name="VMD_Attribute_InfoType">
         <xsd:annotation><xsd:documentation>This complex type defines attribute information 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_Types" 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>

**Previous Approach: **Re-defines inherited attributes in object definitions.
**<xsd:complexType name="VMD_Attribute_InfoType">**
**         ****<xsd:annotation><xsd:documentation>This complex type defines attribute information 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_Types" 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>**

**Notes:**
This is an example of the old approach. As you can see, attribute inheritance is not achieve in this approach. In this approach, the attributes must be re-define every time they are inherited by a particular MOC. 

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

	<xsd:group name="Alert_Attributes">
		<xsd:all>
		<xsd:element name="Alert-Condition" type="Device-Alert-Condition_Type"/>
		<xsd:element name="Limit-Specification" type="Limit-Specification_Type"/>
		<xsd:element name="Vmo-Reference" type="Operation_Vmo-Reference_Type"/>
		</xsd:all>
	</xsd:group>
	<xsd:complexType name="Alert_Attribute_InfoType">
		<xsd:annotation><xsd:documentation>This complex type defines attribute information for Alert</xsd:documentation>
		</xsd:annotation>
	     <xsd:choice>
		<xsd:group ref="Alert_Attributes"/>
		<xsd:group ref="VMO_Attributes"/>
		<xsd:element ref="Private-Attributes" minOccurs="0"/>
	     </xsd:choice>
	</xsd:complexType>

Schematron:
<sch:pattern name="Attribute occurances">
<sch:rule context="//dim:Alert/dim:Attribute_Info">
<sch:assert test="count(dim:Alert-Condition)=1">Element Alert-Condition should be mandatory</sch:assert>
<sch:assert test="count(dim:Limit-Specification)&lt;2">Element Limit-Specification should be optional</sch:assert>
<sch:assert test="count(dim:Vmo-Reference)&lt;2">Element Vmo-Reference should be optional</sch:assert>
<sch:assert test="count(dim:Type)=1">Element Type should be mandatory</sch:assert>
<sch:assert test="count(dim:Handle)=1">Element Handle should be mandatory</sch:assert>
<sch:assert test="count(dim:Label-String)&lt;2">Element Label-String should be optional</sch:assert>
</sch:rule></sch:pattern>

**New Approach:**  “Group Model” used for grouping elements with the <choice> unbounded compositor (from above) + Schematron to recover the uniqueness property of the elements (attributes)
- 	**<xsd:group name="Alert_Attributes">**
**	****	****<xsd:all>**
**	****	****<xsd:element name="Alert-Condition" type="Device-Alert-Condition_Type"/>**
**	****	****<xsd:element name="Limit-Specification" type="Limit-Specification_Type"/>**
**	****	****<xsd:element name="Vmo-Reference" type="Operation_Vmo-Reference_Type"/>**
**	****	****</xsd:all>**
**	****</xsd:group>**
**	****<xsd:complexType name="Alert_Attribute_InfoType">**
**	****	****<xsd:annotation><xsd:documentation>This complex type defines attribute information for Alert</xsd:documentation>**
**	****	****</xsd:annotation>**
**	****     ****<xsd:choice>**
**	****	****<xsd:group ref="Alert_Attributes"/>**
**	****	****<xsd:group ref="VMO_Attributes"/>**
**	****	****<xsd:element ref="Private-Attributes" minOccurs="0"/>**
**	****     ****</xsd:choice>**
**	****</xsd:complexType>**
**Schematron:**
**<sch:pattern name="Attribute occurances">**
**<sch:rule context="//dim:Alert/dim:Attribute_Info">**
**<sch:assert test="count(dim:Alert-Condition)=1">Element Alert-Condition should be mandatory</sch:assert>**
**<sch:assert test="count(dim:Limit-Specification)&lt;2">Element Limit-Specification should be optional</sch:assert>**
**<sch:assert test="count(dim:Vmo-Reference)&lt;2">Element Vmo-Reference should be optional</sch:assert>**
**<sch:assert test="count(dim:Type)=1">Element Type should be mandatory</sch:assert>**
**<sch:assert test="count(dim:Handle)=1">Element Handle should be mandatory</sch:assert>**
**<sch:assert test="count(dim:Label-String)&lt;2">Element Label-String should be optional</sch:assert>**
**</sch:rule></sch:pattern>**

## Completed (on-plan) Tasks
PAR Project Plan
Minor Revision to plan (post Cologne, pre Atlanta)
Requirements Gathering
Identify Schema Best Practices and Approach for Implementation
Identify Approach for Object Inheritance
Identify Approach for Content Model Extensibility
Map Requirements to Schema
Develop Textual Definitions
ASN.1 Common Data Types
Map ASN.1 to Schema using ASN2XSD Tool
Service Model
ICS Tables
Implementation, Validation, and Testing

- Completed (on-plan) Tasks
- PAR Project Plan
- Minor Revision to plan (post Cologne, pre Atlanta)
- Requirements Gathering
- Identify Schema Best Practices and Approach for Implementation
- Identify Approach for Object Inheritance
- Identify Approach for Content Model Extensibility
- Map Requirements to Schema
- Develop Textual Definitions
- ASN.1 Common Data Types
- Map ASN.1 to Schema using ASN2XSD Tool
- Service Model
- ICS Tables
- Implementation, Validation, and Testing

## Completed (on-plan) Tasks (cont)
Maintenance
Comments and issues to IEEE Standards Body
DIM and Nomenclature
Updates to XSchema Libraries based on review comment
Update XSchema documentation to be consistent
Design and Code revision and documentation
Synchronize XSchema with Paper DIM

- Completed (on-plan) Tasks (cont)
- Maintenance
- Comments and issues to IEEE Standards Body
- DIM and Nomenclature
- Updates to XSchema Libraries based on review comment
- Update XSchema documentation to be consistent
- Design and Code revision and documentation
- Synchronize XSchema with Paper DIM

## Outstanding and Near-term Tasks
Development of X73-10202 document
Compose Outline (based on DIM, X73-10201)
Compose first draft, review and produce version 1.0
Ongoing Tasks
Present, Review, Update Plan (Atlanta Sept 07 mtg)
Develop X73-10202 Document (version 1.0)
Maintenance
Comments to Standards Body (DIM and Nomenclature)
Updates to XSchema Libraries based on review 
Update XSchema documentation to be consistent
Determine Future Needs 
Extensibility and Expandability

- Outstanding and Near-term Tasks
- Development of X73-10202 document
- Compose Outline (based on DIM, X73-10201)
- Compose first draft, review and produce version 1.0
- Ongoing Tasks
- Present, Review, Update Plan (Atlanta Sept 07 mtg)
- Develop X73-10202 Document (version 1.0)
- Maintenance
- Comments to Standards Body (DIM and Nomenclature)
- Updates to XSchema Libraries based on review
- Update XSchema documentation to be consistent
- Determine Future Needs
- Extensibility and Expandability

## X73-10202 Standardization Process Issues
Establish review process for DIM XSchema
Establish core review group
Get help with administrative process for IEEE submittal and acceptance (Todd and Jan?)
Develop initial document draft
Identify document guidance and format 

- X73-10202 Standardization Process Issues
- Establish review process for DIM XSchema
- Establish core review group
- Get help with administrative process for IEEE submittal and acceptance (Todd and Jan?)
- Develop initial document draft
- Identify document guidance and format

## DIM Issues

- Attribute inheritance
- NIST assumption: inheritance is captured in the attribute groups.
- Inconsistencies:
- Demo document (attribute table for infusion pump Hydra MDS):  MDS inherits the “handle” attribute from VMS
- DIM : Handle is not part of any attribute groups inherit by MDS