1 / 28

Medical Device Test Effort NIST Team Members

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 , 301-975-5248) Sandra I. Martinez ( sandra.martinez@nist.gov , 301-975-3579)

ferrol
Download Presentation

Medical Device Test Effort NIST Team Members

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Integrating the Healthcare Enterprise, IEEE 11073andNISTMedical Device CommunicationTest EffortSeptember 2007

  2. Medical Device Test EffortNIST Team Members • John Garguilo (john.garguilo@nist.gov, 301-975-5248) • Sandra I. 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)

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

  4. ISO/IEEE 11073 Nomenclature Part 10101 DIM Part 20101 DIMXSchema Compare Devices ICSGenerator HL7/OBXMapping(XML) Device UML Diagram NIST’s ICSGenerator and XSchema

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

  6. ValidatePDU APDU (XER) Validation Report (DIM-DataTypes.xsd) (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 (xml) ValidatePDU ROSEapdu (MDER) Validation Report (MDER + XER Coder) (APDU Syntax and Semantic Validation) APDU (XER)

  7. System-Type Attr System-Model Attr Medical Device System MDS MDSCreateInfo System-Type System-Model Common Medical Device Information Service Element CMDISE EventReport MDSCreateInfo Remote Operation Service Element ROSE Operation invoke EventReport APDU

  8. 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)

  9. 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)

  10. 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> …

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

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

  13. ValidatePDU 2.0

  14. ValidatePDU 2.0 (XER view)

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

  16. WIRESHARK Validation NIST ICSGenerator Report NIST ValidatePDU Device Profile (XML) X73 APDU (MDER) “libpcap”file (Non-RT) MDER Extraction Tool X73 PDUs PnP MD Manager Simulator PnP MD Agent Simulator PnP PoC RT 11073-30200 11073-30300(G) 11073-20101 11073-2020x Plug-n-Play Real Time Profile Test Tool Validation

  17. DIM XSchema Discussion Points • Quick XSchema Component Review • Characteristics • Update • Object Inheritance • Project Plan

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

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

  20. 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 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)

  21. 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: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>

  22. 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: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>

  23. DIM XSchema Project Plan

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

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

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

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

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

More Related