slide1 n.
Skip this Video
Download Presentation
Medical Device Test Effort NIST Team Members

Loading in 2 Seconds...

play fullscreen
1 / 28

Medical Device Test Effort NIST Team Members - PowerPoint PPT Presentation

  • Uploaded on

Integrating the Healthcare Enterprise, IEEE 11073 and NIST Medical Device Communication Test Effort September 2007. Medical Device Test Effort NIST Team Members. John Garguilo ( , 301-975-5248) Sandra I. Martinez ( , 301-975-3579)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Medical Device Test Effort NIST Team Members' - kalin

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Integrating the Healthcare Enterprise, IEEE 11073andNISTMedical Device CommunicationTest EffortSeptember 2007
medical device test effort nist team members
Medical Device Test EffortNIST Team Members
  • John Garguilo (,


  • Sandra I. Martinez (,


  • Maria Cherkaoui (

Guest Researcher)

  • Richard Theimer (

CENTECH Group, Inc., Contractor)

meeting goals
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

ISO/IEEE 11073


Part 10101


Part 20101


Compare Devices



Device UML Diagram

NIST’s ICSGenerator and XSchema

icsgenerator enhancements since last wg meetings cologne april 07
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.
validatepdu 2 0 validatepdu 1 0 re designed







(APDU Syntax and low level Semantic Validation)

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.

Device Profile







(MDER + XER Coder)

(APDU Syntax and Semantic Validation)




System-Type Attr

System-Model Attr

Medical Device System





Common Medical Device Information Service Element




Remote Operation Service Element


Operation invoke


validatepdu 2 0 capabilities
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)
validatepdu 2 0 capabilities1
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)


<?xml version="1.0" encoding="UTF-8"?>

<!-- edited with XMLSpy v2007 ( by NIST (NIST) -->


<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 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 2 0 restrictions
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
validatepdu 2 0 restrictions cont
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.
validatepdu 2 0 future enhancements
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.








Device Profile (XML)


“libpcap”file (Non-RT)

MDER Extraction Tool

X73 PDUs

PnP MD Manager


PnP MD Agent







Plug-n-Play Real Time Profile Test Tool Validation

dim xschema discussion points
DIM XSchema Discussion Points
  • Quick XSchema Component Review
  • Characteristics
  • Update
  • Object Inheritance
  • Project Plan
dim xml schema














DIM XSchema Document Structure





DIM XML Schema
dim xschema characteristics
DIM XSchema Characteristics
  • 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
dim xschema update
DIM XSchema Update
  • 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


        • “<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)
dim xschema dim object inheritance
DIM XSchema DIM Object inheritance

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: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"/>



dim xschema dim object inheritance cont
DIM XSchema DIM Object Inheritance (cont.)

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: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:complexType name="Alert_Attribute_InfoType">

<xsd:annotation><xsd:documentation>This complex type defines attribute information for Alert</xsd:documentation>



<xsd:group ref="Alert_Attributes"/>

<xsd:group ref="VMO_Attributes"/>

<xsd:element ref="Private-Attributes" minOccurs="0"/>




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


dim x73 1020 2 xschema project plan
DIM X73-10202XSchema Project Plan
  • 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
dim x73 1020 2 xschema project plan cont
DIM X73-10202XSchema 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 1020 2 xschema project plan1
DIM X73-10202XSchema 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 (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
dim x73 1020 2 xschema project plan cont1
DIM X73-10202XSchema Project Plan (cont)
  • 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
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