Integrating the Healthcare Enterprise: Orientation for IHE Columbia March 25, 2014 including 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)

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

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

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

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

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) “Open Interoperability” We can call this “Open Interoperability” … What is the role of IHE PCD in promoting “Open Interoperability”? 7

Dimensions of Interoperability Physical Interoperability Physical Interoperability Transport (Lower Layers) Interoperability Transport (Lower Layers) Interoperability Syntactic Interoperability Syntactic Interoperability Semantic Interoperability Semantic Interoperability Secure Interoperability Secure Interoperability Safe Interoperability Safe Interoperability Authenticated Interoperability Authenticated Interoperability Secure Interoperability Secure Interoperability

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 9

Years of Steady Evolution 1998 – 2014 The IHE Development Domains Pharmacy since 2009 Pathology since 2006 Radiation Oncology since 2004 Radiology since 1998 Cardiology since 2004 Patient Care Coordination since 2004 Now including home care devices, telehealth, and PHRs Eye Care since 2006 Quality Research & Public Health since 2006 Laboratory since 2004 (Healthcare) IT Infrastructure since 2003 Endoscopy since 2010 Dentistry since 2010 Mobile devices Under way for 2014! Surgery since 2012 Look carefully: MOST Domains have “devices!” Patient Care Devices since 2005

1111 Contributing & Participating Vendors provide SMEs 26 Deployment Committee Board seats IHE Europe IHE North America France USA Canada IHE Asia-Oceania Japan KoreaAustralia Netherlands Spain Sweden UK Italy Germany Norway China Austria IHE is Primarily USER driven Professional 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 IT Infrastructure Patient Care Coordination Patient Care Devices Laboratory Pathology Eye CareRadiation Oncology Public Health, Quality and Research Pharmacy 11 Endoscopy Dentistry

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.

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

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.

Profile and Use Case Development The 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

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

On the Road to Interoperability: From Base Standards to Profiles Profile Standards Base Standards eHealth Projects IHTSDO IETF Specific Restrictions Feedback

IHE Profiles Are Standards-Based Why aren’t the standards themselves sufficient? 18

Standards are: Foundational - to interoperability and communications Foundational - to interoperability and communications Broad - varying interpretations and implementations Broad - varying interpretations and implementations Narrow - may not consider relationships between standards domains Narrow - may not consider relationships between standards domains Plentiful - often redundant or disjointed Plentiful - often redundant or disjointed Focused - standards implementation guides focus only on a single standard Focused - standards implementation guides focus only on a single standard Standards are Necessary but not Sufficient !! Just follow the Standards…

20 IHE Standards Adoption Process 20 Document Use Case Requirements Identify available standards ( e.g. HL7, DICOM, IEEE, IETF) Develop technical specifications Testing at Connectathons IHE Demonstrations Products with IHE Easy to integrate products 20 Improved safety, quality & efficiency!

Completed: 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: 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

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

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

24 North AmericanConnectathon

NIST Medical Device Communication Testing Rosetta Terminology Mapping Management System - RTMMS John J. Garguilo National Institute of Standards and Technology March 25, 2013 – Introduction to RTMMS for IHE-Columbia Contact:

26 NIST MDC Testing Project Web Sites John J. Garguilo (FTE), , Nicolas Crouzier(GR) – lead developer Project Web site: NIST HL7 V2 Test Tooling Web sites: –IHE-PCD Pre-Connectathon: IHE-PCD Connectathon: NIST Medical Device Terminology Service: – Rosetta Terminology Mapping Management System (RTMMS): Semantic Interoperability of Medical Devices 26

27 Medical Device Interoperability Using ‘Profiles’ To Advance Rigorous Testing Integrating the Healthcare Enterprise (IHE) Patient Care Devices (PCD) Assertions HL7 v2 Standard Message Definition IHE TF Message Transaction Constraints HL7 v2 Standard Value Sets IHE TF Message Transaction Value Set Constraints Harmonized Rosetta Terminology Mapping Constraints ISO/IEEE Nomenclature Validation Context File (XML) Table Library (XML) Conformance Profile (XML) Test Case Specific Test Assertions IHE-PCD TF Message Transaction Test Assertions Validation Context File (XML) User / Device Message E.g., HL7 V2 Specification Constraints Terminology/ Nomenclature Standards Profile Domain Framework Test Case/ Value(s) Test Case/ Value(s) Based on Use Case(s) Report Validation Test Management Test Services Test System Development Components Test Harness Test Resources 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 Vendor Terms RTM 1606 rows Harmonized Terms hRTM 660 terms ISO/IEEE Semantic Standards Vendor A Vendor B Vendor C HL7 V2 Messages HL7 V3 CDA/CCD PnP Comm Vendor Semantics 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||| ||ORU^R01|a4e2e3:11036b5cdbb:- |P|2.6| ||NE|AL||8859/1 PID|||GE101^^^DefaultDomai||JACKSON^IRWIN^^^^^L PV1||E|3WICU^305^305 OBR|1|080019FFFF4F6AFE200701|080019FFFF4F6AC | ^2000^MDC||| OBX|1|NM|147842^MDC_ECG_HEART_RATE^MDC| |80|/min^/min^UCUM|||||R OBX|2|NM|148065^MDC_ECG_V_P_C_CNT^MDC| |0|/min^/min^UCUM|||||R OBX|3|NM|150035^MDC_PRESS_BLD_ART_MEAN^MDC| |96|{mm[Hg]}^{mm[Hg]}^UCUM|||||R OBX|4|NM|150033^MDC_PRESS_BLD_ART_SYS^MDC| |120|{mm[Hg]}^{mm[Hg]}^UCUM|||||R OBX|5|NM|150034^MDC_PRESS_BLD_ART_DIA^MDC| |80|{mm[Hg]}^{mm[Hg]}^UCUM|||||R OBX|6|NM|149522^MDC_BLD_PULS_RATE_INV^MDC| |80|/min^/min^UCUM|||||R OBX|7|NM|150047^MDC_PRESS_BLD_ART_PULM_MEAN^MDC| |15|{mm[Hg]}^{mm[Hg]}^UCUM|||||R OBX|8|NM|150045^MDC_PRESS_BLD_ART_PULM_SYS^MDC| |24|{mm[Hg]}^{mm[Hg]}^UCUM|||||R OBX|9|NM|150046^MDC_PRESS_BLD_ART_PULM_DIA^MDC| |10|{mm[Hg]}^{mm[Hg]}^UCUM|||||R OBX|10|NM|150344^MDC_TEMP^MDC| |26.4|cel^cel^UCUM|||||R OBX|11|NM|150344^MDC_TEMP^MDC| |37.4|cel^cel^UCUM|||||R OBX|12|NM|151610^MDC_VENT_CO2_RESP_RATE^MDC| |12|{{breath}/min}^{{breath}/min}UCUM|||||R OBX|13|NM|151804^MDC_PRESS_AWAY_END_EXP_POS^MDC| |4|{cm[H20]}^{cm[H20]}^UCUM|||||R OBX|14|NM|152008^MDC_VENT_VOL_MINUTE_AWAY^MDC| |0.0|l/min^l/min^UCUM|||||R OBX|15|NM|151920^MDC_VENT_CONC_AWAY_O2_INSP^MDC| |21|%^%^UCUM|||||R OBX|16|NM|151980^MDC_VENT_VOL_TIDAL^MDC| |920|ml^ml^UCUM|||||R OBX|17|NM|151957^MDC_VENT_PRESS_MAX^MDC| |17|{cm[H20]}^{cm[H20]}^UCUM|||||R OBX|18|NM|151784^MDC_PRESS_RESP_PLAT^MDC| |31|{cm[H20]}^{cm[H20]}^UCUM|||||R OBX|19|NM|151792^MDC_PRESS_AWAY^MDC| |36|{cm[H20]}^{cm[H20]}^UCUM|||||R OBX|20|NM|151808^MDC_PRESS_AWAY_END_EXP_POS_INTRINSIC^MDC| |1|{cm[H20]}^{cm[H20]}^UC UM|||||R ‘Heart Rate’‘/min’ UOM Termcode OBX-4 Unified 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 entries For 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 ( Cycle 8+) Pre-Connectathon + Connectathon John J. Garguilo National Institute of Standards and Technology March 25 th 2014 (WebEx 2:00 – 3:00 PM to IHE-Columbia) Contact:

35 NIST IHE-PCD V2 Test Effort NIST IHE-PCD V2 Test Effort NIST Team Members John Garguilo Nicolas Crouzier Guest NIST HL7 V2 Tool Web sites NIST HL7 V2 Tool Web sites: Instance Test Environment (Pre + Connectathon): Isolated Test Environment: (Pre-Connectathon): RTMMS: (Medical Device Terminology / database):

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 ( ) - HL7 V2 Validation (IHE-PCD) Instance-type Environment (at message level) / Pre and Connectathon Setting – – (general use site – domain agnostic) Isolated-type Environment / Pre-Connectathon Setting –Scenario based –Actor centric –One System Under Test (SUT) – Both environments incorporate RTM –Rosetta Terminology Mapping Management System (RTMMS) –dBase/Web Interface at:

41 NIST IHE-PCD Test Tool: Actors / Transactions Supported IHE-PCD Profile/HL7 Version 2.6Transaction [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.6TransactionActors (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: Report 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 V2 Message Validation HL7 V2 Message Validation Services Test Management HL7 V2 Message Validation Test Case HL7 V2 Message Validation Test Case Results HL7 V2 Message Validation Report Results HL7 V2 Message Validation Report Test Harness (Java Code) Test Harness (Java Code) Test Execution User Web Application Client HL7 V2 Message HL7 V2 Message Registry/ Repository

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: Report IHE-PCD DOR/DOF Test Agent IHE-PCD DOR/DOF Test Agent HL7 V2 Message Generation HL7 V2 Message Generation IHE-PCD DOC Test Agent IHE-PCD DOC Test Agent HL7 V2 Message Validation HL7 V2 Message Validation Services Test Management Router/Logger/Proxy Vendor System Under Test IHE-PCD Client Test Scenario IHE-PCD Client Test Scenario Results HL7 V2 Message Validation Reports Results HL7 V2 Message Validation Reports Test Harness (Java Code) Test Harness (Java Code) Test Execution Web Application Client IHE-PCD IOR Test Agent IHE-PCD IOR Test Agent IHE-PCD AM Test Agent IHE-PCD AM Test Agent IHE-PCD IOC Test Agent IHE-PCD IOC Test Agent IHE-PCD AR Test Agent IHE-PCD AR Test Agent IHE-PCD IDCC Test Agent IHE-PCD IDCC Test Agent IHE-PCD IDCR Test Agent IHE-PCD IDCR Test Agent

48 Test Environment Message Validation NIST 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 Services Testing Validation Types

Overview of the NIST HL7 V2 IHE-PCD Pre-Connectathon Test Tools

51 NIST HL7 V2 IHE-PCD Test Tool: Access Web-based application (no downloads or installations needed) –‘Isolated’ Site: –‘Instance’ Site: 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 protocol currently 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 (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

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… IHE USA ICSA Labs Certified products are listed on the ICSA Labs web site at…

IHE Profiles Drafted & Revised 6-13 mos. ImplementationPosted Install Interoperable products in Clinical Settings worldwide Demonstrate at a IHE Improves, Safety, Quality and Efficiency in Clinical Settings mos. Publish in IHE’s Product Registry Test at IHE Connectathons Published For Public Comment IHE Technical Framework Developed IHE Call for Proposals Opens Profile Selection by Committees 1-5 mos. Summary: IHE Process/Cycle

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

Simplify product development process Spend 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

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

Next Steps 68