Figures 7-1a, 7-1b and 7-3 depict the DICOM view of the Real-World which identifies the relevant Real-World Objects and their relationships within the scope of the DICOM Standard. It provides a common framework to ensure consistency between the various Information Objects defined by the DICOM Standard.
Figure 7-1a DICOM MODEL OF THE REAL-WORLD
Figure 7-1bDICOM MODEL OF THE REAL-WORLD - PRINT
Figure 7-2a DICOM INFORMATION MODEL
Figure 7-2b DICOM INFORMATION MODEL - PRINT
Figure 7-2c DICOM INFORMATION MODEL - RADIOTHERAPY
Figure 7-2d DICOM INFORMATION MODEL - IMPLANT TEMPLATES
Figure 7-3.MODEL OF THE REAL WORLD FOR THE PURPOSE OF MODALITY-IS INTERFACE
The DICOM Information Model is derived from the DICOM Model of the Real-World. The DICOM Information Model presented by Figures 7-2a, 7-2b , 7-2c and 7-2d identify the various IODs specified by this Standard and their relationships. There is not always a one-to-one correspondence between DICOM Information Object Definitions and Real-World Objects. For example a Composite IOD contains Attributes of multiple real-world objects such as series, equipment, frame of reference, study and patient.
The entities in Figures 7-2a, 7-2b, 7-2c and 7-2d correspond to IODs defined in Annexes A through C.
Annex A defines Composite IOD's (e.g. Images) acquired on a number of Modalities (e.g. CT, MR, NM, US, CR, Secondary Capture). These Composite IOD's reference Modules found in Annex C.
Annex B defines Normalized IODs (e.g. Film Session, Print Job) for a number of Service Classes specified in PS 3.4. These Normalized IODs reference Module definitions found in Annex C.
For the purpose of the Basic Worklist Management Service Class and the Modality Performed Procedure Step SOP Classes an enhancement of the original DICOM Model of the Real-World is made, as depicted in Figure 7-3.
The PS 3.17 Annex entitled Integration of Modality Worklist and Modality Performed Procedure Step in the Original DICOM Standard discusses the relationship of this extension to the original DICOM model of the real world.
Figure 7-3 is an abstract description of the real world objects invoked in the Modality-IS Interface. It is not to be seen as a database scheme for an implementation.
A Patient is a person receiving, or registered to receive, healthcare services, or is the subject of one or more studies for some other purpose, such as research.
Note: A patient may be a human or an animal.
A Service Episode is a collection of events, aggregated during an interval bounded by start and stop times. A Service Episode is the context in which the treatment or management of an arbitrary subset of a Patient’s medical conditions occurs. The definition of the start time, stop time, and included events of a Service Episode is entirely arbitrary; it may include a single outpatient visit or a hospitalization, or extend over significant period of time, e.g., the duration of a pregnancy, or an oncology treatment regimen, or a cardiac episode from infarction through rehabilitation. A Service Episode may involve one or more Healthcare Organizations (administrative entities that authorize Healthcare Providers to provide services within their legal administrative domain, e.g. hospitals, private physician’s offices, multispecialty clinics, nursing homes).
A subset of Service Episode, the Visit, is the collection of events that fall under the accountability of a particular Healthcare Organization in a single facility. A Visit may be associated with one or more physical locations (e.g. different rooms, departments, or buildings) within the Healthcare Organization's definition of a facility, with admission and discharge diagnoses and with time boundaries of the visit.
Notes: 1. The Visit is a part of the Service Episode. The Service Episode describes several administrative aspects of healthcare, while the Visit is limited to the description of one visit of a Patient to a facility.
2. In the context of the Modality Worklist SOP Class, the attributes of the Service Episode are defined in the Visit modules.
3. The attributes for Visit often use the term “admission” for historical reasons, although a visit in an ambulatory clinic does not involve an admission as an in-patient.
An Imaging Service Request is a set of one or more Requested Procedures selected from a list of Procedure Types. An Imaging Service Request is submitted by one authorized imaging service requester to one authorized imaging service provider in the context of one Service Episode. An Imaging Service Request includes pertinent specific and general information. Each instance of an Imaging Service Request carries the information common to one or more Requested Procedures requested at the same moment. An Imaging Service Request may be associated with one or more Visits that occur within the same Service Episode. The existence of an Imaging Service Request will typically result in the creation of one or more Imaging Service Reports and the distribution of Imaging Service Reports to one or more destinations.
In the context of the Modality Worklist the information provided by the Imaging Service Request aims at performing one or more imaging procedures, i.e. at acquiring new images. In the context of the General Purpose Worklist the information provided by the Imaging Service Request supports a more general kind of request, e.g. reporting, requesting an image processing procedure on an existing examination, etc.
A Procedure Type identifies a class of procedures. In the context of imaging services, a Procedure Type is an item in a catalog of imaging procedures that can be requested and reported upon in an imaging service facility. An instance of a Procedure Type typically has a name and one or more other identifiers. A Procedure Type is associated with one or more Procedure Plans.
Note: The information content of this entity relates to the general identification of a Procedure Type rather than to its decomposition into the protocol(s) required to perform a specific instance of a Requested Procedure for a particular Patient.
A Requested Procedure is an instance of a Procedure of a given Procedure Type. An instance of a Requested Procedure includes all of the items of information that are specified by an instance of a Procedure Plan that is selected for the Requested Procedure by the imaging service provider. This Procedure Plan is defined by the imaging service provider on the basis of the Procedure Plan templates associated with the considered Procedure Type. An Imaging Service Request may include requests for several different Requested Procedures. The purpose of this entity is to establish the association between Imaging Service Requests and Procedure Types, to convey the information that belongs to this association and to establish the relationships between Requested Procedures and the other entities that are needed to describe them. A single Requested Procedure of one Procedure Type is the smallest unit of service that can be requested, reported, coded and billed. Performance of one instance of a Requested Procedure is specified by exactly one Procedure Plan. A Requested Procedure leads to one or more Scheduled Procedure Steps involving Protocols as specified by a Procedure Plan. A Requested Procedure may be associated with one or more Visits. A Requested Procedure may involve one or more pieces of equipment.
A Modality Scheduled Procedure Step is an arbitrarily defined scheduled unit of service, that is specified by the Procedure Plan for a Requested Procedure. A Modality Scheduled Procedure Step prescribes Protocol which may be identified by one or more protocol codes. A Modality Scheduled Procedure Step involves equipment (e.g. imaging Modality equipment, anesthesia equipment, surgical equipment, transportation equipment), human resources, consumable supplies, location, and time (e.g. start time, stop time, duration). While in the context of imaging services the scheduling of a Modality Scheduled Procedure Step might include only a general designation of imaging Modality that could be satisfied by multiple pieces of the same equipment type, the performance of one instance of a Modality Scheduled Procedure Step involves one and only one piece of imaging Modality equipment.
The performance of a Modality Scheduled Procedure Step may result in the creation of zero or more Modality Performed Procedure Step instances.
Notes: 1. The Procedure Step entity is provided to support management of the logistical aspects of procedures (e.g. materials management, human resources, scheduling). The full definition of the contents of Procedure Steps and protocols according to which they are performed is implementation dependent and is beyond the scope of this Standard.
2. A Modality Scheduled Procedure Step may contribute to more than one Requested Procedure (e.g. a Modality Scheduled Procedure Step requiring an intravenous iodine contrast injection might be shared by an intravenous pyelogram and a CT examination). However, for billing purposes an instance of a Modality Scheduled Procedure Step is typically considered to be a part of only one Requested Procedure.
A Procedure Plan is a specification that defines the set of Protocols that must be done in order to perform the Scheduled Procedure Steps of a Requested Procedure. Each Scheduled Procedure Step is preformed according to a single Protcol which may be identified by one or more Protocol Codes. The Protocols actually performed during a Procedure Step may differ from those prescribed in the related Procedure Plan. Audit of actually performed Protocols versus the prescribed Procedure Plan is an important element of quality control, but is not specified by this Standard.
Note: The fact that Protocols Codes are in a given order in a Procedure Plan is not evident in Figure 7.3. However, the order of Protocols is represented at the syntax level (i.e. as the sequence of items present in the Protocol Code Sequence (0040,0008)).
A Protocol is a specification of actions prescribed by a Procedure Plan to perform a specific Procedure Step. A Scheduled Procedure Step contains only one Protocol which may be conveyed by one or more Protocol Codes. Typically, the code or codes identifying a Protocol instance would be selected from a catalog of protocols. Multiple Protocols may not exist in one Scheduled Procedure Step.
A Performed Procedure Step is an arbitrarily defined unit of service that has actually been performed (not just scheduled). Logically it corresponds to a Scheduled Procedure Step, but real-world conditions may dictate that what is actually performed does not correspond exactly with what was requested or scheduled.
Note: For example, two or more Scheduled Procedure Steps, Requested Procedures or Imaging Service Requests may have been generated by different Referring Physicians but may be satisfied be a single Performed Procedure Step at the discretion of a Performing Physician or Operator. Alternatively, a single Scheduled Procedure Step may need to be satisfied by multiple Performed Procedure Steps on different types or instances of equipment, due to clinical need or failure conditions, or over extended periods of time.
It contains information describing the type of procedure actually performed. This information is represented by the Performed Protocol that may be defined by one or more Protocol Codes.
A Requested Procedure results in the creation of zero or more Performed Procedure Steps.
A Scheduled Procedure Step results in the creation of zero or more Performed Procedure Steps.
The Performed Procedure Step contains information about its state (e.g. in progress, discontinued or completed).
A Modality Performed Procedure Step is a Performed Procedure Step that results from activity (such as the acquisition of images from a Patient or other Imaging Subject) on a Modality.
It contains information describing the performance of a step of an imaging procedure, including data about the performance of the procedure itself, and data for billing and material management.
The Modality Performed Procedure Step contains references to zero or more Series of Images and other Composite SOP Instances that may be created as part of the procedure step. A particular Series is part of only one Modality Performed Procedure Step.
The purpose of the Modality Performed Procedure Step is to report what was performed; it does not imply any storage semantics. While the MPPS represents a unit of service within a workflow, the specification of the workflow itself is beyond the scope of the Standard, and the MPPS does not identify or control any subsequent activities to be performed.
Notes: 1. For example, a modality may create both “for processing” images for automated analysis and “for presentation” images for human review from the same acquisition. The Standard does not specify whether the production of these is a single unit of service, or two. A single Modality Performed Procedure Step instance could list both the “for processing” images and the “for presentation” images, regardless of whether or not both sets of images were stored to the same or different AEs, or indeed were stored at all, since the MPPS is independent of the storage semantics. Alternatively, the modality may treat these two sets of images as two separate units of service, and send two separate MPPS Instances.
A Radiation Dose SR from the irradiation events of an acquisition could be referenced in the same MPPS Instance as that of the acquired images, again irrespective of where such a Radiation Dose Structured Report might be sent, if at all. Alternatively, the modality may treat the production of the Radiation Dose SR as a separate unit of service, and report it in a distinct MPPS.
Another example is the case of thin and thick slice CT images acquired from the same acquisition (raw) data. When the reconstruction of both sets of images is prospectively defined and automatically initiated by the protocol selection, then both sets might be referenced from a single MPPS Instance. However, if the reconstruction of one or the other set is performed retrospectively by manual intervention some time after the acquisition MPPS had been completed, the subsequent instances will necessarily be referenced in a new MPPS Instance, since the acquisition MPPS cannot be modified once completed.
2. The completion of an MPPS may be a significant event that triggers or enables downstream activity, but it is not the intent to require the modality to be configured to “manage” such activity. The “units of service” that the modality describes in an MPPS, and how the modality relates those Performed Procedure Steps to Scheduled Procedure Steps, are implementation decisions beyond the scope of the Standard. The IHE Radiology Scheduled Workflow Profile provides additional guidance for implementation.
3. An MPPS may describe instances that were acquired but that have not been, nor may ever be, stored. For example, a modality may be capable of storing a CT acquisition as multiple single frame CT Image Storage SOP Instances, as a single multi-frame Enhanced CT Image Storage SOP Instance, or as several Enhanced CT Image Storage SOP Instances that together comprise a Concatenation. An MPPS may describe all three possibilities, even though only one choice may ultimately be stored, perhaps depending on the negotiated capabilities of the storage recipient. Alternatively, separate MPPS instances could be used for different storage SOP Classes.
4. The MPPS is not a substitute for, nor is equivalent to, a Storage Commitment request, nor an Instance Availability Notification.
A General Purpose Scheduled Procedure Step is an arbitrarily defined scheduled unit of service, that is specified by the Procedure Plans of one or more Requested Procedures. A General Purpose Scheduled Procedure Step prescribes one Workitem that describes the procedure step to be performed. A General Purpose Scheduled Procedure Step involves applications, human resources, location, and time resources (e.g. start time, stop time, duration).
Notes: 1. In this section, application is the generic term used to designate software applications and pieces of devices.
2. The status of a general Purpose Scheduled Procedure Step must not be confused with the status of the Requested Procedure or Imaging Service Request to which it belongs. One General Purpose Scheduled Procedure Step may be completed, but that does not imply that also the related Requested Procedure has reached its completion.
A General Purpose Scheduled Procedure Step contains references to Composite SOP Instances or Performed Procedure Steps, which denote the information to be used for the performance of the General Purpose Scheduled Procedure Step.
A general Purpose Performed Procedure step is an arbitrarily defined unit of service that has actually been performed ( not just scheduled ). Normally it corresponds to one General Purpose Scheduled Procedure step, but real-world conditions may dictate that what is actually performed does not correspond exactly with what was requested or scheduled.
Note: For example, two or more General Purpose Scheduled Procedure Steps, Requested Procedures or Imaging Service Requests may have been generated by different Referring Physicians but may be satisfied by a single General Purpose Performed Procedure Step at the discretion of a Performing Physician or Operator. Alternatively, a single General Purpose Scheduled Procedure step may need to be satisfied by multiple General Purpose Performed Procedure Steps on different types or instances of equipment, due to clinical need or failure conditions, or over extended periods of time.
It contains information describing the type of procedure actually performed.
A Requested Procedure results in the creation of zero or more General Purpose Performed Procedure Steps.
A General Purpose Scheduled Procedure Step results in the creation of zero or more General Purpose Performed Procedure Steps.
The General Purpose Performed Procedure Step contains information about its state.
It contains information describing the performance of the general purpose procedure step of a procedure.
The General Purpose Performed Procedure step contains references to zero or more Composite SOP Instances that have been created as part of the procedure step.
A Workitem is one of the tasks prescribed by a Procedure Plan to perform an instance of a Requested Procedure. Each General Purpose Scheduled Procedure Step will contain exactly one Workitem. The code identifying a Workitem instance would be selected from a catalog of workitem types, for example with the value of Image Processing or Interpretation.
A Clinical Document is a part of the medical record of a patient. A Clinical Document is a documentation of clinical observations and services and has the following characteristics:
Persistence - A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements.
Stewardship - A clinical document is maintained by an organization entrusted with its care.
Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.
Context - A clinical document establishes the default context for its contents.
Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
Human readability - A clinical document is human readable.
Note: This definition is from ANSI/HL7 CDA R1.0-2000, and HL7 v3 CDA R2-2005.
Clinical Documents may provide significant context for the performance of imaging and related procedures, e.g., patient clinical history, pre-imaging-procedure lab test results, or patient advance medical directives.
Clinical Documents may be associated with Service Episodes, Service Requests, Requested Procedures, or other entities subsidiary to the Patient in the Real-World Model. Such associations are not explicitly modeled for the purposes of the Modality-IS or General Purpose Worklist contexts.
Clinical Documents are one sub-class of the class of healthcare Structured Documents; Structured Documents, in general, are not necessarily related to a patient. Structured Documents may be used for imaging procedure operational instructions, e.g., in product labeling, Procedure Plans, or patient care plans.
Notes: 1. The format and semantics of Structured Documents, including Clinical Documents, are defined outside the scope of the DICOM Standard (e.g., by HL7). DICOM provides the means to reference Structured Documents within the Modality-IS and General Purpose Worklist contexts.
2. The general class of Structured Documents is not modeled in the Real-World Model; only specific sub-classes, e.g., Clinical Documents, are modeled.
For the purpose of the General Purpose Worklist SOP Class in the Worklist Management Service Class an extension of the DICOM Model of the Real-World is made, as depicted in Figures 7.4.a and 7.4.b.
This subset of the real-world model covers the requirements for the General Purpose Worklist SOP Class in the Worklist Management Service Class.
Figures 7.4.a and 7.4.b are an abstract description of the real world objects involved in Workflow Management.
Figure 7.4.a Model of the real world for the purpose of General Purpose Worklist interface
Figure 7.4.bModel of the real world for the purpose of General Purpose Worklist interface
For the purpose of accommodating large sets of frames in Multi-frame Image SOP Instances the Real-World Entity Relationship Diagram has been extended to describe the relationships of these instances: Concatenation (see Section 7.5.1) and Dimension Organization (see Section 7.5.2). Figure 7-5.1 depicts the additions to Figure 7-2.
[pic]Figure 7.5-1 EXTENSION OF THE REAL-WORLD MODEL WITH CONCATENATIONS AND DIMENSIONS
For implementation specific reasons (such as practical limits on the maximum size of an individual SOP Instance) the content of a multi-frame image may need to be split into more than one SOP Instance. These SOP Instances together form a Concatenation, which is a group of SOP Instances within a Series that is uniquely identified by the Concatenation UID (0020,9161).
The Dimension Organization contains a set of dimensions. A dimension is a set of attributes which change on a per-frame basis in a manner which is known before the image is acquired, which are defined by the generating application and which are especially intended for presentation. Other attributes may also change on a per-frame basis but if they are not present in the Dimension Organization, they are not considered significant as a dimension for organizational purposes.
Receiving applications shall use the order of dimensions for guidance when presenting images if the Multi-frame Dimension Module is present. The first item of the Dimension Index Sequence shall be the slowest varying index.
Note: See Multi-frame Dimension Module section (C.7.6.17) for an example.
The DICOM Model of the Real World is extended for Clinical Trials with the addition of several objects whose relationships to each other and existing DICOM Real World objects are shown in Figure 7.6-1.
Attributes of the Clinical Trial Sponsor, Clinical Trial Protocol, Clinical Trial Subject, and Clinical Trial Site objects are represented in the Clinical Trial Subject Module within the Patient IOD. Attributes of the Clinical Trial Time Point object are represented in the Clinical Trial Study Module within the Study IOD. The Clinical Trial Coordinating Center attribute is represented in the Clinical Trial Series Module within Image IODs.
[pic]Figure 7.6-1 - DICOM MODEL OF THE REAL WORLD - CLINICAL TRIALS
For the purpose of Clinical Trial Information, an extension of the DICOM Model of the Real World is made, as depicted in Figure 7.6-1.
A Clinical Trial Sponsor identifies the agency, group, or institution responsible for conducting the clinical trial and for assigning a Protocol Identifier.
A Clinical Trial Protocol identifies the investigational Protocol in which the Subject has been enrolled. The Protocol has a Protocol Identifier and Protocol Name.
A Clinical Trial Subject identifies the Patient who is enrolled as a Subject in the investigational Protocol.
A Clinical Trial Site identifies the location or institution at which the Subject is treated or evaluated and which is responsible for submitting clinical trial data. Images and/or clinical trial data may be collected for a given Subject at alternate institutions, e.g. follow-up scans at a satellite imaging center, but the Clinical Trial Site represents the primary location for Patient management and data submission in the context of a clinical trial.
The Clinical Trial Time Point identifies an imaging Study within the context of an investigational protocol. A Time Point defines a set of studies that are grouped together as a clinical time point or submission in a clinical trial.
The Clinical Trial Coordinating Center identifies the institution responsible for coordinating the collection, management, processing, and/or analysis of images and associated data for Subjects enrolled in a clinical trial. Within a given Clinical Trial Protocol, there may be multiple Clinical Trial Coordinating Centers, each handling different aspects of the clinical data submitted by the Clinical Trial Sites.
The DICOM Model of the Real World is extended for Hanging Protocols with the addition of an entity that is separate from the rest of the DICOM Real World objects, as shown in Figure 7.7-1. A Hanging Protocol is not associated with any specific objects in the existing DICOM Information model, because it is not associated with a specific patient. There is no hierarchy applied to Hanging Protocol objects.
Figure 7.7-1 DICOM MODEL OF THE REAL WORLD - HANGING PROTOCOL
A Hanging Protocol entity specifies the viewing preferences of a specific user or group, for a specific type of study (Modality, Anatomy, Laterality combination, and optionally Procedure, and/or Reason). A Hanging Protocol definition includes descriptors that identify the Hanging Protocol, the creator, the type of study it addresses, the type of image sets to display, the intended display environment, and the intended layout for the screen(s).
The DICOM Model of the Real World is extended for Color Palettes with the addition of an entity that is separate from the rest of the DICOM Real World objects, as shown in Figure 7.8-1. A Color Palette is not associated with any specific objects in the existing DICOM Information model, because it is not associated with a specific patient. There is no hierarchy applied to Color Palette objects.
Figure 7.8-1 DICOM MODEL OF THE REAL WORLD - COLOR PALETTE
A Color Palette entity specifies a color palette suitable for application to an image with a single channel of information (grayscale) to render it in color, i.e., pseudo-coloring.
The DICOM Model of the Real World is extended for Specimens with the addition of several objects whose relationships to each other and existing DICOM Real World objects are shown in Figure 7.9-1.
Attributes of the Specimen, Container, Component and Preparation Step objects are represented in the Specimen Module within the Image IODs.
Figure 7.9-1 - DICOM MODEL OF THE REAL WORLD - SPECIMENS
A physical object (or a collection of objects) is a specimen when the laboratory considers it a single discrete, uniquely identified unit that is the subject of one or more steps in the laboratory (diagnostic) workflow.
Specimen containers (or just “containers”) play an important role in laboratory (diagnostic) processes. In most, but not all, process steps, specimens are held in containers, and a container often carries its specimen’s ID. Sometimes the container becomes intimately involved with the specimen (e.g., a paraffin block), and in some situations (such as examining tissue under the microscope) the container (the slide and coverslip) become part of the optical path.
Containers are often made up of components. For example, a “slide” is container that is made up of the glass slide, the cover slip and the “glue” the binds them together.
Before a slide is imaged, the preparation of the specimen (including sampling, processing and staining) will take place. Specimen preparation is described as a sequence of time-stamped process steps. Mulitple steps are possible, and may include sampling from ancestor specimens.
For the purpose of Implant Template SOP Classes the DICOM Model of the Real-World is described in this section. This subset of the real-world model covers the requirements for the planning of surgical implantation of implants using 2D and/or 3D templates. In this context, a Manufacturer may be a company, an institution or a person that issues Implant Templates.
Figures 7.10-1 is an abstract description of the real world objects involved in Implant Templates.
Figure 7.10-1IMPLANT TEMPLATE MODEL OF THE REAL WORLD
Figure 7.10-2IMPLANT ASSEMBLY TEMPLATE MODEL OF THE REAL WORLD
Figure 7.10-3IMPLANT TEMPLATE GROUP MODEL OF THE REAL WORLD
The DICOM Model of the Real-World is extended with the addition of a Unified Procedure Step object whose relationship to existing DICOM Real World objects is shown in Figure 7.11-1. [pic]
Figure 7.11-1 DICOM Model of the Real World – Unified Procedure Step
A Unified Procedure Step (UPS) represents an arbitrary unit of service. Unified Procedure Steps are generally scheduled in response to a Requested Procedure, although a UPS may be triggered by other events, such as a scheduled calibration, completion of prior work in a pipeline, etc.
The Unified Procedure Step (UPS) unifies the details of the procedure step that has been requested, the progress details during performance, and the details of the procedure step actually performed. The details can describe the specific service activity, the subject and/or data acted on, the originator and context of the request, the human/equipment/application resources involved, the priority, date, time and location of the activity, and references to resulting output data.
Normally the details about the activity as performed correspond to the details of the activity as requested, however real-world conditions may dictate that what is actually performed does not correspond exactly with what was requested or scheduled.
A Worklist is an arbitrary collection of Unified Procedure Steps that share a common worklist label.