Presentation on theme: "IHE-PCD, PHD, IEEE 11073 and NIST Medical Device Communication Test Effort HL7/IEEE WG Meetings (San Antonio) January 2008."— Presentation transcript:
1IHE-PCD, PHD, IEEE and NIST Medical Device Communication Test Effort HL7/IEEE WG Meetings (San Antonio) January 2008
2Medical Device Test Effort NIST Team Members John Garguilo)Sandra Martinez)Maria CherkaouiGuest Researcher)Richard TheimerCENTECH Group, Inc., Contractor)
3Meeting Topics NIST Test Tools Update ICSGeneratorValidatePDUNIST P DIM XSchema (PAR)PAR Project PlanX DocumentationNext Steps and Future Direction…DIM XSchema DocumentationRT PnP Device CommunicationAdapt 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.
4ICSGenerator Tool and XSchema CEN and 13735ISO/IEEE 11073DIMPart 10201NomenclaturePart 10101DIM XSchemaCompare DevicesICSGeneratorThis 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 SchemaAllows comparison of device ICSsDevice ICSs comparison capability aids in identifying potential interoperability issuesGenerates (via transformations) HL7 OBX Segments (1-7)Generates Device UML Diagram13734/5 Standard provided information model for baseline and polling application profilesHL7/OBX Mapping (XML)Device UML Diagram
5ICSGenerator Capabilities Generates Implementation Conformance Statements (ICSs)Required in conformance section (10) of DIM x73 documentEnsures common format for ICS generationBuilds Device Profile (XML)Generates an electronic (XML) version of device data model based strictly on the IEEE x73 DIMIncludes private or manufacturer-specific extensionsProvides validation against DIM SchemaA device data model generated using this tool can be validated against an updated version of the DIM XSchemaProvides high level semantic interoperabilityEnsures correct containment relationship and terminology at the object class and related attribute, notification, and behavior levelCompare Device ICSsDevice ICSs comparison capability aids in identifying potential interoperability issuesGenerates HL7 OBX SegmentsGenerates Device UML DiagramUser 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.
6ValidatePDU ToolValidatePDU: Performs APDU syntax/structure and semantic validation using a MDER Coder.ValidatePDU(APDU Syntax and Semantic Validation)Device Profile(xml)ValidationReportROSEapdu(MDER)(MDER + XER Coder)(From ICSGenerator)Device Profile(xml)Device Profile(xml)ValidatePDUValidatePDUROSEapdu(MDER)ROSEapdu(MDER)ValidationReportValidationReport(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)
7APDU Structure MDS CMDISE ROSE System-Type Attr System-Model Attr MDSCreateInfoSystem-TypeSystem-ModelEventReportOperation invokeCMDISEROSEMedical Device SystemCommon Medical Device Information Service ElementRemote Operation Service ElementThis a representation of the PDU level that we are addressing in ValidatePDU. We validate starting from ROSE layer all way to the MDIB layer.
8ValidatePDU Capabilities Validates APDU syntax against X73 DIM specifications and the X73 Application Profiles – Base StandardASN.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 definitionSemantics: performs semantic validation (on the content) at the profile level (produced from ICSGenerator);
9ValidatePDU 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 binaryEnhanced 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.
10ValidatePDU (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.
11ValidatePDU (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.
12ValidatePDU (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.
13Assertions (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>…
14ValidatePDU Recent Enhancements Validates against Baseline Profile onlyValidates against polling mode profile and supports:MDS Create NotificationMDS-Poll-MDIB-DataProcess RoseInvoke and RoseResult typesProcess of all Rose typesProcess CMIP types: Get, Set, Create, EventReportProcess CMIP type : ActionDisplays information concerning message (whether message from Agent or Manager, Rose type, CMIP Type, MOC object)Displays Notification/Method name
15ValidatePDU Enhancements (Cont.) Process the following notifications:MDSCreateNotificationMDSAttributeUpdateAlertScannerScanEventReportEpiCfgScannerUnbufferedScanReportPeriCfgScannerBufferedScanReportContextScannerObjectCreateNotificationAdded support for all Notifications in DIMAttribute-UpdateSystem-ErrorMds-Create-NotificationMds-Attribute-UpdateClock-Date-Time-Status-ChangedSCO-Operating-RequestSCO-Operation-Invoke-ErrorUnbuf-scan-reportBuf-scan-reportFast-Buf-Scan-ReportObject-create-notificationObject-delete-notificationAlert-Scan-ReportOper-Create-NotificationOper-Delete-NotificationOper-Attribute-UpdatePatient-Demographics-ModifiedPatient-Demographics-State-ChangeVersion 3 supports all the DIM Notifications
16ValidatePDU Enhancements (Cont.) No processing of action type messages.Supports all DIM Actions:Clear-SegmentsGet-SegmentsGet-Segment-InfoMds-Set-StatusClear-LogGet-Event-Log-EntriesSet-TimeSet-Time-ZoneSet-Leap-SecondsSet-Time-ISOOperation-InvokeGet-Ctxt-HelpRefresh-Episodic-DataRefresh-Operation-contextRefresh-Operation-AttributesGet-Mib-DataDischarge-PatientAdmit-PatientPre-Admit-PatientVersion 3 now supports all the DIM actions (aka methods or behaviors)
17ValidatePDU 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 ProfileTest Tool Validation of X73 APDUsNISTICSGeneratorPnP MD AgentSimulatorPnP MD ManagerPnP PoC RT(G)xValidatePDUDevice Profile (XML)X73 APDU (MDER)X73 PDUsValidationReportWIRESHARKMDER 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.
19DIM XSchema Status/Update Quick XSchema Component ReviewPAR Approval DIM XSchemaApproval Date: 05-December-2007IEEE P TMD01a Draft Standard for Health Informatics – Medical Device Communication – Domain Information Model – XML Schema FormatProject PlanNext StepsFuture 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.
20DIM XML Schema PollingMode.xsd Rose.xsd Transport.xsd DIM.xsdGeneralICS.xsdserviceICS.xsdPollingMode.xsdMOC_Defs.xsdBaseline-Manager.xsdMOC_Attr_Behav_Notif.xsdRose.xsdDIM_Values.xsdDIM_Data_Types.xsdAs 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 shownTransport.xsd(http://www.nist.gov/x73DIM)DIM XSchema Document Structure(http://www.obj.sys.com/v1.0/XMLSchema)osxdlib.xsdincludeimport
21DIM 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.
23DIM X73-10202 XSchema Project Plan Completed (on-plan) TasksPAR Project PlanMinor Revision to plan (post Atlanta, pre San Antonio)Requirements GatheringIdentify Schema Best Practices and Approach for ImplementationIdentify Approach for Object InheritanceIdentify Approach for Content Model ExtensibilityMap Requirements to SchemaDevelop Textual DefinitionsASN.1 Common Data TypesMap ASN.1 to Schema using ASN2XSD ToolService ModelICS TablesImplementation, Validation, and Testing
24DIM X73-10202 XSchema Project Plan (cont) Completed (on-plan) Tasks (cont)MaintenanceComments and issues to IEEE Standards BodyDIM and NomenclatureUpdates to XSchema Libraries based on review commentUpdate XSchema documentation to be consistentDesign and Code revision and documentationSynchronize XSchema with Paper DIM
25DIM X73-10202 XSchema Project Plan Outstanding and Near-term TasksDevelopment of X documentCompose Outline (based on DIM, X )Compose first draft, review, and produce version 1.0Ongoing TasksPresent, Review, Update Plan (San Antonio Jan 08 mtg)Develop X Document (version 1.0)MaintenanceComments to Standards Body (DIM and Nomenclature)Updates to XSchema Libraries based on reviewUpdate XSchema documentation to be consistentDetermine Future NeedsExtensibility and Expandability
26DIM Issue (outstanding from Atlanta) Attribute inheritanceNIST assumption: inheritance is captured in the attribute groups.Inconsistencies:Demo document (attribute table for infusion pump Hydra MDS): MDS inherits the “handle” attribute from VMSDIM : Handle is not part of any attribute groups inherited by MDS
27Next Steps…Call for help w/ P10202 document content, issues, and reviewNeed (Industry involvement with) V & VVerification of translation: DIM XML SchemaIs it a faithful translation?Validation of tools by modeling devicesE.g., Monitor, Ventilator, Infusor (PHD devices?)Do users find the XSchema correct? Usable?How do we support it?10202 Document and Standardization ProcessUsability issues and contentE.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?TrackingIssues: e.g., Informative vs. Normative, how do we handle copyright and IP issues, etc…Establish review process for DIM XSchemaEstablish core review group
29PHD Project IEEE PIEEE 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 definedAdditional Attributes may be definedSome features of the original model might not be usedWhen 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)
30ICSGenerator, 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 createdThis XSchema will adopted the DIM XSchema architecture and reuse some of it components when applicable.
31PHD-DIM XML Schema DIM.xsd PHD-DIM.xsdGeneralICS.xsdserviceICS.xsdPHD-MOC_Defs.xsdDIM.xsdPHD-MOC_Attr_Behav_Notif.xsdPHD-DIM_Values.xsdPHD-DIM_Data_Types.xsdThe 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.xsdincludeimport
32Moving forward…Integration of Validation Test Tools NISTICSGeneratorDevice ProfileScenarioAgent Simulator/ ManagerEngineAPDUsPDUsCommunicationServicesThe 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 ProfileThe 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.ApduGenValidation ReportsPDUsASN.1 Module &Type services
33Agent/Manager Simulator Device profileGenerated using ICSGenerator.Used to build an agent/manager simulatorsMessage Exchange ScenariosAn 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.EngineDrive entire simulation processAPDUGenGenerates APDUs using a device profile.Communication ServicesProvides presentation, session and transport services.ASN.1 module and type servicesProvides ASN.1 library to decode and encode BER, MDER and XER.Validation ReportsReport syntax/structure and semantic validation errorsIt will also include behavioral validation
34BenefitsA 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.