Đồ án Xây dựng media server ứng dụng trong hội chẩn từ xa

y tính cho phép truy cập trên thế giới thông qua Internet. Hai ngôn ngữ dành cho ứng dụng Web phổ biến nhất mà cho phép hiển thị những văn bản đa phương tiện và đã được định dạng là HTML và ngôn ngữ Java.Gần đây, XML cũng được mở rộng sử dụng. Hiện tại, các trình duyệt như IE hay Netcape Navigator thường hỗ trợ dạng ảnh JPEG và GIF. Trong thuật ngữ web, ta thường hay nói đến máy chủ web hay máy khách web. Website có thể truy cập thông tin trên máy chủ web thông qua giao thức HTTP. Trong suốt nhiều năm qua, những ứng dụng của kỹ thuật web đã mở rộng cho ứng dụng trong lĩnh vực chăm sóc sức khỏe. Một số website bây giờ đã hỗ trợ truy cập những thông tin dạng văn bản từ hệ thống ePR (một hệ thống ghi nhận bệnh nhân). Những hệ thống ePR dựa vào web có thể phân loại theo nhiều yếu tố của chúng như mức độ hoàn thiện và chi tiết của thông tin, chất lượng của dữ liệu và từ góc độ của khách hàng. Việc sử dụng máy chủ web như một phương tiện để truy cập đến ảnh và thông tin ở trong PACS đã được thực thi bởi cả những trung tâm hàn lâm và các nhà sản xuất. Mô tả máy chủ web trongmôi trường PACS: cần xem xét đến một máy chủ chứa ảnh dựa vào web thì nó cần phải có những thành phần như sau: Hình 2. 65: Máy chủ chứa ảnh dựa vào web Hình trên là kiến trúc cơ bản của máy chủ web mà cho phép trình duyệt web truy vấn và lấy ảnh và dữ liệu ở trong PACS thông qua máy chủ dựa vào web. Trình biên dịch DICOM/HTTP là thành phần chính trong kiến trúc. Nhiệm vụ của nó là : Hỗ trợ trình duyệt web kết nối Internet Giải thích những truy vấn từ trình duyệt được viết bằng HTML hoặc Java và chuyển đổi những truy vấn sang chuẩn HL7 và DICOM Hỗ trợ truy cập đến DICOM SOP để truy vấn và lấy ảnh hoặc dữ liệu từ điều khiển PACS. Cung cấp trình biên dịch để chuyển đổi ảnh DICOM và HL7 thành HTTP. Máy chủ web là một khái niệm tốt mà nó tận dụng tốt những kỹ thuật Internet có sẵn trong bất cứ máy để bàn nào để truy cập ảnh và dữ liệu của PACS. Nó làm việc rất tốt trong môi trường Intranet bởi vì Intranet thường được thiết kế với tốc độ cao. Tuy nhiên,có nhiều trở ngại khi sử dụng Internet hiện hành cho những ứng dụng WAN vì 2 nguyên nhân. Đầu tiên, đáp ứng thời gian cho việc truyền ảnh từ Internet thì quá chậm. Vì lý do này mà nó chỉ hữu dụng khi ta cần truy xuất ảnh với số lượng và kính thước nhỏ. Thêm một vấn đề khác là, kỹ thuật web thì không được thiết kế dành cho việc hiển thị ảnh xám với độ phân giải cao. Trong trường hợp này, thời gian chờ cho việc hiển thị và thao tác ảnh sẽ trở nên quá lâu. Các yêu cầu trong việc thiết kế hệ thống PACS Khi thiết kế mạng PACS chúng ta phải xem xét bốn yêu cầu sau. Tiêu chuẩn hoá hệ thống. Kiến trúc mở của hệ thống. Độ tin cậy của hệ thống. Tính bảo mật của hệ thống. Tiêu chuẩn hoá hệ thống Nguyên tắc đầu tiên trong việc thiết kế kiến trúc cho hệ thống PACS đó là viêc sử dụng tối đa các chuẩn công nghiệp hiện tại để phù hợp với toàn bộ sơ đồ thiết kế của PACS, cũng có nghĩa là đối thiểu hoá việc thiết kế phần mềm cho người sử dụng. Hơn nữa, việc sử dụng cả tiêu chuẩn phần cứng cũng như tiêu chuẩn phần mềm sẽ làm tăng khả năng nâng cấp thay đổi cho hệ thống. Sử dụng tối đa các chuẩn công nghiệp đã có như là hệ điều hành Unix, Window, giao thức truyền thông TCP/IP, hệ quản trị cơ sở dữ liệu SQL, Orangcle, định dạng dữ liệu hình ảnh DICOM, địng dạng dữ liệu chữ viết HL7, ngôn ngữ lập trình Visual Basic.NET, C#.Net, C++.Net, java.Net… Việc sử dụng các chuẩn để thực thi cho PACS sẽ đem lại nhiều thuận lợi như là việc thi hành các thành phần và các mônđun của PACS sẽ đơn giản hơn. Việc vận hành bảo dưỡng, tìm hiểu hệ thống cũng dễ dàng hơn. Hơn nữa, việc xác định hoạt động của PACS sẽ làm giảm thiểu sự mã hoá máy tính dư thừa, do đó dễ dàng hơn cho việc Debug và tìm kiếm thông tin. Trong các chuẩn công nghiệp nêu trên thì chuẩn DICOM và HL7 là quan trọng nhất vì chúng cung cấp truyền thông giữa PACS và HIS/RIS, giữa các thiết bị của những nhà sản xuất khác nhau. Kiến trúc mở của hệ thống Nếu hai module của hệ thống PACS trong cùng một bệnh viện không thể thông tin được với nhau thì chúng trở thành hệ thống cách ly, từng module có thông tin của bệnh nhân là riêng biệt. Khi đó không thể xây dựng được hệ thống PACS mở và hệ thống bị giới hạn. Do đó, kiến trúc mở là cần thiết đề cung cấp mộ phương pháp tiêu chuẩn cho việc trao đổi thông tin giữa các hệ thống khác nhau. Do công nghệ máy tính và truyền thông phát triển rất nhanh nên kiến trúc đóng sẽ là hạn chế việc nâng cấng cho hệ thống. Vì vậy, khi phát triển một hệ thống PACS dù là cỡ lớn hay cỡ nhỏ thì cũng luôn luôn đảm bảo đó là hệ thống mở. Để một hệ thống PACS là hệ thống mở thì nó phải đảm bảo các yêu cầu sau: Có thể truyền dữ liệu từ module của PACS này đến module của PACS khác. Dạng dữ liệu và hình ảnh phải sử dụng đúng chuẩn. Giao thức máy tính cũng phải là giao thức chuẩn. Độ tin cậy Độ tin cậy là một đặc điểm cần được chú ý vì hệ thống PACS có rất nhiều thiết bị nên xác suất lỗi của hệ thống là rất cao. Hơn nữa do thông tin bệnh viện là thông tin cần tức thời và chính xác nên thời gian chết của hệ thống chỉ có thể nằm trong khoảng cho phép Các biện pháp tăng độ tin cậy của hệ thống : Có chương trình phần mềm kiểm tra sữa lỗi phục hồi, sao lưu dữ liệu . Xây dựng hệ thống phần cứng dự phòng Tính bảo mật Đây là một nhân tố quan trọng của hệ thống, nó đảm bảo tính riêng tư về thông tin của bệnh nhân. Hệ thống cơ sở dữ liệu phải hạn chế mức truy cập cho từng đối tượng cụ thể. Phần lớn các hệ thống quản trị cơ sỡ dữ liệu phức tạp đều có cơ chế bảo mật bằng account và password. Người thiết kế hệ thống phài đảm bảo cho người quản trị mạng có thể gắn các quyền truy nhập vào cơ sở dữ liệu PACS cho từng đối tượng người sử dụng. Các vi phạm về về bảo mật dữ liệu chủ yếu tập trung ở các loại sau: Việc xâm phạm về vật lý liên quan đến sự bảo mật của phương tiện quản lý thiết bị Các vi phạm về thái độ và sự lạm dụng có thể được giảm thiểu bằng điều khiển và account. Hệ thống MyFreePACS Giới thiệu MyFreePACS được phát triển bời Pacssoft ( và ứng dụng tại bệnh viện nhi Seattle. MyFreePACS là một hệ thống lưu trữ và truyền thông ảnh vói mục đích là cung cấp phương thức xem ảnh chuẩn DICOM một cách dễ dàng nhất từ mọi nơi trong bệnh viện, hoặc từ xa thông qua mạng. Các tính năng chính Các tính năng chính của MyFreePACS gồm có: Thu nhận ảnh từ các thiết bị như máy X-Quang, máy siêu âm, máy chụp cộng hưởng từ,… Các thành phần quản trị hệ thống MyFreePACS và DICOM Server thông qua giao diện Web. Có thể tìm kiếm ảnh theo tên bệnh nhân, mã số (ID) bệnh nhân hay thời gian. Cung cấp một số công cụ xử lý ảnh: Chỉnh độ sáng Di chuyển Phóng to/thu nhỏ Đo khoảng cách Lật ảnh Xoay ảnh Lấy âm bản. Yêu cầu hệ thống Yêu cầu tối thiểu của hệ thống Hệ điều hành: Windows 2000, XP, 2003 Server, Linux Cơ sở dữ liệu: SQL Server 2000, SQL Server 2005 Express Edition, SQL Server 2005 hay MySQL PHP 4 trở lên Web Server: IIS (Internet Information Server) hay Apache Server Lợi ích của hệ thống Lợi ích sau cài đặt hệ thống Cài đặt đơn giản, dể dàng Hệ thống hoàn toàn miễn phí, chi phí để cài đặt cũng không quá cao. Vì ngoại trừ phải cài đặt hệ điều hành Windows, các thành phần khác như PHP, hay cơ sở dữ liệu đều có thể sử dụng miễn phí (SQL Server 2005 Express Edition, MySQL) Hệ thống dựa trên nền web nên có thể truy cập dễ dàng từ bất kì nơi nào chỉ cần có kết nối internet, rất thuận tiện cho việc chẩn bệnh từ xa. Chuẩn hình ảnh DICOM dùng trong y tế Tổng quan về DICOM DICOM (The Digital Image and Communication in Medicine) là chuẩn định nghĩa ra các qui tắc định dạng và trao đổi hình ảnh y tế cũng như thông tin liên quan. Hình ảnh y tế được nhận từ các thiết bị thu nhận hình ảnh số khác nhau như máy CT (compited Tomography), MR (Magnetic Resonance), US (UltraSound), NM (Nuclear Medicine). Nó tạo ra một ngôn ngữ chung cho phép giao tiếp hình ảnh và các thông tin y tế liên quan giữa các thiết bị và hệ thống trong mạng thông tin y tế. Với sự ra đời của máy tạo ảnh chẩn đoán vào những năm 1970, cũng như việc sử dụng ngày càng nhiều hệ thống máy tính và ảnh số trong y tế với các định dạng khác nhau thì nhu cầu cần phải có một chuẩn chung cho quá trình truyền ảnh số và các thông tin liên quan ngày càng lớn. Trước nhu cầu đó, American College of Radiology (ACR) và The National Electrical Manufacturers Association (NEMA) đã thiết lập thành một ủy ban chung vào năm 1983 để phát triển một chuẩn gọi là chuẩn ACR-NEMA. Chuẩn ACR-NEMA (American College of Radiology và The National Electrical Manufacturers Association) ra đời nhằm mục đích để cho các thiết bị tạo ảnh của các nhà sản xuất khác nhau có thể trao đổi và chia sẻ thông tin trong môi trường thông tin ảnh y tế, đặc biệt là trong môi trường PACS. Chuẩn này trung vào trao đổi,kết nối và truyền thông giữa các hệ thống y tế. Phiên bản 1 của ACRNEMA ra đời năm 1985 xác định việc truyền bản tin điểm tới điểm,khuôn dạng dữ liệu và một số lệnh. Phiên bản thứ 2 ra đời năm 1988 định nghĩa phần cứng và giao thức phần mềm cũng như từ điển dữ liệu chuẩn. Nhưng vấn đề kết nối mạng chưa rõ ràng qua hai phiên bản này vì thế mà phiên bản thứ 3 ra đời và lấy tên là DICOM. Vì sự ra đời của các chuẩn là khác nhau nên với các thiết bị không tuân theo tiêu chuẩn DICOM mà thực hiện theo tiêu chuẩn CR-NEMA hoặc tiêu chuẩn riêng của nhà sản xuất cần thì thích ứng sang DICOM. Để thích ứng với chuẩn ACR – NEMA thì cần một chuyển đổi từ ACR-NEMA sang DICOM, còn để thích ứng với các chuẩn riêng của nhà sản xuất thì cần phải chuyển đổi các đặc tính của nhà sản xuất sang ACR-NEMA hoặc DICOM. Để giải quyết các yêu cầu này cần tập hợp các mođun phần mềm tạo nên thư viện mã hóa. Thư viện mã hóa ưu việt cần có các đặc tính sau: Sử dụng chung cho các thiết bị tạo ảnh của các nhà sản xuất khác nhau. Thích ứng với các nền phần cứng khác nhau. Kiến trúc phần mềm dựa theo hướng tiếp cận top – down. Ngôn ngữ lập trình chuẩn. Hình 2. 66: Các thiết bị tạo,lưu trữ và truyền ảnh DICOM DICOM hỗ trợ nhiều loại ảnh nén khác nhau để tối ưu cho việc lưu trữ và việc thuyền thônh ảnh DICOM trên mạng. Dưới đây là một số so sánh giữa các loại ảnh mà DICOM hỗ trợ. Kiểu ảnh Kích thước (byte) 8-bit J2K Lossy Gray.dcm 24,848 8-bit JPEG Lossless Gray.dcm 106,326 8-bit Uncompressed Gray.dcm 179,640 16-bit J2K Lossy Gray.dcm 305,856 16-bit JPEG Lossless Gray.dcm 561,292 16-bit Uncompressed Gray.dcm 610,394 24-bit J2K Lossy Color.dcm 100,348 24-bit JPEG Lossless Color.dcm 6,830,920 24-bit JPEG Lossy Color.dcm 1,620,038 24-bit RunLength Color.dcm 14,040,714 24-bit Uncompressed Color.dcm 18,875,660 Bảng 2. 67: So sánh các dung lượng các ảnh của một số chuẩn DICOM hỗ trợ Phạm vi và lĩnh vực ứng dụng của DICOM Chuẩn DICOM gắn liền với thông tin y tế. Với lĩnh vực này, nó định ra sự trao đổi thông tin số giữa các thiết bị tạo ảnh và hệ thống mạng thông tin. Do các thiết bị tạo ảnh có thể hoạt động tương tác với các thiết bị y tế khác, phạm vi của chuẩn cần thiết phải chồng lên các khu vực khác trong thông tin y tế. Chuẩn tăng cường khả năng hoạt động tương tác của các thiết bị tạo ảnh y tế bằng cách định ra: Với việc truyền thông tin qua mạng, chuẩn đưa ra một bộ giao thức được tuân theo bởi các thiết bị thích nghi chuẩn. Cú pháp và ngữ nghĩa của lệnh và các thông tin liên quan được trao đổi sử dụng các giao thức này. Với việc truyền tin bằng phương tiện trung gian, chuẩn đưa ra một bộ các dịch vụ lưu trữ trung gian, cũng như khuôn dạng file và cấu trú thư mục y tế, tạo điều kiện cho việc truy nhập thông tin lưu trữ trên phương tiện trung gian. Thông tin được sử dụng trong ứng dụng tuân theo chuẩn. Thích nghi DICOM Một thành phần quan trọng của bất cú một chuẩn nào là phải định nghĩa tính thích nghi với nó, hay nói cách khác là tính tuân thủ những điều mà chuẩn đề ra. Trong nhiều trường hợp khác như chuẩn DICOM chẳng hạn, sự thích nghi là hoàn toàn tự nguyện. Ủy ban của chuẩn DICOM không tạo ra bất cú sự áp đặt nào. Mặc dầu vậy, DICOM vẫn có một phần dành riêng để quy định sự thích nghi. Mọi nhà sản xuất muốn chứng minh thiết bị hay phần mềm của họ thích nghi với chuẩn đều phải đưa ra một báo cáo thích nghi miêu tả một cách cụ thể sản phẩm của họ thích nghi với chuẩn như thế nào. Một báo cáo thích nghi được tham khảo với một khuôn dạng do DICOM đề ra, do vậy mà việc đối chiếu các trình bày về thích nghi trở nên đơn giản và khoa học. Người sử dụng và nhà sản xuất có thể xác định xem tài liệu hai thiết bị tuân theo DICOM có thể giao tiếp ăn khớp với nhau hay không bằng cách đối chiếu bản báo cáo thích nghi của hai thiết bị với nhau. Những người làm DICOM có thể xác định được chính xác khả năng đồng loạt hoạt động của hai ứng dụng. Các nội dung cơ bản trong báo cáo thích nghi DICOM gồm: Mô hình thực thi ứng dụng: Mô hình thực thi (Implementation Model) của ứng dụng là một lược đồ đơn giản thể hiện cách mà một ứng dụng liên kết với phạm vi cục bộ trong một thiết bị được đưa ra và từ xa thông qua giao diện DICOM. Ví dụ, hoạt đông cục bộ có thể tao ra một đối tượng thông tin ảnh DICOM, còn hoạt động từ xa là hiển thị đối tượng đó. Ngữ cảnh thể hiện được sử dụng: Bao gồm cú pháp trừu tượng và cú pháp chuyển đổi tương ứng. Thuật ngữ cú pháp trừu tượng được sử dụng trong phần này vì nó được định nghĩa trong một chuẩn quốc tế khác mà DICOM tham chiếu đến. Một bản báo cáo thích nghi. DICOM sẽ liệt kê cả ngữ cảnh cả ngữ cảnh thể hiện mà ứng dụng đưa ra trong thỏa thuận cũng như khi đã được chấp thuận. Cách liên kết thực hiện: Bản báo cáo thích nghi phải miêu tả sử thực hiện liên kết ( ví dụ như là khi nào tạo các liên kết và chấp nhận nhiều liên kết) cho từng hoạt động trong mô hình. Một số thiết bị như thiết bị lưu trữ trong hệ thống PACS phải được hổ trợ nhiều liên kết nếu chúng được chấp nhận. Mục tiêu của ảnh DICOM Định ra ngữ nghĩa của lệnh và các dữ liệu liên quan, đưa ra các chuẩn cho các thiết bị tương tác lệnh và dữ liệu với nhau. Định ra ngữ nghĩa của dịch vụ file, khuôn dạng file và các thư mục thông tin cần thiết cho truyền tin ngoại tuyến. Định rõ các yêu cầu thích nghi của ứng dụng thực hiện chuẩn, cụ thể một bản báo cáo thích nghi phải định ra đầy đủ thông tin để xác định các chức năng có thể đáp ứng. Tạo thuận lợi cho hoạt động trong môi trường mạng thông tin. Có cấu trúc thuận lợi cho phép đáp ứng với các dịch vụ mới, vì thế có thể hỗ trợ các ứng dụng hình ảnh y tế trong tương lai. Cấu trúc của chuẩn DICOM Các thành phần của định dạng ảnh DICOM: Thích nghi: Định nghĩa các nguyên tắc thực thi chuẩn gồm các yêu cầu thích nghi và báo cáo thích nghi CS (Conformance Statement) Định nghĩa đối tượng thông tin IOD (Information Object Definition) Định nghĩa lớp dịch vụ SC (Service Classes) Ngữ nghĩa và cấu trúc dữ liệu Từ điển dữ liệu Trao đổi bản tin Hỗ trợ truyền thông mạng cho việc trao đổi bản tin Khuôn dạng file và lưu trữ trung gian Sơ lược ứng dụng lưu trữ trung gian Chức năng lưu trữ và khuôn dạng trung gian cho trao đổi dữ liệu Chức năng hiển thị chuẩn mức xám Sơ lược an toàn Nguồn ánh xạ nội dung. Hình 2. 68: DICOM và mô hình tham chiếu OSI Định dạng file DICOM: bồm 2 phần là header, dữ liệu ảnh. Header: Tên và ID của bệnh nhân. Loại ảnh y khoa ( CT,MR,Audio Recording,..) Kích thước ảnh… Ví dụ : Hình 2. 69: Ví dụ về ảnh MRI Hình trên chỉ ra rằng: 794 bytes đầu dùng để định dạng Header DICOM, mô tả kích thước ảnh và các thông tin ảnh. Kích thước của ảnh trên : 109x91x2 =19838 bytes. Hình 2. 70: Ví dụ về một số trường của ảnh DICOM Dữ liệu ảnh: Ảnh nén (bitmap) hoặc ảnh chưa nén từ (jpeg, gif...) Định nghĩa đối tượng thông tin IOD (Information Object Definition) Định nghĩa lớp dịch vụ SC (Service Classes) Ngữ nghĩa và cấu trúc dữ liệu Từ điển dữ liệu Trao đổi bản tin Hỗ trợ truyền thông mạng cho việc trao đổi bản tin Khuôn dạng file và lưu trữ trung gian Sơ lược ứng dụng lưu trữ trung gian Chức năng lưu trữ và khuôn dạng trung gian cho trao đổi dữ liệu Chức năng hiển thị chuẩn mức xám Sơ lược an toàn Nguồn ánh xạ nội dung Các lớp đối tượng và dịch vụ trong DICOM DICOM có hai lớp thông tin là lớp đối tượng và lớp dịch vụ SOP (Service Object Pair). Hình 2. 71: Lớp dịch vụ và lớp đối tượng Lớp đối tượng của DICOM định ra hai lớp nhỏ là lớp tiêu chuẩn và lớp tổ hợp. Mỗi lớp tiêu chuẩn bao gồm các đặc tính vốn có của thực thể hiện diện trong thế giới thực. Lớp tổ hợp là do ACR-NEMA định nghĩa từ các thông tin tổ hợp của các thiết bị ảnh tạo khác nhau. Lớp đối tượng tiêu chuẩn Bệnh nhân Xét nghiệm Nguồn lưu trữ Chú giải ảnh Lớp đối tượng tổ hợp Ảnh CR (Computed Radiography) Ảnh CT (Computed Tomography) Ảnh số hóa film DF (Digital Fluorography) Ảnh MR (Magnetic Resonance) Ảnh y học hat nhân NM (Nuclear Medicine) Ảnh siêu âm US (Ultrasound) Đồ hoạ Đồ hình Hình 2. 72: Minh họa đối tượng ảnh Lớp dịch vụ của DICOM định nghĩa các dịch vụ như lưu trữ, in chất vấn và truy vấn… Mỗi lớp đều có một từ điển định nghĩa các thuộc tính để mã hoá dữ liệu một cách chính xác. Hình 2. 73: Các dịch vụ của DICOM Các dịch vụ DICOM được sử dụng để truyền đối tượng bên trong thiết bị và cho thiết bị thực hiện một dịch vụ cho đối tượng ví dụ như dịch vụ lưu trữ, dịch vụ hiển thị… Một lớp dịch vụ được xây dựng trên một tập các dịch vụ truyền thông DICOM được gọi là DIMSE (DICOM Message Sevice Elements). Các DIMSEs là các chương trình phần mềm thực hiện chức năng xác định. Có hai loại DIMSEs là một cho đối tượng tổ hợp và một cho đối tượng tiêu chuẩn. Một DIMSE tổ hợp được một cặp thiết bị gồm một thiết bị gồm thiết bị đưa ra yêu cầu và thiết bị nhận yêu cầu. Vì trong môi trường hướng đối tượng nên dịch vụ của DICOM được coi là một lớp dịch vụ. Nếu một thiết bị cung cấp dịch vụ thì được gọi là SCU (Service Class User). Chẳng hạn như đĩa từ là SCP để cho PACS controller lưu trữ dữ liệu còn CT scanner là SCU để cho đĩa từ trong PACS controller lưu ảnh. Tuy nhiên, có thể 1 thiết bị vừ là SCP, vừa là SCU như PACS controller, nó gửi ảnh tới trạm hiển thị bằng các đưa ra các yêu cầu dịch vụ thì nó là SCU. Nếu nó nhận ảnh từ các thiết bị tạo ảnh bằng cách cung cấp dịch vụ lưu trữ thì nó lại là SCP. Hình 2. 74: Các dịch vụ DIMSEs tiêu chuẩn Hình 2. 75: Ví dụ các lớp đối tượng và lớp dịch vụ được truyền giữa SCU và SCP Khuôn dạng file DICOM Thông tin đầu file: bao gồm các định danh bộ dữ liệu được đưa vào file. Nó bắt đầu bởi 128 byte file Preamble (tất cả được đưa về 00H). Sau đó 4 byte kí tự “DICM”. Tiếp theo là các thành phần dữ liệu đầu file. Các thành phần dữ liệu đầu file này là bắt buộc đối với mọi file DICOM. Các thành phần dữ liệu đầu file này là bắt buộc đối với mọi file DICOM. Các thành phần dữ liệu này có nhãn dạng (0002, xxxx), được mã hóa theo cú pháp chuyển đổi VR ẩn và Little Endian. Bộ dữ liệu: Mỗi file chỉ chứa một bộ dữ liệu thể hiện một SOP cụ thể và duy nhất liên quan đến một lớp SOP đơn và IOD tương ứng. Một file có thể chứa nhiều hình ảnh khi các IOD được xác định mang nhiều khung. Cú pháp chuyển đổi được sử dụng để mã hóa bộ dữ liệu được xác định duy nhất thông qua UID cú pháp chuyển đổi trong thông tin đầu file DICOM. Thông tin quản lý file: Khuôn dạng file DICOM không bao gồm thông tin quản lí file để tránh sự trùng lặp với chức năng liên quan ở lớp khuôn dạng trung gian. Nếu cần thiết với một sơ lược ứng dụn DICOM cho trước, các thông tin sau sẽ được đưa ra bởi một lớp khuôn dạng trung gian: Định danh sở hữu nội dung file Thông tin truy cập (ngày giờ tạo) Điều khiển truy cập file ứng dụng Điều khiển truy cập phương tiện trung gian vật lý (bảo vệ ghi…) Khuôn dạng file DICOM an toàn: Một file DICOM an toàn là một file DICOM được mã hóa với một cú pháp bản tin mật mã được định nghĩa trong RFC2630. Phụ thuộc vào thuật toán mật mã sử dụng, một file DICOM an toàn có thể có các thuộc tính an toàn sau: Bảo mật dữ liệu Xác nhận nguồn gốc dữ liệu Tính toàn vẹn dữ liệu Hình 2. 76: Khuôn dạng file DICOM DICOM Toolkit DCMTK DCMTK – phiên bản mới nhất là DCMTK 3.5.4 – là một tập hợp các thư viện và các ứng dụng hỗ trợ cho chuẩn DICOM. Bộ toolkit này bao gồm các module kiểm tra, xây dựng và chuyển đổi ảnh DICOM, xử lý dữ liệu offline, truyền và nhận ảnh trên mạng (có thể đáp ứng khả năng bảo mật cao thông qua kết nối SSL), DCMTK được viết bằng ngôn ngữ ANSI C, và C++. DCMTK có thể hỗ trợ cho nhiều loại hệ điều hành như Windows, Linux, Solaris, QNX, IRIX, Free/Net/OpenBSD, và MacOS. Tất cả các thông tin cấu hình đều cho từng loại hệ điều hành đều được cung cấp đầy đủ. Về tính năng bảo mật, DCMTK hỗ trợ nhiều tính năng bảo mật cho DICOM dưa trên toolkit OpenSSL về việc sử dụng các hàm mật mã và giao thức truyền tải dữ liệu bảo mật TLS được tin tưởng sử dụng ở các hệ thống lớn. Một số gói cơ bản của DCMTK Config – chứa các tiện ích cấu hình cho DCMTK dcmdata – chứa các thư viện mã hoá/giải mã cho DCMTK dcmimage – cung cấp thêm các hỗ trợ ảnh màu dcmimgle – các thư viện và ứng dụng dùng cho việc xử lý ảnh. Dcmjpeg - các thư viện nén và giải nén ảnh jpeg. Dcmnet – các thư viện hỗ trợ cho việc truyền tải trên mạng Dcmqrdb – Server quản lý ảnh Dcmsign – các thư viện dùng cho chữ kí số dcmtls – các thư viện mở rộng dành cho bảo mật dữ liệu khi truyền trên mạng. DCM4CHE DCM4CHE là một bô công cụ mã nguồn mở để phục vụ cho việc xử lý ảnh DICOM mở giống như DCMTK nhưng được viết bằng ngôn ngữ Java. Hiện tại dcm4che đang được phát triển tới phiên bản 2 với những cải tiến về hiện năng cũng như sử dụng bộ nhớ, và khả năng xử lý ảnh DICOM mạnh mẽ. Bộ công cụ dcm4che thiết kế để xử lý ảnh DICOM theo chuẩn DICOM 2006. Môt số gói chính của DCM4CHE org.dcm4che2.audit.message: cung cấp các lớp cho việc tạo các thông điệp xác thực theo định dạng XML tuân theo các đặc tả trong DICOM Supplement 95 org.dcm4che2.data: gói này chứa các lớp cho phép thao tác đọc ghi trên tập tin DICOM org.dcm4che2.io: chứa các lớp đảm nhận vai trò nhập xuất tập tin theo chuẩn DICOM. Ngoài ra còn có: org.dcm4che2.media, org.dcm4che2.net, org.dcm4che2.image, org.dcm4che2.util Thao tác với ảnh DICOM với DCM4CHE Đọc ảnh DICOM: tập tin DICOM có thể được đọc thông qua đối tượng của Java như java.io.InputStream và java.io.File. Tuy nhiên dcm4che đã thiết kế sẵn lớp chuyên dùng để đọc tập tin DICOM org.dcm4che2.io.DicomInputStream kế thừa lớp java.io.FilterInputStream. Tập tin DICOM sẽ được đọc ra thành các đối tượng org.dcm4che.data.DicomObject. Ví du: DicomObject dcmObj; DicomInputStream din = null; try { din = new DicomInputStream(new File("image.dcm")); dcmObj = din.readDicomObject(); } catch (IOException e) { e.printStackTrace(); return; } finally { try { din.close(); } catch (IOException ignore) { } } Khi đọc tập tin DICOM thì đối tượng DicomInputStream sẽ tự động nhận ra cú pháp của tập tin DICOM tương ứng tuy nhiên cũng có thể chỉ rõ ra cú pháp này qua câu lệnh như sau: din = new DicomInputStream(new BufferedInputStream(new FileInputStream("image.dcm")), TransferSyntax.ImplicitVRLittleEndian); Ghi tập tin DICOM: việc ghi thành tập tin theo chuẩn DICOM cũng được dễ dàng thực hiện thông qua lớp org.dcm4che2.io.DicomOutputStream File f = new File("newFile.dcm"); FileOutputStream fos; try { fos = new FileOutputStream(f); } catch (FileNotFoundException e) { e.printStackTrace(); return; } BufferedOutputStream bos = new BufferedOutputStream(fos); DicomOutputStream dos = new DicomOutputStream(bos); try { dos.writeDicomFile(obj); } catch (IOException e) { e.printStackTrace(); return; } finally { try { dos.close(); } catch (IOException ignore) { } } Các tiện ích khác: dcm4che còn chứa một số các tiện ích có thể sử dụng theo nhiều mục đích khác nhau thao tác trên tập tin DICOM theo kiểu chạy thông qua dòng lệnh. dcm2txt – chuyển tập tin DICOM sang dạng text dcm2xml – chuyển tập tin DICOM sang dạng XML dcmdir – thao tác với một thư mục chứa ảnh DICOM. jpg2dcm – chuyển ảnh JPEG sang ảnh DICOM. pdf2dcm - chuyển ảnh tập tin PDF sang tập tin DICOM. rgb2ybr – chuyển dữ liệu màu trong tập tin DICOM từ hệ màu YBR sang hệ màu RGB xml2dcm – chuyển một định dạng XML thành dạng DICOM. DCM4CHEE Bên cạnh dcm4che, dcm4chee (dcm4che enterprise) là một hệ thống quản lý dữ liệu bệnh viện được mở rộng từ dcm4che. dcm4chee được dùng với nhiều chức năng khác nhau. Tuy nhiên có 2 chức năng phổ biến là: Lưu trữ và quản lý ảnh DICOM Cho phép làm việc với các chương trình xem ảnh DICOM thông dụng OsiriX, K-PACS, ClearCanvas,… Dcm4chee cũng được viết trên Java và chỉ sử dụng một ít C/C++ cho việc tối ưu việc nén ảnh. Dcm4chee sử dụng cơ sở dữ liệu để lưu thông tin đọc được trong header của tập tin DICOM, thông tin về việc lưu trữ tập tin DICOM, và dữ liệu y tế. dcm4chee hỗ trợ 6 loại cơ sở dữ liệu thông dụng hiện nay như: PostgreSQL MySQL Oracle SQL Server DB2 Firebird HSQL Hình 2. 77 Mô hình hệ thống dcm4chee Một số module của dcm4chee: Module Mô tả Giao diện Web Dcm4chee chứa một tập hợp các giao diện web dùng cho việc quản lý DICOM Interface Hoạt động như một kho lưu trữ, thông qua module này dcm4chee có thể lưu trữ, truy lục ảnh DICOM. HL7 Interface Một server tích hợp HL7 có thể hoạt động theo kiều thông điệp ADT, ORM, và ORU WADO and RID Interfaces Giao tiếp WADO và RID cho phéo truy cập vào nội dung đã được lưu trữ thông qua web Media Creation Quản lý việc xuất ra CD Bảng 2. 78: Một số tính năng của dcm4chee Hệ thống thông tin y tế và chuẩn dữ liệu văn bản HL7 Hệ thống thông tin y tế Giới thiệu Hệ thống thông tin bệnh viện HIS (Hospital Information System) được phát triển từ cuối những năm 1950 đầu 1960, ban đầu chỉ được dùng để làm công việc kế toán, lập hóa đơn, quản lí nhà kho như các phần mềm quản lí doanh nghiệp khác. Hiện nay, HIS đã được phát triển, mở rộng rất nhiều chức năng, trở thành một công cụ hữu ích cho các bệnh viện. HIS là hệ thống quản lí các loại công việc trong môi trường bệnh viện: Hỗ trợ các hoạt động chẩn đoán và chăm sóc sức khỏe bệnh nhân trong bệnh viện. Quản lí công việc kinh doanh hàng ngày của bệnh viện: tài chính, nhân sự, bảng lương, viện phí… Đánh giá hiệu quả và chi phí của bệnh viện để từ đó đề ra kế hoạch phát triển lâu dài cho bệnh viện. Hệ thống thông tin bệnh viện có thể chia thành nhiều loại: Hệ thống tập trung hay phân tán. Hệ thống hướng kinh doanh thuần túy hay là hướng đến bệnh nhân. Mục đích của bất kì một hệ thống HIS nào cũng là sử dụng hệ thống mạng các máy tính để thu thập, xử lí và khôi phục lại thông tin quản lí và chăm sóc bệnh nhân từ các khoa trong toàn bệnh viện, thỏa mãn các chức năng cần thiết của tất cả người dùng. Nó cũng là một hệ thống hỗ trợ người điều hành bệnh viện đưa ra các quyết định về việc cải thiện các chế độ chăm sóc sức khỏe, tiết kiệm chi phí và nâng cao hiệu quả. Kiến trúc hệ thống Kiến trúc của hệ thống thông tin bệnh viện đòi hỏi phải được thiết kế đảm bảo độ mở rộng cả về phần cứng lẫn phần mềm. Khả năng nâng cấp các chức năng của hệ thống là chủ yếu tùy theo sự phát triển của công nghệ. Kiến trúc phần cứng được đề xuất gồm có một máy chủ cơ sở dữ liệu trung tâm với tính năng kĩ thuật mới nhất nhằm giảm thiểu nguy cơ thất thoát dữ liệu, kết nối với các hệ thống đầu cuối được cấu hình cần thiết để hỗ trợ các công nghệ tiên tiến. Hình 2. 79: Mô hình kiến trúc của hệ thống HIS Tùy thuộc vào chức năng, quy mô của từng bệnh viện mà ta có thể tổ chức, sắp xếp hệ thống theo nhiều dạng khác nhau: Hệ thống tập trung hoàn toàn. Hình 2. 80: Hệ thống máy chủ tập trung Hệ thống tập trung, truy xuất đến một hệ thống song song ở phòng xét nghiệm. Hình 2. 81: Hệ thống tập trung + hệ thống song song ở phòng xét nghiệm Hệ thống các chức năng ở máy trạm, cơ sở dữ liệu tập trung. Hình 2. 82: Hệ thống hướng đến máy trạm với cơ sở dữ liệu tập trung Hệ thống hoàn toàn phân tán Hình 2. 83: Chức năng và cơ sở dữ liệu của mỗi bộ phận độc lập nhau. Các nhiệm vụ của hệ thống HIS Quản lí hồ sơ bệnh nhân, bệnh án, trang thiết bị, thuốc, quản lí vật tư, tài chính, đội ngũ y bác sĩ. Cho phép trao đổi thông tin, dữ liệu thống kê hai chiều giữa các phòng ban, các khoa nhằm phục vụ cho người bệnh một cách tốt hơn. Giúp ban giám đốc của bệnh viện theo dõi kịp thời tình hình của bệnh viện về công tác chữa bệnh, quản lí bệnh nhân, bệnh án… Hỗ trợ cho công tác đào tạo cũng như nghiên cứu khoa học tại bệnh viện Có khả năng liên kết với hệ thống thông tin của các cơ sở y tế khác như các bệnh viện trong Bộ Y tế, các cơ sở y tế bên ngoài… Xây dựng các cơ sở dữ liệu về thông tin chuyên ngành y tế. Đánh giá hiệu qủa và chi phí của bệnh viện để từ đó đề ra kế hoạch phát triển lâu dài cho bệnh viện. Hệ thống FreeMED FreeMED là một hệ thống mã nguồn mở quản lý hồ sơ bệnh án điện tử có thể hoạt động như một HIS. FreeMED được phát triển dựa trên Linux, Apache, MySQL, và PHP (LAMP). Dự án FreeMED được chính thức khởi động 1999 bởi Jeffrey Buchbinder. FreeMED kế thừa từ AMOS (Automated Medical Office System), một chương trình được viết năm 1983 bằng Pascal với hệ thống quản lý cơ sở dữ liệu dBase, sau này FreeMED đã sửa lại sử dụng cơ sở dữ liệu quan hệ và lập trình hướng đối tượng. FreeMED được sử dụng tại các phòng mạch hoặc các bệnh viện. Dữ liệu bệnh nhân được bảo mật tránh các sự truy cập từ bên ngoài. Freemed đã trở thành ứng dụng tùy biến có thể mở rộng, nó thuận lợi cho việc điền mọi thông tin theo yêu cầu y khoa. Một vài đặc điểm thuận lợi của Freemed Giao diện người dùng thân thiện Hồ sơ bệnh nhân được bảo mật Quản lý được các phiên trao đổi trong hệ thống(Account Receivable) Quản lý được các yêu cầu truy cập và xem các thông tin chuyên sâu hơn Thao tác với dữ liệu của bệnh nhân dễ dàng, đồng thời có tích hợp REMITT 0.3 để hỗ trợ cho việc tính hóa đơn và báo cáo tình trạng của bệnh nhân. Kết nối với hệ thống Fax, máy in. Lập lịch cho bệnh nhân Hỗ trợ chuẩn HL7 v2.3… Chuẩn dữ liệu văn bản HL7 Thuật ngữ HL7 (Health Level Seven) được phát triển vào năm 1987, được dùng riêng cho việc trao đổi thông tin y tế, giúp cho việc truyền thông trong y tế được thuận tiện và đơn giản hơn. Chuẩn HL7 được sử dụng phổ biến trong nhiều quốc gia: Úc, Phần Lan, Đức, Hà Lan, Nhật Bản, New Zealand, Áo, Hoa Kỳ…Tháng 6/1994, HL7 được ANSI (American National Standard Institute) xem xét, chấp nhận như là một chuẩn chính thức. HL7 đã trải qua nhiều phiên bản. HL7 đưa ra phiên bản 2.2 vào tháng 12/1994, được ANSI chấp nhận vào ngày 8/2/1996, phiên bản 2.3 được đưa ra trên CD-ROM vào tháng 4/1997, được công nhận theo chuẩn của ANSI vào 13/5/1997. Chuẩn 2.3 hỗ trợ ADT (Administrator Discharge Transfer), văn bản quản trị bệnh nhân PAD (Patient Administrative Documentation), các yêu cầu, báo cáo kết quả, theo dõi y tế, quản lí báo cáo y tế MRM (Medical Record Management), sao chép, lập kế hoạch, báo cáo trắc nghiệm y tế CTR (Clinical Trials Reporting), báo cáo sự kiện có hại AER (Adverse Event Reporting), tình hình tài chính, các dịch vụ chăm sóc bệnh nhân… Năm 2001, version 3.0 chính thức được triển khai, đi vào tiếp cận hướng đối tượng cho việc trao đổi dữ liệu y tế. Phiên bản 3.0 ra đời khắc phục một số nhược điểm của các phiên bản 2.x như: tiến trình tích hợp dữ liệu phức tạp, có sự hiểu lầm các đặc tính kĩ thuật, khó khăn trong việc đánh giá tiến trình thực hiện, việc mở rộng là tùy chọn, thiếu chức năng hỗ trợ cho việc bảo mật, thiếu các chức năng hỗ trợ cho công nghệ mới như XML, Web. Hình 2. 84: Định dạng một file HL7 Giải pháp mở rộng Giải pháp 1: sử dụng Cluster Server Các Cluster Server chạy như những Server dịch vụ, và sử dụng cho việc mở rộng một ứng dụng Java có thể chạy trên nhiều máy cùng một lúc, cùng đáp ứng những yêu cầu giống nhau. Giải pháp này có nhiều lợi điểm: Tránh sự dư thừa dữ liệu, bao gồm cả RAID và quản lý nhập xuất Tránh sự dư thừa tài nguyên mạng Khắc phục sự cố Hệ thống có thể đáp ứng nhiều yêu cầu hơn và mạnh mẽ hơn. Hình 2. 85: Mô hình cơ bản Sau đây là mô hình khác cụ thể hơn dành riêng cho các ứng dụng Java Hình 2. 86: Một mô hình cụ thể cho hệ thống Java Nhược điểm của giải pháp này: Độ bảo mật không cao bởi vì mỗi máy phải mở thêm một cổng để liên lạc với các máy tính khác. Có tính chất cục bộ về mặt địa lý: các máy tính dùng làm Cluster được đặt trong mạng nội bộ. Nếu xảy ra sự cố (như mất điện chẳng hạn) thì tất cả các máy đều bị ảnh hưởng Giải pháp 2: phát triển thêm tính năng mở rộng cho Server Với đặc điểm của ứng dụng có tính tương tác, các Client cần phải được truyền dữ liệu với nhau, cho nên trong giải pháp này khi cần mở rộng một Server thì ngoài việc yêu cầu Client mới kết nối đến một Server dự phòng thì Server ban đầu sẽ đóng vai trò như là một Client của một Server dự phòng để Client ở hai Server có thể liên lạc được với nhau. Hình 2. 87: Cơ chế hoạt động của tính năng mở rộng Khi cần mở rông Server, Server A và Server B sẽ đóng vai trò là các User của nhau. Sau đó các user mới sẽ kết nối tới Server B mà vẫn tương tác được với các User trong Server A vì Server B sẽ chuyển dữ liệu tới Server A và ngược lại. Ưu điểm của giải pháp này: Các Server không cần nằm tập trung về mặt địa lý Dễ dàng bảo trì Server bị hư hỏng hay khắc phục các sự cố mất điện. Khi Server A đang thực hiện nhiệm vụ của mình, tuy nhiên nó cần được ngưng hoạt động để bảo trì. Do đó nó cần phải chuyển hết User của mình cho Server khác rồi sau đó mới dừng hoạt động được. Trong quá trình di chuyển User như vậy thì chắc chắn sẽ có những ảnh hưởng nhất định tới User đang bị di chuyển, tuy nhiên hoạt động hay tương tác giữa các User khác không bị ảnh hưởng. Hình 2. 88: Di chuyển User Nhược điểm: Cần nhiều thời gian và điều kiện để nghiên cứu, phát triển. Hoạt động của User có thể bị ảnh hưởng. Giải pháp 3: kết hợp giữa hai giải pháp 1 và 2 Giải pháp này sử dụng Cluster để mở rộng Server. Dữ liệu nào cần tính thời gian thực thì chuyền trực tiếp giữa 2 Server ứng dụng giống như giải pháp 2, còn ngược lại thì thông qua các Cluster Server để giảm áp lực lên Server ứng dụng. Ưu điểm: tận dụng ưu điểm của cả hai giải pháp trên, giảm bớt nhược điểm về độ trễ của dữ liệu so với giải pháp 1. Nhược điểm: các Server vẫn có tính cục bộ. CHƯƠNG III: THỰC HÀNH Server được viết bằng ngôn ngữ Java và được đặt tên là WebF. Trong đó Client tương thích sẽ được viết bằng ngôn ngữ Action Script vì ngôn ngữ này đã được hỗ trợ giao thức RTMP khi giao tiếp với Server. Bất kì một ứng dụng nào khi viết trên Server WebF đã được hỗ trợ sẵn tính năng chuyển phát hình ảnh, âm thanh, Shared Object. Ngoài ra ứng dụng cũng được hỗ trợ cơ chế quản lý user, quản lý room, một số sự kiện phát sinh liên quan tới user như có user mới tham gia room, user thoát khỏi room,… Tạo một ứng dụng chạy trên Server WebF Minh hoạ sau đây là tạo ra một ứng dụng chạy trên Server WebF với một hàm sayHello() trả về một chuỗi “Hello World”. Client được viết bằng ngôn ngữ Action Script gọi hàm sayHello() của ứng dụng chạy trên Server và sau đó hiện lên kết quả trả về từ Server. Bước 1: Tạo một dự án Java đặt tên là Hello, sau đó viết một lớp Application kế thừa lớp WebF.Manager.App.AppAdapter. package Hello; import WebF.Manager.App.AppAdapter; public class Application extends AppAdapter { public String sayHello() //hàm này có thể được gọi từ Client { return "Hello World"; } } Sau khi viết xong biên dịch thành tập tin Hello.jar đề sử dụng. Bước 2: Tạo một dự án Flex đặt tên là Hello, sau đó viết code như sau <![CDATA[ import mx.controls.Alert; private var nc:NetConnection; //đối tượng tạo một kết nối tới Server private function onClick():void { nc=new NetConnection(); // tạo mới đối tượng nc.objectEncoding=ObjectEncoding.AMF0; //sử dụng chuẩn AMF0 // Khai báo hàm thụ lý sự kiện nc.addEventListener(NetStatusEvent.NET_STATUS,netStatusHandler); nc.connect(uri.text); } function netStatusHandler(event:NetStatusEvent):void { switch(event.info.code) { case "NetConnection.Connect.Success": //Gọi hàm “sayHello” trên Server nc.call("sayHello",new Responder(callSuccess)); break; } } public function callSuccess(s:String):void { Alert.show(s); } ]]> Những dòng code như trên sẽ tạo ra trang Hello.html với một ô textbox chứa địa chỉ của Server cần kết nối tới và một nút bấm để thực hiện lệnh kết nối tới Server, nếu thành công thì gọi hàm sayHello() trên Server. Kết quả như sau: Hình 3. 1: Giao diên web của Client Bước 3: Cấu hình cho Server biết có một ứng dụng mới Tạo một thư mục Hello trong thư mục WebFApp (đây là thư mục chứa các ứng dụng của WebF) có sẵn. Thư mục này là thư mục gốc của ứng dụng. Sau này tất cả các dữ liệu của ứng dụng sẽ được lưu ở đây. Tạo một thư mục conf nằm trong thư mục Hello đã tạo ở trên. Tiếp theo thực hiện các công việc sau trong thư mục conf Chép tập tin Hello.jar đã biên dịch ở trên vào thư mục conf Tạo một tập tin giống với tên của ứng dụng với phần mở rộng là “.conf” tức là Hello.conf. Thêm vào tập tin một dòng chỉ lớp đã kế thừa lớp WebF.Manager.App.AppAdapter. Nội dung của tập tin Hello.conf như sau: Hello.Application Bước 4: Khởi động WebF bằng lệnh “java –jar WebF.jar”. Hình 3. 2: Khởi động Server WebF Khởi động Server thành công. Hiện tại Server có hai ứng dụng một là ứng dụng Hello, hai là ứng dụng iPath. Bước 5: chạy trang web Hello.html và thu nhận kết quả Hình 3. 3: Kết nối thành công Thông báo trên màn hình hiện ra chứng tỏ Client đã kết nối thành công với Server và ứng dụng đã chạy được. Tính năng chia sẻ và lưu trữ Video Giới thiệu Server chuyển phát âm thanh và hình ảnh được thiết kế dựa trên giao thức RTMP. Việc thiết kế dựa trên giao thức này nhận được nhiều sự thuận lợi bởi vì dữ liệu âm thanh và hình ảnh dùng trong giao thức này được tối ưu hoá bởi các giải thuật nén tiên tiến nhất hiện nay, và có thể đáp ứng được nhu cầu thực tế về truyền tải video thời gian thực. Bắt tay trên giao thức RTMP Áp dụng cách bắt tay 3-hướng của TCP Bước 1: Sau khi hai máy client và server bắt tay nhau trên IP/TCP thì client gởi gói TCP đến port 1935 (port mặc định của giao thức RTMP) Dữ liệu của gói này đầu tiên là byte 0x03 Tiếp theo là 1536 byte có giá trị ngẫu nhiên Hình 3. 4: Bắt tay RTMP giai đoạn một Bước 2: Sau khi server nhận được thông điệp yêu cầu kết nối của client, server gửi gói TCP về client yêu cầu xác nhận kết nối. Dữ liệu của gói này gồm 1+1536x2 byte bắt đầu bằng byte 0x03 Tiếp theo là 1536 byte được tạo ngẫu nhiên ở server Cuối cùng là server gửi trả lại 1536 byte mà mà client đã gửi lên cho server Hình 3. 5: Bắt tay giai đoạn 2 Bước 3: Giai đoạn cuối cùng trong quá trình bắt tay 3 hướng là client gửi gói xác nhận lại yêu cầu kết nối của mình. Dữ liệu của gói này gồm có 1+1536 byte, cũng bắt đầu bằng byte 0x03 Tiếp theo sau đó là 1536 byte của server đã gửi cho client để xác nhận chính xác là client thực sự muốn kết nối tới server Hình 3. 6: Bắt tay giai đoạn 3 Thực hiện kết nối Sau khi client và server thực hiện xong bắt tay, client gửi một thông điệp kết nối. Trong thông điệp này client yêu cầu được kết nối vào một phòng có sẵn hoặc là tạo một phòng mới. Trong thông điệp trả về của server, server sẽ trả về thông điệp kết nối thành công nếu client yêu cầu kết nối vào một phòng đã tồn tại, hoặc yêu cầu tạo một phòng mới chưa có trên server. Server sẽ gửi về thông điệp báo lỗi, nếu yêu cầu kết nối vào phòng chưa có sẵn hoặc tạo một phòng đã tồn tại trên server. Hình 3. 7: Sơ đồ gửi, trả lời thông điệp kết nối giữa client và server. Chia sẻ âm thanh, hình ảnh và lưu trữ tại Server Sau khi thực hiện xong việc kết nối, nếu client muốn yêu cầu server chuyển dữ liệu video của nó đi tới các client khác để hiện thị thì client sẽ gửi thông điệp publish kèm theo tên của dữ liệu video đó. Khi nhận được thông điệp publish, server sẽ kiểm tra xem tên gửi kèm với thông điệp publish đã được sử dụng chưa nếu chưa thì server gửi trả thông điệp thành công. Ngược lại thì server gửi trả thông điệp lỗi. Tên gửi kèm với thông điệp publish của client dùng để nhận diện các dữ liệu của từng client với nhau, tránh nhầm lẫn dữ liệu giữa các client. Khi client bắt đầu nhận được thông điệp thành công gửi trả từ server, liền ngay sau đó client sẽ gửi dữ liệu video đến cho server. Server sẽ nhận dữ liệu video này rồi làm trạm trung gian cho các client khác. Hình 3. 8: Sơ đồ gửi, trả lời thông điệp publish giữa client và server. Một client muốn nhận dữ liệu video của một client nào đó, thì client này cần gửi thông điệp play kèm theo tên của dữ liệu video muốn hiển thị. Khi nhận được thông điệp play, server sẽ kiểm tra xem tên gửi kèm với thông điệp này đã tồn tại hay chưa, nếu đã tồn tại server gửi trả thông điệp thành công rồi tiếp sau đó server sẽ chuyển dữ liệu video đã nhận được tương ứng với tên của client gửi lên về cho client hiển thị. Ngược lại thì server gửi trả thông điệp lỗi. Hình 3. 9: Sơ đồ gửi, trả lời thông điệp play giữa client và server. Như vậy, cuối cùng thì luồng dữ liệu giữa server và các client sẽ như sau Hình 3. 10: Mô hình luồng dữ liệu giữa client và server khi chuyển dữ liệu video Hình 3. 11: Kết quả thử nghiệm Trong quá trình chia sẻ âm thanh, hình ảnh giữa các Client, Server còn có thể lưu trữ những dữ liệu này lại. Do đó người dùng có thể xem dưới dạng một đoạn Video có sẵn trên Server. Và lúc này Server hoạt động như một streaming Server. Tính năng Shared Object Shared Object là một tính năng khá hay, được hỗ trợ như là phần nền của hệ thống cho nên rất mạnh và dễ dàng sử dụng. Để sử dụng Shared Object, đoạn mã bằng Action Script sau đây cần được xem qua public var so:SharedObject; so = SharedObject.getRemote(“name”, “rtmp://localhost/iPath”, true); //trong đó đối số đầu tiên là tên của đối tượng Shared Object //đối số thứ 2 là địa chỉ của ứng dụng trên Server //đối số cuối cùng chỉ ra là đối tượng Shared Object có lưu trữ trên Server hay không? so.connect(nc); //kết nối đối tượng Shared Object tới Server so.data[“thuộc tính”] = giá_trị; //thiết lập giá trị giá_trị= so.data[“thuộc tính”]; //lấy giá trị của thuộc tính. Tiếp theo sau đây là minh hoạ một chương trình có sử dụng Shared Object khi các bác sĩ đang thảo luận một hình ảnh mà một bác sĩ muốn báo cho những bác sĩ khác tập trung vào một điểm mình đang nói trên hình ảnh. Đầu tiên mở một Client lên kết nối tới Server. Hình 3. 12: Kết nối tới Server Hình 3. 13: Kết nối thành công Khi biểu tượng kết nối mở ra tức là kết nối thành công, tiếp theo một Client khác tiếp tục được mở ra. Hình 3. 14: Tính năng Shared Object Bác sĩ sẽ click vào mũi tên đỏ kéo đến chỗ khác để thông báo cho bác sĩ khác tập trung vào điểm mà mình muốn nói. Trong khi bác sĩ kéo mũi tên đỏ đi chỗ khác thì Client sẽ gửi thông báo đến sever rằng dữ liệu về toạ độ của mũi tên đã thay đổi. Hình 3. 15: Thông điệp thiết lập dữ liệu của Shared Object được gửi về Server Kết quả giữa hai Client sau khi bác sĩ kéo mũi tên đi chỗ khác. Hình 3. 16: Sử dụng tính năng Shared Object Rõ ràng với tính năng này, khả năng chia sẻ thông tin được nâng cao và cũng làm tăng hiệu quả truyên đạt thông tin giữa các ứng dụng, đồng thời cũng tạo ra cảm giác trực quan hơn giữa các người dùng đầu cuối. Tính năng lấy thông tin của bệnh nhân trong FreeMED Thông tin của bệnh nhân được lấy dễ dàng khi bác sĩ gõ tên, ID hay ngày nhập viện của bệnh nhân vào ô tìm kiếm. Hình 3. 17: Tìm kiếm thông tin bệnh nhân Trong khi bác sĩ gõ thông tin, chương trình sẽ đóng vai trò của Client sẽ tự động tìm kiếm thông tin phù hợp. Client sẽ gửi các thông điệp yêu cầu Server tìm kiếm thông tin về bệnh nhân gần đúng nhất so với những gì bác sĩ đang gõ trực tiếp vao ô tìm kiếm. Hình 3. 18: Thông điệp “searchPatient” giúp tìm kiếm bệnh nhân Sau khi bác sĩ đã gõ đầy đủ thông tin thì Client sẽ gửi thông điệp yêu cầu Server lấy thông tin của bệnh nhân trong FreeMED gửi về cho Client. Hình 3. 19: Thông điệp “getFreemedInfo” lấy thông tin của bệnh nhân trong FreeMED Kết quả như sau Hình 3. 20: thông tin bệnh nhân được hiển thị lên sau khi đã nhận kết quả từ Server Tính năng lấy ảnh trong MyFreePACS và chuyển thành ảnh JPEG Sau khi lấy thông tin bệnh nhân trong FreeMED thì dựa vào id của bệnh nhân, Client tiếp tục gửi yêu cầu Server lấy id ảnh của bệnh nhân gửi về cho Client. Sau khi nhận được id ảnh, nếu các bác sĩ nhấn nút xem ảnh thì một thông điệp yêu cầu Server lấy ảnh DICOM của bệnh nhân trong hệ thống MyFreePACS. Hình 3. 21: Thông điệp “getDicomofPatient” giúp lấy ID ảnh thông qua ID của bệnh nhân Khi Server có được ảnh DICOM, một module trên Server dùng thư viện dcm4che để tách ảnh DICOM ra thành ảnh JPEG, rồi cũng đọc thông tin của bệnh nhân chứa trong ảnh ra cùng lúc, nhằm tránh việc mở đọc ảnh DICOM nhiều lần. Trong quá trình chuyển đổi ảnh, Server cũng tạo ảnh thumbnail của các ảnh đã tạo ra để Client lấy về hiện thị lên trước. Hình 3. 22: Thông điệp lấy ảnh Thumbnail của ảnh DICOM tương ứng Hình 3. 23: Ảnh thumbnail được hiện thị sau khi lấy về từ Server Khi các bác sĩ click vào ảnh thumbnail nào thì ảnh thật tương ứng sẽ được gửi về và hiện lên Hình 3. 24: Ảnh thật tương ứng với ảnh thumbnail được chọn. Trong quá trình xem ảnh các bác sĩ có thể xem thông tin về ảnh khi click vào nút “Thông tin ảnh”. Hình 3. 25: Thông điệp “getDICOMInformation” giúp lấy thông tin chứa trong ảnh DICOM Hình 3. 26: Kết quả thông tin chứa trong ảnh DICOM sau khi được lấy về CHƯƠNG IV: THẢO LUẬN Trong khoảng thời gian làm luận án tốt nghiệp, tuy thời gian cũng khá khiêm tốn nhưng cùng với sự giúp đỡ của thầy hướng dẫn, bạn bè và nỗ lực cá nhân nên các mục tiêu đề ra đã dần dần được hoàn tất. Tuy nhiên, một vấn đề đặt ra cho ứng dụng hội chẩn từ xa này là khả năng bảo mật thông tin của bệnh nhân bởi vì đây là những dữ liệu nhạy cảm. Nhưng việc đi sâu vào vấn đề bảo mật này cần rất nhiều thời gian nghiên cứu để làm sao vừa bảo đảm cho hệ thống truyền tải dữ liệu âm thanh, hình ảnh theo thời gian thực cũng như việc đảm bảo bí mật thông tin. Việc bảo mật thông tin này làm ảnh hưởng rất nhiều tới độ trễ của dữ liệu. Như vậy định hướng sau này của đề tài là sẽ được tiếp tục phát triển thêm những tính năng để mã hoá thông tin bênh nhân. Ngoài ra, với bất cứ một ứng dụng nào cung cấp cho số đông các người dùng thì cũng đều phải áp dụng Cluster. Rõ ràng nếu hệ thống được sử dụng cho một bệnh viện nhỏ có khoảng vài chục người cùng tham gia một lúc thì sẽ không cần sử dụng Cluster. Nếu hệ thống này được sử dụng rộng rãi hơn thì vấn đề này bắt buộc phải xem xét. Do đó đây cũng là một hướng khác cho con đường phát triển tiếp theo của đề tài. Mặt khác, hệ thống media Server này cũng có thể xây dựng để trở thành hệ thống elearning. Vì trong hệ thống elearning cần rất nhiều tương tác giữa người học và giảng viên. Giảng viên có thể chia sẻ bài giảng trực tuyến cũng như trực tiếp tương tác để chỉ rõ cho từng học viên đang theo dõi. Khi cần giảng viên có thể thao tác trực tiếp trên máy của mình để hướng dẫn một bài học nào đó và tất cả mọi học viên đều xem thấy được. Trong hệ thống elearning thông thường thì học viên chỉ có thể lắng nghe mà không thể đặt được câu hỏi cho người trình bày. Còn đối với hệ thống này, học viên không những có thể đặt câu hỏi trực tiếp cho giảng viên mà còn có thể thảo luận thành nhóm chung với các học viên khác nữa. Không chỉ thế, media Server này còn có thể xây dựng thành Server chia sẻ video trực tuyến, hội thảo trực tuyến,… CHƯƠNG V: KẾT LUẬN Về mặt lý thuyết: Luận văn đã đề ra vấn đề “xây dựng media Server ứng dụng trong hội chẩn từ xa”, do đó luận văn tập trung nghiên cứu cơ sở lý thuyết để giải quyết cho được vấn đề trên, cụ thể như sau: Mô hình hệ thống Mô hình Peer to Peer Mô hình Client – Server Kiến trúc Server Giao thức truyền tải dữ liệu thời gian thực RTP (Realtime Transport Protocol) RTMP (Real Time Messaging Protocol) Chuẩn mã hoá dữ liệu AMF (Action Message Format) AMF0 AMF3 Shared Object Chuẩn nén âm thanh HE-AAC Chuẩn nén hình ảnh MPEG4/H.264 Hệ thống lưu trữ và truyền tải hình ảnh (PACS) Hệ thống MyFreePACS Chuẩn hình ảnh DICOM dùng trong y tế DICOM Toolkit DCMTK DCM4CHE Hệ thống thông tin y tế HIS Hệ thống FreeMED Chuẩn dữ liệu văn bản HL7 Giải pháp mở rộng: Giải pháp là giải pháp sử dụng Cluster Server Giải pháp phát triển tính năng mở rộng của Server Cơ bản luận văn đã giải quyết tương đối đầy đủ tất cả nội dung lý thuyết đã đề ra Về mặt thực hành Từ phần cơ sở lý thuyết đã nghiên cứu, một media server ở mức cơ bản dùng trong việc chia sẻ và lưu trữ âm thanh, hình ảnh, hỗ trợ tính năng Shared Object, cũng như tính năng tương tác với HIS, PACS để lấy ảnh và thông tin bệnh nhân đã được xây dựng. Media Server này cũng đã hoạt động tốt với một Client được xây dựng ở một đề tài khác, và hợp thành một bộ sản phẩm hỗ trợ các bác sĩ trong việc hội chẩn từ xa. TÀI LIỆU THAM KHẢO Rafael C. Gonzalez, Richard E. Woods. Digital Image Processing (2nd Edition), Prentice Hall, 2002. Akimichi Ogawa, Katsushi Kobayashi, Kazunori Sugiura, Osamu Nakamura, Jun Murai, "Design and Implementation of DV based video over RTP", May 2000, Packet Video Workshop 2000. Adobe Systems Inc, "Action Message Format - AMF 0", June 2006. Adobe Systems Inc, "Action Message Format -- AMF 3", June 2006. David Salomon, “Data Compression The Complete Reference Fourth Edition”, Springer-Verlag London Limited 2007. Gerald Moser, “MPEG-4 aacPlus - Audio coding for today’s digital media world”, Coding Technologies, November 2005. Iain E. G. Richardson, “H.264 and MPEG-4 Video Compression Video Coding for Next-generation Multimedia”, John Wiley & Sons Ltd, 2003. Nguyễn Đức Thuận , Vũ Duy Hải, Trần Anh Vũ, “Hệ thống thông tin y tế”, Nhà xuất bản Bách Khoa Hà Nội, năm 2006. H.K.Huang, “PACS and Imaging Informatics”, JohnWiley & Son Inc., Hoboken, NewJersey, năm 2004. Nguyễn Quốc Cường, “Internetworking với TCP/IP”, Nhà Xuất Bản Giáo duc, 2001. Nguyễn Tấn Quy, Lưu Dương Minh Phương, “Tìm Hiểu Và Ứng Dụng MyFreePacs Trong Việc Xây Dựng Hệ Thống Lưu Trữ Và Truyền Ảnh” (Picture Archive and Communication Systems – PACS ), 2008. Đặng Thị Thanh Huyền, “Nghiên cứu một tích hợp dữ liệu giữa hai hệ thống HIS và PACS”, 2008. Coding Technologies, Gnash, Red5, DICOM,