# Presentation: 230493

## ISO/IEEE 11073, IHE-PCD, PHD  and NISTMedical Device CommunicationTest EffortHL7/IEEE WG Meetings (Vancouver, British Columbia, Canada)17-18 September 2008

**Notes:**
NIST Presentation to IEEE/HL7 Healthcare Devices SIG in Vancouver, Canada on September 17th, 2008.
Also included are slides for presentation to PHD group on Thursday, September 18th, 2008.

## Medical Device Test EffortNIST Team Members

**John Garguilo** (_[john.garguilo@nist.gov](mailto:john.garguilo@nist.gov)_,
- 301-975-5248)
**Sandra Martinez** (_[sandra.martinez@nist.gov](mailto:sandra.martinez@nist.gov)_,
- 301-975-3579)
- Maria Cherkaoui (_[maria.cherkaoui@nist.gov](mailto:maria.cherkaoui@nist.gov)_
- Guest Researcher)
- Richard Theimer (_[richard.theimer@nist.gov](mailto:richard.theimer@nist.gov)_
- CENTECH Group, Inc.,  Contractor)
- _[www.nist.gov/medicaldevices](http://www.nist.gov/medicaldevices)_

## Meeting Topics/Discussion

- NIST Tooling
- IHE-PCD Profile/Message Validation
- NIST V2 Validation Tools
- ICSGenerator
- Supporting IHE-PCD
- Enhancements for X73-20601 and 104xx
- RTM Management Service
- Use Case
- UML System Model, and Package diagram
- Standards development
- NIST P11073-10202 DIM XSchema (PAR)
- PAR Project Plan Update
- X73-10202 Documentation
- Needs
-  Validation and Verification (currently only through tooling)
- _[http://](http://www.nist.gov/medicaldevices)__[www.nist.gov/medicaldevices](http://www.nist.gov/medicaldevices)_

**Notes:**
In today’s presentation I will provide with an update of the NIST Test tooling efforts, our ideas for a Rosetta Terminology Mapping Management Service, and quick update on the P11073-10202 PAR/project plan.

Thursday’s presentation will focus on specific enhancements made to the NIST ICSGenerator tool which now encorporates application profiles for PHD devices (including the manager and agent).

## 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
- 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*.

**Notes:**
Medical Device Semantic Database
“Approved” content profiles (for various devices)
SDO “Approved” harmonized Rosetta terminology
X73 Nomenclature

## NIST V2 Testing Tools IHE-PCD: PCD-01  

- NIST V2
- Testing tools
- (MessageValidator)** **

**PCD-01 **
**HL7 V2 msg.**

**Validation **
**Report**

**PCD-01 **
**HL7 V2 Assertions**
**(XML)**
**(validation context)**

- HL7
- Profile
- (XML)

- MSH,PID,PV1,OBR,NTE,{OBX},OBX,OBX,OBX,...

**Medical Dev Semantic DB**
** **

**Notes:**
The need is to test that units, enumerations, external lead sites, and the parent OBXs are checked. 	Vendors would provide the messages, perhaps in email. 	Validation assures that units of measure and nomenclature are correct. 
Verify if this is the type of testing to be done:
RTM verification can be triggered whenever an observation identifier is recognized in the message, based on the four-level hierarchy used by PCD-01 and related messages,

Get first observation (parameter) (term code)  from msg and check against Rosetta 
- If observation is found in Rosetta  => term check ok!
- Check the units for that parameter
- If the unit matches the unit identified in Rosetta for the term being tested => unit check ok!
- If the unit does not match the unit identified in Rosetta for the term being tested => invalid unit for term xxx! 
- Check enumerations
- Check external lead sites (OBX20)
- If observation is not in the table => “term” is missing!
Need type of errors to identify.

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

- NIST Testing Tools
-  Validating IHE-PCD Transactions (messages)What’s Needed?

## IHE-PCD MWB: HL7 V2.5 PCD-01 Profile

- Validation performed at the HL7 profile level
- 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 V2 Tooling ***does not***  provide the capability of conditional validation (e.g., validating that a REF_ID has the proper unit associated to it.)

- NIST Testing Tools
-  Validating IHE-PCD Transactions (messages)What is and is NOT validated?

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

## RTM Validation Sample Validation Context

**Notes:**
At this time, NIST focused on the test cases identified by Paul Schluter...
Validation Context format needed (in XML) by the NIST V2 testing tools was generated (by hand)
Later, as test cases coverage grows, value insertion (into the needed XML format) can be done by querying specific values from the Medical Device Semantic Database.
For conditional test cases

## RTM Validation Sample Validation Context (Continued)

## ICSGenerator Supporting IHE-PCD; PCD-01  

-  (<MDS><VMD><CHAN><METRIC>)
- X73** **GENERAL DEFINITION
- (Vol. II)

**ICSGenerator**

- PCD-01
- Vol II

**Medical Dev Semantic DB**

- Device
- XML Profile
- + ICSs

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

**Device**
**XML Profile **
- + **ICSs**

- RTM
- Harmonized
- (Terminology, UoM)

- X73Nomenclature
- (11073-10101)

**Notes:**
In today’s presentation I will provide with an update of the NIST Test tools including the DIM Schema

## Meeting Topics/DiscussionXML Schema: Normative Addition to x73-DIM

- Standards development
- NIST P11073-1020_2_ DIM XML Schema (PAR)
- _[PAR Project Plan Update](http://x73.10202_9_12_08.mpp/)_
- “x73.10202_9_12_08.mpp”
- X73-10202 Documentation
- No update since last 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])

## Thank You! 

- Questions/Discussion
- Thank you!
- _[www.nist.gov/medicaldevices](http://www.nist.gov/medicaldevices)_

## Meeting Topic/Discussion

- RTM “Management Service”
- Proposed Service
- Proposed Steps to implement
- Use Case
- UML System Model
- Package Diagram
- Entity Relationship Diagram

**Notes:**
In today’s presentation I will provide with an update of the NIST Test tools including the DIM Schema

## 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”.

##   “RTM Management Service” Proposed Steps

** **Database/XML Service initially prototyped and located at NIST
- Once there’s a road: Migrate ‘protoype’ to ‘pilot’
- Down the road: Migrate ‘pilot’ the 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

## RTM Management SystemUse Case

## RTM UML Model

**Notes:**
This UML diagram represents RTM data model. At the top we find “HarmonizedRosetta” that models the Harmonized Rosetta table data.
Each HarmonizedRosetta object contains observation information such as codes, datatype, units and enumerations...
On the right, there is “Rosetta” class which associates vendor information to x73 terminology.

We distinguish three areas in this diagram that we represented in three different colors.  =>next slide

## RTM Packages

**Notes:**
In blue, we have “terminology” package that is a meta model describing the terminology in a more general manner.
Then in yellow, the “rtm” package which is part of x73 terminology. “X73terminology” extends “terminology” package.
And finally, “rosetta mappings” package , in green, is part of “rtm”. It gathers vendor information and maps it to x73 terminology (Rosetta class).

This model was useful for us to design our  RTM database. => next slide

## RTM Database Entity Relationship Diagram

- RTM Database Entity Relationship Diagram

**Notes:**
Here is the Entity Relationship diagram that we come up with.
For example, we have, at the top, the ‘harmonizedRosetta’ table that lists several observations, each Observation having code, datatype...
And we have rosetta Table that associates a vendor parameter to an observation...  => next slide

## Thank You! 

- Questions/Discussion
- Thank you!
- _[www.nist.gov/medicaldevices](http://www.nist.gov/medicaldevices)_

## ISO/IEEE 11073, PHD WG and NIST Medical Device CommunicationTest EffortSeptember 18 2008

## Leveraging NIST Tools For PHD

**ICSGenerator**

**ValidatePDU**

**Notes:**
We have an electronic representation of the X73 “Classic” DIM in a form of an XML Schema and we are re-using some or its components and adopting it architecture to generate a PHD-DIM XSChema.
An XML instance of the PHD-DIM XSchema was created to represent the PHD DIM (object cardinality, attributes, actions, event and data types). Also, each X73-104xx specification will have its own XML configuration file, of course in compliance with the X73-20601 specification because they were generated using ICSGenerator and the 20601 configuration file as the basis.  ICSGenerator will utilize the configuration files to allow an implementer to generate a totally compliance  electronic representation of  a device including its ICS statements.  Notice the X73-104xx XSchematron rules, these will allow validations on variable constraints such as the attribute qualifiers. For example PHD 20601 might call for an attribute to be “C” or “O” and a specialization might required this attribute to be mandatory or prohibited.

##  ICSGenerator, DIM XSchema and PHD-DIM PHD XSchema

- A PHD-DIM XSchema has been developed to represent the IEEE P11073 20601 standard.
- The PHD XSchema adopts the DIM XSchema architecture and reuses some of it components, when applicable.
- DIM_Data_Type.xsd containing classic x73 ASN.1 definition included and redefined, when appropriate.

## PHD_DIM XSchema

**PHD_MOC_Defs.xsd**

**PHD_MOC_Attr_Behav_Notif.xsd**

**PHD_Data_Types.xsd**

**(http://www.nist.gov/x73DIM)**

**PHD_DIM.xsd**

**include**

**import**

**DIM_Data_Types.xsd**

**PHD_Import.xsd**

**Enumerations_Bases.xsd**

**redefine**

**Qual_Bases.xsd**

**Notes:**
 This is the PHD-DIM XSchema architecture. The PHD_DIM XSchema adopts the X73 DIM XSchema architecture and re-uses the X73 DIM_Data_Types.xsd, accessing X73 Classic inherited data type definitions.  PHD_Imports.xsd redefine DIM_Data_Types, basically including the inherited types and modifying some of them like measurementStatus, enumVal and nomPartitionEnum. PHD_Data_Type.xsd includes the X73 Classic data types with its modifications and add the new PHD data type definitions. Qual_Bases.xsd was created to allow the qual element to be open, therefore allowing specialization to establish their own constraints. Mandatory qualifiers are fixed in the attribute definition file (PHD_MOC_Attr_Behav_Notif.xsd).

##  ICSGenerator, DIM XSchema and PHD-DIM ICSGenerator Enhancements

- Ability to model X73-PHD 104xx device specializations.
- Added interface for dynamic ICS update.
- New validation tab to show validation errors and ability to update the validation reports at any time.
- Ability to import a default configuration file from the context menu of the tree.
- Improved comparison capability to support agent to manager and device to device comparison types.
- Agent -> Manager : compares the data model objects for interoperability purposes.
- Device -> Device : compares supported features.

**Notes:**
Dynamic ICS update – ICS table ability to dynamically capture changes that impact the ICS table. No need to reload the xml file to see ICS updates.

##  ICSGenerator, DIM XSchema and PHD-DIM Validating 104xx Specializations

- A 104xx device specialization configuration file is created using the IEEE P11073-104xx specialization document.
- XMLSPY is used to capture attribute, behavior and notification information in an xml file (partial configuration file).
- Merges the xml “partial configuration” file with the IEEE P11073-20601 configuration file using an in-house program to get the final configuration file for 104xx specialization.
- The merge adds missing information such as datatypes, term codes, object, attribute, behavior and notification ids.
- The newly created P11073-104xx  specialization file is validated when the file is loaded into the ICSGenerator tool.
- Validation is performed against the IEEE P11073-20601 XSchema and will identify any inconsistencies mostly related to objects, attribute, behavior and notification information.

**Notes:**
Dynamic ICS update – ICS table ability to dynamically capture changes that impact the ICS table. No need to reload the xml file to see ICS updates.

## ICSGenerator, DIM XSchema and PHD-DIMSpecialization Profiles

##  ICSGenerator, DIM XSchema and PHD-DIMX73-10441 (Cardiovascular fitness and activity monitor)

##  ICSGenerator, DIM XSchema and PHD-DIM X73-10441 (Cardiovascular fitness and activity monitor)

##  ICSGenerator, DIM XSchema and PHD-DIMX73-10441 (Cardiovascular fitness and activity monitor)

##  ICSGenerator, DIM XSchema and PHD-DIM X73-10404 (Pulse Oximeter)

##  ICSGenerator, DIM XSchema and PHD-DIM X73-10415 (Weighing Scale)

## ValidatePDU 2.0 and PHD-DIM 

- Current version of ValidatePDU validation
- Validates APDU syntax against X73 DIM specifications and the X73 Application Profiles – Base Standard and
- Validates APDU semantic/content against device profile.
- ValidatePDU must be enhanced to support IEEE P11073-20601 specification:
- Incorporate new and modified PHD data types.
- Extract assertions from the PHD specifications.
- Develop code to properly validate and parse PHD messages.

**Notes:**
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).

## Next Steps 

- Work with Vendors/WGs to validate and verify ICSGenerator Tool and XSchema
- Enhance ValidatePDU to validate PHD type messages.
- Obtain X73 APDUs (from Doug’s simulation tool?) to validate coding (encoding/decoding) of the NIST tool

## Thank You! 

- Questions/Discussion
- Thank you!
- _[www.nist.gov/medicaldevices](http://www.nist.gov/medicaldevices)_