1. IHE Profile – SOA Analysis: In Progress Update Brian McIndoe December 6, 2010

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

3. 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/http://wiki.ihe.net/ 3

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

5. IHE to SOA Concept Mapping IHE Concept IHE Concept DefinitionCorresponding 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

6. SOA to IHE Concept Mapping SOA ConceptSOA Concept DefinitionCorresponding 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

7. SOA and IHE Concepts 7

8. IHE Workflow Diagram (SWF) 8

9. IHE Actors ActorDescription 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

10. Part of the SWF Workflow 10 The IHE Technical Framework documents have many sequence diagrams that show the general flow of transactions

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

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

13. The Method (cont.) The next step was to identify the transactions that supported each use case 13

14. The Method (cont.) Diagramming actors and transactions defined by the IHE for the SWF profile shows that transactions are somewhat chatty: 14

15. Entities within the SWF Profile 15

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