POAD Distributed System Case Study: A Medical Informatics System Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU

Outline n Introduction n Requirements of a Medical Informatics System n Applying the POAD process – The POAD Analysis phase – The POAD Design phase – The POAD Design Refinements phase

Introduction n Distributed information systems are often too complex to develop from scratch. n The design of such systems involves many frequent design decisions that can be addressed using large-grained design components (e.g., frameworks) and fine-grained design components (e.g., design patterns). n Distributed information systems often contain communication subsystems, user interface frameworks, and database solutions. n Due to their complexity, distributed information systems are often hierarchical in nature.

Requirements of a Medical Informatics System n Provides means to manage the distribution and presentation of medical images within the same medical institution and across institutions. n Among the many other functionalities, a medical informatics system manages – Storage and retrieval of medical information records and images. – Transfer of medical information between various medical locations and sites. – Storage of media. – Communication protocols between collaborating medical institutions. – Records of various medical services provided to patients.

Requirements of a Medical Informatics System: DICOM n The Digital Imaging and Communication in Medicine (DICOM) is a standard that defines the communication messages and application services between medical applications. n The DICOM standard facilitates interoperability of medical imaging equipment by specifying: – A set of protocols to be followed by medical devices. – The syntax and semantics of commands and associated information. – Information that must be supplied with an implementation claiming interoperability and conformance to the standard.

Requirements of a Medical Informatics System: DICOM n DICOM defines information object classes, which provide an abstract definition of the real-world entities applicable to communication of digital medical images. n These classes are called Information Object Definitions (IODs). n DICOM defines a number of service classes. A service class associates one or more IODs with one or more commands to be performed on these objects. n Service classes are defined in terms of service object pairs (SOPs), n An SOP is a combination of an IOD and the commands that are applicable on that IOD. Commands

Requirements of a Medical Informatics System: DICOM n Part 3 of DICOM defines the Information Object Definitions (IODs). n Part 4 defines a number of service classes (SOPs),. n Part 5 specifies how Application Entities (AE) construct and encode the data set information resulting from the use of the IOD and services classes defined in the parts 3 and 4. n Application entities use and receive a set of message primitives called DICOM Message Service Elements (DIMSE). n DIMSE are often grouped in message service groups.These groups are used together with IODs to define SOPs.

Requirements of a Medical Informatics System: DICOM

n Part 7 specifies the protocols used by an AE in a medical imaging environment to exchange messages over the network. n Part 8 specifies the upper-layer protocols and communication services necessary to support, in a networked environment, communication between DICOM application entities. n They are referred to as the UL services, which allow peer application entities to establish associations, transfer messages, and terminate associations. n Part 9 is concerned with point-to-point communication between application entities

Requirements of a Medical Informatics System: DICOM

Applying the POAD process: The POAD Analysis phase The first analysis step is to decompose the system at a high level into large components (subsystems) and define their interconnections. Figure 14–3 illustrates a highlevel structure of the medical informatics system as a client/server application connected via a network

Applying the POAD process: The POAD Analysis phase n At a very high level the client side is composed of the two subsystems: the application entity as a client (Client AE) and the DICOM UL client. n The Client AE plays the role of the service class user (SCU) as specified in DICOM standard n The server side is composed of the application entity as a server (Server AE) and the DICOM UL server. n The Server AE plays the role of a service class provider (SCP) as specified in the DICOM standard. n We focus first on developing a pattern-oriented design for the DICOM UL. n Then, we develop a pattern-oriented design for the Client AE.

The POAD Analysis phase for the DICOM UL n The UL services allow peer application entities to establish association and transfer messages. There are three options for communication in DICOM: – A minimum OSI (Open System Interconnection) stack of protocols with a full-duplex Session Kernel, Presentation Kernel, – A UL protocol augmenting TCP/IP, or – A point-to-point protocol stack.

The POAD Analysis phase for the DICOM UL client n Requirements Analysis. For this case study, the DICOM specification documents define the functional requirements for the communication subsystem functionalities: – DICOM UL: The UL protocol is related to the session, presentation, and part of the application layer of the ISO reference model. – DIMSE: The DICOM Message Service Element is a set of DICOM applicationlayer communication messages.These messages define the possible services, such as storing and retrieving images and queries. – PDU Messages: Protocol Data Unit (PDU) messages are the messages exchanged between peer entities within a layer in the ISO reference model. A PDU consists of protocol control information and user data. – Message Primitives:The messages exchanged between the application entities and the UL services entities (DICOM UL).

The POAD Analysis phase for the DICOM UL Client

The POAD Analysis phase for the DICOM UL Server

The POAD Analysis phase for the DICOM UL n When studying the specification of this layer in the DICOM standard, we find that it is a heavily state-based engine that reacts to many events. n This layer has many states, and depending on its state, the behavior of the layer is determined n Acquaintance and Retrieval. Based on the analysis of the specification that we conducted in the previous step, we conclude that the DICOM UL is a state-based component with complex behavior. n We search for patterns that we can use to design components with complex state-based behavior, which is usually the case for reactive systems. n A set of five statechart patterns [Yacoub & Ammar] are found —Basic Statechart, Hierarchical Statechart, Orthogonal Behavior, Broadcasting, and History State

The POAD Analysis phase for the DICOM UL n Pattern Selection. Since the DICOM UL is a state-based subsystem, we use state machine patterns. Since the behavior of the UL is complex, it is better to manage the complexity using statecharts. Thus, we use the Statechart patterns [Yacoub & Ammar]

POAD Design for DICOM Upper- Layer Subsystem n Constructing Pattern-Level Diagrams

POAD Design for DICOM Upper- Layer Subsystem

POAD Design Refinement for the DICOM Upper-Layer Subsystem

POAD Analysis for the Client Application Entity Requirements Analysis n The Client AE subsystem provides the medical informatics system user with the interface that handles services initiated by the user as a client. n Client requests are mapped into commands that correspond to specific services. n Examples of the command initiated by the user include retrieval of an image, storage of an image, storage of a study conducted on a patient, retrieval of the information about a specific visit, and retrieval of information about a patient.

POAD Analysis for the Client Application Entity Acquaintance, Retrieval, and Pattern Selection – First, the client side application should have a graphical user interface (GUI) to make it easy for the client to interact with the client DICOM AE. n consider the Model View Controller (MVC) pattern – We need to look for patterns to communicate user requests to other application entities that handle the requests or commands. n consider the Command pattern – Service Object Pairs. The creation of an SOP is not a simple procedure. Client AE may support several SOPs and service classes. n consider the Abstract Factory – Protocol Machine.The protocol machine is responsible for building DICOM messages from DIMSE constructs. n A Builder pattern is used to facilitate the process of construction complex messages using its constituting parts.

POAD Analysis for the Client Application Entity Acquaintance, Retrieval, and Pattern Selection (Cont.) – Message Coordinator: To coordinate message exchange between the DICOM UL, the SCU (implementing an SOP), and the protocol machine, a message coordinator is used. n Message coordinator can be implemented by the Mediator pattern. – DICOM UL Client. The DICOM UL provides the OSI service related to presentation and session services. It also provides services related to association establishment. n A Statechart pattern is used to design and implement this complex behavior as shown earlier.

POAD Design for the Client Application Entity

POAD Design Refinement for the Client Application Entity