Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
DICOM
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Services == DICOM consists of services, most of which involve transmission of data over a network. The file format for offline media is a later addition to the standard. === Store === The DICOM Store service is used to send images or other persistent objects (structured reports, etc.) to a [[picture archiving and communication system]] (PACS) or workstation. === Storage commitment === The DICOM storage commitment service is used to confirm that an image has been permanently stored by a device (either on redundant disks or on backup media, e.g. burnt to a CD). The Service Class User (SCU: similar to a [[Client–server model|client]]), a modality or workstation, etc., uses the confirmation from the Service Class Provider (SCP: similar to a [[Client–server model|server]]), an archive station for instance, to make sure that it is safe to delete the images locally. === Query/retrieve === This enables a workstation to find lists of images or other such objects and then retrieve them from a picture archiving and communication system. === Modality worklist === The DICOM modality worklist service provides a list of imaging procedures that have been scheduled for performance by an image acquisition device (sometimes referred to as a modality system). The items in the worklist include relevant details about the subject of the procedure (patient ID, name, sex, and age), the type of procedure (equipment type, procedure description, procedure code) and the procedure order (referring physician, [[Accession number (bioinformatics)|accession number]], reason for exam). An image acquisition device, such as a CT scanner, queries a service provider, such as a [[Radiological information system|RIS]], to get this information which is then presented to the system operator and is used by the imaging device to populate details in the image metadata. Prior to the use of the DICOM modality worklist service, the scanner operator was required to manually enter all the relevant details. Manual entry is slower and introduces the risk of misspelled patient names, and other data entry errors. === Modality performed procedure step === A complementary service to modality worklist, this enables the modality to send a report about a performed examination including data about the images acquired, beginning time, end time, and duration of a study, dose delivered, etc. It helps give the radiology department a more precise handle on resource (acquisition station) use. Also known as MPPS, this service allows a modality to better coordinate with image storage servers by giving the server a list of objects to send before or while actually sending such objects. === Print === The DICOM print service is used to send images to a DICOM printer, normally to print an "X-Ray" film. There is a standard calibration (defined in DICOM Part 14) to help ensure consistency between various display devices, including hard copy printout. === Offline media (files) === The format for offline media files is specified in Part 10 of the DICOM Standard. Such files are sometimes referred to as "Part 10 files". DICOM restricts the filenames on DICOM media to 8 characters (some systems wrongly use 8.3, but this does not conform to the standard). No information must be extracted from these names (PS3.10 Section 6.2.3.2). This is a common source of problems with media created by developers who did not read the specifications carefully. This is a historical requirement to maintain compatibility with older existing systems. It also mandates the presence of a media directory, the DICOMDIR file, which provides index and summary information for all the DICOM files on the media. The DICOMDIR information provides substantially greater information about each file than any filename could, so there is less need for meaningful file names. DICOM files typically have a .dcm file extension if they are not part of a DICOM media (which requires them to be without extension). The [[MIME]] type for DICOM files is defined by RFC 3240 as application/dicom. The [[Uniform Type Identifier]] type for DICOM files is org.nema.dicom. There is also an ongoing media exchange test and "connectathon" process for CD media and network operation that is organized by the [[Integrating the Healthcare Enterprise|IHE]] organization.
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
DICOM
(section)
Add topic