Материал: part03

Note​

TheinformationcontentofthisentityrelatestothegeneralidentificationofaProcedureTyperatherthantoitsdecomposition​ into the protocol(s) required to perform a specific instance of a Requested Procedure for a particular Patient.​

7.3.1.5 Requested Procedure​

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​ exactlyoneProcedurePlan.ARequestedProcedureleadstooneormoreScheduledProcedureStepsinvolvingProtocolsasspecified​ 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.​

7.3.1.6 Scheduled Procedure Step​

A Modality Scheduled Procedure Step is an arbitrarily defined scheduled unit of service, that is specified by the Procedure Plan for​ aRequestedProcedure.AModalityScheduledProcedureStepprescribesaProtocol,whichmaybeidentifiedbyoneormoreprotocol​ codes. A Modality Scheduled Procedure Step involves equipment (e.g., imaging Modality equipment, anesthesia equipment, surgical​ equipment,transportationequipment),humanresources,consumablesupplies,location,andtime(e.g.,starttime,stoptime,duration).​ While in the context of imaging services the scheduling of a Modality Scheduled Procedure Step might include only a general desig-​ nation 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.​

Note​

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 ac-​ cording 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​ ScheduledProcedureSteprequiringanintravenousiodinecontrastinjectionmightbesharedbyanintravenouspyelogram​ 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.​

7.3.1.7 Procedure Plan​

A Procedure Plan is a specification that defines the set of Protocols that must be done in order to perform the Scheduled Procedure​ StepsofaRequestedProcedure.EachScheduledProcedureStepisperformedaccordingtoasingleProtocol,whichmaybeidentified​ by one or more Protocol Codes and may be described in a Defined Procedure Protocol. The Protocols actually performed during a​ Procedure Step may be recorded in a Performed Procedure Protocol and 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.​

7.3.1.8 Protocol​

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

A Protocol may be specified by a Defined Procedure Protocol to be used on any appropriate Patient.​

A Protocol can be documented, once a Procedure Step has been performed, in a Performed Procedure Protocol.​

- Standard -​

7.3.1.8.1 Defined Procedure Protocol​

A Defined Procedure Protocol describes a set of parameters and associated details for the prescribed action. The Defined Procedure​ Protocolmayprovidespecificvaluesforrelevantparameters,ormayprovideconstraintsonthoseparameters(suchasanacceptable​ range) to guide the choice of specific values.​

Defined Procedure Protocol is not associated with any particular Patient or Scheduled Procedure Step. A Defined Procedure Protocol​ may contain parameters specific to a particular model or version of device, or it may be generic in that it only describes parameters​ common to multiple device models.​

A Defined Procedure Protocol may include information such as the clinical purpose, indications, and appropriate device models, in-​ tended for selection and management.​

7.3.1.8.2 Performed Procedure Protocol​

A Performed Procedure Protocol encodes the parameter values used. A Performed Procedure Protocol is always associated with a​ specific Patient and Performed Procedure Step. The Performed Procedure Protocol may reference the Defined Procedure Protocol​ on which it was based, but does not otherwise record the orginal constraints and whether or not they were satisfied by the final values​ as recorded in the Performed Procedure Protocol.​

7.3.1.9 Modality Performed Procedure Step​

A Performed Procedure Step is an arbitrarily defined unit of service that has actually been performed (not just scheduled). Logically​ itcorrespondstoaScheduledProcedureStep,butreal-worldconditionsmaydictatethatwhatisactuallyperformeddoesnotcorrespond​ exactly with what was requested or scheduled.​

Note​

Forexample,twoormoreScheduledProcedureSteps,RequestedProceduresorImagingServiceRequestsmayhavebeen​ 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.​

Itcontainsinformationdescribingthetypeofprocedureactuallyperformed.ThisinformationisrepresentedbythePerformedProtocol​ 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.​

Note​

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​

- Standard -​

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 transmitted,​ 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 sub-​ sequent instances will necessarily be referenced in a new MPPS Instance, since the acquisition MPPS cannot be​ modified once completed.​

2.​ThecompletionofanMPPSmaybeasignificanteventthattriggersorenablesdownstreamactivity,butitisnottheintent​ 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 imple-​ mentation decisions beyond the scope of the Standard. The IHE Radiology Scheduled Workflow Profile provides addi-​ tional 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​ singlemulti-frameEnhancedCTImageStorageSOPInstance,orasseveralEnhancedCTImageStorageSOPInstances​ 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, sep-​ arate MPPS instances could be used for different storage SOP Classes.​

4.​The MPPS contains only the instances that the modality created, not instances converted and created subsequently in​ response to a query (e.g., during legacy conversion).​

5.​The MPPS is not a substitute for, nor is equivalent to, a Storage Commitment request, nor an Instance Availability Noti-​ fication.​

7.3.1.10 General Purpose Scheduled Procedure Step (Retired)​

Retired. See PS3.3-2011.​

7.3.1.11 General Purpose Performed Procedure Step (Retired)​

Retired. See PS3.3-2011.​

7.3.1.12 Workitem (Retired)​

Retired. See PS3.3-2011.​

7.3.1.13 Clinical Document​

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 require-​ ments.​

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

- Standard -​

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

ClinicalDocumentsmayprovidesignificantcontextfortheperformanceofimagingandrelatedprocedures,e.g.,patientclinicalhistory,​ 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 context.​

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

Note​

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

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

7.4 Extension of the DICOM Model of the Real World for the General Purpose​ Worklist (Retired)​

Retired. See PS3.3-2011.​

7.5 Organizing Large Sets of Information​

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 Or-​ ganization (see Section 7.5.2). Figure 7.5-1 depicts the additions to Figure 7-1a.​

- Standard -​

Patient

1 is the subject of

Figure 7.5-1. Extension of the Real World Model with Concatenations and Dimensions​

7.5.1 Concatenation​

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 Concatenation UID (0020,9161).​

7.5.2 Dimension Organization​

The Dimension Organization contains a set of dimensions. A dimension is a set of Attributes that change on a per-frame basis in a​ manner that is known before the image is acquired, are defined by the generating application and 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 Section C.7.6.17 for an example.​

7.6 Extension of the DICOM Model of the Real World for Clinical Trials and Re-​ search​

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

- Standard -​