1. Software and Systems Division Medical Device Communication Test Effort IHE-PCD F2F WG Meetings Medical Device Communication Test Effort IHE-PCD WG Meetings (Boston/Holliston, Massachusetts) 21-23 October 2008

2. Software and Systems Division Medical Device Test Effort Medical Device Test Effort NIST Team Members John Garguilo (john.garguilo@nist.gov,john.garguilo@nist.gov 301-975-5248) Sandra Martinez (sandra.martinez@nist.gov,sandra.martinez@nist.gov 301-975-3579) Maria Cherkaoui (maria.cherkaoui@nist.govmaria.cherkaoui@nist.gov Guest Researcher) Richard Theimer (richard.theimer@nist.govrichard.theimer@nist.gov CENTECH Group, Inc., Contractor) www.nist.gov/medicaldevices http://hl7v2tools.nist.gov/

3. Software and Systems Division Meeting Topics/Discussion NIST Tooling –IHE-PCD Profile/Message Validation –NIST V2 Validation Tools –ICSGenerator Supporting IHE-PCD Enhancements for X73-20601 and 104xx –ValidatePDU Validates APDU syntax against X73 DIM specifications and the X73 Application Profiles – Base Standard and Validates APDU semantic/content against device profile. RTM Management Service –Use Case –UML System Model, and Package diagram Standards development –NIST P11073-10202 DIM XSchema (PAR) –X73-10202 Documentation –Needs Validation and Verification (currently only through tooling) http://www.nist.gov/medicaldevices

4. Software and Systems Division NIST Tooling IHE-PCD Profile/Message Validation NIST V2 Testing Tools –Validate HL7 V2 profiles (Msg_type^Event_type^ e.g., ORU^R01^…) –Validate HL7 V2 messages (e.g., PCD-01) Message structure (e.g., MSH,PID,PV1,OBR,NTE,{OBX},OBX,OBX,OBX,…}) –Generate HL7 V2.x messages ICSGenerator Tool -Model Device according to x73 (DIM and Nomenclature) -Generate device profiles (device specialization in XML format) -Device profile becomes part of a “Medical Device Semantic Database” -Used for semantic/content validating and system configuration. Proposed RTM “Management Service” –A web application/service to facilitate RTM terminology authoring, review, and reporting –The “Harmonized” Rosetta table will become part of a “Medical Device Semantic Database” for purposes of semantic testing. Medical Device Semantic Database (Yet to come…) –To include semantic related information such as: Terminology based on Rosetta Terminology Mapping (RTM) – The “Harmonized” Rosetta Table. ISO/IEEE 11073-10101 Nomenclature Device specializations (IHE-PCD Vol. 3 Content Profiles), PHD 104xx specializations – –Will include terminology from RTM and from ISO/IEEE 11073-10101 Nomenclature entered by the user via ICSGenerator.

5. Software and Systems Division NIST V2 Testing Tools IHE-PCD: PCD-01 NIST V2 Testing tools (MessageValidator) PCD-01 HL7 V2 msg. Validation Report HL7 Profile (XML) MSH,PID,PV1,OBR,NTE,{ OBX},OBX,OBX,OBX,… NIST Medical Dev Semantic DB NIST Medical Dev Semantic DB PCD-01 HL7 V2 Assertions (XML) (validation context) V2 Test Scenario + NIST ICSGenerator

6. Software and Systems Division HL7 Profile (typically from MWB) –MWB profile:.mwb file –MWB table:.mwt file(s) A Validation Context (for NIST V2 Validation Tools) –Context must be provided where the user specifies the elements of the message to be validated. Referred to as “failure types”: User-provided (XML) ‘validation context’ file in a specific format. User provided tables or databases –E.g., Medical Device Semantic Database or –By providing the values in the ‘validation context’ file… Test Scenarios for each profile (e.g., IHE-PCD ACM, PIV Profiles) –Tied to Framework Docs (supplements) NIST Testing Tools Validating IHE-PCD Transactions (messages) What’s Needed?

7. Software and Systems Division IHE-PCD MWB: HL7 V2.5 PCD-01 Profile

8. Software and Systems Division Validation performed at the HL7 profile level NIST V2 Tooling does not provide the capability of conditional validation (e.g., validating that a REF_ID has the proper unit associated to it.) Semantic validation at Element Level –Based on the “Medical Device Semantic Database” –Includes: * observation identifier (REF_ID) CF_CODE10 CODE10 Units Enum_Values ContainedBy NIST Testing Tools Validating IHE-PCD Transactions (messages) What is and is NOT validated?

9. Software and Systems Division NIST Testing Tool provides validation in the following areas (failure types): VERSION*: The version in the message and in the profile should match. MESSAGE_STRUCTURE_ID*: The message type (MSH.9 element) in the profile and in the message should match. MESSAGE_STRUCTURE: The message should have a valid message structure (correct usage, correct cardinality, and correct element name). USAGE: R elements should be present; X elements should not be present in the message. CARDINALITY: Elements should be present at least the minimum times and at most the maximum times specified in the profile. It should also take into account the usage of the element (X element with a minimum of 4 should not be present in the message). LENGTH: The value of the element should have a length equal or less than the value specified in the profile. DATATYPE: For the datatype NM, DT, DTM, SI and TM, the value of the element should match the regular expression defined in the standard. DATA: The value of the element should match a constant specified in the profile, a value set specified in a table, a value or a regular expression specified in the message validation context. MESSAGE_VALIDATION_CONTEXT*: This is a user input error when the location specified in the message validation context can't be found in the message. TABLE_NOT_FOUND*: This is a user input when a table can't be found in the table files (TableProfileDocument). AMBIGUOUS_PROFILE*: The profile should not be ambiguous. NIST V2 Testing Tools: PCD-01 and Rosetta relationship (RTM Validation at the Device/Gateway Message Level)

10. Software and Systems Division RTM Validation Sample Validation Context

11. Software and Systems Division RTM Validation Sample Validation Context (Continued)

12. Software and Systems Division NIST Tooling Medical Device Semantics Medical Device Semantic Database (Yet to come…) –To include semantic related information such as: Terminology based on Rosetta Terminology Mapping (RTM) – The “Harmonized” Rosetta Table. ISO/IEEE 11073-10101 Nomenclature Device specializations (IHE-PCD Vol. 3 Content Profiles), PHD 104xx specializations – –Will include terminology from RTM and from ISO/IEEE 11073-10101 Nomenclature entered by the user via ICSGenerator. Medical Dev Semantic DB Medical Dev Semantic DB Device XML Profile + ICSs RTM Harmonized (Terminology, UoM) X73 Nomenclature (11073-10101) NIST V2 Test Scenario +

13. Software and Systems Division Meeting Topics/Discussion XML Schema: Normative Addition to x73-DIM Standards development –NIST P11073-10202 DIM XML Schema (PAR) –X73-10202 Documentation No update since last IEEE/HL7 WG meeting –“ ieee-11073-10202-d01a-2008-04-30-clean-jjg.doc ” –“ ieee-11073-10202-d01a-2008-04-30-deltas-jjg.doc ” Call for reviewers and help with documentation –Needs Validation and Verification of XML Schema (currently only through tooling) V & V is ongoing –As ICSGenerator is further enhanced and developed –As RTM work comes to fruition and is incorporated into tooling –As IHE-PCD model device specializations (content profiles – in Technical Framework Volume III) –As PHD WG approves PHD devices and models (validating -20601 and 104xx [as tied to Nomenclature – 10101 and DIM – 10201])

14. Software and Systems Division Thank You! Questions/Discussion Thank you! www.nist.gov/medicaldevices http://hl7v2tools.nist.gov/

15. Software and Systems Division Rosetta Terminology Service F2F Agenda Item RTM “Management Service” –Proposed Service –Proposed Steps to implement –Use Case –UML System Model –Package Diagram –Entity Relationship Diagram –Task List and Proposed Project Plan

16. Software and Systems Division NIST Tooling To Support RTM Process Proposed “RTM Management Service” The tool will be a web application to allow vendors and reviewers access, retrieval, and reporting of Rosetta Tables over the internet in conformance to RTM. -Addresses RTM requirement : “Any corrections or additions will be reflected back in the vendor’s table and a new version of the merged table (and XML files) will be created. The tool will provide the capability of saving information in XML format as defined by RTM proposal The tool will provide the capability to apply XSLT transformations specified by the RTM proposal to harmonize the tables –Merge individual vendor table(s) into a single table. Provide a report identifying differences –RTM example: “Create a list of the MDC reference identifiers and the vendors that select it, and MDC identifiers that were selected by only a single vendor --would be examined and compared with similar terms”. Provide a report identifying missing or new terms (no mapping). -RTM requirement: “Any missing or new MDC reference identifiers will be submitted to the appropriate standards group to create and add the new terms to the relevant standard”.

17. Software and Systems Division “RTM Management Service” Proposed Steps Database/XML Service initially prototyped and located at NIST Once there’s a road: Migrate ‘protoype’ to ‘pilot’ application Down the road: Migrate ‘pilot’ tool into a web service. Further down the road: vetted ‘pilot’ system/functionality is moved to SDO which becomes “owner” and “maintainer” A set of assertions extracted from RTM will be used to make sure we take into consideration all normative requirements and to facilitate the tool development process. NOTE: The final merged table will be used as basis for testing  ICSGenerator, ValidatePDU and NIST V2 Testing Tool

18. Software and Systems Division RTM Management System Use Case Use Case

19. Software and Systems Division RTM UML Model

20. Software and Systems Division RTM Packages

21. Software and Systems Division RTM Database Entity Relationship Diagram

22. Software and Systems Division RTM Management System Proposed Project Plan: ~2.5 months Create and populate database Get data from “Rosetta” excel document –Extract data for each vendor –Populate all tables View vendors, “Rosetta” or “Harmonized-Rosetta” tables Edit/add vendor data –Display possible group values –Display possible reference ids –Display possible units –Verify mandatory information has been supplied Add comments to “Rosetta” by reviewers –Display time of comment and name of the user –Update vendor table Save data –Vendor data and update “Rosetta” –Save “Rosetta” and update vendor data Download XML “Rosetta” and xml Harmonized-”Rosetta” –Generate XML form database Generate harmonized “Rosetta” –Highlight conflicts in “Rosetta” (verify that a reference id is always associated to one term code, verify that mandatory fields are filled, etc...) –If no conflicts detected generate harmonized “Rosetta”

23. Software and Systems Division Thank You! Questions/Discussion Thank you! www.nist.gov/medicaldevices

24. Software and Systems Division Medical Device Communication Test Effort Extra Slides IHE-PCD F2F WG Meetings Medical Device Communication Test Effort 21 – 23 October 2008

25. Software and Systems Division What are we doing? Test Tools Test ToolsICSGeneratorValidatePDU What is it?Implementation Conformance Statement Generator, Profile builder X73 Message validation: profile and standard Why?Automate and simplify ICS and profile generation Based on standard Promote Interoperability How is it being used? As a requirement to standard (ICSs) Early stage interoperability Standards Development/Feedback Message validation Device profile validation Who’s using it?Major medical device manufacturers – B. Braun, Draeger Medical (Siemens) (US and Europe), GE Healthcare, Philips (US and Europe), Welch Allyn, – EPIC, SpaceLabs Healthcare, Capsule – Several smaller/simpler device manufactures – PHD participants (including Intel – primary sponsor of Continua effort) Several small manufactures have expressed interest Countries participating: US, Europe, Japan, Korea, Canada Who are we working with? IHE-Patient Care Device Domain Personal Health Device WG IEEE 11073 WG

26. Software and Systems Division CEN 13734 and 13735 DIM XSchema Compare Devices HL7/OBX Mapping (XML) Device UML Diagram ISO/IEEE 11073 DIM Part 10201 Nomenclature Part 10101 ICSGenerator ICSGenerator Tool and XSchema

27. Software and Systems Division 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

28. Software and Systems Division ValidatePDU Tool ValidatePDU: Performs APDU syntax/structure and semantic validation using a MDER Coder. APDU (XER) ValidatePDU (APDU Syntax and Semantic Validation) Device Profile (xml) Validation Report ROSEapdu (MDER) (MDER + XER Coder) ValidatePDU (APDU Syntax and Semantic Validation) Device Profile (xml) Validation Report ROSEapdu (MDER) (MDER + XER Coder) ValidatePDU (APDU Syntax and Semantic Validation) Device Profile (xml) Validation Report ROSEapdu (MDER) (MDER + XER Coder Encode/Decode) (From ICSGenerator)

29. Software and Systems Division 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)

30. Software and Systems Division 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)

31. Software and Systems Division IHE-PCD Year 3+ Profile Proposal PCD-Device Point-of-Care Integration X73 APDU Validate APDUs against Standard Determine if APDUs meets device profile (defined using ICSGenerator)

32. Software and Systems Division Potential Future Direction… Gazelle Detailed DEC Test Scenario –Test Scenario Actors / Evaluation Items Notes and Questions Message Profile and Data –Transactions [1..x] e.g., communicate data, query data… »Segment Spec and Data (e.g., MSH, OBX, etc.) *Validation Criteria –Transactions [1..x] e.g., communicate data, query data… »Message Profile »Table Definitions »Test Case Specific Validation Criteria *Validation Criteria Specified for the purpose of determining whether or not the implementations successfully completed the tests

33. Software and Systems Division Observation Segment… Observation Segments –OBX.2 Value Type (ID) Identifies type for value(s) in OBX.5 –OBX.3 Observation Identifier (CE) For kind of measurement or device-dependent data in OBX.5 –OBX.4 Observation Sub-ID (ST) Used to group related components... –OBX.5 Observation Value –OBX.6 Units (CE)