# Presentation: 464134

## Integrating the Healthcare Enterprise, IEEE 11073 and The National Institute of Standards and TechnologyPatient Care Devices DomainTest EffortSeptember 2006

## Introduction

- _NIST PCD Team_
- 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)
- _Agenda_
- Meeting Goals
- PCD background, IEEE 1073, IHE
- Involvement in IHE PCD and IEEE 1073
- Year 1, Year 2+
- High Level Diagram
- IHE PCD Test Cases
- NIST Conformance Test Tools
- HL7 Test Framework (including Message Maker)
- Input POC (HL7) XML message profiles
- Data source (physiologic)
- Output: HL7 test messages
- Test framework
- ICSGenerator
- Implementation Conformance Statements
- Capabilities and Enhancements (since last WG meeting...)
- ValidatePDU
- PDU syntax
- NIST 11073 XSchema
- Issues and Open Discussion...

## Goals

- Describe high-level test focus areas
- Provide Tool Inventory/update:
- Brief description/demonstration of development enhancements
- Pointer/Links for more detail and contact information
- NIST XSchema
- Provide status update
- Discuss/resolve outstanding issues
- Call for vendor review/use of ICSGenerator
- Discuss/Resolve any open issues...

## Integrating the Healthcare Enterprise IHE and NIST

- IHE defines a _Technical Framework_ for the implementation of established messaging standards to achieve specific clinical goals.
- Volume I: Integration Profiles
- Volume II: Transactions
- NIST supports IHE fundamental objective:
- To ensure that in the care of patients all required information for medical decisions is both _correct and available_ to healthcare professionals.
- NIST contributes to a rigorous testing process for the implementation of the Technical Framework.
- Conformance claims by products must still be made in direct reference to specific standards.
- Vendors implementing IHE integration capabilities shall use an IHE Integration Statement to describe the conformance of their product to the specifications in the IHE Technical Framework.

**Notes:**
This slide is a re-iteration that the direction of IHE (via technical framework documents within specified domains) is in alignment of the NIST mission to “enhance economic security and improve the quality of life...”

A rigorous test effort/process is critical to better enable conformance of implementations to specifications (in the IHE Technical Framework and various standards such as IEEE 1073 and HL7).

## IHE/PCD Year 1 Use Cases

- The Patient Care Devices Domain is concerned with Use Cases in which at least one actor is a regulated patient care device.
- Year One Profiles:**- Profile 1: The Enterprise Communication of Patient Care Device Data Integration Profile**
**Goal**: Communicate PCD data to enterprise information systems.
**IHE PCD Profile Name: **Device Enterprise Communication (DEC)
**IHE PCD Transactions**:   PCD-01: Communicate PCD Data
- 				      PCD-02: Subscribe to PCD Data
**      ****IHE PCD Actors**: Device Observation Consumer, Filter, and Reporter **IHE ITI Actor: **Time Client
**	****- Profile 2:** **The Patient Identification Integration Profile**
**Goal**: Bind enterprise unique patient identification to the PCD Data which is communicated to the enterprise
- PCD Test Cases

## ISO/IEEE 11073-60101 HL7(V2.x) ORI [IEEE P1073.6.1.1](Application Gateway)

**1073**
**Network**

**HL7**
**Network**

**1073**
**Device**

**11073/HL7**
**Gateway**

**HL7**
**System**

**HL7**
**System**

- 11073-based communications network where 11073 devices interact and
- an HL7-based communications network, where HL7-based systems interact.
- Problem: A  communication gateway is needed between these two worlds!
- Solution: ISO/IEEE 11073-60101 HL7(V2.x) ORI [IEEE P1073.6.1.1]

**Notes:**
The 1073 Observation Reporting Interface (ORI) is the linkage between what we see as two test efforts.
While the test efforts are distinct, they are inter-related from the standpoint of sharing critical PCD data within the healthcare arena.
The 1073 test effort is in it’s infancy and work will continue to define a more comprehensive test framework.
The IHE test effort will be described in more detail over the next several slides.

## How the NIST Test Framework/Message Maker and ICS-Generator could contribute to the IHE/PCD year one Initiative...

- 1073
- Standard
- (DIM)

- How the NIST Test Framework/Message Maker and ICS-Generator *could* contribute to the IHE/PCD year one Initiative...

- (XSLT)

- Testing
- Framework(***Year 2+)***

***NIST***

*******HL7 v2.x Message Profile: **Captures and describes a set of HL7v2.x messages used to solve a Use Case.

***(Year 2+***** )**

**Notes:**
The IHE Technical Framework identifies the transactions and the standards that it references.
NIST could develop HL7v2.x test messages for an IHE (HL7v2.x) message profile that was based on a transaction that uses HL7 Messaging Standard v2.x or a transaction that uses 1073 medical device data that was mapped to HL7v2.x using the HL7v2.x ORI (gateway) specification. 

Year 2 and beyond:  The ICSGenerator could potentially generate a data set based on users/vendors/implementers selected conformance attributes.
The Testing Framework would be developed to enable test messages (produced from Message Maker) to be utilized as test cases/suites within the enterprise environment.

## Conformance Test Tools

_***NIST HL7 Test Framework***_
_***Message Maker***_
- Message Maker dynamically constructs HL7 messages based on an HL7 message profile.
- Data values for the primitive elements (i.e., Field, Component, and Subcomponent) defined in the profile are obtained from a number of data sources.
- NIST developed database of HL7 primitive data items, HL7 tables, User tables, External tables, local tables, example values from the profiles and default values.
- Test messages can be valid or invalid and contain variation from message to message.
- Example of invalid message is a missing data item for a required field.
- A number of test parameters control the variation in the construction of a message.
- These may include segment and field cardinality, the usage of certain primitive fields, value sets, data content, and more.
- Data content variation is achieved by randomly selecting items from the HL7 items database.
- Framework to test HL7 implementations is under development
**http://www.nist.gov/messagemaker**
**Robert Snelick (robert.snelick@nist.gov)**

## Conformance Test Tools (continued)(based on 11073 DIM Schema)

- Conformance Test Tools (continued)(based on 11073 DIM Schema)

_***ICSGenerator***_
- Facilitates creation of **vendor conformance statements**.
- Provides Medical device data such as parameters or attributes with value ranges and restrictions.  [*This data can be used as needed by Message Maker (in addition to testing options, data source(s) and HL2 V2.x profile file) to build the test messages*.]
**http://www.nist.gov/medicaldevices**

## ICSGenerator Inputs/Outputs

- IEEE 11073

- DIM

- Nomenclature

- ICSGenerator

- Valid XML File

**XSLT**

- ICS

- XSchema File

## ICSGenerator Capabilities

- Generates ICS’s as required in DIM document.
- Ensures common format for ICS generation.
- Generates an electronic (XML) version of device data model based strictly on the IEEE 11073 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
- Ensuring correct containment relationship and terminology at the object class and related attribute, notification and behavior level.
- Device ICS’s comparison capability aids in identifying potential interoperability issues.

## ICSGenerator Enhancements(since last WG meetings [San Antonio, May 06])

- Dynamic tree generation
- Ability to generate UML diagrams
- Device data model comparison reports.
- Exported to HTML or PDF document format.
- General and Service Support ICS captured in XML
- Transport ICS for IRDA Cable Connected profile.
- Ability to handle private or manufacturer-specific extensions.
- DIM MOC, Attribute, Notification and Behavior ICS tables generated into HTML.

## ICSGenerator Enhancements(Continued...)

- Ability to add an Application Guidance Statement for the MOC
- CREATE/DELETE Service Support for MOC's
- Ability to Add Attribute Access for an attribute. (e.g., GET, SET, SCAN...)
- Enhanced ability to Add/Remove Attributes, Behaviors and Notifications.

## Conformance Test Tools (continued)(based on 11073 DIM Schema)

- Conformance Test Tools (continued)(based on 11073 DIM Schema)

_***ValidatePDU***_
- Provides a basic syntax and structure check for a set of captured messages.
_**Future Enhancements**_
- Translating BER/MDER XML
- Needed for 1073 syntax/structure/semantic testing
**http://www.nist.gov/medicaldevices**

## DIM XSchema

- Checks common data types
- Ensures DIM object definition (attributes, behaviors and notifications)
- Ensures containment association
- Represents attributes/notification/behavior inheritance
- Ensures object cardinality
- Ensures term codes (Managed Objects, attributes, behaviors and notifications)
- Validates for proper XML structures
- Checks syntax of XML instances
- Allows for future extentions of the model

## Common data type

- <xsd:element name="InstNumber“ type=“instNumber”/>                <xsd:simpleType name="instNumber">
- 		<xsd:restriction base="iNT-U16"/>
- 	</xsd:simpleType>

## Containment/Object Definition

- <xsd:complexType name="Simple_MDS_Type">
- 	<xsd:annotation>
- 		<xsd:documentation>This type defines the Simple_MDS object including its containment tree.</xsd:documentation>
- 		</xsd:annotation>
- 		<xsd:choice minOccurs="0" maxOccurs="unbounded">
- 		<xsd:element name="OBJECT_NAME">
- 		   <xsd:complexType>
- 		     <xsd:simpleContent>
- 		        <xsd:extension base="Simple_MDS_Object_Name_Type">
- 			<xsd:attribute name="Label" type="xsd:string"/>
- 		         </xsd:extension>
- 		      </xsd:simpleContent>
- 		   </xsd:complexType>
- 		</xsd:element>
- 		<xsd:element name="OBJECT_ID" type="Simple_MDS_Object_Id_Type"/>
- 		<xsd:element name="TERM_CODE" type="Simple_MDS_Term_Code_Type"/>
- 		<xsd:element name="Reference" type="Simple_MDS_Reference_Type"/>
- 		<xsd:element ref="MOC_RESTRICTIONS"/>
- 		<xsd:element ref="MOC_APPLICATION_GUIDANCE"/>
- 		<xsd:element ref="MOC_SERVICES_SUPPORTED"/>
- 		<xsd:element ref="MOC_COMMENT"/>
- 		<xsd:element name="Attribute_Info" type="Simple_MDS_Attribute_InfoType" maxOccurs="unbounded"/>
- 		<xsd:element name="Behaviour_Info" type="Simple_MDS_Behaviour_InfoType" minOccurs="0" 				maxOccurs="unbounded"/>
- 		<xsd:element name="Notification_Info" type="Simple_MDS_Notification_InfoType" minOccurs="0" 			maxOccurs="unbounded"/>
- 		<xsd:element name="Alert" type="AlertType" minOccurs="0" maxOccurs="unbounded"/>
- 		<xsd:element name="Alert_Monitor" type="Alert_MonitorType" minOccurs="0"/>
- 		<xsd:element name="Alert_Scanner" type="Alert_ScannerType" minOccurs="0" maxOccurs="unbounded"/>
- 		<xsd:element name="Alert_Status" type="Alert_StatusType" minOccurs="0"/>
- 		<xsd:element name="Battery" type="BatteryType" minOccurs="0" maxOccurs="unbounded"/>
- 		<xsd:element name="Bedside_Communication_Controller" type="Bedside_Communication_ControllerType" minOccurs="0"
- 					...

## Attribute Definition

- <xsd:group name=“Simple_Mds_Attribute_InfoType">
- 	<xsd:all>
- 	 <xsd:element name="Mds-Status">
- 	  <xsd:complexType>
- 	   <xsd:complexContent>
- 	    <xsd:extension base="Mds_Mds-Status_Type">
- 	      <xsd:attributeGroup ref="System_Application_Attribute_Group"/>
- 	      <xsd:attribute name="derivedFrom" type="xsd:string“ 	default="MDS"/>
- 	    </xsd:extension>
- 	  </xsd:complexContent>
- 	 </xsd:complexType>
- 	</xsd:element> ...
- </xsd:group>

## Attribute Definition  (Cont.)

- <xsd:complexType name="Mds_Mds-Status_Type">
-   <xsd:sequence>
- 	<xsd:element name="ATTRIBUTE_NAME" type="xsd:string" 	fixed="Mds-Status"/>
- 	<xsd:element name="ATTRIBUTE_ID" type="xsd:string" 	fixed="MDC_ATTR_VMS_MDS_STAT"/>
- 	<xsd:element name="ATTRIBUTE_TYPE" type="xsd:string" 	fixed="MDSStatus"/>
- 	<xsd:element name="TERM_CODE" type="xsd:integer" 	fixed="2471"/>
- 	<xsd:element name="Reference" 	type="Mds_Attribute_Reference_Type"/>
- 	<xsd:element name="Qual" type="xsd:string" fixed="C"/>
- 	<xsd:group ref="Attribute_Information"/>
-   </xsd:sequence>
- </xsd:complexType>

## Attribute Groups

- <xsd:attributeGroup name="System_Application_Attribute_Group">
- 	<xsd:attribute name="attrGrpId" type="xsd:string" 	default="MDC_ATTR_GRP_SYS_APPL"/>
- 	<xsd:attribute name="attrGrpName" type="xsd:string" default="System 	Application Attribute Group"/>
- 	<xsd:attribute name="attrGrpTermCode" type="xsd:string" 	default="2058"/>
- 	</xsd:attributeGroup>

## Behavior Definition

- <xsd:complexType name="Simple_MDS_Behaviour_InfoType">
- 	<xsd:sequence>
- 	<xsd:element name="Mds-Set_Status" type="Mds-Set-Status_Type"/>
- 	</xsd:sequence>
- </xsd:complexType>
- <xsd:complexType name="Mds-Set-Status_Type">
- 	<xsd:sequence>
- 	<xsd:element name="METHOD_NAME" type="xsd:string" fixed="Mds-Set-Status"/>
- 	<xsd:element name="METHOD_ID" type="xsd:string" fixed="MDC_ACT_SET_MDS_STATE"/>
- 	<xsd:element name="BEHAVIOUR_ACTION_PARAMETER" type="xsd:string" 	fixed="MdsSetStateInvoke"/>
- 	<xsd:element name="BEHAVIOUR_ACTION_RESULT" type="xsd:string" fixed="MdsSetStateResult"/>
- 	<xsd:element name="TERM_CODE" type="xsd:integer" fixed="3087"/>
- 	<xsd:element name="Reference" type="xsd:string" fixed="clause 7.5.2.2"/>
- 	<xsd:element name="Qual" type="xsd:string" fixed="Confirmed"/>
- 	<xsd:element ref="BEHAVIOUR_RESTRICTIONS"/>
- 	<xsd:element ref="BEHAVIOUR_COMMENT"/>
- 	</xsd:sequence>
- </xsd:complexType>

## Notification Definition

- <xsd:complexType name="Simple_MDS_Notification_InfoType">
- 	<xsd:sequence>
- 	 <xsd:element name="System-Error" type="System-Error_Type"/>
- 	 <xsd:element name="Mds-Create-Notification" type="Mds-Create-	Notification_Type"/>
- 	 <xsd:element name="Mds-Attribute-Update" type="Mds-Attribute-	Update_Type"/>
- 	 <xsd:group ref="Top_Notification_InfoType"/>
- 	</xsd:sequence>
- </xsd:complexType>

## Notification Definition (Cont.)

- <xsd:complexType name="System-Error_Type">
- 	<xsd:sequence>
- 	  <xsd:element name="NOTIFICATION_NAME" type="xsd:string" 	fixed="System-Error"/>
- 	<xsd:element name="NOTIFICATION_ID" type="xsd:string" 	fixed="MDC_NOTI_SYS_ERR"/>
- 	<xsd:element name="NOTIFICATION_EVENT_PARAMETER" 	type="xsd:string" fixed="MdsErrorInfo"/>
- 	<xsd:element name="TERM_CODE" type="xsd:integer" fixed="3349"/>
- 	<xsd:element name="Reference" type="xsd:string" fixed="clause 	7.5.2.3"/>
- 	<xsd:element name="Qual" type="xsd:string" fixed="Unconfirmed"/>
- 	<xsd:element ref="NOTIFICATION_RESTRICTIONS"/>
- 	<xsd:element ref="NOTIFICATION_COMMENT"/>
-   </xsd:sequence>
- </xsd:complexType>

## XML INSTANCE FILE

- <?xml version="1.0" encoding="utf-8"?>
- <DIM xmlns="http://www.nist.X73.gov">
- 	<Simple_MDS>
- 		<OBJECT_NAME Label="">Simple_MDS</OBJECT_NAME>
- 		<OBJECT_ID>MDC_MOC_VMS_MDS_SIMP</OBJECT_ID>
- 		<TERM_CODE>37</TERM_CODE>
- 		<Reference>clause 7.5.3</Reference>
- 		<MOC_RESTRICTIONS/>
- 		<MOC_APPLICATION_GUIDANCE/>
- 		<MOC_COMMENT/>
- 		<Attribute_Info>

## XML Instance (cont.)

- <Mds-Status attrGrpId="MDC_ATTR_GRP_SYS_APPL" attrGrpName="System Application Attribute Group" attrGrpTermCode="2058" derivedFrom="MDS">
- 		<ATTRIBUTE_NAME>Mds-Status</ATTRIBUTE_NAME>			<ATTRIBUTE_ID>MDC_ATTR_VMS_MDS_STAT</ATTRIBUTE_ID>
- 		<ATTRIBUTE_TYPE>MDSStatus</ATTRIBUTE_TYPE>
- 		<TERM_CODE>2471</TERM_CODE>
- 		<Reference>clause 7.5.2.1</Reference>
- 		<Qual>C</Qual>
- 		<ATTRIBUTE_ACCESS/>
- 		<ATTRIBUTE_VALUE_RANGE/>
- 		<ATTRIBUTE_RESTRICTIONS/>
- 		<ATTRIBUTE_APPLICATION_GUIDANCE/>
- 		<ATTRIBUTE_COMMENT/>
- </Mds-Status> ...
- </Attribute_Info>

## Infusion Pump 

- Infusion pump

- Electronic profile

## Containment/Object definition

- XSchematron rules embedded  into the XSchema to solve Xschema constraints of not allowing unordered/unbounded elements.
- This constraint was adding the constraint of maintaining the objects in order, which is not a requirement in the DIM.

## XSchematron rules

- <xsd:element name="Simple_MDS" type="Simple_MDS_Type">
- <xsd:annotation>
- 	<xsd:appinfo>
- 	   <sch:pattern name="testOccurences">
- 		<sch:rule context="Simple_MDS">
- 		<sch:assert test="count(OBJECT_NAME)=1">OBJECT_NAME must appear one time</sch:assert>
- 		<sch:assert test="count(OBJECT_ID)=1">OBJECT_ID in Simlple_MDS must appear one 	time</sch:assert>
- 		<sch:assert test="count(TERM_CODE)=1">TERM_CODE must appear one time</sch:assert>
- 		<sch:assert test="count(Reference)=1">Reference must appear one time</sch:assert>
- 		<sch:assert test="count(MOC_RESTRICTIONS)=1">MOC_RESTRICTIONS must appear one 	time</sch:assert>
- 		<sch:assert test="count(MOC_APPLICATION_GUIDANCE)=1">MOC_APPLICATION_GUIDANCE 	must appear one time</sch:assert>
- 		<sch:assert test="count(MOC_COMMENT)=1">MOC_APPLICATION_GUIDANCE must appear one 	time</sch:assert>
- 		<sch:assert test="count(Attribute_Info)=1">Attribute_Info must appear one time</sch:assert>
- 		<sch:assert test="count(Notification_Info)=1">Notification_Info must appear one 	time</sch:assert>
- 		<sch:assert test="count(Behaviour_Info)=1">Behaviour_Info must appear one time</sch:assert>
- 		<sch:assert test="count(VMD)&lt;2">VMD  in Simple_MDS should appear at most once( 0 or 1) in 	Simple_MDS</sch:assert>
- 		<sch:assert test="count(Clock)&lt;2">Clock  in Simple_MDS should appear at most once( 0 or 	1)</sch:assert>
- 		<sch:assert test="count(Patient_Demographics)&lt;2">Patient_Demographics in Simple_MDS 	should appear at most once( 0 or 1)</sch:assert>
- 		</sch:rule>
- 	</sch:pattern>
-      </xsd:appinfo>
- </xsd:annotation>
- </xsd:element>