1. IHE Profile – SOA Analysis: In Progress Update Brian McIndoe January 18, 2011

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 determine whether it is possible to come up with a generalized approach to IHE Profiles in the SOA world 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 examined 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 Essential component of an IHE Integration Profile that is an abstraction of the endpoint responsible for the initiation or response to a Transaction. 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. Similar to a capability or operation. 5

6. SOA to IHE Concept Mapping SOA ConceptSOA Concept DefinitionCorresponding IHE Concept Service Provider An host that offers the use of capabilities by means of a service Similar to an IHE Actor that is a recipient of a transaction Service Consumer An component which seeks to satisfy a particular need through the use capabilities offered by service providers Similar to an IHE Actor that is an initiator of a transaction Service Capability A function offered by a serviceLoosely corresponds to a transaction or individual message. Sometimes corresponds directly to an IHE transaction, but not always. Payload Data structures shared between service provider and service consumer Relates loosely to an IHE 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. SOA and Modeling Approach Approach used was a simplified version of Thomas Erl’s SOA Analysis and Modeling methodology: Decompose the business process Identify suitable steps for service automation (Candidate Capabilities) Group Capabilities into Candidate Services Identify Candidate Compositions 10

11. Part of the SWF Workflow 11 The IHE Technical Framework documents contain many sequence diagram fragments that show the general flow of transactions. These diagrams and other information in the IHE Technical Volumes was used to create an overall business process activity diagram.

12. Business Process – Activity Diagram 12

13. Each Transaction was Analyzed 13 Each transaction was analyzed in detail to determine which entity was the target of the transaction, and the capability that would be invoked if one was specified by IHE.

14. Additional Views of Transactions 14 A component diagram showing message flows between components was created.

15. List of Candidate Capabilities 15 From this analysis a list of candidate capabilities and related entities was created.

16. Initial Candidate Compositions From this analysis, an initial set of compositions was created. This serves as a start and needs to be reviewed and refined with input from architects and SMEs 16