POAD Distributed System Case Study: A Medical Informatics System

1
POAD Distributed System Case Study A
MedicalInformatics System

• Instructor Dr. Hany H. Ammar
• Dept. of Computer Science and Electrical
  Engineering, WVU

2
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

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

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

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

6
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

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

8
Requirements of a Medical Informatics System
DICOM
9
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

10
Requirements of a Medical Informatics System
DICOM
11
Applying the POAD processThe 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 143 illustrates a highlevel structure of
the medical informatics system as a client/server
application connected via a network
12
Applying the POAD processThe 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.

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

14
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 PrimitivesThe messages exchanged between
  the application entities and the UL services
  entities (DICOM UL).

15
The POAD Analysis phase for the DICOM UL Client
16
The POAD Analysis phase for the DICOM UL Server
17
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

18
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

19
POAD Design for DICOM Upper-Layer Subsystem

• Constructing Pattern-Level Diagrams

20
POAD Design for DICOM Upper-Layer Subsystem
21
POAD Design Refinement for the DICOM Upper-Layer
Subsystem
22
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.

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

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

25
POAD Design for the Client Application Entity
26
POAD Design for the Client Application Entity
27
POAD Design for the Client Application Entity
28
POAD Design Refinement for the Client Application
Entity
29
POAD Design Refinement for the Client Application
Entity
30
POAD Design Refinement for the Client Application
Entity
31
POAD Design Refinement for the Client Application
Entity
32
(No Transcript)