PACS DICOM là gì và cách hoạt động?
Bất kỳ ai tìm hiểu về hệ thống PACS đều sẽ sớm gặp thuật ngữ DICOM — chuẩn công nghệ đóng vai trò nền tảng, gắn liền không thể tách rời với toàn bộ cách PACS vận hành. Nếu PACS là "cơ thể" của hệ thống lưu trữ hình ảnh y tế, thì DICOM chính là "ngôn ngữ chung" mà mọi thiết bị, mọi phần mềm trong hệ thống đó dùng để giao tiếp với nhau. Bài viết này giải thích chi tiết DICOM là gì, lịch sử ra đời, cấu trúc kỹ thuật của một file DICOM, và cách chuẩn này vận hành để giúp PACS trở thành một hệ thống thống nhất, có thể kết nối thiết bị của nhiều hãng khác nhau.
DICOM là gì?
DICOM là viết tắt của Digital Imaging and Communications in Medicine (Hình ảnh số và Truyền thông trong Y tế) — một chuẩn quốc tế quy định cách các hình ảnh y tế và dữ liệu liên quan được định dạng, lưu trữ và truyền tải giữa các thiết bị, hệ thống trong lĩnh vực chăm sóc sức khỏe. DICOM thực chất bao gồm hai thành phần: một định nghĩa định dạng file (file format) và một giao thức truyền thông qua mạng (network communications protocol). Nói cách khác, khi ai đó nhắc đến "một file DICOM", họ thường muốn nói đến một file .dcm cụ thể được lưu trên ổ đĩa; còn khi nhắc đến "giao tiếp DICOM" (DICOM communication), họ đang nói về giao thức mạng TCP/IP mà các thiết bị dùng để gửi những file đó cho nhau. Cùng một chuẩn quy định cả hai khía cạnh này, và cùng những phần tử dữ liệu (data element) xuất hiện ở cả hai — đây là lý do việc hiểu DICOM cần bắt đầu từ bộ từ vựng dữ liệu chung, trước khi đi vào sự khác biệt giữa file và mạng.
Lịch sử ra đời của DICOM
Trước khi có DICOM, mỗi nhà sản xuất thiết bị chẩn đoán hình ảnh đều sử dụng định dạng riêng, mang tính độc quyền (proprietary format) của hãng mình. Điều này có nghĩa là một máy CT của hãng GE không thể gửi hình ảnh trực tiếp đến một trạm làm việc của hãng Siemens mà không cần một lớp chuyển đổi (translation layer) tùy chỉnh tốn kém, làm cho việc kết nối liên thông giữa các thiết bị của các hãng khác nhau trở nên vô cùng khó khăn.
Để giải quyết vấn đề này, năm 1983, Hiệp hội Điện quang Hoa Kỳ (American College of Radiology – ACR) và Hiệp hội các nhà sản xuất thiết bị điện quốc gia (National Electrical Manufacturers Association – NEMA) đã cùng thành lập một ủy ban chung nhằm phát triển các tiêu chuẩn công nghệ hình ảnh y tế. Phiên bản chuẩn đầu tiên ra đời, và phiên bản thứ hai được phát hành sau đó vẫn tiếp tục là phiên bản nền tảng cho đến ngày nay, dù đã được cập nhật liên tục kể từ năm 1993. Nhờ có DICOM, gần như toàn bộ các nhà sản xuất thiết bị chẩn đoán hình ảnh lớn và các công ty công nghệ thông tin y tế trên thế giới hiện nay đều tuân thủ chuẩn chung này, cho phép các thiết bị của những hãng khác nhau "nói chuyện" được với nhau một cách liền mạch.
Cấu trúc của một file DICOM
Một file DICOM (định dạng .dcm) có cấu trúc gồm bốn phần chính, tương tự cách các định dạng ảnh phổ biến khác như JPEG hay PNG mã hóa cả siêu dữ liệu (metadata) lẫn dữ liệu điểm ảnh, nhưng với mức độ chi tiết chuyên sâu hơn nhiều dành riêng cho lĩnh vực y tế:
File Preamble (phần mở đầu): một khối dữ liệu cố định dài 128 byte, có công dụng chính là giúp tăng khả năng tương thích, cho phép các file DICOM được nhận diện dễ dàng bởi nhiều loại phần mềm xử lý ảnh thông thường khác.
DICOM Prefix (tiền tố): một chuỗi 4 byte cố định chứa ký tự "DICM" viết hoa, đóng vai trò như "dấu hiệu nhận diện" xác nhận đây là một file tuân thủ chuẩn DICOM.
File Meta Information (thông tin siêu dữ liệu file) — phần Header: chứa các thông tin về bệnh nhân (họ tên, mã số, ngày sinh...), thông số thu nhận hình ảnh (loại máy, tham số chụp), kích thước ma trận ảnh, không gian màu và cách mã hóa, cùng một tập hợp lớn các tham số bổ sung khác. Cấu trúc, cách mã hóa và cách biểu diễn các giá trị này được quy định chi tiết trong Phần 10 của chuẩn DICOM, và được gọi chung là các "thẻ dữ liệu chuẩn" (standard data elements, hay còn gọi là "tags").
Data Set (bộ dữ liệu) — phần Body: chứa dữ liệu hình ảnh thực tế, được lưu dưới dạng một thuộc tính đặc biệt duy nhất (thường có mã nhận diện 7FE0), là một chuỗi nhị phân (chuỗi số 0 và 1) mà từ đó hình ảnh được tái tạo lại dựa trên các thông tin mô tả có trong phần header.
Cơ chế "thẻ" (tag) — đơn vị dữ liệu cơ bản của DICOM
Mỗi phần tử dữ liệu (data element) trong file DICOM được xác định bằng một cặp mã định danh dạng nhóm/phần tử (group/element), ví dụ cặp mã (0010,0010) đại diện cho trường "Tên bệnh nhân" (Patient's Name). Mỗi thẻ còn đi kèm một "Value Representation" (VR — kiểu biểu diễn giá trị) quy định cách dữ liệu đó được mã hóa: ví dụ ngày tháng dùng mã VR là "DA", tên người dùng mã "PN", mã định danh duy nhất dùng mã "UI", còn dữ liệu điểm ảnh dùng mã "OB" hoặc "OW". Chuẩn DICOM hiện quy định gần 5.000 thẻ dữ liệu khác nhau, bao phủ hầu như mọi loại thông tin có thể cần thiết trong một nghiên cứu hình ảnh y tế. Ngoài các thẻ chuẩn, DICOM cũng cho phép các nhà sản xuất tạo thêm các thẻ riêng (private tags) tùy chỉnh theo nhu cầu đặc thù của từng hãng.
SOP Class — quy định tập hợp thẻ bắt buộc cho từng loại hình ảnh
Để đảm bảo tính nhất quán, với mỗi loại thiết bị (modality) như MRI, CT, siêu âm, PET, X-quang..., chuẩn DICOM quy định một danh sách các thẻ bắt buộc phải có, gọi là "Storage Service-Object Pair" (Storage SOP), quy định rõ những thuộc tính nào cần xuất hiện và kiểu biểu diễn giá trị tương ứng của chúng. Để một file được coi là hợp lệ theo chuẩn DICOM, mỗi SOP Class sẽ quy định rõ những nhóm thẻ nào là bắt buộc phải có, nhóm nào là tùy chọn. Danh sách đầy đủ các SOP Class được công bố công khai trên trang web chính thức của tổ chức DICOM, được tổ chức theo "mã định danh lớp" (class ID) — một mã định danh duy nhất giúp xác định loại thiết bị đã tạo ra hình ảnh đó.
DICOM hoạt động trên mạng như thế nào?
Bên cạnh định dạng file, phần giao thức mạng của DICOM (đôi khi gọi riêng là DIMSE — DICOM Message Service Element) quy định cách các thiết bị trao đổi dữ liệu với nhau qua mạng TCP/IP. Về cơ bản, hai thiết bị sẽ thiết lập một "phiên kết nối" (association) giữa hai vai trò: Service Class User (SCU) — bên yêu cầu dịch vụ, và Service Class Provider (SCP) — bên cung cấp dịch vụ. Phiên kết nối này trao đổi chính những phần tử dữ liệu (data element) đã nêu ở trên, được đóng gói theo cấu trúc DICOM Upper Layer và các thông điệp DIMSE.
Có một số nhóm lệnh dịch vụ (service class) phổ biến nhất mà các thiết bị dùng để "yêu cầu" nhau thực hiện hành động cụ thể:
C-STORE: thông điệp có ý nghĩa "đây là một hình ảnh, hãy lưu trữ nó lại" — đây là lệnh chủ lực, được các thiết bị chẩn đoán hình ảnh (modality) sử dụng để gửi hình ảnh vừa chụp đến PACS để lưu trữ.
C-FIND: thông điệp có ý nghĩa "hãy hiển thị cho tôi tất cả các nghiên cứu khớp với các tiêu chí này" — được các trạm làm việc sử dụng để truy vấn, tìm kiếm dữ liệu đang lưu trong PACS.
C-MOVE: thông điệp có ý nghĩa "hãy gửi những nghiên cứu này đến địa chỉ AE Title (Application Entity Title — định danh ứng dụng) chỉ định" — đây là cách một trạm làm việc kéo (pull) các nghiên cứu trước đó từ kho lưu trữ về để so sánh với nghiên cứu hiện tại.
C-GET: một phương án thay thế cho C-MOVE, giúp tránh được sự phức tạp về tường lửa/định tuyến mà C-MOVE có thể gặp phải, đổi lại cần duy trì cùng một phiên kết nối đang mở trong suốt quá trình truyền dữ liệu.
Vai trò của DICOM trong việc vận hành PACS
Chính nhờ có chuẩn DICOM mà một hệ thống PACS mới có thể tiếp nhận hình ảnh gửi đến từ nhiều loại thiết bị chẩn đoán hình ảnh khác nhau — dù đến từ các hãng sản xuất khác nhau — theo một định dạng thống nhất, thay vì phải xây dựng riêng từng bộ chuyển đổi dữ liệu cho mỗi loại máy. Khi một thiết bị gửi hình ảnh đến PACS bằng lệnh C-STORE, hệ thống PACS sẽ phân tích (parse) phần dữ liệu nghiên cứu và hình ảnh chứa trong header DICOM, đối chiếu với dữ liệu bệnh nhân và chỉ định được chuyển từ hệ thống RIS, nhằm đảm bảo hình ảnh được gán chính xác vào đúng bệnh nhân trước khi lưu vào kho lưu trữ.
Ngoài dữ liệu hình ảnh thuần túy, DICOM còn hỗ trợ đóng gói cả những dữ liệu không phải hình ảnh — ví dụ tài liệu đã quét (như phiếu chỉ định, kết quả kèm theo) có thể được đóng gói theo các định dạng tiêu chuẩn công nghiệp như PDF, rồi mã hóa bên trong một file DICOM để lưu trữ đồng bộ cùng với hình ảnh trong cùng một hệ thống.
Vấn đề tương thích: khi các hãng "hiểu" DICOM theo cách khác nhau
Dù DICOM là một chuẩn chung, trên thực tế, các nhà cung cấp PACS đôi khi vẫn áp dụng những biến thể cú pháp (syntax) khác nhau trong khuôn khổ chuẩn DICOM, khiến việc sử dụng dữ liệu từ hệ thống này trong một hệ thống y tế khác gặp khó khăn nhất định. Đây chính là lý do khiến công nghệ Vendor Neutral Archive (VNA) ra đời và ngày càng phổ biến trong một số cơ sở y tế — VNA hoạt động như một lớp trung gian, giúp tích hợp dữ liệu bằng cách tách dữ liệu ra khỏi hệ thống PACS gốc và di chuyển sang hệ thống mới với cú pháp phù hợp, không phụ thuộc vào bất kỳ hãng cụ thể nào.
Trong quá trình triển khai thực tế, khi tích hợp thất bại giữa các hệ thống PACS của các hãng khác nhau (ví dụ giữa GE và Philips), nguyên nhân phổ biến thường đến từ việc các thiết bị áp dụng cách triển khai DICOM không chuẩn hoặc sử dụng các giao thức độc quyền riêng. Trong những trường hợp này, kỹ thuật viên thường cần đối chiếu lại tài liệu công bố mức độ tuân thủ DICOM của từng thiết bị (gọi là "DICOM Conformance Statement" — tài liệu mà mỗi nhà sản xuất bắt buộc phải công bố, mô tả chính xác những tính năng và SOP Class nào mà thiết bị của họ hỗ trợ), cập nhật firmware/phần mềm lên phiên bản mới nhất, hoặc sử dụng một lớp phần mềm trung gian trung lập thương hiệu để đảm bảo khả năng tương tác.
HL7 và DICOM: hai chuẩn khác nhau, cùng phối hợp trong hệ thống y tế
Một điểm dễ gây nhầm lẫn là DICOM không phải chuẩn duy nhất được sử dụng trong hệ thống công nghệ thông tin y tế. Trong khi DICOM chuyên trách việc mã hóa và truyền tải dữ liệu hình ảnh cùng các siêu dữ liệu liên quan trực tiếp, chuẩn HL7 (Health Level Seven) lại đảm nhiệm việc trao đổi các dữ liệu hành chính, lâm sàng dạng văn bản (như thông tin chỉ định, báo cáo kết quả) giữa các hệ thống như HIS, RIS và PACS. Hai chuẩn này phối hợp chặt chẽ với nhau: chỉ định chụp được truyền từ hệ thống bệnh án điện tử sang RIS bằng thông điệp HL7, sau đó RIS truyền thông tin ca khám cho thiết bị chụp thông qua giao diện DICOM Modality Worklist (một phần mở rộng của chuẩn DICOM) để tự động điền sẵn thông tin bệnh nhân, tránh việc kỹ thuật viên phải nhập liệu thủ công.
Kết luận
DICOM không chỉ đơn thuần là một định dạng file ảnh, mà là toàn bộ nền tảng ngôn ngữ chung cho phép các thiết bị chẩn đoán hình ảnh, hệ thống PACS và các trạm làm việc của nhiều nhà sản xuất khác nhau có thể giao tiếp, trao đổi dữ liệu hình ảnh y tế một cách liền mạch. Hiểu rõ cấu trúc file DICOM (preamble, prefix, header, body), cơ chế thẻ dữ liệu (tag), SOP Class, cùng các giao thức mạng cốt lõi (C-STORE, C-FIND, C-MOVE) sẽ giúp các cơ sở y tế và đội ngũ kỹ thuật vận hành hệ thống PACS hiệu quả hơn, đồng thời hiểu rõ nguyên nhân gốc rễ khi gặp các vấn đề tương thích giữa thiết bị của những nhà sản xuất khác nhau trong quá trình triển khai thực tế.
Mất điện giữa phiên truyền DICOM — rủi ro dữ liệu ít ai để ý
Như đã trình bày ở trên, khi một thiết bị chẩn đoán hình ảnh gửi dữ liệu đến PACS bằng lệnh C-STORE, quá trình này diễn ra thông qua một "phiên kết nối" (association) giữa hai thiết bị, truyền tải toàn bộ dữ liệu hình ảnh và metadata theo từng gói tin. Nếu nguồn điện của thiết bị chụp, máy chủ PACS, hoặc thiết bị mạng trung gian bị ngắt đột ngột ngay giữa phiên truyền này, dữ liệu hình ảnh có thể bị truyền thiếu, gây lỗi file DICOM hoặc buộc phải chụp lại từ đầu — vừa lãng phí thời gian, vừa có thể ảnh hưởng đến bệnh nhân nếu phải tiếp xúc thêm bức xạ (với các thiết bị dùng tia X như CT, X-quang). Đây là một trong nhiều lý do cho thấy việc trang bị UPS cho toàn bộ chuỗi thiết bị liên quan đến truyền tải DICOM — từ modality, mạng, cho đến máy chủ PACS — là khoản đầu tư cần thiết chứ không phải tùy chọn. Các dòng UPS Hyundai và UPSmart là những lựa chọn phù hợp để bảo vệ hạ tầng truyền tải hình ảnh y tế khỏi những rủi ro gián đoạn này.
