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

Medical Device Test Effort NIST Team Members John Garguilo (john.garguilo@nist.gov, 301-975-5248) Sandra Martinez (sandra.martinez@nist.gov, 301-975-3579) Maria Cherkaoui (maria.cherkaoui@nist.gov Guest Researcher) Richard Theimer (richard.theimer@nist.gov CENTECH Group, Inc., Contractor)

Meeting Topics NIST Test Tools Update ICSGenerator ValidatePDU NIST P11073-10202 DIM XSchema (PAR) PAR Project Plan X73-10202 Documentation Next Steps and Future Direction… DIM XSchema Documentation RT PnP Device Communication Adapt PHD efforts into NIST Tools? http://www.nist.gov/medicaldevices 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.

ICSGenerator Tool and XSchema CEN 13734 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

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.

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)

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.

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);

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.

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.

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.

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.

Assertions (Example) <?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> …

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

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

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)

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)

“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 11073-30200 11073-30300(G) 11073-20101 11073-2020x 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.

DIM XSchema Status/Update Quick XSchema Component Review PAR Approval DIM XSchema Approval Date: 05-December-2007 IEEE P11073-10202TMD01a 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.

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 (http://www.nist.gov/x73DIM) DIM XSchema Document Structure (http://www.obj.sys.com/v1.0/XMLSchema) osxdlib.xsd include import

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.

DIM XSchema Project Plan

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

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

DIM X73-10202 XSchema Project Plan 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 (San Antonio Jan 08 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

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

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

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

PHD Project IEEE P11073-20601 IEEE P11073-20601 makes use of information objects that are defined in ISO/IEEE Std 11073-10201, 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 P11073-20601 replicates relevant portions of ISO/IEEE Std 11073-10101 and incorporates new nomenclature codes to add. (pg. 4)

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 P11073-20601 specification. Basically taking the current XML file and adding additional attributes, methods and behaviours and removing any definition that is not required by the P11073-20601 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.

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 (http://www.nist.gov/x73DIM) DIM XSchema Document Structure (http://www.obj.sys.com/v1.0/XMLSchema) osxdlib.xsd include import

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 110010011101001111110010 110010011101001111110010 Validation Reports PDUs ASN.1 Module & Type services

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

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.