- Do có khảo sát thực tế tại bệnh viện Hồng Đức nên chương trình có thể đáp ứng được nhu cầu thực tiễn hiện tại.
- Ứng dụng hỗ trợ tốt hoạt động khám chữa bệnh ngoại trú cho bệnh viện đặc biệt khám cận lâm sàng. Giúp cho bệnh nhân đến khám cảm thấy thuận tiện, thoải mái và tiết kiệm nhiều thời gian khám.
- Thông tin khám chữa bệnh có thể được truy xuất tiện lợi, nhanh chóng trên mạng nội bộ trong bệnh viện.
- Hình ảnh thông tin chẩn đoán được luân chuyển tốt trong nội bộ, chủ yếu mọi hoạt động dựa trên máy tính là chính. Dữ liệu chẩn đoán cận lâm sàng được lưu trữ tập trung trên máy chủ nên tránh tối đa nguy cơ mất mát dữ liệu
70 trang |
Chia sẻ: baoanh98 | Lượt xem: 1111 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Luận văn Nghiên cứu chuẩn DICOM dùng trong hệ thống thông tin hình ảnh y khoa - Ứng dụng xây dựng hệ thống quản lí và truyền thông hình ảnh y tế trong bệnh viện, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Mục lục
Chương I
Giới thiệu chung
Ngày nay Công nghệ Thông tin đã đi sâu và rộng vào đời sống của của con người, việc ứng dụng Công nghệ vào cuộc sống và kinh doanh là rất cần thiết trong thời đại ngày nay.
Hiện nay hầu hết các công ty, cơ quan, trường học và bệnh viện vừa và nhỏ đều sở hữu cho mình một hệ thống công nghệ thông tin, việc đầu tư cho hệ thống không hề nhỏ, để có được hệ thống để quản lí công ty đòi hỏi cần có nhiều thời gian, nhân lực và tiền bạc. Với mục đích duy trì công ty một cách hiệu quả, nhanh chóng và chính xác thì ngoài nhân lực ra, công nghệ cũng chiếm phần quan trọng rất lớn. Các hệ thống như: hệ thống quản lí nhân sự, hệ thống quản lí công văn, hóa đơn, chứng từ, hệ thống quản lí việc nhập xuất hàng hóa, hệ thống tài chính đều đang ứng dụng sức mạnh của Công nghệ Thông tin vào quy trình quản lý.
Trong lĩnh vực y khoa, việc quản lý chặt chẽ thông tin bệnh nhân, quản lý các y cụ, các thuốc đặc thù là điều rất quan trọng. Khi đó chúng ta cần phải có một hệ thống bảo mật, phân bố cao phù hợp với loại hình tổ chức bệnh viện. Từ đó phát sinh ra các quy trình trong từng khâu từng bộ phận như :
Quản lí hồ sơ bệnh nhân.
Quản lí thông tin các y cụ và dược phẩm.
Quản lí các hình ảnh chẩn đoán cận lâm sàng.
Quản lí các quy trình khám bệnh.
Quản lí tài chính.
Quản lí bệnh nhân nội - ngoại trú.
Quản lí ngân hàng máu.
Từng quy trình trên phải có mối liên kết với nhau tạo nên một thể thống nhất cho việc điều hành mọi mặt trong bệnh viện. Hệ thống không chỉ quản lý và sử dụng trong nội bộ bệnh viện mà còn được phục vụ cho cả tập toàn, cách trụ sở khác của bệnh viện như trong việc phân tán dữ liệu, chẩn bệnh từ xa Khi đó các bệnh viện trên toàn thế giới sẽ kết nối được với nhau chia sẻ thông tin vì mục đích sức khỏe cho nhân loại.
Để phục vụ cho nhu cầu đó, cần phải tạo các chuẩn giao tiếp là hết sức quan trọng và cần thiết trong việc truyền thông, trao đổi dữ liệu. Khi các bệnh viện trên thế giới có một tiếng nói chung thì việc chẩn đoán bệnh từ xa, giải phẫu từ xa ... sẽ trở nên phổ biến. Từ đó có thể thu thập được trí tuệ của nhân loại để phục vụ cho sức khỏe cộng đồng.
Hiện nay trên thế giới có rất nhiều hệ thống quản lý bệnh viện sử dụng Công nghệ Thông tin mạnh và thông dụng như:
RIS (Radiology Information System).
HIS (Hospital Information System).
LIS (Laboratory Information System).
PACS (Picture Archiving and Communication Systems) và chuẩn hình ảnh đa dụng như hiện nay là DICOM được nhiều nhà sản xuất thiết bị chẩn đoán cận lâm sàng hỗ trợ.
Chương II
Kiến thức liên quan
Tổng quan về ảnh dùng trong y khoa
Các chuẩn lưu trữ ảnh trong y khoa
Analysis of Functional NeuroImaging – AFNI
AFNI (Analysis of Functional NeuroImaging) là một môi trường xử lý, phân tích và hiển thị fMRI data – một kĩ thuật mô phỏng hoạt động của bộn não con người. AFNI chạy trên hệ thống Unix+X11+MOTIF, bao gồm cả SGI và Linux.
ANFI được viết bằng ngôn ngữ C, được phát triển rất mạnh ở đại học y dược Wisconsin vào năm 1994 và sau này Robert W. Cox phát triển thêm. Việc phát triển này mang lại nhiều điểm nhấn trong NIH (National Institutes of Health) vào năm 2001 và tiếp tục phát triển ở NIMH Scientific and Statistical Computing Core.
AFNI lưu trữ thông tin vào 2 file:
File BRIK lưu trữ dữ liệu.
File ACII HEAD lưu trữ các thông tin header.
Chương trình phần mềm AFNI
Analyse
Analyze là chương trình phần mềm mạnh do BIR (Biomedical Imaging Resource) ở Mayo Clinic phát triền, dùng trong hiển thị, xử lí và đo đạc các ảnh đa chiều trong trong y khoa. Analyze được sử dụng để lấy các ảnh chụp từ MRI, CT and PET.
Định dạng file trong Analyse 7.5 đã được sử dụng sâu rộng trên lĩnh vực xử lí ảnh não bộ thần kinh, và các chương trình khác như SPM (Statistical Parametric Mapping), AIR, MRIcro có thể đọc và ghi định dạng đó. Những file có thể được sử dụng để lưu trữ những hình khối đa chiều.
Một mục dữ liệu gồm hai file :
Một file chứa dữ liệu kiểu binary với phần mở rộng .img
Một file chứa metadata với phần mở rộng .hdr
Chương trình phần mềm Analyse
DICOM
DICOM (Digital Imaging and Communications in Medicine) là tập hợp các chuẩn dùng trong xử lý, truyền tải thông tin, lưu trữ và in ấn ảnh y khoa. Chuẩn này bao gồm định dạng file và giao thức truyền tin qua mạng. File DICOM được trao đổi giữa 2 chương trình và các chương trình này có thể nhận ảnh và dữ liệu bệnh nhân theo định dạng DICOM.
DICOM cho phép tích hợp máy scan, server, trạm làm việc, máy tin và các thiết bị mạng từ nhiều nhà cung cấp vào thành một hệ thống truyền tải và lưu trữ ảnh. Ngày nay, các hầu hết các bệnh viện trên thế giới đều áp dụng DICOM vào trong các thiết bị y khoa, máy trạm, server, các hệ thống quản lý trong hoạt động khám và chữa bệnh.
Các Modality hỗ trợ DICOM.
Viết tắt
Tên đầy đủ
Viết tắt
Tên đầy đủ
AS
Angioscopy
LS
Laser Surface Scan
BI
Biomagnetic Imaging
MA
Magnetic Resonance Angiography
CD
Color Flow Doppler
MR
Magnetic Resonance
CP
Culposcopy
MS
Magnetic Resonance Spectroscopy
CR
Computed Radiography
NM
Nuclear Medicine
CS
Cystoscopy
PT
Positron Emission Tomography
CT
Computed Tomography
RF
Radio Fluoroscopy
DD
Duplex Doppler
RG
Radiographic Imaging
DG
Diaphanography
RTDOSE
Radiotherapy Dose
DM
Digital Microscopy
RTIMAGE
Radiotherapy Image
DS
Digital Subtraction Angiography
RTPLAN
Radiotherapy Plan
DX
Digital Radiography
RTSTRUCT
Radiotherapy Structure Set
EC
Echocardiography
ST
Single-photon Emission Computed Tomography
ES
Endoscopy
TG
Thermography
FA
Fluorescein Angiography
US
Ultrasound
FS
Fundoscopy
XA
X-Ray Angiography
HC
Hard Copy
ECG
Electrocardiograms
LP
Laparoscopy
Chuẩn DICOM
Giới thiệu chung
Vào năm 1970, trước sự ra đời của phương pháp chụp ảnh CT (Computed Tomography) cùng với các phương pháp chụp ảnh số dùng trong chẩn đoán y khoa khác, và sự gia tăng nhanh chóng ứng dụng tin học trong các lĩnh vực y khoa lâm sàng, hai tổ chức ACR (American College of Radiology) và NEMA (National Electrical Manufacturers Association) đã nhận ra yêu cầu cần thiết phải có một phương pháp chuẩn dùng trong truyền tải ảnh và thông tin liên quan đến ảnh đó giữa các nhà sản xuất thiết bị y khoa, mặc dù những thiết bị đó lại cho ra các định dạng ảnh khác nhau. Trong năm 1983, ACR và NEMA thành lập một ủy ban chung để phát triển phương pháp chuẩn này với mục đích:
Tăng cường khả năng giao tiếp thông tin ảnh số của thiết bị y khoa bất chấp thiết bị đó là của nhà sản xuất nào.
Giúp cho việc phát triển và mở rộng các hệ thống truyển tải và lưu trữ ảnh trở nên dễ dàng hơn, từ đó các hệ thống này sẽ là nơi giao tiếp với các hệ thống thông tin bệnh viện khác.
Cho phép tạo ra thông tin thông tin cở sở chẩn đoán, từ đó nhiều loại thiết bị chẩn bệnh sẽ sử dụng và tra cứu thông tin này.
ACR-NEMA công bố "ACR-NEMA Standards Publication" phiên bản 1.0 vào năm 1985. Và năm 1988, ủy ban này công bố tiếp "ACR-NEMA Standards Publication" phiên bản 2.0. Tài liệu "ACR-NEMA Standards Publication" đặc tả giao tiếp phần cứng, số lượng tối thiểu các lệnh phần mềm và các định dạng dữ liệu.
Chuẩn DICOM (Digital Imaging and Communications in Medicine) đưa ra nhiều cải tiến qua trọng so với 2 phiên bản của chuẩn ACR-NEMA trước:
Chuẩn DICOM này áp dụng được trong môi trường mạng vì chúng dùng giao thức mạng chuẩn là TCP/IP. Chuẩn ACR-NEMA chỉ có thể áp dụng cho mạng point-to-point.
Chuẩn DICOM áp dụng cho môi trường lưu trữ off-line, DICOM dùng các thiết bị lưu trữ chuẩn như CD-R, MOD và filesystem luận lý như ISO 9660 và FAT16 . Chuẩn ACR-NEMA không đặc tả định dạng file, thiết bị lưu trữ vật lý hay filesystem luận lý.
Chuẩn DICOM đặc tả các thiết bị y khoa cần tuân theo chuẩn DICOM sẽ phải đáp ứng lệnh và dữ liệu như thế nào. Chuẩn ACR-NEMA bị giới hạn về truyền tải dữ liệu, DICOM dùng khái niệm Service Classes để mô tả ngữ nghĩa lệnh và dữ liệu đi kèm.
DICOM có kèm đặc tả về yêu cầu, quy tắc cho các nhà sản xuất thiết bị y khoa sản xuất sản phẩm tuân theo chuẩn DICOM. Chuẩn ACR-NEMA đặc tả rất ít về điều này.
Hướng phát triển hiện thời: chuẩn DICOM luôn phát triển và do Procedures of the DICOM Standards Committee quản lý. Đề nghị nâng cấp trong tương lại của các thành viên trong ủy ban DICOM dựa trên thông tin từ các những người đã dùng qua chuẩn DICOM. Các ý kiến được xem xét để đưa vào phiên bản tiếp theo của DICOM và các thay đổi của DICOM phải đảm bảo tương thích tốt với phiên bản trước.
Chuẩn DICOM
Đặc tả DICOM áp dụng cho:
Định dạng file ảnh dùng trong trong y khoa.
Giao thức truyền thông dữ liệu DICOM.
File DICOM
File DICOM là file lưu trữ theo định dạng DICOM. File này lưu trữ những thông tin sau
Thông tin bệnh nhân.
Thông tin về lần khám của ảnh.
Thông tin lượt viếng thăm.
Thông tin về thiết bị y khoa đã sinh ra ảnh.
Ảnh của bệnh nhân.
DICOM hỗ trợ các định dạng ảnh JPEG, JPEG Lossless , JPEG 2000, LZW và Run-length encoding (RLE).
Cấu trúc căn bản của file DICOM là Data Set.
Cấu tạo Data Set
Các khái niệm trong DICOM.
Khái niệm
Ý nghĩa
Data Set
Là tập hợp nhiều Data Element trong một file DICOM.
Data Element
Là một đơn vị thông tin trong DICOM file. Date Element chứa một thông tin đầy đủ. Các field trong Data Element có nhiệm vụ đặc tả đầy đủ một thông tin, đặc tả bao gồm: ý nghĩa, giá trị, chiều dài của tin và định dạng dữ liệu của tin.
Tag
Là 2 số nguyên không dấu, mỗi số 16 bit. Cặp số nguyên này xác định ý nghĩa của Data Element như tên bệnh nhân, chiều cao của ảnh, số bit màu, Một số xác định Group Number và số kia xác định Element Number.
Giá trị của Group Number và Element Number cho biết Data Element nói lên thông tin nào. Các thông tin (Data Element) cùng liên quan đến một nhóm ngữ nghĩa sẽ có chung số Group Number.
VR (Value Representation)
Đây là field tùy chọn, tùy vào giá trị của Transfer Syntax mà VR có mặt trong Data Element hay không.
Giá trị của VR cho biết kiểu dữ liệu và định dạng giá trị của Data Element.
VM (Value Multiplicity)
Cho biết số lượng Value của Value Field nếu Value Field có nhiều giá trị.
Nếu số lượng Value không xác định, VM sẽ có dạng “a-b” với a số giá trị Value nhỏ nhất và b là số Value lớn nhất có thể có của Data Element.
VD: VM = “6-10” : Value Field có ít nhất là 6 giá trị và nhiều nhất là 10 giá trị.
Data Element với Value Field có nhiều giá trị sẽ
Với chuỗi kí tự, dùng kí tự 5Ch (‘\’) làm kí tự phân cách.
Với giá trị nhị phân, không có kí tự phân cách.
Value Length
Là một số nguyên không dấu, có độ dài là 16 hay 32 bit. Giá trị của Value Length cho biết độ lớn (tính theo byte) của field Value Field (không phải là độ lớn của toàn bộ Data Element).
Giá trị của Value Length là FFFFFFFFh (32 bit) hàm ý không xác định được chiều dài (Undefined Length).
Value Field
Là nội dung thông tin (Data Element). Kiểu dữ liệu của field này do VR quy định và độ lớn (tính theo byte) nằm trong Value Length.
Transfer Syntax
Transfer Syntax là các quy ước định dạng dữ liệu. Giá trị của Transfer Syntax cho biết cách dữ liệu được định dạng và mã hóa trong DICOM đồng thời cũng cho biết VR sẽ có tồn tại trong Data Element hay không.
Mặc định ban đầu, Transfer Syntax của file DICOM là Explicit VR Little Endian Transfer Syntax.
Information Object Definition (IOD)
IOD đại diện cho một đối tượng chứa thông tin và đối tượng này có tồn tại trong thế giới thực. Thông tin của đối tượng IOD là thông tin của đối tượng trong thế giới thực.
Có 2 loại IOD
Composite IOD: là IOD đại diện cho những phần khác nhau của các đối tượng khác nhau trong thế giới thực.
Normalized IOD: là IOD cho duy nhất một đối tượng trong thế giới thực.
Lớp Service-Object Pair (SOP)
Lớp SOP được tạo ra khi ghép một IOD với DIMSE Service dành cho IOD đó.
Có 2 loại lớp SOP
Lớp Normalized SOP: được tạo ra khi ghép Normalized IOD với các dịch vụ DIMSE-N.
Lớp Composite SOP: được tạo ra khi ghép Composite IOD với các dịch vụ DIMSE-C.
Thứ tự của chuỗi byte: một giá trị sẽ được lưu thành một hay nhiều byte trong file. Có 2 quy ước quy định thứ tự xuất hiện của các byte của một giá trị nào đó trong file DICOM.
Little Endian
Đối với số nhị phân gồm nhiều byte thì byte có trọng số thấp nhất (Least Significant Byte) sẽ nằm trước, những byte còn lại có trọng số tăng dần nằm tiếp sau đó.
Đối với chuỗi kí tự, các kí tự sẽ nằm theo thứ tự xuất hiện trong chuỗi (từ trái sang phải).
Big Endian
Đối với số nhị phân gồm nhiều byte thì byte có trọng số lớn nhất (Most Significant Byte) sẽ nằm trước, những byte còn lại có trọng số giảm dần nằm tiếp sau đó.
Đối với chuỗi kí tự, các kí tự sẽ nằm theo thứ tự xuất hiện trong chuỗi (từ trái sang phải).
Cấu trúc file DICOM.
Cấu trúc file DICOM
Các Data Element ở đầu file cung cấp một số thông tin ban đầu quan trọng. Chúng nằm trong một Data Set tên File Meta Information. Sau Data Set File Meta Information là đến những Data Element bình thường, các Data Element này là nội dung DICOM file (gồm hình ảnh, thông tin hình ảnh, thông tin khám, thông tin bệnh nhân).
Bảng dưới đây là các Data Element nằm trong Data Set File Meta Information.
Tên Data Element
Tag
Mô tả
File Preamble
Không có
Đây là chuỗi byte đầu tiên của file, có chiều dài là 128 byte dành cho chương trình xử lý file DICOM sử dụng. Nếu không sử dụng thì 128 byte này đều có nội dung là 00h.
DICOM Prefix
Không có
4 byte là chuỗi “DICM”. Prefix này để xác định file có phải là DICOM file hay không.
File Meta Information
Group Length
(0002,0000)
Độ lớn của Data Set File Meta Information (tính theo byte). Số byte này được tính từ Data Element theo ngay sau Data Element Group Lengh này .
File Meta Information Version
(0002,0001)
Xác định phiên bản của File Meta Information.
Media Storage SOP Class UID
(0002,0002)
Chuỗi UID cho SOP Class xác định định dạng lưu trữ của file DICOM.
Media Storage SOP Instance UID
(0002,0003)
Chuỗi UID cho bản thân file DICOM.
Transfer Syntax UID
(0002,0010)
Chuỗi UID cho Transfer Syntax sẽ dùng cho các Data Element nằm ở Data Set sau Data Set File Meta Information.
Implementation Class UID
(0002,0012)
Chuỗi UID của chương trình đã tạo ra file DICOM này.
Implementation Version Name
(0002,0013)
Phiên bản của chương trình tạo file DICOM có UID như trên.
Source Application Entity Title
(0002,0016)
Chuỗi tiêu đề cho Application Entity đã tạo ra file DICOM.
Private Information Creator UID
(0002,0100)
Chuỗi UID của người cung cấp thông tin riêng tư (xem bên dưới).
Private Information
(0002,0102)
Thông tin riêng tư.
Ban đầu các Data Set File Meta Information được định dạng, mã hóa theo Transfer Syntax là Explicit VR Little Endian Transfer Syntax. Các Data Element nằm trong Data Set ngay sau Data Set File Meta Information sẽ có định dạng và được mã hóa theo Transfer Syntax quy định bởi UID của Transfer Syntax trong File Meta Information.
Với các Transfer Syntax quy ước không cần VR trong Data Element, cần tra cứu trong Data Dictionary để biết VR mặc định của từng Data Element.
Giao thức DICOM
Tổng quan về giao thức
Các ứng dụng DICOM (xem, xử lý và quản lý ảnh DICOM) giao tiếp thông tin với nhau qua các dịch vụ DICOM và sử dụng giao thức DICOM để truyền tải thông tin. Giao thức DICOM dựa trên TCP/IP để truyền tải dữ liệu.
Kiến trúc của giao thức DICOM.
Kiến trúc của giao thức DICOM
Cả 2 dịch vụ Association và DIMSE (tầng DICOM Application Message Exchange) truyền tải dữ liệu đều thông qua dịch vụ Upper Layer. Dịch vụ Upper Layer sẽ đưa thông tin từ trên ứng dụng truyền qua mạng theo giao thức TCP/IP và ngược lại.
Có 2 dịch vụ DICOM
Dịch vụ Association
Dịch vụ DIMSE (DICOM Message Service Element).
DICOM Message
Thông tin truyền tải qua mạng DICOM là DICOM Message. Hình dưới là cấu trúc tổng quát của DICOM Message.
Cấu trúc DICOM Message
DICOM Message do Command Set và Data Set hợp thành. Command Set dùng để chỉ định lệnh, thao tác sẽ làm trên hay làm cùng với Data Set.
Các Command Element trong Command Set nằm theo thứ tự tăng dần của Tag trong Command Element. Thứ tự của byte trong Command Set là Little Endian. Những Command Element nào cần có trong Command Set sẽ do giao thức DIMSE quy định.
Các field trong Command Element.
Tên field
Mô tả
Tag
Một cặp số nguyên không dấu, mỗi số 16 bit để xác định Group Number và Element Number.
Value Length
Là số nguyên không dấu 32 bit cho biết chiều dài (tính theo byte) của Value Field. Giá trị chỉ áp dụng cho Value Field, không bao gồm chiều dài của Tag và Value Length.
Value Field
Value Field chứa giá trị của Command Element. Kiểu dữ liệu của Value Field cho VR quy định. Dùng Command Dictionary để biết mỗi Tag trong Command Element sẽ dùng VR nào.
Nếu Value Field có nhiều giá trị, dùng Command Dictionary để xem VM cho Tag.
Dịch vụ DICOM
Mô hình dịch vụ DICOM.
Mô hình dịch vụ DICOM
Các ứng dụng DICOM giao tiếp và hoạt động trong môi trường mạng đều thông qua các dịch vụ DICOM. Mỗi dịch vụ DICOM phục vụ cho một công việc cụ thể.
Khi ứng dụng DICOM trao đổi dữ liệu qua mạng thì cần sử dụng dịch vụ tương ứng, chương trình cung cấp một dịch vụ DICOM cụ thể gọi là Service Provider. Ứng dụng DICOM trao đổi dữ liệu với Service Provider để lấy thông tin hay yêu cầu thực hiện một công việc cụ thể. Service Provider có thể tự thực hiện yêu cầu từ ứng dụng DICOM hay gửi yêu cầu cho một Service Provider khác, lúc đấy Service Provider gửi yêu cầu đóng vai trò là một ứng dụng DICOM bình thường.
Chuẩn DICOM đặc tả giao tiếp mạng thông qua 2 lớp dịch vụ.
Dịch vụ DIMSE và Association: ứng dụng DICOM trao đổi dữ liệu trực tiếp với lớp này.
Dịch vụ Upper Layer.
Dịch vụ Association
Trước khi dùng dịch vụ DIMSE để truyền tải dữ liệu, ứng dụng DICOM cần được cung cấp thông tin ban đầu như Transfer Syntax dùng trong lúc truyền, tên ứng dụng DICOM sẽ giao tiếp, Những thông tin này được cung cấp qua dịch vụ Association. Dịch vụ này sẽ cung cấp các thông tin cần thiết trước khi truyền dữ liệu Một Association giữa ứng dụng DICOM sẽ giúp 2 bên biết các thông tin ban đầu trước khi truyền dữ liệu. Khi truyền dữ liệu đi, cả bên truyền và bên nhận đều cung cấp Application Association Information trong request primitive và response primitive.
Dịch vụ Association đi cùng với dịch vụ DIMSE là dịch vụ ở mức tổng quát so với các dịch vụ Association do Upper Layer cung cấp. Tại mức này dịch vụ Association sử dụng dịch vụ A-ASSOCIATE của Upper Layer.
Dịch vụ Association sẽ tạo một association cho 2 ứng dụng DICOM để bắt đầu sử dụng các dịch vụ DIMSE.
Các thông tin dịch vụ Association cần phải có
Application context.
Các yêu cầu về presentation và session.
Thông tin về ứng dụng DICOM sử dụng dịch vụ.
Application Association Information.
Dịch vụ DIMSE
Dịch vụ DIMSE hỗ trợ 2 loại dịch vụ.
Dịch vụ loại Notification: cho phép ứng dụng DICOM thông báo cho ứng dụng khác biết về một sự kiện hay sự thay đổi trạng thái.
Dịch vụ loại Operation: cho phép ứng dụng DICOM yêu cầu ứng dụng DICOM khác thực hiện một công việc trên đối tượng SOP mà ứng dụng này đang quản lý.
Dịch vụ DIMSE được chia làm 2 nhóm.
Dịch vụ DIMSE-N: dịch vụ này chỉ thao tác trên đối tượng Normalized SOP.
Dịch vụ DIMSE-C: dịch vụ này chỉ thao tác trên đối tượng Composite SOP.
Các dịch vụ DIMSE.
Dịch vụ
Nhóm
Loại dịch vụ
C-STORE
DIMSE-C
Operation
C-GET
DIMSE-C
Operation
C-MOVE
DIMSE-C
Operation
C-FIND
DIMSE-C
Operation
C-ECHO
DIMSE-C
Operation
N-EVENT-REPORT
DIMSE-N
Notification
N-GET
DIMSE-N
Operation
N-SET
DIMSE-N
Operation
N-ACTION
DIMSE-N
Operation
N-CREATE
DIMSE-N
Operation
N-DELETE
DIMSE-N
Operation
Công việc của các loại dịch vụ
Tên
Công việc
C-STORE
Ứng dụng DICOM gọi dịch vụ này để yêu cầu lưu trữ đối tượng Composite SOP.
C-GET
Ứng dụng DICOM gọi dịch vụ này khi muốn đưa một hay nhiều đối tượng Composite SOP và nhận kết quả thực hiện.
C-MOVE
Ứng dụng DICOM gọi dịch vụ này để di chuyển một hay nhiều đối tượng Composite SOP đến ứng dụng khác.
C-FIND
Ứng dụng DICOM gọi dịch vụ này để lấy về danh sách các Attribute của SOP (hiện có trên Service Provider hay nơi khác mà Service Provider quản lý) có giá trị phù hợp với yêu cầu của ứng dụng.
C-ECHO
Ứng dụng DICOM gọi dịch vụ này khi cần xác thực liên lạc với ứng dụng DICOM khác.
N-EVENT-REPORT
Ứng dụng DICOM dùng dịch vụ này để ghi nhận sự kiện về đối tượng SOP. Dịch vụ này là dịch vụ cần xác nhận và phải có response trả về.
N-GET
Dịch vụ cho phép ứng dụng DICOM yêu cầu lấy về thông tin từ một ứng dụng DICOM khác.
N-SET
Ứng dụng DICOM dùng dịch vụ này để yêu cầu chỉnh sửa thông tin hiện có trên ứng dụng khác.
N-ACTION
Dịch vụ này cho ứng dụng DICOM yêu cầu ứng dụng DICOM khác thực hiện thao tác nào đó.
N-CREATE
Dịch vụ này cho ứng dụng DICOM tạo một đối tượng SOP trên ứng dụng khác.
N-DELETE
Dịch vụ này cho ứng dụng DICOM xóa một đối tượng SOP trên ứng dụng khác.
Từng loại dịch vụ DIMSE có tham số truyền và thủ tục hoạt động khác nhau. Các tham số và thông tin khác đều truyền theo cấu trúc DICOM Message.
Giao thức DICOM Upper Layer với TCP/IP
Các dịch vụ Upper Layer được sử dụng bởi 2 dịch vụ ở mức trên là Association và DIMSE. Upper Layer chịu trách nhiệm đưa thông tin từ những dịch vụ trên thành các chuỗi byte để truyền qua mạng và nhận chuỗi byte từ mạng, sau đó đóng gói thành thông tin truyền cho dịch vụ trên.
Các dịch vụ Upper Layer cung cấp
A-ASSOCIATE
Thiết lập một association giữa hai ứng dụng DICOM thông qua các message A-ASSOCIATE request, A-ASSOCIATE indication, A-ASSOCIATE response và A-ASSOCIATE confirmation.
Hình minh họa thiết lập association giữa 2 ứng dụng DICOM
A-RELEASE
Khi một trong 2 bên muốn hủy association thì sẽ dùng dịch vụ này để hủy bỏ association giữa hai ứng dụng DICOM thông qua các message A-RELEASE request, A-RELEASE indication, A-RELEASE response và A-RELEASE confirmation.
Cả hai ứng dụng DICOM đều chấp nhận hủy bỏ association để giải phóng tài nguyên.
Hình minh họa hủy bỏ association giữa 2 ứng dụng DICOM
A-ABORT
Ứng dụng DICOM cần ngắt đột ngột association với phía bên kia. Dịch vụ này không cần phải xác nhận lại kết quả thực hiện.
Tuy nhiên, yêu cầu indication từ ứng dụng DICOM không đảm bảo là sẽ đến với ứng dụng kia. Trong những trường hợp như vậy, cả hai ứng dụng đều biết rằng association đã bị ngắt. Việc ngắt được thực hiện thông qua các message A-ABORT request và A-ABORT indication.
Hình minh họa ngắt đột ngột association giữa 2 ứng dụng DICOM
A-P-ABORT
Service Provider phát tín hiệu ngắt association ngay mà không đơi một trong hai ứng dụng DICOM yêu cầu ngắt. Lý do của việc ngắt là do có các dịch vụ khác gặp trực trặc ở lớp Presentation hay lớp trên.
Việc ngắt đột ngột sẽ gây mất thông tin đang truyền.
Hình minh họa ngắt association với yêu cầu ngắt từ Service Provicer
P-DATA
Ứng dụng DICOM dùng dịch vụ này để trao đổi thông tin với nhau (truyền tải DICOM Message). Một association cho phép truyền và nhận P-DATA request primitive, P-DATA indication primitive đồng thời.
Dịch vụ DIMSE được sử dụng trong dịch vụ này.
Hình minh họa truyền tải dữ liệu dựa trên association đã thiết lập giữa 2 ứng dụng
Các dịch vụ Upper Layer dùng giao thức TCP và truyển / nhận dữ liệu tại port 104 (là port chuẩn cho giao thức DICOM).
Định dạng của một đơn vị thông tin giao tiếp giữa 2 peer trong giao thức Upper Layer là PDU (Protocol Data Unit). PDU được tạo từ các field có kích thước cố định và các field tùy chọn, những field tùy chọn sẽ chứa một hay nhiều item hay sub-item .
Có 7 loại PDU trong giao thức DICOM Upper Layer
A-ASSOCIATE-RQ PDU.
A-ASSOCIATE-AC PDU.
A-ASSOCIATE-RJ PDU.
P-DATA-TF PDU.
A-RELEASE-RQ PDU.
A-RELEASE-RP PDU.
A-ABORT PDU.
Chỉ có header của PDU là có thứ tự byte Big Endian còn định dạng fragment của PDV (Presentation Data Values) message trong P-DATA-TF PDU là tuân theo giá trị của Transfer Syntax.
Định dạng của PDU có đặc tả như sau
Kiểu của PDU do một hay nhiều byte chỉ định với byte đầu tiên có số thứ tự thấp nhất.
Mỗi byte trong PDU có 8 bit đánh số từ 0-7 với bit 0 là bit có trọng số thấp.
Những byte liên tục dùng biểu diễn số nhị phân, byte có số thứ tự thấp thì có trọng số lớn.
Byte có số thứ tự thấp nhất sẽ được truyền đầu tiên trong luồng truyền dữ liệu.
Sau đây là cấu trúc của các PDU, độ lớn mỗi field tính theo byte, các ô màu sậm là dùng để dự trữ.
PDU A-ASSOCIATE-RQ và PDU A-ASSOCIATE-AC
PDU A-ASSOCIATE-RQ và PDU A-ASSOCIATE-AC
Variable Field (1) gồm các Item con sau
Application Context Item: chỉ một item.
Presentation Context Item: một hay nhiều item.
User Info Item: chỉ một item.
Application Context Item
Presentation Context Item
User Info Item
Variable Field (2) gồm các Item con sau
Abstract Syntax Item: chỉ một item trên mỗi RQ, không có item này trong AC.
Transfer Syntax Item: một hay nhiều item trong RQ, chỉ một item trong AC.
Abstract Syntax Item
Transfer Syntax Item
Variable Field (3) gồm các Item con sau
Maximum Length Item.
Maximum Length Item
PDU A-ASSOCIATE-RJ PDU, PDU A-RELEASE-RQ, PDU A-RELEASE-RP PDU và PDU A-ABORT
PDU A-ASSOCIATE-RJ PDU, PDU A-RELEASE-RQ
PDU A-RELEASE-RP PDU và PDU A-ABORT
(*): tùy thuộc vào PDU cụ thể mà field này sẽ dùng hay để dự trữ
P-DATA-TF PDU
P-DATA-TF PDU
Variable Field (4) là các DICOM Message.
Presentation Data Value item
PACS
Giới thiệu chung
Hệ thống PACS lưu trữ hình ảnh và dữ liệu thu thập được và tương tác với hệ thống con trong cùng mạng. PACS có thể chỉ đơn giản là một máy lấy ảnh với cơ sở dữ liệu nhỏ hay hệ thống quản trị ảnh trong y khoa phức tạp để từ đó các máy trạm lấy ảnh về và xử lí. Hiện nay , hầu hết hệ thống PACS phát triển theo hệ thống kiến trúc mở theo đó là việc truyền thông hình ảnh, định dạng ảnh và quản lí ảnh theo chuẩn DICOM.
Người sử dụng dùng các máy trạm để hiển thị hình ảnh như là một giao tiếp chính cho việc truy cập hình ảnh trên hệ thống PACS. Từ các máy trạm hiển thị hình ảnh đó, người sử dụng có thể chẩn đoán, xem xét, phân tích. Các chuyên gia về ngành X-Quang sử dụng các máy trạm chuẩn đoán như là một công cụ chính. Máy trạm chuẩn đoán có phần cứng mạnh trong việc xử lí như cần phải có màn hình với độ phân giải cao, máy tính mạnh với bộ nhớ lớn và tốc độ CPU nhanh... các phần mềm được thiết kế cho việc quản lí nhiều các máy máy lấy ảnh (như máy chụp x-quang, chụp cắt lớp ...), trao giao tiếp hình ảnh giữa chúnh với nhau (thường là sử dung dịch vụ DICOM), xem xét ảnh, hiển thị ảnh động, xử lí ảnh và quản lí luồng công việc của bệnh nhân và những thông tin có liên quan.
Trong PACS điều trị bệnh, ảnh được thu thập từ các máy lấy ảnh dùng trong y khoa (modality) rồi gửi tới máy chủ PACS thông qua DICOM gateway sau đó được đưa tới máy trạm chẩn đoán với dịch vụ truyền thông DICOM.
Mô hình PACS
Phân bổ và hiển thị ảnh
Có 2 cách để đưa hình ảnh của máy chủ PACS tới máy trạm chẩn đoán:
Phương thức Store-Forward (dịch vụ truyền thông DICOM Storage): đầu tiên ảnh được đưa đến và lưu trữ ở máy chủ PACS, tiếp đến là chuyển tới máy trạm hiển thị với một lộ trình định sẵn.
Phương thức Query/Retrieval (dịch vụ DICOM Query/Retrieval): các chuyên gia về ngành X-quang lấy thông tin lịch làm việc từ RIS (Radiology Information System) hoặc PACS sau đó truy vấn và tìm kiếm ảnh từ máy chủ PACS hoặc cơ sở dữ liệu ảnh để hiển thị trên máy trạm của họ.
Cách phân bố ảnh theo phương thức Store-Forward được sử dụng thường hơn phương thức Query/Retrieval trong lĩnh vực ngành X-quang về bộ phận sinh học. Trong chuyên môn về bộ phận sinh học được tổ chức theo từng nhóm dựa theo bộ phận sinh học như: ngực , thần kinh hoặc thuộc khoa nhi Với phương thức Query/Retrieval thì thích hợp nhất cho các chuyên gia X-quang trong khâu giao tiếp với máy lấy ảnh (Modalities). Các máy ảnh được chia theo nhóm dựa trên chức năng của máy như : CT , MR hoặc X-ray. Trong từng lĩnh vực chuyên môn mà các máy lấy ảnh sẽ sinh ra những hình ảnh tương tự nhau tại cùng một điểm đều này sẽ gây khó khăn cho máy chủ PACS trong việc phân phối tất cả ảnh của cùng một bệnh nhân cho bác sĩ chẩn đoán. Trong trường hợp này rất thích hợp cho phương thức Query/Retrieval.
Chức năng chính của máy trạm chẩn đoán là hiển thị ảnh và thao tác trên ảnh kết hợp với việc quản lí ảnh và chức năng xử lí ảnh. Trong môi trường Windows, người sử dụng thao tác ảnh bằng các thiết bị nhập như : chuột và bàn phím. Các thao tác đó được chuyển thành các chuỗi sự kiện. Tiến trình hiển thị ảnh có thể được điều khiển bởi một chuỗi sự kiện như hình.
Tiến trình hiển thị ảnh
Kĩ thuật Web
Sự phát triển của Internet mở ra một viễn cảnh mới trong vấn đề truyền thông dữ liệu trên toàn thế giới. Sự phát triển nhanh chóng của Web làm mở rộng thêm việc truyền thông trao đổi một lượng lớn người sử dụng. Việc phát triển nhanh chóng của WWW là cung cấp một giao tiếp chuẩn cho việc xem và liên kết đến các tài liệu số như hình ảnh, văn bản, âm thanh và ảnh động.
Các máy trạm chuẩn đoán, máy trạm ứng dụng y khoa, hoặc máy trạm xem ảnh ở xa thì việc truyền tải hình ảnh với kích thước tối ưu là thực sự cần thiết. Hệ thống ảnh y khoa dựa trên môi trường web là giải pháp hiệu quả nhất cho mục đích này bằng cách sử dụng giao thức HTTP.
Kiến trúc hệ thống quản lý ảnh y khoa trong môi trường PACS
Kiến trúc PACS điển hình cho hiển thị ảnh dựa trên Web
Kĩ thuật Component:
Việc phát triển phần mềm truyền thống đòi hỏi các chương trình thực thi phải được biên dịch và phụ thuộc vào chương trình. Mỗi lần các lập trình viên muốn thay đổi cách xử lí theo logic khác hoặc thêm tính năng mới, họ phải sửa đổi và dịch lại chương trình. Nên mẩt khá nhiều thời gian, không tối ưu, không tái sử dụng lại code Để giải quyết những vấn đề đó, kĩ thuật component là hướng giải quyết trong việc phát triển phần mềm và kĩ thuật đó cũng được sử dụng rộng rãi trong lĩnh vực phần mềm, quan trọng hơn là phát triển phần mềm thương mại. Kĩ thuật component thương chỉ có hai phần : kiến trúc phần mềm component và phần mềm component.
Kiến trúc phần mềm component là một framwork tĩnh, nó cung cấp một kiểu mẫu hệ thống phầm mềm và các quy ước, chính sách, cơ chế. Những cái đó mục đích tạo nên một thể thống nhất giữa các hệ thống con và các component khác. Kiến trúc đinh nghĩa bằng cách nào những phần quan hệ với nhau và các ràng buộc.
Kiến trúc Component dùng hiển thị ảnh để chẩn đoán tại các workstation
Kiến trúc DP Component
Công nghệ .NET
Giới thiệu
Đầu năm 1998, sau khi hoàn tất phiên bản 4 của Internet Information Server (IIS), một đội lập trình ở Microsoft nhận thấy họ còn rất nhiều sáng kiến để kiện toàn IIS. Họ bắt đầu thiết kế một architecture mới dựa trên những ý đó và project đuợc đặt tên là Next Generation Windows Services (NGWS).
Sau khi Visual Basic 6 đuợc trình làng vào cuối năm 1998, dự án kế tiếp mang tên Visual Studio 7 đuợc sáp nhập vào NGWS. Đội ngũ COM+/MTS góp vào một môi trường thống nhất cho tất cả các ngôn ngữ lập trình trong Visual Studio, họ có ý định cho ngay cả các ngôn ngữ lập trình của công ty khác dùng.
Công tác này được giữ bí mật mãi đến hội nghị Professional Developers' Conference ở Orlando vào tháng 7/2000. Đến tháng 11/2000 thì Microsoft cho phát hành Beta 1 của .NET gồm ba CD. Tính đến lúc ấy thì Microsoft đã làm việc trên dự án ấy gần ba năm rồi. Điều ấy cắt nghĩa tại sao Beta 1 version tương đối rất vững chải.
.NET mang dấu tích những sáng kiến đã được áp dụng trước đây như p-code trong UCSD Pascal cho đến Java Virtual Marchine. Có điều Microsoft góp nhặt những sáng kiến của người khác, kết hợp với những sáng kiến của chính mình để làm nên một sản phẩm ăn rơ từ trong ra ngoài. Có lẽ cuối năm 2001 hay đầu năm 2002 Microsoft mới phát hành .NET. Có người hỏi Microsoft xem .NET quan trọng như thế nào. Các lãnh đạo của Microsoft cho biết 80% từ khóa Research & Development (Nghiên cứu và Triển khai) của Microsoft trong năm 2001 được dành cho .NET, tất cả sản phẩm của Microsoft đều sẽ được dọn nhà qua .NET platform.
.NET là vũ khí chiến lược của Microsoft để trong tương lai thâu chiểm lĩnh môi trường Desktop, Distributed cho đến Internet và Mobile (Phone, Pocket PC). Visual Studio.NET cho ta một IDE (Intergrated Development Environment) tuyệt diệu, đầy đủ để triển khai mọi loại dự án. Cốt lõi của .NET là .NET Framework, hỗ trợ lập trình theo hướng đối tượng (Object Oriented) cho VB.NET (Visual Basic 7) và C#. Hai ngôn ngữ lập trình này khá đơn giản (chỉ có chừng 80 reserved words), tương đương nhau về chức năng và code của hai bên có thể thừa kế lẫn nhau. .NET Framework cung cấp khoảng 5000 classes để hỗ trợ mọi nhu cầu lập trình như Streaming, Threading, Collections, Delegate và EventHandling, Interface, Remoting, Reflection, Unicode, XML, Disconnected database ADO.NET, Encryption ..v.v..
.NET Framework
.NET được phát triển từ đầu năm 1998, lúc đầu có tên là Next Generation Windows Services (NGWS). Nó được thiết kế hoàn toàn từ con số không để dùng cho Internet. Viễn tưởng của Microsoft là xây dựng một hệ thống phân tán toàn cầu, dùng XML (chứa những databases tí hon) làm chất keo để kết hợp chức năng của những computers khác nhau trong cùng một tổ chức hay trên khắp thế giới.
Những computers nầy có thể là Servers, Desktop, Notebook hay Pocket Computers, đều có thể chạy cùng một software dựa trên một platform duy nhất, độc lập với hardware và ngôn ngữ lập trình. Đó là .NET Framework. Nó sẽ trở thành một phần của MS Windows và sẽ được port qua các platform khác, có thể ngay cả Unix.
Mô hình một ứng dụng .NET
Các thành phần chính của .NET Framework
.NET application được chia ra làm hai loại: cho Internet gọi là ASP.NET, gồm có Web Forms, Web Services và cho desktop gọi là Windows Forms.
Windows Forms giống như Forms của VB6. Nó hổ trợ Unicode hoàn toàn, rất tiện cho chữ Việt và thật sự mang tính hướng đối tượng.
Web Forms có những Server Controls làm việc giống như các Controls trong Windows Forms, nhất là có thể dùng codes để xử lý Events như của Windows Forms.
Điểm khác biệt chính giữa ASP (Active Server Pages) và ASP.NET là trong ASP.NET, phần đại diện visual components và code nằm riêng nhau. Ngoài ra ASP.NET hoàn toàn có tính hướng đối tượng.
Chương III
Hệ thống PACS, DICOM và khám bệnh ngoại trú
Các yêu cầu đặt ra cho PACS
Đăng nhập với quyền admin.
Nhận thông tin ảnh chẩn đoán từ các client
Gửi thông tin ảnh chẩn đoán đến các client khi có yêu cầu.
Lưu trữ hình ảnh.
Các yêu cầu đặt ra cho phầm mềm DICOM
Đăng nhập với quyền bác sĩ chẩn đoán cận lâm sàng.
Nhận hình ảnh chẩn đoán từ các modilaty.
Giao tiếp với PACS để gửi và nhận hình ảnh chẩn đoán.
Giao tiếp với các hệ thống hàng đợi để tiếp nhận bệnh khám.
Tìm kiếm bệnh nhân để xem lại các hình ảnh đã được chẩn đoán.
Các công cụ phục vụ cho việc chẩn đoán như :
Các công cụ cơ bản xử lí ảnh (sáng – tối, xoay trái – phải ).
Thêm chú thích trực tiếp trên ảnh.
In ảnh chẩn đoán cho bệnh nhân.
Các khâu khám bệnh ngoại trú
Nhận bệnh
Đăng nhập với quyền là nhân viên nhận bệnh.
Thêm bệnh nhân mới và nhập thông tin bệnh nhân.
Nhận bệnh nhân cũ đã có ID Bệnh nhân.
Giao tiếp với hệ thống thông qua hàng đợi.
Hàng đợi
Đăng nhập với quyền admin.
Nhận thông tin từ :
Khâu nhận bệnh và chuyển tới thu phí.
Khâu thu phí và chuyển tới phòng khám lâm sàng (nếu chưa khám lâm sàng).
Phòng khám lâm sàng và chuyển tới thu phí.
Khâu thu phí và chuyển tới cận lâm sàng (nếu đã khám lâm sàng).
Khâu khám cận lâm sàng đến khám lâm sàng (nếu đã khám xong hết tất cả cận lâm sàng).
Thu phí
Đăng nhập với quyền thu ngân.
Thu phí dịch vụ lâm sàng và cận lâm sàng.
Tính chi phí dịch vụ cho bệnh nhân.
Giao tiếp với hệ thống thông qua hàng đợi.
Chẩn đoán lâm sàng
Đăng nhập với quyền bác sĩ khám lâm sàng.
Giao tiếp với hệ thống thông qua hàng đợi.
Giao tiếp với PACS để nhận và gửi các thông tin hình ảnh chẩn đoán cận lâm sàng.
Bác sĩ có thể chỉ định các chẩn đoán cận lâm sàng.
Bác sĩ xem các kết quả khám cận lâm sàng.
Bác sĩ ra kết quả khám cuối cùng.
Chương IV
Thiết kế và hiện thực dự án
Thiểt kế hệ thống
Đặc tả hệ thống – workflow
Quy trình khám bệnh ngoại trú
Nhận bệnh: thu thập thông tin bệnh nhân và triệu chứng bệnh của bệnh nhân. Cấp số phiếu khám cho người bệnh, sau đó bệnh nhân sang quầy thu phí ngồi chờ đến lượt đóng phí khám
Thu phí khám bệnh: Nhân viên thu phí thực hiện thủ tục thu tiền và cập nhật trên máy tính. Sau đó, ID của bệnh nhân sẽ tự động nạp vào hàng đợi, bệnh nhân đến phòng khám chờ đến lượt vào phòng. Bác sĩ trong phòng sẽ gọi bệnh nhân vào dựa trên danh sách bệnh nhân chờ liệt kê trên máy
Bác sĩ khám cho bệnh nhân, nếu bệnh không nặng thì sẽ ra toa thuốc (nếu cần) và hướng dẫn cách chữa trị và bệnh nhân ra về.
Nếu bác sĩ cần thêm xét nghiệm hay kết quả khám cận lâm sàng để giúp đưa ra kết luận bệnh thì sẽ chỉ định các chẩn đoán cận lâm sàng trên máy để bệnh nhân thực hiện. Các chỉ định được cập nhật lên cơ sở dữ liệu và hàng đợi ngay sau đó. Lúc này bệnh nhân trở lại phòng thu phí để nộp phí chẩn đoán cận lâm sàng
Thu phí cận lâm sàng: Nhân viên thực hiện thu phí chẩn đoán cận lâm sàng và cập nhật trên máy tính. Sau đó ID bệnh nhân sẽ được hàng đợi điều khiển để đưa đến phòng khám cận lâm sàng đầu tiên.
Chuẩn đoán cận lâm sàng: Bác sĩ tại phòng khám sẽ gọi bệnh nhân vào từ danh sách hàng đợi liệt kê trong máy. Sau khi khám xong, ID bệnh nhân được hàng đợi tự động đưa đến phòng cận lâm sàng tiếp theo. Với các chuẩn đoán cận lâm sàng có hỗ trợ DICOM, kết quả sẽ được cập nhật vào hồ sơ bệnh nhân trên hệ thống cơ sở dữ liệu và máy chủ PACS.
Khi bệnh nhân khám xong tất cả chẩn đoán chỉ việc quay trở lại phòng khám lâm sàng cũ. ID họ sẽ được hàng đợi tự động đưa đến phòng khám này
Quầy dược: Sau khi bệnh nhân khám xong có thể đến quầy dược mua thuốc và ra về
Mô hình UML
Use case Diagram
Chương trình Cận lâm sàng
Dịch vụ Hàng đợi và PACS
Chương trình khám bệnh ngoại trú
Chương trình nhận bệnh
Chương trình thu phí
Class Diagram
Công cụ dùng chung
Thực thể dùng trong Hàng đợi
Bộ đếm
Dịch vụ Hàng đợi
Dịch vụ PACS
Chương trình Thu phí
Chương trình Nhận bệnh
Chương trình Khám bệnh ngoại trú
Máy chủ Hàng đợi và PACS
Các lớp cho Chương trình Cận lâm sàng
Sequence Diagram
Thu phí
Khám lâm sàng lần 1 (trước khi chẩn đoán CLS)
Khám lâm sàng lần 2 (sau khi chẩn đoán CLS)
Activity Diagram
Khám bệnh ngoại trú
Khám cận lâm sàng
Chương trình Nhận bệnh
Chương trình Thu phí
Máy chủ Hàng đợi
Máy chủ PACS
Component Diagram
Các component của ứng dụng
Component con củaDPLib
Thiết kế cơ sở dữ liệu
Mô hình ERD
Mô hình thực thể kết hợp
Bảng cơ sở dữ liệu
Đặc tả thực thể
DP_BenhNhan
Tên thuộc tính
Kiểu dữ liệu
Allow Nulls
Diễn giải
ID_BenhNhan
varchar(30)
No
ID để phân biệt giữa các bệnh nhân
TenBenhNhan
nvarchar(50)
Tên bệnh nhân
NgaySinh
datetime
Ngày sinh của bệnh nhân
DiaChi
nvarchar(50)
Địa chỉ của bệnh nhân
GioiTinh
tinyint
Giới tính của bênh nhân
DP_BenhAn
Tên thuộc tính
Kiểu dữ liệu
Allow Nulls
Diễn giải
ID_BenhAn
varchar(30)
No
ID bệnh án của bệnh nhân
ID_BenhNhan
varchar(30)
No
Khóa ngoại của table DP_BenhNhan
NgayTao
datetime
Ngày tạo bệnh án
DP_LanKham
Tên thuộc tính
Kiểu dữ liệu
Allow Nulls
Diễn giải
ID_LanKham
varchar(30)
No
ID lần khám
ID_BenhAn
varchar(30)
Khóa ngoại table DP_BenhAn
ID_BenhNhan
varchar(30)
Khóa ngoại table DP_BenhNhan
NgayKham
datetime
Ngày khám
DP_HoaDonKham
Tên thuộc tính
Kiểu dữ liệu
Allow Nulls
Diễn giải
ID_HoaDon
varchar(30)
No
ID hóa đơn
ID_LanKham
varchar(30)
Khóa ngoại table DP_LanKham
NgayLap
datetime
Ngày lập hóa đơn
LoaiKham
tinyint
Hình thức khám.
Có 2 hình thức khám là khám lâm sàng và khám cận lâm sàng
DP_ThietBiChanDoan
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_ThietBi
numeric
No
ID thiết bị dùng để phân biệt các thiết bị cận lâm sàng
TenThietBi
nvarchar(50)
Tên thiết bị
HangSanXuat
nvarchar(100)
Hãng sản xuất thiết bị
ChucNang
nvarchar(100)
Mô tả sơ lược chức năng của thiết bị
DP_FileDICOM
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_File
varchar(30)
No
ID file DICOM
ID_CanLamSang
varchar(30)
Khóa ngoại table DP_CanLamSang
TenFile
varchar(50)
Tên file
DP_CanLamSang
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_CanLamSang
varchar(30)
No
ID cận lâm sàng
ID_ThietBi
numeric
Khóa ngoại table DP_ThietBi
ID_KhuVuc
numeric
Khóa ngoại table DP_KhuVuc
ID_NguoiDung
numeric
Khóa ngoại table DP_NguoiDung
ID_LanKham
varchar(30)
Khóa ngoại DP_LanKham
KetQuaKham
ntext
Kết quả sau khi khám
KetLuanKham
ntext
Kết luận bệnh dựa trên kết quả khám
MoTa
ntext
Mô tả lần khám cận lâm sàng
DP_LamSang
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_LamSang
varchar(30)
No
ID lâm sàng
ID_LanKham
varchar(30)
No
Khóa ngoại table DP_LanKham
ID_NguoiDung
numeric
Khóa ngoại table DP_NguoiDung
MoTa
ntext
Mô tả lần khám lâm sàng
KetQuaKham
ntext
Kết quả khám lâm sàng
DP_ChiTietHoaDonKham
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_HoaDon
numeric
No
Khóa ngoại table DP_HoaDon
ID_DichVuKham
varchar(30)
No
Khóa ngoại table DP_DichVuKham
DP_KhuVucChanDoan
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_KhuVuc
numeric
No
ID khu vực
TenKhuVuc
nvarchar(50)
Mô tả khu vực chẩn đoán cận lâm sàng
DP_NguoiDung
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_NguoiDung
numeric
No
ID người dùng
TenNguoiDung
varchar(30)
Tên người dùng
MatMa
varchar(30)
Mật mã
MaQuyen
int
Mã quyền (một tài khoản chỉ có thể sử dụng một chương trình)
DP_SoThuTuKhamCLS
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
SoPhieu
Int
Số phiếu
ID_LanKham
varchar(30)
No
Khóa ngoại table DP_LanKham
SoThuTuKham
Int
No
Số thứ tự khám
ID_PhongBan
numeric
Khóa ngoại table DP_PhongBan
ID_DichVuKham
numeric
Khóa ngoại table DP_DichVuKham
DP_PhongBan
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_PhongBan
numeric
No
ID phòng ban
ID_KhoaDieuTri
nvarchar(50)
Khóa ngoại table DP_KhoaDieuTri
TenPhong
numeric
Tên phòng
DP_KhoaDieuTri
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_KhoaDieuTri
numeric
No
ID khoa điều trị
TenKhoa
nvarchar(50)
Tên khoa điều trị
DP_DichVuKham
Tên thuộc tính
Kiểu dữ liệu
Not Null
Diễn giải
ID_DichVuKham
numeric
No
ID dịch vụ khám
ID_KhoaDieuTri
numeric
Khóa ngoại talbe DP_KhoaDieuTri
TenDichVu
nvarchar(50)
Dịch vụ khám
GiaTien
int
Giá dịch vụ
DichVuLS
tinyint
Cho biết dịch vụ khám là lâm sàng hay cận lâm sàng
DEMO hệ thống
Hàng đợi và PACS Server
Đăng nhập để khởi động Hàng đợi và PACS Server
Cấu hình cho Hàng đợi
Cấu hình cho PACS Server
Cấu hình lưu dữ liệu
Chương trình Nhận bệnh
Giao diện đăng nhập của chương trình nhận bệnh
Nhận bệnh với mã bệnh nhân
Nhập thông tin bệnh nhân mới
Chương trình Thu phí
Giao diện đăng nhập cho chương trình thu phí
Thu phí bệnh nhân khám
Chương trình Khám bệnh lâm sàng
Giao diện đăng nhập chương trình lâm sàng
Nhận bệnh nhân khám lâm sàng chỉ định khám cận lâm sàng (nếu có)
Chỉ định chẩn đoán cận lâm sàng
Bác sĩ lâm sàng xem các kết quả chẩn đoán cận lâm sàng
Một trong những công cụ hỗ trợ bác sĩ khám(chỉnh sáng tối ảnh)
Chương trình Chẩn đoán cận lâm sàng
Giao diện đăng nhập chương trình cận lâm sàng
Giao diện hàng đợi nhận bệnh khám cận lâm sàng
Thông tin bệnh nhân và các ảnh đã chụp trước đó (nếu có)
Bắt hình chẩn đoán
Công cụ phục vụ cho bác sĩ chú thích trực tiếp trên ảnh
Một trong những công cụ hỗ trợ bác sĩ khám (đảo sắc)
In ảnh thông tin chẩn đoán cận lâm sàng
Kết quả thực nghiệm (Phần mềm và phần cứng)
Ứng dụng được xây dựng dựa trên thực trạng khảo sát tình hình hoạt động khám chữa bệnh ngoại trú tại bệnh viện Hồng Đức.
Mục tiêu của chương trình là xây dựng quy trình khám bệnh ngoại trú khép kín thuận tiện cho bệnh nhân đến khám và tăng hiệu suất hoạt động khám ngoại trú hiện tại ở bệnh viện.
Các chương trình đều được phân tích trên yêu cầu thực tế của bệnh viện Hồng Đức hiện nay.
Chương V
Kết luận và định hướng phát triển
Kết luận
Lợi ích
Do có khảo sát thực tế tại bệnh viện Hồng Đức nên chương trình có thể đáp ứng được nhu cầu thực tiễn hiện tại.
Ứng dụng hỗ trợ tốt hoạt động khám chữa bệnh ngoại trú cho bệnh viện đặc biệt khám cận lâm sàng. Giúp cho bệnh nhân đến khám cảm thấy thuận tiện, thoải mái và tiết kiệm nhiều thời gian khám.
Thông tin khám chữa bệnh có thể được truy xuất tiện lợi, nhanh chóng trên mạng nội bộ trong bệnh viện.
Hình ảnh thông tin chẩn đoán được luân chuyển tốt trong nội bộ, chủ yếu mọi hoạt động dựa trên máy tính là chính. Dữ liệu chẩn đoán cận lâm sàng được lưu trữ tập trung trên máy chủ nên tránh tối đa nguy cơ mất mát dữ liệu
Thiếu sót của chương trình
Mới chỉ xây dựng một khâu hoạt động của toàn bộ hệ thống bệnh viện là khâu khám bệnh ngoại trú
Do không có thiết bị chẩn đoán cận lâm sàng (máy điện tim, siêu âm,..) nên quá trình lấy phim từ thiết bị không thực tế, chỉ có thể lấy ảnh từ một tập tin film đã được chỉ định trước.
Hệ thống chưa được triển khai hoạt động thực tế tại bệnh viện
Do chưa được triển khai và sử dụng nên có thể chương trình còn có những thiếu sót (sẽ bổ sung cập nhật sau khi đã tiếp nhận các ý kiến).
Hướng phát triển
Xây dựng toàn bộ hệ thống cho một bệnh viện (cụ thể là Hồng Đức). Gắn các hệ thống lại với nhau thành một hệ thống lớn.
Cải tiến chức năng khám lâm sàng và hoàn chỉnh hơn chương trình cận lâm sàng.
Xây dựng thêm các chương trình hỗ trợ quan trọng khác: quản lí dược, quản lý tài chính, quản lý hồ sơ bệnh án và quản lý bệnh nhân nội trú.
Chuyển chương trình cận lâm sàng sang môi trường Web cho phép các y bác sĩ và bệnh viện khác truy xuất được ảnh cận lâm sàng lưu trữ tại bệnh viện
PHỤ LỤC
Các thuật ngữ dùng trong tài liệu
Ảnh số: ảnh kỹ thuật số, là ảnh được lưu trong máy vi tính dạng nhị phân.
Khám lâm sàng: bác sĩ sẽ nhìn thể hiển bên ngoài bằng kinh nghiệm để phán đoán bệnh cho bệnh nhân.
Khám cận lâm sàng : có sự hỗ trợ của các modality trong việc chẩn đoán giúp đưa ra kết luận chính xác hơn
UID (Uniquely Identifie): chuỗi dùng để xác định duy nhất một thực thể
Modality: thiết bị y khoa dùng trong chẩn đoán cận lâm sàng, kết quả thường là hình ảnh hay phim.
Các tài nguyên sử dụng
Tài liệu tham khảo
DICOM trên Wikipedia tại
Tài liệu về chuẩn DICOM (phiên bản 3.0) tại
Thư viện hỗ trợ
Tên thư viện
Mô tả
DCMTK Toolkit
Dùng trong xử lý file DICOM
Data Access Application Block in Enterprise Library
Dùng truy xuất hệ quản trị cơ sở dữ liệu Microsoft SQL Server
Configuration Application Block in Enterprise Library
Dùng đọc và ghi thông tin cấu hình cho ứng dụng
Sử dụng mã cho một số chức năng
DShowNET - dùng để play phim minh họa cho việc chụp hình từ thiết bị chẩn đoán cận lâm sàng
FrameGrabber - captutre khung hình (frame) từ phim đang được play
Image - xử lý ảnh hỗ trợ cho khám cận lâm sàng