Basic DICOM Concepts v1
Slide # 1
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Basic DICOM Conceptswith Healthcare Workflow
Dwight A. Simon,Medical Standards Director and
Senior Integration Specialist
www.merge.com
* * * * * *
Co-Chair DICOM Standards Committee
DICOM 2005 International Conference
Budapest, Hungary
Basic DICOM Concepts v1
Slide # 2
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Overview
• DICOM Terminology and
Functionality!
• HL7 Terminology and Functionality!
• How DICOM & HL7 work together
in the Healthcare Workflow?
• How does IHE fit in to this?
Basic DICOM Concepts v1
Slide # 3
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
• They allow electronic healthcare information to be:
• exchanged, integrated, shared, and retrieved
• They support:
• clinical practice and management
• delivery and evaluation of healthcare services
• They were specifically created to allow:
• flexible, cost effective approaches, guidelines,
methodologies and related services
• for interoperability between healthcare information
systems
DICOM and HL7 have Common Goals
Basic DICOM Concepts v1
Slide # 4
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
The DICOM Standard
• DICOM covers:• Communication protocols over networks
• Communication via interchangeable media
• Data content
• Functional application services
• Consistent display of images across devices
• Security and configuration management
• Physician defined look and feel of display (Hanging Protocols)
• Identifying and grouping related information (Structured Reports)
• Etc.
Basic DICOM Concepts v1
Slide # 5
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
The DICOM Standard
• DICOM does not cover:
• Anything related to implementation
• Database structure
• Programming languages
• Hardware
• Operating systems
• etc.
• How and what data to process
• Graphical user interface design
Basic DICOM Concepts v1
Slide # 6
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
DICOM Message/File Content
(Information Object Definition – IOD)
Image Image
ModuleModule
Patient Patient
ModuleModule
General General
Study Study
ModuleModule
Patient Patient
Study Study
Module*Module*
General General
Series Series
ModuleModule
Frame of Frame of
Reference Reference
ModuleModule
General General
Equipment Equipment
ModuleModule
General General
Image Image
ModuleModule
Image Image
Plane Plane
ModuleModule
ContrasContras
t/Bolus t/Bolus
ModuleModule
Overlay Overlay
Plane Plane
Module*Module*
VOI VOI
LUT LUT
ModuleModule
**
SOP SOP
Common Common
ModuleModule
Image Image
Pixel Pixel
ModuleModule
Image Pixel
Module
Image Pixel Image Pixel
ModuleModule
Row/Col Size
Photometric Interpretation
Row/Col SizeRow/Col Size
Photometric InterpretationPhotometric Interpretation
Patient Patient
InformationInformation
Study Study
InformationInformation
Series Series
InformationInformation
(Image)
Information
InstanceInstance
Information
Entities
Modules Attributes
Basic DICOM Concepts v1
Slide # 7
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Command
Patient Name
Patient ID
Study Date
Study Time
Row Size
Column Size
Network Transfer
Data Set=
+
Meta Data +Media Transfer
Data Set=
Group 0
( Describes Service: C-Store)
Group 2 ( Describes Data Set)
D I C O M [ . . . . . . . F I L E . . . . . . . . . . ]
D I C O M [ . . . . . M E S S A G E . . . . . . . ]
Header
Image
DICOM Transfer via Network or Media
Basic DICOM Concepts v1
Slide # 8
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
DICOM Functional Service Groups
Media InterchangeMedia Interchange
Print ImagesPrint Images
Print ManagementPrint Management
Image Related Workflow andImage Related Workflow and
Information ManagementInformation Management
Query RequestQuery Request
Image Related Information Image Related Information
TransferTransfer
Persistent Object StoragePersistent Object Storage
Persistent Object StoragePersistent Object Storage
Retrieve RequestRetrieve Request
Basic DICOM Concepts v1
Slide # 9
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Functional DICOM Application Services
( SOP Classes)
• DICOM supports many functions over Networks:• A CT transferring CT images to a remote archive for Storage
• An MR workstation sending 12 images and a film layout to a departmental film printer for Printing a hardcopy film
• An Ultra Sound device querying a Radiology Information System (RIS) for a list of all the patients scheduled for the next 8 hours, along with the procedures to be performed for each of the scheduled patients
• DICOM supports storage of data for many different applications on Interchangeable Media:• A technologist storing a patients Digital X-Ray images on a CD so that the patient can take them to her personal doctor
• A radiologist sending a Mammography study on a DVD to another radiologist for consultation (no network available)
Basic DICOM Concepts v1
Slide # 10
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Service Class
• A Service Class is a group of commonly functioning SOP Classes
• Storage Service Class
• Print Management Service Class
• Study Management Service Class
• A Service Class has Rules and Behaviors that are defined and must be adhered by products that claim to be DICOM Compliant via a DICOM Conformance Statement
Basic DICOM Concepts v1
Slide # 11
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Network Addressing with DICOM
Handshake Requirements
ID: CT_AE1
IP: 10.3.253.8
Port: 104
ID: WK_AE1
IP: 10.3.253.9
Port: 4006
4006WK_AE110.3.253.9
104Fusion10.3.253.1
Port #AE TitleIP Addr
104CT_AE110.3.253.8
104Fusion10.3.253.1
Port #AE TitleIP Addr
Association / Association /
NegotiationNegotiation
CT CT ConfigConfig FileFile WkstnWkstn ConfigConfig FileFile
Node Level Node Level
SecuritySecurity
Basic DICOM Concepts v1
Slide # 12
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Typical Network Flow
DICOM AE “A”DICOM AE “A” DICOM AE “B”DICOM AE “B”AA--ASSOCIATEASSOCIATE--RQRQ
AA--ASSOCIATEASSOCIATE--ACAC
AA--RELEASERELEASE--RSPRSP
AA--RELEASERELEASE--RQRQ
Only The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItHowever, Either May Initiate An AHowever, Either May Initiate An AHowever, Either May Initiate An AHowever, Either May Initiate An A----ABORTABORTABORTABORT
Only The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItOnly The AE Which Initiated The Association May Release ItHowever, Either May Initiate An AHowever, Either May Initiate An AHowever, Either May Initiate An AHowever, Either May Initiate An AHowever, Either May Initiate An AHowever, Either May Initiate An AHowever, Either May Initiate An AHowever, Either May Initiate An A--------ABORTABORTABORTABORTABORTABORTABORTABORT
oror
AA--ASSOCIATEASSOCIATE--RJRJ
DICOM MessagesDICOM Messages
oror
AA--ABORTABORT
Either AEEither AE
Basic DICOM Concepts v1
Slide # 13
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Providers and Users of DICOM Functions
over the Network
• Service Class Provider (SCP):
• Application that is Providing the Service for a particular DICOM Function (SOP Class).
• Therefore, a device that can receive CT images over a network utilizing the DICOM protocol and stores those received CT images in its databases would be called, in DICOM terms:
• a CT Image Storage SOP Class
• that plays the network role of an SCP
• and follows the rules of the Storage Service Class.
• Service Class User (SCU):
• Application using a particular DICOM Function (SOP Class)
Basic DICOM Concepts v1
Slide # 14
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
DICOM Network Roles
• Successful communication - products must play “opposite roles”
• Receive images = Service Class Provider (SCP)
• Send images = Service Class User (SCU)
Network roles are defined for all DICOM Network roles are defined for all DICOM Network roles are defined for all DICOM Network roles are defined for all DICOM FunctionsFunctionsFunctionsFunctions
Network roles are defined for all DICOM Network roles are defined for all DICOM Network roles are defined for all DICOM Network roles are defined for all DICOM Network roles are defined for all DICOM Network roles are defined for all DICOM Network roles are defined for all DICOM Network roles are defined for all DICOM FunctionsFunctionsFunctionsFunctionsFunctionsFunctionsFunctionsFunctions
Image SendImage SendImage Send
CT Image StorageSOP Class (SCU)CT Image StorageCT Image StorageSOP Class (SCU)SOP Class (SCU)
CT Image StorageSOP Class (SCP)CT Image StorageCT Image StorageSOP Class (SCP)SOP Class (SCP)
Basic DICOM Concepts v1
Slide # 15
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
DICOM Media Interchange
DICOMDIRDICOMDIR• A “directory file”, which is required for DICOM Media
• Contains pointers to a list of DICOM files on a CD, DVD, MOD, Flash Memory, etc.
• Used to locate and load DICOM files from a CD, DVD, etc.
• Is a file with a Meta Header (Group 2) + Directory Attributes (Group 4) + Key Attributes for Searching (regular Data Set Attributes)
DICOM FileDICOM File• Is a file with a Meta Header (Group 2) + a Data Set
• Is pointed to by DICOMDIR
• Has filename of 1-8 Characters with NO extension
Basic DICOM Concepts v1
Slide # 16
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
• Application profiles define a selection of choices
applicable to a specific context for exchanging media
(e.g. Cardiac profile- 512 X-ray Angio, Lossless JPEG,
CD-R)
• The profile “negotiates” the media capabilities
• More than one application profile may exist on a
specific media
• A device may support one or more of the following
roles:• File-Set Creator (FSC) - initialize new media and write SOP instances
• File-Set Reader (FSR) - read the medical directory and selected SOP instances
• File-Set Updater (FSU) - read and update the medical directory as well as SOP instances on the media
DICOM Media Interchange
Basic DICOM Concepts v1
Slide # 17
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Network and Media Interchange
• Common Image Types
• Single image, monochrome
• Single image, color
• Multiframe
• Multiple image frames embedded into pixel data
• One data set (message / file) can contain multiple images
• Can be monochrome or color
• Data Set Encoding
• Uncompressed Pixel Data (Transfer Syntax = Implicit VR Little Endian (Default for
Network Only), Explicit VR Little Endian and Explicit VR Big Endian)
• Compressed Pixel Data Only with Explicit VR Little Endian encoding
• JPEG Lossless
• JPEG Lossy
• RLE (Run Length Encoded)
• JPEG 2000 (Wavelet based)
• Compressed Data Set
• Deflated Explicit VR Little Endian (Public Domain “ZIP” format)
Basic DICOM Concepts v1
Slide # 18
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Command
Patient Name
Patient ID
Rows
Columns
Bits Stored
…
Network Transfer
Data Set=
+
Meta Data +Media Transfer
Data Set=
Group 0
( Describes Service: C-Store)
Group 2 ( Describes Data Set)
D I C O M [ . . . . . . . F I L E . . . . . . . . . . ]
D I C O M [ . . . . . M E S S A G E . . . . . . . ]
Header
Image
DICOM Transfer over Network & Media
Transfer Syntax
is NOT
Implicit VR Little Endian
Default Transfer Syntax is
Implicit VR Little Endian
Basic DICOM Concepts v1
Slide # 19
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
DICOM Conformance StatementDICOM Conformance Statement
• It is Required!
• It is a Public Document
• It Conveys a Product’s DICOM Functionality
• It is Based on DICOM Vocabulary
• Abstract Syntaxes (SOP Classes),
Transfer Syntaxes, SCU/SCP…..
• It is Used to Compare Connectivity
• It is most Often on the Web @ Vendor Site
• It Does Not Address All of an Application’s
Capabilities, but should Address All of the
Application’s DICOM ones
Ok, you say its DICOM, Ok, you say its DICOM,
prove it!prove it!
A Major Step Towards InteroperabilityA Major Step Towards Interoperability
Basic DICOM Concepts v1
Slide # 20
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
• Messages are sent when an Event occurs• Patient gets registered for exam
• Order is issued for exam
• Patient arrives at hospital
• Exam complete (Ready for Billing)
• How messages get where they are needed• Normally via a Network (TCP/IP over Ethernet or any of
the hardware communication protocols, including wireless)
• Probably via an Interface Engine
• An intermediate application that can map HL7 messages from one interpretation to another and also route it to all the destinations that need it
The HL7 Standard
Health Level Seven Text based Messages
Basic DICOM Concepts v1
Slide # 21
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
MSH|^~\&|ADMIN|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01|MSG00001|P|2.4|<cr>
EVN|A01|198808181123||<cr>
PID|1||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||JONES^WILLIAM^A^III||19610615|M-||C|1200 N ELM STREET^^GREENSBORO^NC^27401-1020|GL|(919)379-1212|(919)271-3434||M||PATID12345001^2^M10^ADT1^AN^A|123456789|9-87654^NC|<-cr>
NK1|1|JONES^BARBARA^K|WI^WIFE||||NK^NEXT OF KIN<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||-||ADM|A0-|<cr>
Patient William A. Jones, III was admitted on August 18, 1988 at 11:23 a.m. To be attended by doctor Sidney J. Lebauer (#004777) for surgery (SUR).
He has been assigned to room 2012, bed 01 on nursing unit 2000.His wife, Barbara K. Jones is a related family member (next of kin).
HL7 Messagefor Admitting a Patient as an In-Patient
Basic DICOM Concepts v1
Slide # 22
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Encoding Requirements of Previous Message Encoding Requirements of Previous Message -- ADT^A01 v2.4ADT^A01 v2.4
ADT^A01^ADT_A01 ADT Message Chapter
MSH Message Header 2EVN Event Type 3PID Patient Identification 3[ PD1 ] Additional Demographics 3[{ ROL }] Role 12[{ NK1 }] Next of Kin / Associated Parties 3 PV1 Patient Visit 3[ PV2 ] Patient Visit - Additional Info. 3[{ ROL }] Role 12[{ DB1 }] Disability Information 3[{ OBX }] Observation/Result 7[{ AL1 }] Allergy Information 3[{ DG1 }] Diagnosis Information 6[ DRG ] Diagnosis Related Group 6[{ PR1 Procedures 6 [{ ROL }] Role 12}][{ GT1 }] Guarantor 6[{ IN1 Insurance 6 [ IN2 ] Insurance Additional Info. 6 [{ IN3 }] Insurance Additional Info - Cert. 6 [{ ROL }] Role 12}][ ACC ] Accident Information 6[ UB1 ] Universal Bill Information 6[ UB2 ] Universal Bill 92 Information 6[ PDA ] Patient Death and Autopsy 3
ExtractedExtracted
FromFrom
HL7 v2.4HL7 v2.4
3.3.13.3.1
This is a This is a
MessageMessage
defineddefined
by by
SegmentsSegments
= Required= Required
[ ] = Optional[ ] = Optional
{ } = Repeatable { } = Repeatable
Basic DICOM Concepts v1
Slide # 23
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
MSH||||^~\&|ADMIN||||MCM||||LABADT||||MCM||||198808181126||||SECURITY||||ADT^A01||||MSG00001||||P||||2.4<cr>
EVN||||A01||||198808181123<cr>
PID||||1||||||||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||||||||JONES^WILLIAM^A^III||||||||19610615||||M-||||||||C||||1200 N ELM STREET^^GREENSBORO^NC^27401-1020||||GL||||(919)379-1212||||(919)271-3434||||||||M||||||||PATID12345001^2^M10^ADT1^AN^A||||123456789||||9-87654^NC||||<-cr>
NK1||||1||||JONES^BARBARA^K||||WI^WIFE||||||||||||||||NK^NEXT OF KIN<cr>
PV1||||1||||I||||2000^2012^01||||||||||||||||004777^LEBAUER^SIDNEY^J.||||||||||||SUR||||||||-||||||||ADM||||A0-||||<cr>
PID – Patient ID Segment Table (partial )
SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME
1 4 SI O 00104 Set ID - Patient ID
2 20 CX O 00105 Patient ID (External ID)
3 20 CX R Y 00106 Patient ID (Internal ID)
4 20 CX O Y 00107 Alternate Patient ID - PID
5 48 XPN R Y 00108 Patient Name
6 48 XPN O 00109 Mother’s Maiden Name
7 26 TS O 00110 Date/Time of Birth
8 1 IS O 0001 00111 Sex
9 48 XPN O Y 00112 Patient Alias
10 1 IS O 0005 00113 Race
11 106 XAD O Y 00114 Patient Address
12 4 IS O 00115 County Code
13 40 XTN O Y 00116 Phone Number - Home
Basic DICOM Concepts v1
Slide # 24
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Primary HL7 Messages used for PACS
• ADT – Admit, Discharge, Transfer Message• Used for registering a patient for a specific exam
• Used for admitting a patient into the hospital
• Used for discharging a patient from the hospital
• ORM – Order Message• Used for ordering a specific exam
• ORU – Report Message• Used to send a report to a place where it is needed
Basic DICOM Concepts v1
Slide # 25
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Link HIS/RIS Data Into Images
……other informationother information
Patient Patient
ModuleModule
General General
Study Study
ModuleModule
Patient Patient
Study Study
ModuleModule
General General
Series Series
ModuleModule
Frame of Frame of
Reference Reference
ModuleModule
General General
Equipment Equipment
ModuleModule
Image Image
ModuleModule
General General
Image Image
ModuleModule
Image Image
Plane Plane
ModuleModule
ContrasContras
t/Bolus t/Bolus
ModuleModule
Overlay Overlay
Plane Plane
ModuleModule
VOI VOI
LUT LUT
ModuleModule
SOP SOP
Common Common
ModuleModule
Image Image
Pixel Pixel
ModuleModule
Patient Patient
InformationInformation
Study Study
InformationInformation
Series Series
InformationInformation
Patient’s NamePatient’s Name
Patient’s IDPatient’s ID
Patient’s Patient’s BirthdateBirthdate
Patient’s SexPatient’s Sex
Patient’s WeightPatient’s Weight
Accession NumberAccession Number
Study Instance UIDStudy Instance UID(Image)
Information
Referring Referring
Physician’s NamePhysician’s Name
InstanceInstance
Information
Entities
Modules Attributes
Basic DICOM Concepts v1
Slide # 26
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
InternalInternal
ExternalExternal
The e-Health Workflow
Referring PhysiciansReferring PhysiciansPatientsPatients PayersPayers
RadiologistRadiologist FinanceFinanceAdminAdmin TechTech
• Images • Reports• Claims
WORKFLOW WORKFLOW WORKFLOW WORKFLOW WORKFLOW WORKFLOW WORKFLOW WORKFLOW
• Referrals /Orders
• Reimbursement
Basic DICOM Concepts v1
Slide # 27
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
A Sample WorkflowA Sample WorkflowE. Patient Information is sent to the Radiology InformationE. Patient Information is sent to the Radiology Information
System (RIS) via an HL7 transaction.System (RIS) via an HL7 transaction.F. If LAB work needed, the HIS sends Patient Information to F. If LAB work needed, the HIS sends Patient Information to
LAB via HL7LAB via HL7--ADT and Order via HL7ADT and Order via HL7--ORM.ORM.G. HIS sends Order for Diagnostic Imaging Exam to G. HIS sends Order for Diagnostic Imaging Exam to
Radiology Information System (RIS) via HL7Radiology Information System (RIS) via HL7--ORM.ORM.H. Modality requests Worklist from RIS via DICOMH. Modality requests Worklist from RIS via DICOM--MWL.MWL.I. Modality sends information about Procedure Performed I. Modality sends information about Procedure Performed
to RIS via DICOMto RIS via DICOM--MPPS.MPPS.J. RIS sends information about When, How, and WhatJ. RIS sends information about When, How, and What
Procedure Steps have been Completed to the HIS viaProcedure Steps have been Completed to the HIS via
HL7HL7--ORM ORM (some HIS’ don’t currently handle this).(some HIS’ don’t currently handle this).
K. RIS sends notification of Performed Procedure to PACS K. RIS sends notification of Performed Procedure to PACS
system via DICOMsystem via DICOM--MPPSMPPS--NOTIFY.NOTIFY.L. PACS systems requests selected info about Performed L. PACS systems requests selected info about Performed
Procedure from RIS via DICOMProcedure from RIS via DICOM--MPPSMPPS--RETRIEVE.RETRIEVE.M. Modality sends Images to PACS system via M. Modality sends Images to PACS system via
DICOMDICOM--STORESTORE..
N. Modality request PACS system to let it know when all N. Modality request PACS system to let it know when all
Images sent have been reliably stored via Images sent have been reliably stored via
DICOMDICOM--STORAGESTORAGE--COMMITMENT.COMMITMENT.
O. After all requested Images are safely Archived the PACS O. After all requested Images are safely Archived the PACS
notifies the Modality that the Images are reliably stored vinotifies the Modality that the Images are reliably stored via a
DICOMDICOM--STORAGESTORAGE--COMMITMENTCOMMITMENT--NOTIFICATION.NOTIFICATION.
P. Radiology Review Station can issue Queries and Retrieves P. Radiology Review Station can issue Queries and Retrieves
for as much information as needed. It is possible that all for as much information as needed. It is possible that all
needed information has already been sent ahead of time.needed information has already been sent ahead of time.
Q. The PACS sends requested, preQ. The PACS sends requested, pre--fetched, and autofetched, and auto--routedrouted
images and related information to the Radiology Review images and related information to the Radiology Review
Station.Station.
R. Radiologist reviews the information and dictates a report,R. Radiologist reviews the information and dictates a report,
which is sent and received back from dictation and signedwhich is sent and received back from dictation and signed
(authorized) as final Diagnostic Reports.(authorized) as final Diagnostic Reports.
S. The WEB Server can Query and Retrieve for whatever S. The WEB Server can Query and Retrieve for whatever
information is needed from client requests. However, most information is needed from client requests. However, most
things actually get sent here automatically as it is availabthings actually get sent here automatically as it is available.le.
T. The PACS sends requested, preT. The PACS sends requested, pre--fetched, and autofetched, and auto--routedrouted
images and related information to the WEB Server. The images and related information to the WEB Server. The
WEB Server usually has final Diagnostic Reports as well.WEB Server usually has final Diagnostic Reports as well.
U. Final Diagnostic Reports are sent to either or both the U. Final Diagnostic Reports are sent to either or both the
PACS and/or the RIS for distribution to appropriate PACS and/or the RIS for distribution to appropriate
physicians. Distribution can happen in a variety of ways.physicians. Distribution can happen in a variety of ways.
V. If an external Lab is used, then the lab results and billing V. If an external Lab is used, then the lab results and billing
can be transferred electronically utilizing the ASTM can be transferred electronically utilizing the ASTM
standard (one of many used in conjunction with HL7).standard (one of many used in conjunction with HL7).
W. The lab results can be stored in the RIS for general W. The lab results can be stored in the RIS for general
distribution.distribution.X. Insurance and billing might be done utilizing the X.12 X. Insurance and billing might be done utilizing the X.12
standard (another of the HL7 related standards).standard (another of the HL7 related standards).
A. Patient visits Physician, who then determines that some A. Patient visits Physician, who then determines that some
diagnostic imaging exam must be done.diagnostic imaging exam must be done.
B. Request for Service is Faxed from Referring Physician to B. Request for Service is Faxed from Referring Physician to
Medical Orders Department in Hospital.Medical Orders Department in Hospital.
C. Orders Department enters Patient Information and C. Orders Department enters Patient Information and
Request for Service directly into Hospital InformationRequest for Service directly into Hospital Information
System (HIS).System (HIS).
D. Scheduling Department orders appropriate Procedure to D. Scheduling Department orders appropriate Procedure to
be Performed at a specific time, by a specific Modality.be Performed at a specific time, by a specific Modality.
A Sample WorkflowA Sample Workflow
Modality Worklist Modality Worklist
(MWL)(MWL)
Modality Performed Procedure StepModality Performed Procedure Step
(MPPS)(MPPS)
Storage Storage
CommitmentCommitmentMPPS MPPS
RetrieveRetrieve
StoreStore
ImagesImages
Patient Admittance Patient Admittance
(ADT)(ADT)
Ordered Ordered
Procedure (ORM)Procedure (ORM)
Query/RetrieveQuery/Retrieve
Store Store
ImagesImages
MPPS MPPS
NotifyNotify Procedure CompleteProcedure Complete
X.12X.12X.12X.12X.12X.12X.12X.12
InsuranceInsurance
/ Billing/ Billing
ADT/ADT/
ORMORM
Lab/Lab/
ResultsResults
ORUORU
ASTMASTMASTMASTMASTMASTMASTMASTMLabLab
ResultsResults
ChargesCharges
Query/Query/
RetrieveRetrieve
StoreStore
ImagesImages
Referring Physician / Surgeon / EReferring Physician / Surgeon / E--R / ??R / ??
Dept Dept Dept Dept Dept Dept Dept Dept
Informtn Informtn Informtn Informtn Informtn Informtn Informtn Informtn
SysSysSysSysSysSysSysSysModalityModalityModalityModalityModalityModalityModalityModality
RadRadRadRadRadRadRadRad
Rvw Rvw Rvw Rvw Rvw Rvw Rvw Rvw DicDicDicDicDicDicDicDic--------
tationtationtationtationtationtationtationtation
HH
oo
ss
pp
II
nn
ff
oo
SS
yy
ss
PACS PACS PACS PACS PACS PACS PACS PACS
ArchiveArchiveArchiveArchiveArchiveArchiveArchiveArchive
LabLabLabLabLabLabLabLab
WEBWEBWEBWEBWEBWEBWEBWEB
ServerServerServerServerServerServerServerServer
DICOMDICOMDICOMDICOMDICOMDICOMDICOMDICOM
HL7HL7HL7HL7HL7HL7HL7HL7
EE
FFF
GGHHII
JJKK
LL
MMNN
PP
RR
SSTT
UU
VV
WW
XX
OO
Store ReportStore Report
SR or ORUSR or ORU
ORUORU
Basic DICOM Concepts v1
Slide # 28
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
IHE
Integrating the Healthcare Enterprise
Initiative promoting and supporting the
integration of systems in the healthcare
enterprise
Improve the efficiency and effectiveness of clinical
practice by improving information flow
IHE information partially extracted from slides of SCAR2003 IHE presentations
Basic DICOM Concepts v1
Slide # 29
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
What is IHE?
• Standards based communication between healthcare systems
• HL7 and DICOM are two of these standards
• Actors: perform communications roles between systems
• Transactions: messages sent between systems
• Integration Profiles: grouping of actors and transactions to perform specific workflows
Basic DICOM Concepts v1
Slide # 30
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
Usage of IHE
• Integration Profiles
• Integrated solutions that support specific workflows in Radiology, Information Technology, Cardiology, Laboratory, Radiation Oncology, etc.
• User and Vendor Communications
• Integration Profiles provide common language for discussion
• To help specify which specific clinical functions are needed within a product
• To help identify what kind of information must be sent or received to accomplish those clinical functions
Basic DICOM Concepts v1
Slide # 31
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
IHE brings Reality to the
Healthcare Workflow
• It is not a standard, but utilizes Standards.
• It is really a blueprint trying to solve tricky workflow
problems.
• There is enormous intellectual property in IHE and
extremely thorough solutions to problems.
• Tapping into the experience and knowledge is free.
• In many ways IHE is the lessons learned from all
those who have tried to go soft-copy in the past
decade and ran into stumbling blocks, plus much
more.
Basic DICOM Concepts v1
Slide # 32
DICOM 2005 International Conference
Budapest, Hungary
September 26, 2005
DICOM Does Not Stand Alone!
Many standards and initiatives work together to help us implement the electronic information workflow
within our healthcare environments.
DICOM is just one of those standards.
Top Related