1. IHE-PCD, PHD, IEEE and NIST Medical Device Communication Test Effort HL7/IEEE WG Meetings (San Antonio) January 2008

2. Medical Device Test Effort NIST Team Members
John Garguilo )
Sandra Martinez )
Maria Cherkaoui
Guest Researcher)
Richard Theimer
CENTECH Group, Inc., Contractor)

3. Meeting Topics NIST Test Tools Update
ICSGenerator
ValidatePDU
NIST P DIM XSchema (PAR)
PAR Project Plan
X Documentation
Next Steps and Future Direction…
DIM XSchema Documentation
RT PnP Device Communication
Adapt PHD efforts into NIST Tools?
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.

4. ICSGenerator Tool and XSchema
CEN and 13735
ISO/IEEE 11073
DIM
Part 10201
Nomenclature
Part 10101
DIM XSchema
Compare Devices
ICSGenerator
This diagram shows 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
Allows comparison of device ICSs
Device ICSs comparison capability aids in identifying potential interoperability issues
Generates (via transformations) HL7 OBX Segments (1-7)
Generates Device UML Diagram
13734/5 Standard provided information model for baseline and polling application profiles
HL7/OBX Mapping (XML)
Device UML Diagram

5. ICSGenerator Capabilities
Generates Implementation Conformance Statements (ICSs)
Required in conformance section (10) 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
User can produce a device profile, and subsequently load the profile for validation (and to identify if the profile is still in compliance) as the standard advances.

6. ValidatePDU Tool
ValidatePDU: Performs APDU syntax/structure and semantic validation using a MDER Coder.
ValidatePDU
(APDU Syntax and Semantic Validation)
Device Profile
(xml)
Validation
Report
ROSEapdu
(MDER)
(MDER + XER Coder)
(From ICSGenerator)
Device Profile
(xml)
Device Profile
(xml)
ValidatePDU
ValidatePDU
ROSEapdu
(MDER)
ROSEapdu
(MDER)
Validation
Report
Validation
Report
(MDER + XER Coder)
(MDER + XER Coder)
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 MDER instead of 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 Syntax and Semantic Validation)
(APDU Syntax and Semantic Validation)
APDU
(XER)

7. APDU Structure MDS CMDISE ROSE System-Type Attr System-Model Attr
MDSCreateInfo
System-Type
System-Model
EventReport
Operation invoke
CMDISE
ROSE
Medical Device System
Common Medical Device Information Service Element
Remote Operation Service Element
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.

8. ValidatePDU 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)
Tool determines if:
a MOC, attribute, behavior and notifications identified in a message is implemented by the device profile.
attributes identified in a message are implemented as part of a MOC in the device profile.
the message contains the attribute as required by the device profile (missing or unrecognized attributes).
the message contains valid MOC information, such as handle and context-id according to the device profile.
the message contains valid attribute information, such as fixed values and value ranges according to the device profile.
a behavior identified in a message is supported by the device profile.
MOC objects hierarchy complies with device profile specifications.
the message contains the MOCs as required by the device profile (missing MOC or unrecognized MOCs)
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 performs syntax and semantic validation,
Syntax: syntax validation is performed on ASN.a data types and object definition
Semantics: performs semantic validation (on the content) at the profile level (produced from ICSGenerator);

9. ValidatePDU Capabilities
Decodes MDER PDUs and builds 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 functionalities are captured in a ValidatePDU Software Requirements Specification document. (Reviewed by members of the WG)
Test assertions are basically requirements extracted from the standards, which becomes the basis for validation.

10. ValidatePDU (Enhanced View)
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.

11. ValidatePDU (XER View)
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.

12. ValidatePDU (MDER View)
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.

13. Assertions (Example) <?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2007 ( 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> …

14. ValidatePDU Recent Enhancements
Validates against Baseline Profile only
Validates against polling mode profile and supports:
MDS Create Notification
MDS-Poll-MDIB-Data
Process RoseInvoke and RoseResult types
Process of all Rose types
Process CMIP types: Get, Set, Create, EventReport
Process CMIP type : Action
Displays information concerning message (whether message from Agent or Manager, Rose type, CMIP Type, MOC object)
Displays Notification/Method name

15. ValidatePDU Enhancements (Cont.)
Process the following notifications:
MDSCreateNotification
MDSAttributeUpdate
AlertScannerScanEventReport
EpiCfgScannerUnbufferedScanReport
PeriCfgScannerBufferedScanReport
ContextScannerObjectCreateNotification
Added support for all Notifications in DIM
Attribute-Update
System-Error
Mds-Create-Notification
Mds-Attribute-Update
Clock-Date-Time-Status-Changed
SCO-Operating-Request
SCO-Operation-Invoke-Error
Unbuf-scan-report
Buf-scan-report
Fast-Buf-Scan-Report
Object-create-notification
Object-delete-notification
Alert-Scan-Report
Oper-Create-Notification
Oper-Delete-Notification
Oper-Attribute-Update
Patient-Demographics-Modified
Patient-Demographics-State-Change
Version 3 supports all the DIM Notifications

16. ValidatePDU Enhancements (Cont.)
No processing of action type messages.
Supports all DIM Actions:
Clear-Segments
Get-Segments
Get-Segment-Info
Mds-Set-Status
Clear-Log
Get-Event-Log-Entries
Set-Time
Set-Time-Zone
Set-Leap-Seconds
Set-Time-ISO
Operation-Invoke
Get-Ctxt-Help
Refresh-Episodic-Data
Refresh-Operation-context
Refresh-Operation-Attributes
Get-Mib-Data
Discharge-Patient
Admit-Patient
Pre-Admit-Patient
Version 3 now supports all the DIM actions (aka methods or behaviors)

17. ValidatePDU 3.0 Restrictions
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.
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)

18. “libpcap”file (Non-RT)
Plug-n-Play Real Time Profile
Test Tool Validation of X73 APDUs
NIST
ICSGenerator
PnP MD Agent
Simulator
PnP MD Manager
PnP PoC RT
(G) x
ValidatePDU
Device Profile (XML)
X73 APDU (MDER)
X73 PDUs
Validation
Report
WIRESHARK
MDER Extraction Tool
“libpcap”file (Non-RT)
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 and subsequently validated using ValidatePDU to generate a validation report.

19. DIM XSchema Status/Update
Quick XSchema Component Review
PAR Approval DIM XSchema
Approval Date: 05-December-2007
IEEE P TMD01a Draft Standard for Health Informatics – Medical Device Communication – Domain Information Model – XML Schema Format
Project Plan
Next Steps
Future Directions?
Issues (Jan)
Tied to IEEE standardization process, where Jan is the lead as working group chair. We will be supporting the effort (vice-chair and contributer). NIST role is to support industry in standard development.

20. DIM XML Schema PollingMode.xsd Rose.xsd Transport.xsd
DIM.xsd
GeneralICS.xsd
serviceICS.xsd
PollingMode.xsd
MOC_Defs.xsd
Baseline-Manager.xsd
MOC_Attr_Behav_Notif.xsd
Rose.xsd
DIM_Values.xsd
DIM_Data_Types.xsd
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.
NIST Schema Architecture , name space is shown
Transport.xsd (
DIM XSchema Document Structure (
osxdlib.xsd
include
import

21. DIM XSchema Objectives/Goals and Intent
Translate DIM (into XML) to develop conformance related automation (tooling) [one of NIST’s original objectives],
Serve as feedback/loop mechanism to DIM standard,
Enable standard-based implementation,
Gain understanding of standard.
Intent:
Not intended to replace DIM, but enable implementation of it…
Tied to IEEE standardization process, where Jan is the lead as working group chair. We will be supporting the effort (vice-chair and contributer). NIST role is to support industry in standard development.

22. DIM XSchema Project Plan

23. DIM X73-10202 XSchema Project Plan
Completed (on-plan) Tasks
PAR Project Plan
Minor Revision to plan (post Atlanta, pre San Antonio)
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

24. DIM X73-10202 XSchema Project Plan (cont)
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

25. DIM X73-10202 XSchema Project Plan
Outstanding and Near-term Tasks
Development of X document
Compose Outline (based on DIM, X )
Compose first draft, review, and produce version 1.0
Ongoing Tasks
Present, Review, Update Plan (San Antonio Jan 08 mtg)
Develop X 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

26. DIM Issue (outstanding from Atlanta)
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 inherited by MDS

27. Next Steps…
Call for help w/ P10202 document content, issues, and review
Need (Industry involvement with) V & V
Verification of translation: DIM  XML Schema
Is it a faithful translation?
Validation of tools by modeling devices
E.g., Monitor, Ventilator, Infusor (PHD devices?)
Do users find the XSchema correct? Usable?
How do we support it?
10202 Document and Standardization Process
Usability issues and content
E.g., mapping of XML to/from paper DIM, nomenclature, etc.
Who is the audience?
Could be the main users of the doc/project are conformance folks?
Is the draft a reasonable starting place?
Still need 1 or more iterations to get things organized?
Tracking
Issues: e.g., Informative vs. Normative, how do we handle copyright and IP issues, etc…
Establish review process for DIM XSchema
Establish core review group

28. Potential Future Direction…
RT PnP Profile
Leveraging NIST Conformance Tooling to PHD work
PHD Application Profile (optimized exchange protocol)
As ‘Specializations’ balloted ( xx)
Manager/Agent Simulator
X73 APDU Message Generation

29. PHD Project IEEE P
IEEE P makes use of information objects that are defined in ISO/IEEE Std , adapting these information objects to the domain of Personal Health Device communication. The information objects are specialized and therefore modified in the following ways:
The definition of attributes that are mandatory, optional, or conditional may be different *
Additional Object Services may be defined
Additional Attributes may be defined
Some features of the original model might not be used
When discrepancies occur between these standards, the referenced standards take priority.
IEEE P replicates relevant portions of ISO/IEEE Std and incorporates new nomenclature codes to add. (pg. 4)

30. ICSGenerator, DIM XSchema and PHD-DIM
ICSGenerator uses an XML representation of the DIM specification.
A new XML configuration file must be created to represent the IEEE P specification.
Basically taking the current XML file and adding additional attributes, methods and behaviours and removing any definition that is not required by the P specification.
The new xml configuration file would not validate against the current x73 DIM XSchema, therefore a PHD-DIM XSchema must be developed.
The tool could be enhanced to generate PHD profiles by allowing the user to select type of profile to generate.
The X73-DIM XML configuration file could be use to allow user to extend the objects by using additional object attributes as defined by x73 DIM.
A PHD-DIM XSchema must be created
This XSchema will adopted the DIM XSchema architecture and reuse some of it components when applicable.

31. PHD-DIM XML Schema DIM.xsd
PHD-DIM.xsd
GeneralICS.xsd
serviceICS.xsd
PHD-MOC_Defs.xsd
DIM.xsd
PHD-MOC_Attr_Behav_Notif.xsd
PHD-DIM_Values.xsd
PHD-DIM_Data_Types.xsd
The architecture (componentization) would be modeled after the existing DIM XSchema (
DIM XSchema Document Structure (
osxdlib.xsd
include
import

32. Moving forward…Integration of Validation Test Tools
NIST
ICSGenerator
Device Profile
Scenario
Agent Simulator/ Manager
Engine
APDUs
PDUs
Communication
Services
The idea is to receive and send PDU’s from/to X73 devices.
Process Flow:
A PDU is received by the Agent/manager simulator…
The PDU is validated for syntax/structure and semantics (functionality that ValidatePDU tool currently provides)…
The PDU is then analyzed to generate the correspondent response based on scenarios generated (input – based on the state machine).
[assumption: scenarios generated by medical device community?]
Module Functionality:
APDUGen (Module) generates the APDU messages; communication services added (by Communication Service Module) to generate a PDU ready for transmission.
ICSGenerator generated Device Profile
The device profile:
Must be generated using ICSGenerator.
Is used to validate messages for semantics and structure (meets the containment tree hierarchy and are appropriate or legal attributes behavior or notifications).
Provides the basis for message generation of the agent/manager simulator (used to generate agent/manager type messages).]
The simulator basically behaves as a manager or agent depending on type of message received (and subsequently needed [or appropriate] in response).
Note: In the initial phase of this development, we can not simulate a manager because the capability of dynamically building a MDIB copy of the agent would not be available. Therefore, in order to simulate a manager the correspondent agent profile (device to communicate with) must be used to generate the manager type messages that an agent can understand.
In this process there is no need for a sniffer.
Side note: a manager could communicate with different agent devices, it knows how to communicate by requesting a context scanner to build a copy of the agent MDIB.
ApduGen
Validation Reports
PDUs
ASN.1 Module &
Type services

33. Agent/Manager Simulator
Device profile
Generated using ICSGenerator.
Used to build an agent/manager simulators
Message Exchange Scenarios
An xml file describing a message exchange.
Using message interaction diagrams and the finite state machine.
Used as input to the simulator to manage messages to be sent.
Engine
Drive entire simulation process
APDUGen
Generates APDUs using a device profile.
Communication Services
Provides presentation, session and transport services.
ASN.1 module and type services
Provides ASN.1 library to decode and encode BER, MDER and XER.
Validation Reports
Report syntax/structure and semantic validation errors
It will also include behavioral validation

34. Benefits
A non-proprietary x73 simulator that can be used by any x73 implementer.
Helps implementers understand the x73 standard.
Could be used as a reference implementation for helping others to implement their own version of the standard.
Provides conformance testing capabilities.