Download
1 / 32
320 likes | 470 Views
POAD Distributed System Case Study: A Medical Informatics System. Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU. Outline. Introduction Requirements of a Medical Informatics System Applying the POAD process The POAD Analysis phase
E N D
POAD Distributed System Case Study: A MedicalInformatics System Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU
Outline • Introduction • Requirements of a Medical Informatics System • Applying the POAD process • The POAD Analysis phase • The POAD Design phase • The POAD Design Refinements phase
Introduction • Distributed information systems are often too complex to develop from scratch. • 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). • Distributed information systems often contain communication subsystems, user interface frameworks, and database solutions. • Due to their complexity, distributed information systems are often hierarchical in nature.
Requirements of a Medical Informatics System • Provides means to manage the distribution and presentation of medical images within the same medical institution and across institutions. • 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 • The Digital Imaging and Communication in Medicine (DICOM) is a standard that defines the communication messages and application services between medical applications. • 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 • DICOM defines information object classes, which provide an abstract definition of the real-world entities applicable to communication of digital medical images. • These classes are called Information Object Definitions (IODs). • 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. • Service classes are defined in terms of service object pairs (SOPs), • 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 • Part 3 of DICOM defines the Information Object Definitions (IODs). • Part 4 defines a number of service classes (SOPs),. • 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. • Application entities use and receive a set of message primitives called DICOM Message Service Elements (DIMSE). • 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 • Part 7 specifies the protocols used by an AE in a medical imaging environment to exchange messages over the network. • Part 8 specifies the upper-layer protocols and communication services necessary to support, in a networked environment, communication between DICOM application entities. • They are referred to as the UL services, which allow peer application entities to establish associations, transfer messages, and terminate associations. • Part 9 is concerned with point-to-point communication between application entities
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 • 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. • The Client AE plays the role of the service class user (SCU) as specified in DICOM standard • The server side is composed of the application entity as a server (Server AE) and the DICOM UL server. • The Server AE plays the role of a service class provider (SCP) as specified in the DICOM standard. • We focus first on developing a pattern-oriented design for the DICOM UL. • Then, we develop a pattern-oriented design for the Client AE.
The POAD Analysis phase for the DICOM UL • 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 • 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 • 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. • This layer has many states, and depending on its state, the behavior of the layer is determined • 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. • We search for patterns that we can use to design components with complex state-based behavior, which is usually the case for reactive systems. • 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 • 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 • Constructing Pattern-Level Diagrams
POAD Analysis for the Client Application Entity Requirements Analysis • The Client AE subsystem provides the medical informatics system user with the interface that handles services initiated by the user as a client. • Client requests are mapped into commands that correspond to specific services. • 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. • 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. • 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. • consider the Abstract Factory • Protocol Machine.The protocol machine is responsible for building DICOM messages from DIMSE constructs. • 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. • 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. • A Statechart pattern is used to design and implement this complex behavior as shown earlier.
