DICOM 3_information object definition II

Part 1 Definition of Information Objects (2)

6 DICOM Information Model

DICOM information model defines the structure and organization of information related to medical image transmission. 6-1 describes the relationship between the main structures of the DICOM information model.

Figure 6-1 main structure of DICOM Information Model

6.1 Definition of Information Objects

An information object model (IOD) is an object-oriented abstract data model used to identify the information of objects in the real world. An IOD provides an application entity for exchange and a public view for additional exchange information.

A iod is not a clear example in the real world, but a category of objects with common attributes in the real world. A iod is the standard IOD used to describe a single real-world object. An IOD contains information about the relevant real-world objects as a composite IOD.

6.1.1 compound IOD

Composite IOD is an information object definition that describes the parts of multiple entities in the DICOM model of the real world. This model is described in Section 7th. The IOD attribute of this class does not inherit the real-world objects described by IOD, but inherits the relevant real-world objects.

These real-world objects provide a complete context for information exchange. When an instance with a composite IOD is exchanged, its entire context is exchanged between application entities. The relationship between the compound IOD instances should be transmitted in this context.

6.1.2 standard IOD

A standard IOD is the information object definition of a single entity that generally describes the real world of DICOM models.

When an instance of the standard IOD is switched, the context of the IOD is not actually switched. However, its context is provided by a pointer to the relevant standard IOD instance.

Standard IOD is described in appendix B.

6.2 attributes

An IOD attribute depicts the nature of a real-world object instance. Relevant attributes are defined by component modules to describe the semantics of higher levels, which are detailed in the module description in appendix C.

Attributes are encoded as data elements by rules. The diversity of value representation and value is defined in ps3.5. For specific data elements, the diversity of value representation and value is defined in the data dictionary in ps3.6.

When multiple modules in a IOD have the same attribute, this attribute can only be encoded once into the data element.

6.3 online transmission and media storage service

For online transmission, the DIMSE service allows a DICOM AE to request an operation or notification through a network or point-to-point interface. The DIMSE service is defined in ps3.7.

For media storage switching, the media storage service allows a DICOM AE request for media storage-related operations.

Note: These media storage services are discussed in ps3.10.

6.3.1 DIMSE-C Service

The DIMSE-C service only applies to a service with a composite IOD. DIMSE-C services only provide operational services.

6.3.2 DIMSE-N Service

The DIMSE-N service is only used for a standard IOD service. DIMSE-N services provide both operational and Notification Services.

6.4 DIMSE Service Group

One DIMSE Service Group defines one or more operations and notifications as defined in ps3.7; applies to one IOD.

The DIMSE service group is defined in the class description of the service object in ps3.4.

6.5 service object pair (SOP)

A service object pair is defined by the combination of a iod and a DIMSE Service Group. The SOP class defines the services that can be used to restrict the use of the DIMSE Service Group and the IOD attribute.

The SOP category is selected by AE to create an agreed set that supports its interoperability. This negotiation is performed at the time of joint creation, as described in ps3.7. An extension negotiation allows AE to further agree on a clear option within the SOP category.

Note: For management object classes, the SOP classes defined in the DICOM information object model are equivalent to ISO/OSI terms. Readers familiar with object-oriented terms will regard SOP operations (and notifications) as an object class method.

6.5.1 standard and composite Sop

DICOM defines two SOP classes: Standard and composite. The standard SOP class is defined as a combination of a standard iod and a DIMSE-N service set. The composite SOP class is defined as a combination of a composite iod and a DIMSE-C service set.

Note: The SOP class plays a key role in defining DICOM compatibility requirements. It allows DICOM AE to select a well-defined application-level subset of the standard DICOM V3.0 that needs to be declared compatible, such as ps3.2.

6.6 Joint Negotiation

Joint creation is the first phase of communication between AE applicable to DICOM. AE should use joint creation to negotiate which SOP class can be exchanged and how the data is encoded.

Joint Negotiation is defined in Chapter ps3.7.

6.7 service class description

A service description defines one or more SOP classes and a specific function, which is being completed by AE. A service class description also defines rules that allow application declarations to be compatible with some predefined levels of one or more SOP classes. Applications can be compatible with SOP classes, such as a SCU and SCP.

The service class description is defined in Chapter ps3.4.

Note: the interaction of the same AE type is based on the client/server model. SCU plays the client role, while SCP plays the server role. SCU and SCP roles are determined during joint creation.

7. DICOM models in the real world

Figure 7-1a, 7-1b, and 7-2 depict the DICOM view of the real world. The real world defines the objects of the real world and their relationships within the DICOM standard. It provides a general framework to ensure the persistence between various information objects defined in the DICOM standard.

Figure 7-1a: DICOM model in the real world

Figure 7-1b: real world-print-DICOM Model

7-2a, DICOM Information Model

7-2b, DICOM Information Model-print

P7-2c, DICOM Information Model-Radiation Therapy

Figure 7-3. real-world model-interface to achieve Model

7.1 DICOM Information Model

DICOM information model is a DICOM model derived from the real world. DICOM information models are depicted through 7-2a, 7-2b, and 7-2c. Various IOD types are defined and their relationships are clearly defined by this standard. Generally, the IOD of DICOM has no one-to-one relationship with objects in the real world. For example, a composite IOD contains attributes of objects in multiple real worlds, such as sequences, devices, frame references, examinations, and patients.

Figure 7-2a, 7-2b, and 7-2c correspond to the IOD defined from appendix A to C.

7.2 appendix A, B, and C

Appendix A defines a composite IOD (image) to obtain a series of forms (such as CT, Mr, nm, US, Cr, and secondary capture ). The Reference Components for the composite IOD are found in appendix C.

Appendix B defines a series of services that are used by the standard IOD (such as video interval and print job) in ps3.4. Reference Components for these standard IOD are found in appendix C.

7.3 extensions of DICOM models in the real world.

To achieve the basic worksheet management service class and form Execution Process SOP class, the original DICOM model has been enhanced in the real world, as described in 7-3.

In the appendix of ps3.17, "form worksheet integration and form execution process of raw DICOM standards" discusses the relationship between the extension of the original DICOM model with respect to the real world.

Figure 7-3 is an abstract description of a real-world object, called in the modality-Is interface. It is not used as the database mode of an application.

7.3.1 extended definition of DICOM real-world model

7.3.1.1 patient

A patient is a person who is receiving or registered will receive health care, or has one or more subjects for other purposes, such as scientific research.

Note: A person may be a person or an animal.

7.3.1.2 service fragment and access

OneService FragmentIs a group of events, which are clustered in the intervals defined by the start time and end time. A service segment is the context of treatment and management that occurs by a specific subset of the patient's medical condition. The start time, end time, and event definitions in a service fragment are completely specific. It may include a single outpatient service.Follow-upAnd hospitalization, or continuation for an important period, such as a pregnancy, a tumor treatment, or a segment of the heart from the state of infarction to the state of rehabilitation. A service segment may involve one or more medical institutions (Management Institutions authorize medical providers to provide medical services in their legal management fields, such as hospitals, private doctor clinics, multi-professional clinical institutions and nursing communities ).

Follow-upAs a subset of service fragments, an event set is formed and executed by a specialized medical institution in a single facility. One follow-up may be associated with one or more physical areas (such as different rooms, departments, and buildings) within the scope of an implementation Definition of a medical institution, including the licensing and release of diagnostics, the time interval of follow-up.

Note: 1) follow-up is part of the service segment. Service snippets describe multiple medical management aspects, while follow-up is only a description of a patient's one access to a facility.

2) In the context of the modality worklist SOP class, the attributes of the Service fragment are defined in the follow-up section.

3) The properties of follow-up usually use the historic term "License", although a follow-up at a mobile clinic does not involve permission as a hospitalization patient.

7.3.1.3 image service request

OneImage Service RequestYesProcess typeOne or moreRequest Process. An image service request is in the context of a service segment and is authorized byImage Service RequestorSubmitted to an authorizedImage Service Provider. An image service request includes both customary and general information. Each instance of an image service request carries the common information to one or more request processes. An image service request may be associated with one or more follow-up requests in the same service segment. The existence of an image service request may specifically lead to the generation of one or more Image Service reports and the distribution of Image Service reports to one or more targets.

In the context of the modality worklist, the information provided by the image service request is designed to complete one or more image processes, such as acquiring new images. In the context of general purpose worklist, the information provided by Image Service requests supports a more common request type, such as writing a report and requesting an image processing process in an existing check.

7.3.1.4 process type

OneProcess typeDefines a process category. In the context of Image Service, a process type is a breakdown of the image process directory and can be requested and reported in an image service facility. A process-type instance typically has one name and one or more other identifiers. A process type is associated with one or more Process plans.

Note: The information context of this object is associated with a general definition of a process type, not just a clear instance of the required protocol for a developed patient to complete a request process.

To be continued...

[Disclaimer:

1) This content may come from the Internet, or I have sorted it out by myself. It only represents the opinions and opinions of the Internet and individuals!
2) This content is for reference only. Any reference to this content will cause any consequences and will be irrelevant to the original author and the author of this blog !]