DICOM là gì: chuẩn hình ảnh y tế và quan hệ với FHIR

1. DICOM là gì? Định nghĩa và lịch sử

DICOM viết tắt cho Digital Imaging and Communications in Medicine, là chuẩn quốc tế quản lý cách lưu trữ, truyền tải và mô tả hình ảnh y tế cùng metadata kèm theo. Câu hỏi dicom là gì có thể tóm tắt trong một dòng: đây là tập hợp quy ước kỹ thuật giúp một máy chụp CT của Siemens nói chuyện được với một workstation đọc phim của GE, một PACS của Carestream, hay một viewer mã nguồn mở như OHIF — bất kể vendor.

Phiên bản đầu của chuẩn ra đời từ năm 1985 với tên ACR-NEMA, do American College of Radiology (ACR) và National Electrical Manufacturers Association (NEMA) đồng chủ trì. Tới năm 1993, phiên bản DICOM 3.0 được phát hành và trở thành nền móng còn dùng đến hôm nay. NEMA tiếp tục giữ vai trò Secretariat cho ủy ban DICOM Standards Committee, công bố các bản cập nhật nhiều lần mỗi năm dưới định danh kiểu 2026a, 2026b… DICOM được tham chiếu trong tiêu chuẩn ISO 12052 và là nền tảng cho hầu hết hệ thống chẩn đoán hình ảnh trên thế giới.

Khác với HL7 v2 vốn tập trung vào tin nhắn hành chính - lâm sàng, DICOM tập trung vào pixel data và metadata kèm theo từng lát cắt. Một file DICOM không chỉ chứa ảnh: nó còn mang theo toàn bộ thông tin bệnh nhân, thông số kỹ thuật của lần chụp, hiệu chỉnh modality, và định danh duy nhất xuyên suốt vòng đời. Đây là lý do DICOM tồn tại độc lập và khó bị thay thế bởi định dạng ảnh đa dụng như JPEG hay PNG.

2. Ba thành phần: file, DIMSE, DICOMweb

Khi nói đến DICOM, kỹ sư tích hợp cần phân biệt ba lớp riêng biệt nhưng được mô tả chung trong bộ tiêu chuẩn 22 phần PS3.1 đến PS3.22.

Định dạng file .dcm

File DICOM là cấu trúc nhị phân có header tag-based. Pixel data và metadata được đóng gói cùng một file, không tách rời. Phần header dùng các cặp (Group, Element) để mô tả thuộc tính, kèm mã VR (Value Representation) chỉ kiểu dữ liệu. Ảnh có thể được nén bằng JPEG Baseline, JPEG Lossless, JPEG-LS, JPEG 2000 hay RLE; mỗi kiểu nén ứng với một Transfer Syntax UID.

Giao thức mạng DIMSE

DIMSE (DICOM Message Service Element) chạy trên TCP, định nghĩa tập operations để hai ứng dụng AE (Application Entity) trao đổi: C-STORE để gửi instance, C-FIND để truy vấn, C-MOVE để yêu cầu bên thứ ba chuyển ảnh, C-GET để tự kéo về, và C-ECHO để kiểm tra kết nối. Mỗi operation gắn với một SOP Class — ví dụ CT Image Storage hay Modality Worklist.

DICOMweb — lớp HTTP RESTful

Từ năm 2011 trở đi, ủy ban DICOM mở rộng chuẩn sang HTTP với DICOMweb, đặc tả trong PS3.18. Bốn dịch vụ chính gồm WADO-RS để đọc, QIDO-RS để truy vấn, STOW-RS để lưu, và UPS-RS cho worklist hợp nhất. DICOMweb không thay thế DIMSE mà là kênh song song; nhiều PACS hiện đại mở cả hai endpoint cùng lúc.

3. Anatomy file DICOM — Tag, VR, SOP Class UID

Một file DICOM được tổ chức theo nhóm thuộc tính (module), nhưng tag thực tế lại được định nghĩa trong bảng PS3.6 Data Dictionary. Dưới đây là các tag mà kỹ sư FHIR cần nhớ khi map sang ImagingStudy:

File Meta Information   (Group 0002)         — header, transfer syntax
PatientName             (0010,0010)          — họ tên bệnh nhân
PatientID               (0010,0020)          — định danh bệnh nhân (MRN)
PatientBirthDate        (0010,0030)          — ngày sinh
StudyInstanceUID        (0020,000D)          — UID lần khám (Study)
SeriesInstanceUID       (0020,000E)          — UID chuỗi ảnh (Series)
SOPInstanceUID          (0008,0018)          — UID từng instance ảnh
SOPClassUID             (0008,0016)          — kiểu Service-Object
StudyDate               (0008,0020)          — ngày chụp
StudyDescription        (0008,1030)          — mô tả lần khám
Modality                (0008,0060)          — CT, MR, US, CR, DX, MG…
PixelData               (7FE0,0010)          — dữ liệu điểm ảnh nhị phân

Mỗi data element gồm bốn phần: cặp tag (Group, Element), mã VR (PN cho tên người, UI cho UID, DA cho ngày, OW/OB cho pixel data…), trường length, và value thực. Chính cấu trúc này giúp file DICOM tự mô tả: phần mềm parser không cần biết trước layout vì có thể đọc tuần tự dựa trên VR và length.

Bộ ba StudyInstanceUID — SeriesInstanceUID — SOPInstanceUID tạo thành cây định danh ba tầng cho mọi instance trên thế giới. Một bệnh nhân có thể có nhiều Study (ví dụ một CT ngực và một MRI sọ); mỗi Study có nhiều Series (axial, coronal, sagittal, hoặc các pha tiêm thuốc khác nhau); mỗi Series chứa nhiều Instance (thường là từng lát cắt). UID không bao giờ trùng giữa các hệ thống vì được phát sinh theo OID toàn cục, ví dụ 1.2.840.113619.2.5.1762583153.215519.978957063.78.

SOP Class UID — viết tắt của Service-Object Pair — chỉ ra cặp dịch vụ kết hợp với kiểu đối tượng. Khi modality CT gửi ảnh về PACS, nó dùng SOP Class CT Image Storage (1.2.840.10008.5.1.4.1.1.2); khi RIS hỏi worklist, nó dùng Modality Worklist Information Model FIND. Hai bên phải đàm phán SOP Class trong giai đoạn association request, nếu không khớp thì kết nối bị từ chối.

4. Workflow modality và bệnh viện

Một ca chẩn đoán hình ảnh thường đi qua bốn hệ thống: HIS (hồ sơ bệnh án), RIS (quản lý chẩn đoán hình ảnh), modality (máy chụp) và PACS (kho lưu trữ). DICOM kết nối ba mắt xích sau, còn HL7 v2 hoặc FHIR đảm nhiệm trao đổi với HIS.

[HIS]      — HL7 v2 ORM (order)        →  [RIS]
[RIS]      — DICOM Modality Worklist  →  [Modality (máy CT/MR…)]
[Modality] — DICOM C-STORE             →  [PACS]
[PACS]     — DICOM C-MOVE / WADO-RS    →  [Viewer / workstation]
[Bác sĩ]   — HL7 v2 ORU hoặc FHIR
             DiagnosticReport          →  [HIS]

Khi bác sĩ lâm sàng chỉ định chụp, HIS phát một order sang RIS. RIS lập lịch và đẩy thông tin ca chụp vào hàng đợi worklist. Modality khi bắt đầu ca chụp sẽ truy vấn RIS qua DICOM Modality Worklist, nhận về mã bệnh nhân, tên thủ thuật và Accession Number, qua đó đảm bảo metadata gắn đúng vào ảnh. Sau khi chụp xong, modality nén ảnh và gửi C-STORE về PACS. Bác sĩ chẩn đoán hình ảnh mở viewer để đọc — viewer dùng C-MOVE, C-GET hoặc DICOMweb WADO-RS để kéo ảnh từ PACS, đọc xong viết kết luận và gửi report ngược về HIS dưới dạng tin nhắn HL7 v2 ORU hoặc tài nguyên FHIR DiagnosticReport.

5. PACS, RIS, Modality Worklist

Ba thuật ngữ này xuất hiện trong gần như mọi tài liệu kỹ thuật chẩn đoán hình ảnh, nên cần phân biệt rõ:

• PACS — Picture Archiving and Communication System: kho lưu trữ DICOM tập trung, đóng vai trò vừa là server C-STORE SCP nhận ảnh, vừa là Query/Retrieve SCP phục vụ viewer. Một PACS hiện đại thường mở thêm endpoint DICOMweb cho viewer web và mobile.
• RIS — Radiology Information System: phần mềm nghiệp vụ của khoa chẩn đoán hình ảnh, quản lý lịch hẹn, order, nhân lực, thời gian đọc phim, và phát hành báo cáo. RIS không lưu ảnh; nó tham chiếu tới PACS qua Accession Number và Study UID.
• MWL — Modality Worklist: dịch vụ DICOM (Modality Worklist Information Model FIND) cho phép modality kéo về danh sách công việc trong ngày từ RIS, giúp tránh nhập tay sai sót thông tin bệnh nhân vào màn hình modality.

Trong nhiều bệnh viện vừa và nhỏ, ranh giới giữa RIS và HIS bị xóa nhòa: HIS đảm nhiệm luôn vai trò RIS, còn worklist được tạo trực tiếp từ HIS. Cách triển khai đó vẫn hợp lệ về mặt DICOM, miễn là endpoint MWL được expose đúng SOP Class.

6. DICOMweb — lớp REST kế thừa

DICOMweb là cách DICOM bắt kịp web hiện đại. Thay vì giữ TCP raw, các dịch vụ được biểu diễn bằng URL HTTP, trả JSON hoặc multipart binary. Ba dịch vụ cốt lõi:

• WADO-RS — Web Access to DICOM Objects, RESTful: kế thừa C-MOVE/C-GET.
• QIDO-RS — Query based on ID for DICOM Objects: kế thừa C-FIND.
• STOW-RS — Store Over the Web: kế thừa C-STORE.

GET /studies?PatientID=0123456789
   Accept: application/dicom+json
   → JSON danh sách Study khớp QIDO-RS

GET /studies/{StudyInstanceUID}/metadata
   Accept: application/dicom+json
   → JSON metadata toàn bộ Study (WADO-RS Metadata)

GET /studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}
   Accept: multipart/related; type="application/dicom"
   → multipart binary từng instance DICOM

POST /studies
   Content-Type: multipart/related; type="application/dicom"
   → STOW-RS: gửi instance mới lên PACS

Ưu điểm lớn nhất của DICOMweb: viewer chạy trong trình duyệt không cần plugin, không cần mở port DICOM, hoạt động xuyên proxy HTTPS. Đây là lý do các viewer mã nguồn mở như OHIF, Cornerstone3D chọn DICOMweb làm giao tiếp mặc định.

7. FHIR + DICOM — quan hệ bổ sung

Câu hỏi tự nhiên với người làm FHIR: liệu FHIR có thay được DICOM không? Câu trả lời ngắn là không, ít nhất trong tương lai gần. FHIR và DICOM giải quyết hai bài toán khác nhau và được thiết kế để bổ sung lẫn nhau.

Mô hình tích hợp phổ biến: PACS tiếp tục lưu ảnh DICOM và phục vụ qua DIMSE/DICOMweb. Hệ thống FHIR tạo tài nguyên ImagingStudy tham chiếu tới Study đó, và một tài nguyên Endpoint chứa URL DICOMweb của PACS. Viewer client đọc ImagingStudy, lấy URL từ Endpoint, rồi gọi WADO-RS để tải pixel data. FHIR đóng vai trò index và metadata layer xuyên bệnh viện; DICOM giữ vai trò storage gốc.

8. ImagingStudy và ImagingSelection

ImagingStudy là tài nguyên FHIR chuẩn từ R4 dành riêng cho chẩn đoán hình ảnh. Mỗi ImagingStudy đại diện cho đúng một DICOM Study, dùng định danh urn:dicom:uid để mang StudyInstanceUID nguyên gốc.

{
  "resourceType": "ImagingStudy",
  "identifier": [{
    "system": "urn:dicom:uid",
    "value": "urn:oid:1.2.840.113619.2.5.1762583153.215519.978957063.78"
  }],
  "status": "available",
  "subject": { "reference": "Patient/123" },
  "started": "2026-04-15T08:30:00+07:00",
  "modality": [{
    "system": "http://dicom.nema.org/resources/ontology/DCM",
    "code": "CT"
  }],
  "endpoint": [{ "reference": "Endpoint/dicomweb-pacs" }],
  "numberOfSeries": 3,
  "numberOfInstances": 240
}

Lưu ý hệ thống mã trong modality phải là canonical URI của DICOM Controlled Terminology, tức http://dicom.nema.org/resources/ontology/DCM. Nếu dùng URI placeholder, server FHIR có thể từ chối khi validate ValueSet.

Phía R5 bổ sung tài nguyên mới ImagingSelection để mô tả vùng quan tâm (ROI), bookmark, hay key image — ví dụ bác sĩ đánh dấu một lát CT có khối u để gửi cho hội chẩn. ImagingSelection là R5 chứ không phải R4; trong các IG dựa trên FHIR R4 (kể cả VN Core), nên giữ ImagingStudy là chính và coi ImagingSelection là tham chiếu tương lai khi nâng lên R5.

9. IHE Radiology profile

IHE (Integrating the Healthcare Enterprise) phát hành các profile gắn DICOM và HL7 vào quy trình thực tế. Trong domain Radiology, bốn profile thường gặp gồm:

• SWF — Scheduled Workflow: chuẩn hóa luồng order — schedule — perform — store — report.
• XDS-I — Cross-Enterprise Document Sharing for Imaging: chia sẻ ảnh và báo cáo giữa các tổ chức qua registry/repository.
• IID — Invoke Image Display: chuẩn URL để HIS gọi viewer hiển thị Study cụ thể.
• XCA-I — Cross-Community Access for Imaging: liên cộng đồng / liên vùng, mở rộng cho mạng quốc gia.

Khi bệnh viện hoặc cụm bệnh viện cần chia sẻ ảnh xuyên đơn vị, các profile IHE giúp tránh phát minh lại bánh xe. Đây cũng là nền cho các hub PACS quốc gia ở nhiều nước châu Âu. Xem thêm trang IHE profile cho y tế Việt Nam để hiểu sâu hơn cách áp các profile này.

10. Bối cảnh Việt Nam

Tại Việt Nam, DICOM là chuẩn de facto cho mọi modality nhập khẩu. Đa số bệnh viện tuyến tỉnh và tuyến trung ương đã triển khai PACS — đến từ các vendor lớn như Carestream, GE Healthcare, Siemens Healthineers, Fujifilm, Philips, hoặc các nhà cung cấp nội địa tích hợp lại. Do bản chất quốc tế của chuẩn, PACS tại Việt Nam thường dùng nguyên DICOM 3.0 mà không cần local profile riêng.

Tích hợp HIS-PACS phổ biến nhất hiện nay vẫn dựa trên HL7 v2 ORM (gửi order) và HL7 v2 ORU (nhận report). Một số bệnh viện đã thí điểm tầng FHIR phía trước HIS, nhưng việc đưa ImagingStudy vào sản xuất rộng còn ở giai đoạn đầu. Khi VN Core FHIR (canonical http://fhir.hl7.org.vn/core) được nhân rộng, ImagingStudy sẽ là tài nguyên trục để đặc tả khả năng xem hình ảnh liên bệnh viện (cross-hospital viewing) — đặc biệt phù hợp với mô hình bệnh án điện tử theo Thông tư 13/2025/TT-BYT.

Thông tư 13/2025/TT-BYT yêu cầu bệnh án điện tử của bệnh viện phải hoàn thiện chậm nhất ngày 31/12/2026. Hình ảnh chẩn đoán là một hợp phần bắt buộc của bệnh án điện tử. Việc giữ ảnh ở DICOM và mở thêm tầng FHIR ImagingStudy là con đường dung hòa giữa đầu tư PACS đã có và yêu cầu interoperability mới. Để hiểu sâu hơn về bệnh án điện tử và các tài nguyên FHIR liên quan, xem trang giới thiệu các FHIR Resource cốt lõi.

11. Câu hỏi thường gặp

File DICOM thường lớn cỡ nào?

Một CT scan tiêu chuẩn cho ra khoảng 500 MB tới 2 GB cho mỗi Study (vài trăm tới vài nghìn lát cắt mỏng). MRI tương đương hoặc lớn hơn nếu chụp đa chuỗi. Phim X-quang số (CR/DX) chỉ chiếm 10 MB tới 50 MB mỗi ảnh. Mammography (MG) độ phân giải cao có thể vượt 100 MB mỗi view.

Chuẩn DICOM có miễn phí không?

Tiêu chuẩn DICOM được công bố miễn phí trên website dicomstandard.org/current, không cần trả phí licence như một số chuẩn HL7 v2 cũ. Chi phí thực tế nằm ở phần triển khai: PACS, viewer, modality, dịch vụ vận hành.

Nếu chỉ làm FHIR, có cần học DICOM sâu không?

Tùy phạm vi. Để tích hợp ImagingStudy với PACS, kỹ sư FHIR cần nắm khái niệm SOP Class UID, bộ ba Study/Series/Instance UID, và URL DICOMweb. Đào sâu Transfer Syntax, VR hay Modality Worklist có thể chờ tới khi cần làm viewer hoặc xử lý ảnh trực tiếp.

FHIR có thay được DICOM trong tương lai không?

Không trong tương lai gần. FHIR không đặc tả cấu trúc pixel data, không có chuẩn nén ảnh y tế, và không có hệ tag VR. Hướng đi thực tế là FHIR đóng vai trò metadata + index, còn DICOM giữ phần ảnh nguyên gốc. Mọi roadmap bệnh án điện tử nên coi DICOM là tầng không thể bỏ.

12. Tài liệu tham khảo và đọc tiếp

Nguồn chính

• DICOM Standard hiện hành — dicomstandard.org/current. Toàn bộ 22 phần PS3.1 đến PS3.22, cập nhật nhiều lần mỗi năm.
• DICOM Data Dictionary (PS3.6) — dicom.nema.org PS3.6 Chapter 6. Bảng tag chuẩn để tra (Group, Element).
• DICOMweb services (PS3.18) — dicom.nema.org PS3.18. Đặc tả WADO-RS, QIDO-RS, STOW-RS, UPS-RS.
• DICOM Controlled Terminology (PS3.16) — dicom.nema.org PS3.16 Chapter 8. Canonical URI http://dicom.nema.org/resources/ontology/DCM.
• FHIR R4 ImagingStudy — hl7.org/fhir/R4/imagingstudy.html.
• FHIR R5 ImagingSelection — hl7.org/fhir/R5/imagingselection.html.
• IHE Radiology Technical Frameworks — ihe.net/resources/technical_frameworks.
• Thông tư 13/2025/TT-BYT về bệnh án điện tử — căn cứ pháp lý cho lộ trình hoàn thiện EMR và tích hợp hình ảnh tại Việt Nam.

Đọc tiếp trên hl7.org.vn