Integrating the Healthcare Enterprise: Orientation for IHE Columbia March 25, 2014 including slides...

68
Integrating the Healthcare Enterprise: Orientation for IHE Columbia March 25, 2014 including slides from other presentations that were edited for today’s purpose

Transcript of Integrating the Healthcare Enterprise: Orientation for IHE Columbia March 25, 2014 including slides...

Integrating the Healthcare Enterprise: Orientation for IHE

Columbia

March 25, 2014including slides from other presentations

that were edited for today’s purpose

Agenda• 1- What is IHE – beginning with discussion of interoperability• 2- What are the Domains and its Committees• 3- What is the PCD Domain• 4- How a Use Case is proposed, and prioritized, by whom, when• 5- How the Technical Committee deals with the proposal • 6- How some standards are selected to construct the Profile• 7- How the profile is actually built - tested• 8- What tools are available (NIST - Gazelle, other)• 9- What is a Connectathon (purpose - structure)• 10- What should be the profile of the participants to these

Teleconferences (from vendors and from Universities)

www.ihe.net

Integrating the Healthcare Enterprise (IHE)

IHE is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE promotes the coordinated use of established standards such as DICOM and HL7 to address specific clinical needs in support of optimal patient care. Systems developed in accordance with IHE communicate with one another better, are easier to implement, and enable care providers to use information more effectively.

3

www.ihe.net

Interoperability – What me Worry?

• “Interoperability”, or more accurately the “Lack of Interoperability”, is a hot topic these days…

• What is the issue?– Most, if not all, EMRs can connect to devices– We have a growing contingent of vendors (Capsule, Nuvon,

Cerner, etc.) providing device integration services– Patient monitoring vendors have created integrated

systems incorporating many 3rd party devices.– Clinicians have developed many demonstrations and

applications requiring device interoperability.

4

www.ihe.net

Interoperability – What me Worry?

• These solutions meet every definition of Interoperability that we are aware of…

• All these solutions demonstrate that we have Interoperability in the medical device space!

• So, what is the Problem?

5

www.ihe.net

Interoperability – Is the Problem…?

• Is the problem that…?– Each new device integration is a custom effort requiring

months of effort using skilled engineers?– Clinicians desiring to use a new device must wait for their

vendor to develop a new driver?– The complexity of device interfacing is stopping research

which could lead to improved patient care?– Purchasing decisions are driven by whether an interface to

specific devices exists?– Safety issues can arise due to the sizable software effort

and on-site customization required to integrate devices?– Costs to the healthcare Providers for system integration

services are very high?

6

www.ihe.net

Interoperability – The Solution is…?

• The solution is…– Device Interoperability based on Framework(s) of

Open Standards, Profiles, Conformance Testing, Certification Testing, etc.

– Requirements that all parties must comply with the Framework(s)

• We can call this “Open Interoperability” …• What is the role of IHE PCD in promoting

“Open Interoperability”?

7

www.ihe.net

Dimensions of InteroperabilityPhysical InteroperabilityTransport (Lower Layers) InteroperabilitySyntactic InteroperabilitySemantic InteroperabilitySecure InteroperabilitySafe InteroperabilityAuthenticated InteroperabilitySecure Interoperability

www.ihe.net

IHE Domains• IHE is organized by clinical and operational domains. In each

domain users with clinical and operational experience identify integration and information sharing priorities and vendors of relevant information systems develop consensus, standards-based solutions to address them.

• The variety of medical equipment requires that developers specialize in areas such as imaging, lab, eye care, etc.

• IHE supports this by providing “domains”. These are listed and described at http://www.ihe.net/IHE_Domains/

9

www.ihe.net 10

17 Years of Steady Evolution 1998 – 2014The IHE Development Domains

Pharmacysince 2009

Pathologysince 2006

Radiation Oncologysince 2004

Radiologysince 1998

Cardiologysince 2004

Patient Care Coordination

since 2004Now including home care devices, telehealth, and

PHRs

Eye Caresince 2006

QualityResearch & Public Health

since 2006

Laboratorysince 2004

(Healthcare)IT Infrastructure

since 2003

Endoscopysince 2010

Dentistrysince 2010

Mobile devices Under way for 2014!

Surgerysince 2012

Look carefully: MOST Domains have “devices!”

Patient Care Devicessince 2005

1111

Contributing &Participating

Vendors provide SMEs

26 Deployment Committee Board seats

IHE Europe

IHE North America

France

USA

Canada

IHE Asia-Oceania

Japan

Korea Australia

Netherlands

Spain Sweden UKItaly

Germany

Norway

China

Austria

IHE is Primarily USER drivenProfessional Societies & Gov’t agencies must be primary “sponsors”

e.g., HIMSS, RSNA, American College of Cardiology, Saudi Ministry of Health

IHE Board is Global and Interdisciplinary AND User driven!

14 Development Domain Board seats

Radiology

Cardiology

ITInfrastructure

Patient CareCoordination

Patient CareDevices

Laboratory

Pathology

Eye CareRadiationOncology

Public Health, Quality and Research

Pharmacy

11

Endoscopy Dentistry

www.ihe.net

Role of IHE PCD• IHE PCD was formed in 2005 to address issues

related to integration of Point-of-Care medical devices:– With each other– With enterprise systems

• IHE PCD wants to “raise the bar” from the current state of integration projects to out of the box, open, interoperable solutions.

• IHE PCD’s co-sponsors are HIMSS, ACCE and AAMI.

www.ihe.net

Profile and Use Case Development• Basic Use Case development and proposals

identified...• If accepted, detailed Use Case developed…• If resources, Profiles developed - which are

the technical documents that define the message construction in detail.

• Profiles are developed in well defined and public ways.

• Profiles are tested (per IHE yearly cycle).• Profiles are updated and edited when needed.

13

www.ihe.net

Technical Framework, Profiles, Options

The Technical Framework provides the high level material and profiles that have been tested and are relatively stable. New profiles (“Supplements”) begin in Trial Implementation versions and may have optional components or optionally utilize other profiles.

www.ihe.net

Profile and Use Case DevelopmentThe process:• Someone proposes a profile, indicates why it is needed, and includes

examples (use cases) of where and when the profile will be used (the “Brief Profile Proposal”).

• The Planning Committee (PC) votes to determine if this is a worthwhile effort.

• If approved, a “Detailed Profile Proposal” is presented to the Technical Committee (TC).

• If approved and there are a reasonable number of people willing to work on it, the Profile is written.

• The Profile is balloted by the TC to determine if it is ready for public comment.

• Comments received are addressed and the document is revised.• The profile is published.

15

www.ihe.net

IHE Profiles Are Standards-Based• Profiles are based upon existing standards. The TC

looks for applicable standards. If the most relevant standard has shortcomings the TC will request that standards organization to update its standard to accommodate these requests.

• When companies test their implementations at venues such as a Connectathon they may find issues with the Profile. These are addressed with Change Proposals.

16

www.ihe.net

On the Road to Interoperability:From Base Standards to Profiles

Profile Standards

Base Standards eHealth Projects

IHTSDO

IETF

Specific Restrictions

Feedback Feedback

www.ihe.net

IHE Profiles Are Standards-Based

• Why aren’t the standards themselves sufficient?

18

www.ihe.net

Standards are:Foundational - to interoperability and communicationsBroad - varying interpretations and implementationsNarrow - may not consider relationships between standards

domainsPlentiful - often redundant or disjointedFocused - standards implementation guides focus only on a

single standard

Standards are Necessary but not Sufficient !!

Just follow the Standards…

www.ihe.net20

IHE Standards Adoption Process

20Document Use Case RequirementsDocument Use Case Requirements

Identify available standards (e.g. HL7, DICOM, IEEE, IETF)

Identify available standards (e.g. HL7, DICOM, IEEE, IETF)

Develop technical

specifications

Develop technical

specifications

Testing at ConnectathonsTesting at Connectathons IHE

DemonstrationsIHE Demonstrations

Products with IHEProducts with IHE

Easy to integrate productsEasy to integrate products 20

Improved safety, quality & efficiency!Improved safety, quality & efficiency!

www.ihe.net

Completed: Rosetta Terminology Management (RTM) Enterprise sharing of Patient Care Data (DEC) PCD Alarm Communication Management (ACM) Point-of-Care Infusion Verification (PIV) Pulse Oximetry Integration (POI) Infusion Pump Event Communication (IPEC)

Implantable Device – Cardiac Observation (IDCO)Waveform Content Module (WCM)Retrospective Data Query (RDQ)

In Process: Event Communication (EVT) Point-of-Care Identity Management (PCIM) Medical Equipment Management (MEM) Device Specializations for Infusion and Other Devices

IHE PCD – Profiles – Overall List

www.ihe.net

The Rosetta Project

22

The Rosetta Project provides robust assurance that messages sent can be accurately interpreted without ambiguity or omission.

www.ihe.net

Tools and Other Resources

23

NIST Tools are used in development and in informal (Pre-Connectathon or with no relation to the Connectathon) and in Connectathon testing (see slide for Gazelle).

www.ihe.net24

North AmericanConnectathon

NISTMedical Device Communication Testing

Rosetta Terminology Mapping Management System - RTMMSJohn J. GarguiloNational Institute of Standards and Technology

March 25, 2013 – Introduction to RTMMS for IHE-

Columbia

Contact: [email protected], 301-975-5248

26

NIST MDC Testing ProjectWeb Sites

John J. Garguilo (FTE), 301-975-4248, [email protected]

Nicolas Crouzier(GR) – lead developer

• Project Web site: www.nist.gov/medicaldevices• NIST HL7 V2 Test Tooling Web sites:

– IHE-PCD Pre-Connectathon:

http://hit-testing.nist.gov:13100/PCD-HL7WebPreCon/

• IHE-PCD Connectathon: http://hit-testing.nist.gov:13100/PCD-HL7WebCon/

• NIST Medical Device Terminology Service:– Rosetta Terminology Mapping Management System (RTMMS):

http://hit-testing.nist.gov:13110/rtmms/

Semantic Interoperability of Medical Devices26

27

Medical Device InteroperabilityUsing ‘Profiles’ To Advance Rigorous Testing

Integrating the Healthcare Enterprise (IHE)Patient Care Devices (PCD)

AssertionsHL7 v2

StandardMessageDefinition

IHE TFMessage

TransactionConstraints

HL7 v2Standard

Value Sets

IHE TFMessage

TransactionValue Set

Constraints

HarmonizedRosetta

TerminologyMapping

Constraints

ISO/IEEE 11073

Nomenclature

ValidationContext

File(XML)

TableLibrary(XML)

ConformanceProfile(XML)

Test CaseSpecific

TestAssertions

IHE-PCD TFMessage

TransactionTest

Assertions

ValidationContext

File(XML)

User / Device

MessageE.g., HL7 V2

MessageE.g., HL7 V2

Specification Constraints

Terminology/NomenclatureTerminology/Nomenclature

StandardsProfile

StandardsProfile

DomainFramework

DomainFramework

Test Case/Value(s)

Test Case/Value(s)

Based on Use Case(s)

ReportReport

ValidationTest

ManagementTest

Management

Test ServicesTest Services

Test System Development Components

Test System Development Components

Test HarnessTest Harness

Test ResourcesTest Resources

Test System Instance

Test System Instance

Testable Assertions: IHE-PCD Validation Requirements

Used by NIST Test Tools

28

IHE-PCD Rosetta Terminology Mapping

29

IHE-PCD Rosetta Terminology Mapping

IHE PCD Technical Framework Content

VendorTerms

RTM

1606 rows

HarmonizedTerms

hRTM

660 terms

ISO/IEEE 11073Semantic Standards

Vendor A

Vendor B

Vendor C

HL7 V2 Messages

HL7 V3 CDA/CCD

11073PnP Comm

VendorSemantics

• Open consensus process• Observation identifiers and co-constraints• New terms incorporated into standards• hRTM used for conformance testing

Slide developed and provided by Paul Schluter, GE Healthcare

30

PCD-01 Message Example, HL7 V2

MSH|^~\&|HL7^080019FFFF4F6AC0^EUI-64|MMS|||20070118133700||ORU^R01|a4e2e3:11036b5cdbb:-|P|2.6|20070118133700||NE|AL||8859/1PID|||GE101^^^DefaultDomai||JACKSON^IRWIN^^^^^LPV1||E|3WICU^305^305OBR|1|080019FFFF4F6AFE200701|080019FFFF4F6AC0200701|126.3.3.1^2000^MDC|||20070118133700OBX|1|NM|147842^MDC_ECG_HEART_RATE^MDC|1.6.1.1|80|/min^/min^UCUM|||||ROBX|2|NM|148065^MDC_ECG_V_P_C_CNT^MDC|1.6.1.2|0|/min^/min^UCUM|||||ROBX|3|NM|150035^MDC_PRESS_BLD_ART_MEAN^MDC|1.3.1.1|96|{mm[Hg]}^{mm[Hg]}^UCUM|||||ROBX|4|NM|150033^MDC_PRESS_BLD_ART_SYS^MDC|1.3.1.2|120|{mm[Hg]}^{mm[Hg]}^UCUM|||||ROBX|5|NM|150034^MDC_PRESS_BLD_ART_DIA^MDC|1.3.1.3|80|{mm[Hg]}^{mm[Hg]}^UCUM|||||ROBX|6|NM|149522^MDC_BLD_PULS_RATE_INV^MDC|1.2.1.1|80|/min^/min^UCUM|||||ROBX|7|NM|150047^MDC_PRESS_BLD_ART_PULM_MEAN^MDC|1.4.2.1|15|{mm[Hg]}^{mm[Hg]}^UCUM|||||ROBX|8|NM|150045^MDC_PRESS_BLD_ART_PULM_SYS^MDC|1.4.2.2|24|{mm[Hg]}^{mm[Hg]}^UCUM|||||ROBX|9|NM|150046^MDC_PRESS_BLD_ART_PULM_DIA^MDC|1.4.2.3|10|{mm[Hg]}^{mm[Hg]}^UCUM|||||ROBX|10|NM|150344^MDC_TEMP^MDC|1.10.1.1|26.4|cel^cel^UCUM|||||ROBX|11|NM|150344^MDC_TEMP^MDC|1.10.1.2|37.4|cel^cel^UCUM|||||ROBX|12|NM|151610^MDC_VENT_CO2_RESP_RATE^MDC|1.5.1.1|12|{{breath}/min}^{{breath}/min}UCUM|||||ROBX|13|NM|151804^MDC_PRESS_AWAY_END_EXP_POS^MDC|1.5.1.2|4|{cm[H20]}^{cm[H20]}^UCUM|||||ROBX|14|NM|152008^MDC_VENT_VOL_MINUTE_AWAY^MDC|1.5.1.3|0.0|l/min^l/min^UCUM|||||ROBX|15|NM|151920^MDC_VENT_CONC_AWAY_O2_INSP^MDC|1.5.1.4|21|%^%^UCUM|||||ROBX|16|NM|151980^MDC_VENT_VOL_TIDAL^MDC|1.5.1.5|920|ml^ml^UCUM|||||ROBX|17|NM|151957^MDC_VENT_PRESS_MAX^MDC|1.5.1.6|17|{cm[H20]}^{cm[H20]}^UCUM|||||ROBX|18|NM|151784^MDC_PRESS_RESP_PLAT^MDC|1.5.1.7|31|{cm[H20]}^{cm[H20]}^UCUM|||||ROBX|19|NM|151792^MDC_PRESS_AWAY^MDC|1.5.1.8|36|{cm[H20]}^{cm[H20]}^UCUM|||||ROBX|20|NM|151808^MDC_PRESS_AWAY_END_EXP_POS_INTRINSIC^MDC|1.5.1.9|1|{cm[H20]}^{cm[H20]}^UCUM|||||R

‘Heart Rate’ ‘/min’ UOM

Termcode OBX-4Unified Code for Units

Regenstrief Institute

Value

ReferenceID

31

Terminology – RTMMS – Rosetta Terminology Mapping Management System

32

• A web application that allows vendors and reviewers access, retrieval, and reporting of Rosetta Tables over the internet in conformance to RTM

• Aids in the harmonization process by:– Identifying missing terms – Facilitating the proposal of new terms– Facilitating discussion of the proposed term– Automatic generation of the “Harmonized Rosetta Table”

• A web service/tool used as part of SDO’s ballot / approval process  • Fulfills Critical Need of Conformance Tooling

– Message verification and conformance (semantics)– Leading to interoperability…                                

RTMMS – What is it?

33

RTMMS – What is it?

For Vendors• Facilitate input of entries by vendors

• Tooltips providing supplementary information• Available Interface to lookup values from the database• Automatic completion of codes• Validation of required content

• Reduce errors made by vendors while submitting entriesFor Reviewers and SDO

• Facilitate the automated generation of the Harmonized Rosetta• Helps the review process of Rosetta entries

• Highlighting discussed entries• Highlighting proposed REFIDs• Interface to view discussions and add comments

For all users• Rosetta data available to everyone any time / particular data access

controlled• Provide XML version of tables

NIST HL7 V2 IHE-PCD Test Tool Briefing(2013-2014 Cycle 8+)Pre-Connectathon + Connectathon

John J. Garguilo

National Institute of Standards and Technology

March 25th 2014 (WebEx 2:00 – 3:00 PM to IHE-

Columbia)

Contact: [email protected]

35

NIST IHE-PCD V2 Test EffortNIST Team Members

• John Garguilo ([email protected], 301-975-5248)• Nicolas Crouzier ([email protected] Guest Researcher)

NIST HL7 V2 Tool Web sites:

Instance Test Environment (Pre + Connectathon):

http://hit-testing.nist.gov:13100/PCD-HL7WebCon/

Isolated Test Environment: (Pre-Connectathon):

http://hit-testing.nist.gov:13100/PCD-HL7WebPreCon/

RTMMS: (Medical Device Terminology / 11073 database):

http://hit-testing.nist.gov:13110/rtmms/index.htm

36

IHE-PCD Testing

IHE-PCD Testing – Key Objectives• Increase test comprehensiveness & quality • Support both conformance & interoperability testing• Support for Pre- & Virtual-Connectathons, and Connectathon

& enable year round testing• Remain in alignment with IHE-PCD integration profile

development road map• Establish single framework for PCD covering increasing

complexity and technologies over next 3 years• Coordinate with IHE “Gazelle Project”• Generate work products that companies can use in their

regulatory submissions

37

Why do this?…

• Intended to promote a test strategy to meet key testing objectives (specialized for IHE-PCD domain)

• Communicate a recommended common path forward to IHE-PCD participants, Domain Test Managers, and Test Tool developers– More comprehensive documentation– Feed-back mechanism into more complete technical framework and standards

• A focused testing approach for IHE-PCD – Cycle 8+ “2013/14 Pre- and Virtual- Connectathons” / 2014 Connectathon– HL7 V2 (2.6) messages– Using a “centralized testing approach”, no firewall issues (IP/port configured)?– To show conformance of vendor produced messages to specifications

• HL7 Standard• IHE-PCD TF and Supplements• hRTM• IHE-PCD Pre-connectathon and Connectathon Test Cases (Registered by IHE via Gazelle)

• Designed for IHE-PCD Membership ease-of-use

38

What is NOT discussed today…

• Focused on other IHE domains (i.e., outside of IHE-PCD)• Training on a “polished” tool

– We need your feedback… the more collaborative the better– All PCD members need to collaborate (e.g., via Testing Google group)– See ‘Issues’ slide near end of this presentation…

• A lesson in HL7• An HL7 Profile building tool

– A replacement for other tooling – e.g., Message Workbench (MWB)

39

Advantages of NIST Tooling• Simplicity of use, quick feedback (via reports)

– 24 hour x 365 day availability– Test Management Capability – easily record your test results

• Viewable by IHE-PCD Test Manager (aka Manny Furst)

• Tooling focused on IHE-PCD – including:– Current profiles, including recently adopted CPs, – Framework, Supplement, and Trial Implementation Documentation – PCD Test cases – pre-loaded to match/be synchronized with Gazelle– Level of rigor matches specifications (reference standards and TF docs)

• No Conformance Profile needed– Already Integrated into the NIST tooling…

• No stand-alone application installation needed (NIST web site interface)

• MDC nomenclature/terminology included [hRTM]• Support of NIST team and synergy w/ IHE-PCD group

40

Tooling Status Summary

Testing in Cycle 8 (2013-14) - HL7 V2 Validation (IHE-PCD) • Instance-type Environment (at message level) / Pre and

Connectathon Setting– http://hit-testing.nist.gov:13100/PCD-HL7WebCon/– http://hit-testing.nist.gov:8080/HL7Web/ (general use site – domain agnostic)

• Isolated-type Environment / Pre-Connectathon Setting– Scenario based– Actor centric– One System Under Test (SUT)– http://hit-testing.nist.gov:13100/PCD-HL7WebPreCon/

• Both environments incorporate RTM – Rosetta Terminology Mapping Management System (RTMMS)– dBase/Web Interface at: http://hit-testing.nist.gov:13110/rtmms/index.htm

41

NIST IHE-PCD Test Tool: Actors / Transactions Supported

IHE-PCD Profile/HL7 Version 2.6 Transaction[HL7 V2.6 Message Type]

Actors (Source / Receiving)

Device Enterprise Communication – DEC- DEC w/ WCM (option)

PCD-01 – Communicate PCD Data[ORU^R01^ORU_R01]

Reporter / Consumer

Device Enterprise Communication, Subscribe to Patient Data - DEC SPD (Option)

PCD-02 – Communicate PCD Data[QSB^Z02^QSB_Q16]

Reporter / *Filter / Consumer*Grouped w/ DOR*Stand-alone

Point of Care Infusion Verification – PIV

PCD-03 – Communicate Infusion Order[RGV^O15^RGV_O15]

Programmer / Consumer

Alert Communication Mgmt - ACM- ACM w/ WCM (option)

PCD-04 – Report Alert[ORU^R40^ORU_R40]

Reporter / Manager

Implantable Device Cardiac Observation – IDCO

PCD-09 – Communicate IDC Observation [ORU^R01^ORU_R01]

Reporter / Consumer

Infusion Pump Event Communication – IPEC

PCD-10 – Communicate Infusion Pump Event [ORU^R42^ORU_R01]

Reporter / Consumer

42

NIST IHE-PCD Test Tool: Actors / Transactions Supported,continued

IHE-PCD Profile/HL7 Version 2.6 Transaction Actors (Source / Receiving)

Pulse Oximetry Integration with Clinical Applications– POI- DEC DOR test cases

PCD-01 – Communicate PCD Data[ORU^R01^ORU_R01]

Reporter / Consumer

Retrospective Data Query- RDQ

PCD-12 – Communicate Asynchronous Data Query [QBP^Z12^QBP_Q11]PCD-13 - Communicate Asynchronous Data Query Response[RSP^Z13^RSP_K11]

Consumer / Responder*Initial test cases not vetted through WG

NIST Testing Strategy

44

NIST Testing Strategy Test Environments

• Instance Testing– Conformance (e.g., against HL7 2.x or CDA)

• Implementation conforms to Spec. on which it is based• IHE Model: ~Virtual and Pre-Connectathon

• Isolated System Testing– Includes Instance Testing Activities– Protocol Conformance – Functional Behavior Conformance

• Features and Operational behavior correspond to Specs.• IHE Model: ~Virtual and Pre-Connectathon

• Peer-to-Peer System Testing– Includes Isolated System Testing Activities– Interoperability Testing

• Testing complete application environment • May include interacting w/ Database, using Network Communications, or interacting w/ other

hardware, apps, or systems if appropriate• IHE Model: ~Connectathon

45

IHE-PCD Pre-Connectathon NIST Instance Testing Support

NIST V2 Testing Tool is available for message validation using the ‘instance testing’ environment:

ReportReport

Test Artifacts• Conformance Profile• HL7 Tables• ‘Device’ Test Agents• ISO/IEEE

11073/Rosetta Terminology

Test Artifacts• Conformance Profile• HL7 Tables• ‘Device’ Test Agents• ISO/IEEE

11073/Rosetta Terminology

HL7 V2MessageValidation

HL7 V2MessageValidation

Services Test Management

HL7 V2 Message

Validation Test Case

HL7 V2 Message

Validation Test Case

ResultsHL7 V2

MessageValidation

Report

ResultsHL7 V2

MessageValidation

Report

Test Harness(Java Code)

Test Harness(Java Code)

Test Execution

User

Web Application

Client

HL7 V2 Message

HL7 V2 Message

Registry/Repository http://hit-testing.nist.gov:13100/PCD-HL7WebCon/

46

NIST Testing Strategy Test Environments

• Instance Testing– Conformance (e.g., against HL7 2.x or CDA)

• Implementation conforms to Spec. on which it is based• IHE Model: ~Virtual and Pre-Connectathon

• Isolated System Testing– Includes Instance Testing Activities– Protocol Conformance – Functional Behavior Conformance

• Features and Operational behavior correspond to Specs.• IHE Model: ~Virtual and Pre-Connectathon

• Peer-to-Peer System Testing– Includes Isolated System Testing Activities– Interoperability Testing

• Testing complete application environment • May include interacting w/ Database, using Network Communications, or interacting w/ other

hardware, apps, or systems if appropriate• IHE Model: ~Connectathon

47

IHE-PCD Pre-Connectathon NIST Isolated Testing Support

NIST V2 Testing Tool is available for message validation using the ‘isolated testing’ environment:

http://hit-testing.nist.gov:13100/PCD-HL7WebPreCon/

ReportReport

IHE-PCDDOR/DOFTest Agent

IHE-PCDDOR/DOFTest Agent

HL7 V2Message

Generation

HL7 V2Message

Generation

IHE-PCDDOC

Test Agent

IHE-PCDDOC

Test Agent

HL7 V2MessageValidation

HL7 V2MessageValidation

ServicesTest Management

Router/Logger/Proxy

Vendor

System Under Test

Test Artifacts•Conformance Profiles•HL7 Tables•Validation Context Files•Generation Context Files

IHE-PCD ClientTest Scenario

IHE-PCD ClientTest Scenario

ResultsHL7 V2 Message

Validation Reports

ResultsHL7 V2 Message

Validation Reports

Test Harness(Java Code)

Test Harness(Java Code)

Test Execution

Web Application

Client

IHE-PCDIOR

Test Agent

IHE-PCDIOR

Test Agent

IHE-PCDAM

Test Agent

IHE-PCDAM

Test Agent

IHE-PCDIOC

Test Agent

IHE-PCDIOC

Test Agent

IHE-PCDAR

Test Agent

IHE-PCDAR

Test Agent

IHE-PCDIDCC

Test Agent

IHE-PCDIDCC

Test Agent

IHE-PCDIDCR

Test Agent

IHE-PCDIDCR

Test Agent

48

Test Environment Message ValidationNIST V2 Testing Tools: IHE-PCD

• Validation of IHE-PCD message(s) and corresponding HL7 Profile(s)

• Syntax and Semantic Content Validation– Against HL7 V2 message (e.g., PCD-01)

• Message structure (e.g., MSH,PID,PV1,OBR,NTE,{{OBX},OBX,OBX,OBX,…})

– Against HL7 profile• (Msg_type^Event_type^ e.g., ORU^R01^ORU_R01…)

– Against HL7 and/or user provided tables (value sets)• Example of user provided table is RTM for Ref_IDs, Units, etc.

– Against ‘validation context’, including specific values• Defined in XML (e.g., specific test case values)

49

• Validation against ‘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 and ServicesTesting Validation Types

Overview of the NISTHL7 V2 IHE-PCDPre-Connectathon Test Tools

51

NIST HL7 V2 IHE-PCD Test Tool: Access• Web-based application (no downloads or installations needed)

– ‘Isolated’ Site: http://hit-testing.nist.gov:13100/PCD-HL7WebPreCon/– ‘Instance’ Site: http://hit-testing.nist.gov:13100/PCD-HL7WebCon/

• Tool may be used in Anonymous Mode or Registered Mode– Anonymous Mode (“Guest” Users)

• Does not require user registration and may be used to conduct ad-hoc system testing

– Registered Mode (upper right corner of tool interface)• Required for completing the Pre-Connectathon • -- Could be used for participating in the Connectathon• Required to save Pre-Connectathon test results• Test reports are made available to the IHE project manager

52

NIST V2 HL7 IHE-PCD Test Tool: Operational Process

END-USER(VENDOR)

SYSTEM UNDER TEST (SUT)

NIST IHE-PCD HL7 v2/v3 TEST TOOL

SPECIFICATIONS(test material that defines test assertions)

INTERACTION/REPORTS

MESSAGES (TEST OBJECTS)

STIMULUS OR RESPONSE (MESSAGES)

MANUAL OR AUTOMATED SUT

Web Application Interface

(via the communication protocolcurrently only MLLP)

V3 – Future Work

53

HL7 V2 Tool Updates (New Features for Cycle 8 and beyond)• Test event results now stored and selectable

– Maintain (test management) data from test events– E.g., “Cycles 1-7” [< 2012], “Pre-Connectathon 2013-14 (Cycle 8)”,

etc.• Profile Viewer (shows message structure attributes)• Resource Management Capability Added• Test Case Scenario Viewer (Sequence Diagrams)

• New Directions (tool component research/work)– Constrains definition and generation methodologies and utilities

54

HL7 V2 (2.6) Tool Features

• Documentation Tab (see coming slides)– Conformance Profile Tab– Patient Demographics– IDCO Patient Demographics– PIV Drugs– Other Resources– Looking into capability to upload libraries + demographics (future)

– incorporated [automatically] into validation context files used by tooling

55

HL7 V2 Tool Features, Continued: Test Event Selection

56

HL7 V2 Tool Features, Continued – Profile Viewer

57

HL7 V2 Tool Features, Continued – Test Case Viewer

58

HL7 V2 Tool Features, Continued

• Current Version / Release Notes

59

HL7 V2 Tool Features, Continued

• Documentation Tab– Conformance Profiles

60

HL7 V2 Tool Features, Continued

• Documentation Tab– Patient Demographics

61

HL7 V2 Tool Features, Continued

• Documentation Tab– IDCO Patient Demographics

62

HL7 V2 Tool Features, Continued

• Documentation Tab– PIV Drugs

www.ihe.net

Publicizing Conformance

63

A vendor can state their claim of IHE profile based open interoperability using an IHE Integration Statement. To understand the scale of the results of the interoperability efforts by IHE a vendor independent examination of those results might be useful. Confirmation of successful vendor participation in annual IHE Connectathons can be reviewed by IHE profile, profile actor, or Connectathon event at the IHE Connectathon Results web site at… http://connectathon-results.ihe.net IHE USA ICSA Labs Certified products are listed on the ICSA Labs web site at… https://www.icsalabs.com/products?tid%5b%5d=4965

www.ihe.net

IHE Profiles Drafted & Revised

6-13 mos.

Implementation Posted

Install Interoperable

products in Clinical Settings

worldwide

Install Interoperable

products in Clinical Settings

worldwide

Demonstrate at aDemonstrate at a

IHE Improves, Safety, Quality

and Efficiency in Clinical Settings.

14-18 mos.

Publish in IHE’s Product Registry

Test at IHE Connectathons

PublishedFor PublicComment

IHE Technical Framework Developed

IHE Call for Proposals Opens

IHE Call for Proposals Opens

Profile Selection by Committees

1-5 mos.

Summary: IHE Process/Cycle

www.ihe.net

IHE Patient Care Devices (PCD)

Key Benefits of PCD Interoperability

• Heterogeneity – Multiple manufacturers + multiple device modalities coexisting over a shared infrastructure

• Semantic Interoperability (comparability) – shared terminology and data models permit users to interpret data based on the clinical context, compare information from different healthcare facilities, and interrogate systems across enterprises and regions.

• Real-Time Availability – ability to provide data in a time frame appropriate to the physiologic function being measured, displayed or affected (controlled).

www.ihe.net

Simplify product development processSpend time innovating rather than supporting

infrastucture work – again & again & ...Facilitate clinical decision support - innovation -

increased functionality Reduce regulatory impact/work Improve patient safety - reduce liability - make

operations easier - device aware

PCD Vendor Value Proposition

www.ihe.net

Next Steps• Identifying resources

– Recorded descriptions of various domains– Recorded tutorials (e.g., NIST tools) and White Papers– Identifying IHE domains, their working groups and their

meetings and documentation

• Future Orientation and Tutorial Webex Presentations– PCD and perhaps other domains (e.g., ITI)– Goals and timetable of IHE Columbia that can be assisted

by the PCD domain

• What is the larger picture for IHE Columbia?– Who can participate in each step?

67

www.ihe.net68

Next Steps