IHE Profile – SOA Analysis: In

Progress Update

Brian McIndoe

December 6, 2010

Project Objectives

• To understand how IHE Profiles and SOA concepts can be mapped

• To perform Service Oriented Analysis and Service Modeling on the following IHE Profiles: • Scheduled Workflow (SWF)• Patient Information Reconciliation (PIR)• Reporting Workflow (RWF)

• To look for touch points with the NES Inventory

2

IHE Profiles - Background

• IHE – Integrating the Healthcare Enterprise• An Initiative by healthcare professionals and industry to improve the

way computer systems in healthcare share information• IHE develops and publishes Integration Profiles which describe

clinical information management use cases and specify how to use existing standards (HL7, DICOM, etc) to address them.

• IHE is organized into Domains (e.g., Cardiology, Laboratory, Pharmacy, Radiology, etc).

• IHE Integration Profiles are specified in Technical Framework documents

• Volume I: Provides an overview, identifies actors and the transactions between them

• Volume II and III: Provide detailed descriptions of the transactions (message content and format).

• More can be found on the IHE web site: http://wiki.ihe.net/

3

IHE Profiles and SOA

• Some previous work has been done that looked at the feasibility of leveraging IHE Profiles for SOA. This is documented in • “A Service Oriented Architecture (SOA) View of the IHE Profiles”

(http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_A-Service-Oriented-Architecture_SOA_2009-09-28.pdf)

• This work focused on enterprise document exchange using the following IHE profiles:• Cross Enterprise Document Sharing (XDS)

• Patient Identifier Cross Referencing (PIX)

• Patient Demographics Query (PDQ)

• Audit Train and Node Authentication (ATNA)

• This paper was useful in helping map concepts between the IHE and SOA domains.

4

IHE to SOA Concept Mapping

IHE Concept

IHE Concept Definition Corresponding SOA Concept

Actor Abstraction of the endpoint responsible for the initiation or response to a transaction. Actors are information systems or components of information systems that produce, manage, or act on information associated with operational activities in the enterprise.

Service Provider or Service Consumer

Integration Profile

An IHE Integration Profile specifies a coordinated set of interactions exchanged between the functional components of communicating healthcare IT systems and devices (the actors).

An integration profile might correspond to a service definition, collaboration or a capability, depending upon the scope of

the integration profile.

Transaction Transactions are interactions between actors that communicate/transfer the required information through standards-based messages.

Sometimes similar to a capability or

operation.

5

SOA to IHE Concept Mapping

SOA Concept SOA Concept Definition Corresponding IHE Concept

Service Provider

An entity (person or organization) that offers the use of capabilities by means of a service.

Service Provider is similar to IHE Actors that are recipients of transactions

Service Consumer

An entity which seeks to satisfy a particular need through the use capabilities offered by means of a service

Service Consumer is similar to IHE Actors that are initiators of transactions

Service Capability

A functional/behavioral requirement of the service

Loosely corresponds to transaction or message. Sometimes corresponds directly to an IHE transaction or message, but not always.

Payload Data structures shared between service provider and service consumer

Relates to the IHE profile section called Message Semantics which may or may not reference a content profile

6

SOA and IHE Concepts

7

IHE Workflow Diagram (SWF)

8

IHE Actors

Actor Description

Acquisition Modality

A system that acquires and creates medical images while a patient is present, e.g. a Computed Tomography scanner or Nuclear Medicine camera. A modality may also create other evidence objects such as Grayscale Softcopy Presentation States for the consistent viewing of images or Evidence Documents containing measurements.

ADT A system responsible for adding and/or updating patient demographic and encounter information. In particular, it registers a new patient with the Order Placer and Department System.

DSS/Order Filler

A department-based information system (for instance, Radiology or Laboratory) that provides functions related to the management of orders received from external systems or through the department systems user interface

Image Archive A system that provides long term storage of evidence objects such as images, presentation states, Key Image Notes and Evidence Documents.

Image Manager A system that provides functions related to safe storage and management of evidence objects. It supplies availability information for those objects to the Department System Scheduler.

Order Placer A hospital or enterprise-wide system that generates orders for various departments and distributes those orders to the correct department.

Performed Procedure Step Manager

A system that re-distributes the Modality Performed Procedure Step information from the Acquisition Modality or Evidence Creator to the Department System Scheduler/Order Filler, Image Manager and Report Manager.

Report Manager A system that provides management and short-term storage of DICOM Structured Report objects during the reporting process then distributes text or structured reports to report repositories. It also manages the work-lists and status of reporting. 9

Part of the SWF Workflow

10

The IHE Technical Framework documents have many sequence diagrams that show the general flow of transactions

The Use Cases included in SWF

• Register a Patient• Place an Order• Schedule an Acquisition• Retrieve a Worklist at the Modality• Perform an Acquisition• Generate Images• Store Images to the Archive• Retrieve Images for Review

11

The Method

• The Scheduled Workflow (SWF) was made the focus of this effort as it is fundamental to the other two profiles (PIR, RWF), and is the most complex.

• The first step was to analyze in detail the transactions defined for SWF (20+). This is captured in tabular form in a spreadsheet:

• The last two columns (Entity, Capability) contain my determination of which Entity is the target of the transaction message, and the Capability that would be invoked (if there was one defined by IHE).

12

The Method (cont.)

• The next step was to identify the transactions that supported each use case

13

The Method (cont.)

• Diagramming actors and transactions defined by the IHE for the SWF profile shows that transactions are somewhat chatty:

14

Entities within the SWF Profile

15

IHE Profile – Where Next?

• Identify a general approach for analyzing an IHE Profile to create a SOA design

• What are the options to investigate?

• 1. Wrap the IHE actors and treat them as legacy services. Accept the chatty message traffic.

• 2. Attempt to re-engineer the profiles to have a single “source of truth” for each entity. For data that is spread across actors, would need to decide which is the primary owner.

16