Khóa luận Công cụ hỗ trợ chuẩn đáo bệnh từ xa

với cơ chế download file của các giao thức HTTP hay FTP. Truyền dòng cho phép chúng ta thể hiện các dòng video thời gian thực mà không phụ thuộc vào độ dài của video. Điều này rất có ý nghĩa khi truyền các file video có kích thước lớn hay các dòng video có độ dài không xác định. Khi đó, các giao thức khác như FTP hay HTTP sẽ không thể sử dụng được. Chúng ta có thể bắt gặp rất nhiều trường hợp sử dụng cơ chế truyền dòng như các chương trình truyền hình trực tiếp, hội thảo qua mạng. Với khả năng truyền tải nội dung video, audio thông qua mạng, chúng ta có một phương pháp giao tiếp và truy nhập thông tin mới. Với góc nhìn bao quát, truyền dòng là một phương pháp truyền thông tin liên tục, trong đó nội dung video được truyền đi theo trình tự thời gian. Bên nhận khi nhận dòng thông tin, nội dung video có thể trình diễn được ngay trên màn hình. Khả năng này rất có ý nghĩa đối với các loại dữ liệu phụ thuộc thời gian như video, audio, bởi vì để đảm bảo chất lượng cảm thụ video thì phải đảm bảo được mối quan hệ về mặt thời gian giữa các khung hình. 2.3.3 Các phương thức truyền dòng dữ liệu video Có ba phương thức truyền dòng dữ liệu video như sau: Truyền đơn hướng (Unicast) Unicast là một phương thức đơn giản: các gói dữ liệu được truyền trực tiếp từ máy tính này tới máy tính khác. Unicast được sử dụng cho việc truyền dòng giữa hai máy tính (point-to-point). Một vấn đề đặt ra khi sử dụng phương thức truyền unicast, đó là băng thông của mạng (đường nối giữa hai máy tính). Dữ liệu đa phương tiện thời gian thực (audio, video) có dung lượng lớn, đòi hỏi tốc độ truyền cao (các dòng theo nén chuẩn MPEG1, MPEG2 đòi hỏi tốc độ truyền từ 3-9 Mbit/s). Do đó, nếu chúng ta chỉ truyền một dòng thì mạng Ethernet với tốc độ 10Mbit/s là đủ, tuy nhiên nếu chúng ta muốn truyền nhiều dòng cùng một lúc thì cần mạng có tốc độ truyền lớn hơn (các mạng Ethernet 100 Mbit/s, mạng ATM, mạng FDDI…). Một giải pháp khác là sử dụng các công nghệ nén hiện đại(H.263, H.264, MPEG-4) để nén dữ liệu Video và Audio, khi đó yêu cầu về băng thông của mạng sẽ không cao. Truyền quảng bá (Broadcast) Phương thức broadcast được dùng cho việc quảng bá. Khi một máy truyền theo kiểu broadcast, dòng dữ liệu đó sẽ được truyền tới tất cả các máy trong mạng con cùng một lúc. Nhược điểm của phương pháp này, đó là tất cả các máy trong mạng đều nhận được dòng dữ liệu đó cho dù nó không có nhu cầu nhận. Việc này sẽ chiếm dụng băng thông của mạng. Do đó, broadcast chỉ nên dùng trong trường hợp truyền thông cho các loại dữ liệu không cần đòi hỏi băng thông lớn, hay trong trường hợp thiết bị phần cứng của mạng không hỗ trợ phương thức multicast. Truyền đa hướng (Multicast) Khi sử dụng phương thức unicast hay broadcast, chúng ta có thể gặp phải một số vấn đề sau: Với phương thức unicast, khi nhiều máy cùng muốn nhận dòng dữ liệu đa phương tiện đó, đòi hỏi máy tính truyền phải thực hiện nhiều kết nối đồng thời (mỗi kết nối sẽ truyền dòng dữ liệu đó cho máy tính tương ứng), điều này rất phức tạp và thông thường số lượng máy tính muốn nhận rất hạn chế. Với phương thức broadcast, nhiều máy tính có thể nhận được đồng thời một dòng đi ra từ một máy tính, tuy nhiên ngay cả những máy tính không muốn nhận dòng dữ liệu đó cũng phải nhận, điều này gây nên tình trạng “rác” trong mạng, chiếm dụng băng thông của mạng, nên khi số lượng dòng truyền tăng có thể dẫn đến tắc nghẽn mạng. Nhược điểm của hai phương thức đó được khắc phục trong phương thức multicast. Multicasting là một công nghệ mới cho phép dữ liệu được gửi đi từ một host và sau đó được nhân lên và gửi tới những host khác mà không gây ra tắc nghẽn mạng. Dữ liệu truyền theo cơ chế multicast chỉ được nhân lên chỉ khi các tiến trình chạy trên máy trạm thuộc mạng muốn lấy dữ liệu. Lưu ý là không phải tất cả các giao thức đều hỗ trợ “multicast” (trong Windows chỉ có hai giao thức có khả năng hỗ trợ “multicast” là giao thức IP và giao thức ATM). Ngoài ra, không phải lúc nào chúng ta cũng có thể sử dụng được địa chỉ multicast, chỉ những mạng mà thiết bị phần cứng (Hub, Switch, Router) của nó hỗ trợ thì phương thức multicast mới có thể sử dụng được [2]. Hệ thống do nhóm xây dựng, mô hình truyền dòng dữ liệu theo mô hình đơn hướng, tức là giao tiếp thực hiện chỉ giữa bác sĩ khám bệnh và bệnh nhân. 2.3.4 Vấn đề đồng bộ hoá Video và Audio Việc duy trì mối quan hệ về mặt thời gian giữa các dòng dữ liệu khác nhau trong truyền thông đa phương tiện thời gian thực là hết sức quan trọng. Ví dụ như trong ứng dụng hội thảo trực tuyến thì dòng dữ liệu hình ảnh và âm thanh của một thành viên phải có quan hệ chặt chẽ với nhau về mặt thời gian. Ngay cả đối với một file video khi chúng ta tiến hành truyền đi trên mạng, chúng ta sẽ tách các dòng dữ liệu âm thanh và hình ảnh ra và truyền theo các dòng khác nhau, khi tới bên nhận các dòng dữ liệu sẽ lại được tích hợp lại, các dòng dữ liệu này cũng phải có quan hệ chặt chẽ với nhau về mặt thời gian. Quá trình duy trì mối quan hệ đó được gọi là sự đồng bộ hoá. Tuỳ thuộc vào đặc trưng về độ tin cậy của mạng chuyển mạch gói (độ trễ, tỉ lệ mất gói…) mà độ phức tạp của kỹ thuật động bộ có khác nhau. Như vậy, thực chất nhiệm vụ của đồng bộ trong truyền thông đa phương tiện thời gian thực đó là: xác lập quan hệ thời gian thực của các dòng dữ liệu đa phương tiện. Về phương diện cảm thụ: đồng bộ đa phương tiện là quá trình làm “trơn” các hiệu ứng trễ và điều khiển, phối hợp thời gian trình diễn đồng thời các dòng dữ liệu đa phương tiện để thoả mãn độ cảm thụ của con người. Các mô hình đồng bộ sử dụng trong truyền thông đa phương tiện thời gian thực bao gồm: Mô hình dòng thời gian (Timeline): Các hành động được xác định bởi thời điểm bắt đầu, dựa trên các đặc trưng thực hiện đồng bộ bám theo thời gian tồn tại của đối tượng. Mô hình điểm tham chiếu (Reference point): Các điểm tham chiếu hay điểm đồng bộ được xác định bên trong thời gian tồn tại của đối tượng đa phương tiện, tại thời điểm đó, ta thực hiện đồng bộ hóa các dòng dữ liệu đa phương tiện để trình diễn. Mô hình phân cấp (Hierarchic): đồng bộ theo mức phân cấp. Mô hình dựa trên sự kiện (Event based): Trong hệ thống hướng sự kiện, điểm bắt đầu hay kết thúc của một đối tượng được xử lý như sự kiện xẩy ra. Đối với mỗi mô hình đồng bộ chúng ta có thể áp dụng một trong các phương pháp đồng bộ sau[2]: Phương pháp dồn kênh (Multiplexing): Các dòng dữ liệu đa phương tiện (audio, video) được đồng bộ tích hợp lại tại nguồn phát trước khi được truyền đi. Phương pháp dùng kênh riêng chứa thông tin đồng bộ. Phương pháp đồng bộ tại nơi nhận dựa trên các nhãn thời gian được gói vào dữ liệu trước khi truyền đi. 2.4 Nén/Giải nén Video 2.4.1 Các khái niệm cơ bản về nén video Việc phát triển các chuẩn nén rất cần thiết cho tương lai của ngành đa phương tiện. Video có nhu cầu nén cao nhất. Nếu không được nén, thì mỗi khung video sẽ chiếm một chỗ lưu trữ lên đến 7.4 Mb. Vì vậy, khi hình video hiển thị toàn bộ màn hình khoảng 22 giây thì hình video chuyển động toàn phần (FSFM) có thể chiếm không gian lưu trữ trên đĩa quang 600 Mb. Nếu với tốc độ hiển thị 30frame/s, để phát lại video đó đòi hỏi phải có tốc độ truyền 222 Mb/giây, vượt quá tốc độ hiện nay là 1,5 Mb/s. Vì vậy nén là yếu tố quan trọng trong việc giải quyết vấn đề này, ngoài ra, nó còn đòi hỏi phải cần có tốc độ xử lý phát triển cao hơn để thực hiện thuật toán giải nén tinh vi. Việc mã hóa video theo thời gian thực được thực hiện theo một loạt các bước sau[2]: Đầu tiên bộ nén/giải nén tạo một khung gồm hàng ngàn pixel bằng cách lấy mẫu tín hiệu tương tự từ bộ ghi hình. Bộ nén/giải nén sẽ chia khung thành nhiều khối với độ sáng là 16 x 16 pixel và mỗi cặp mầu là 8 x 8 pixel. Sau đó nó sẽ phân tích các khối để xác định dữ liệu nào cần phải được gửi đi để tránh tình trạng gửi những dữ liệu chưa được chuyển đổi từ khung trước. Nếu có thay đổi nào nghiêm trọng thì nó sẽ sử dụng mã hóa nội khung để gửi toàn bộ dữ liệu mới. Nếu chỉ là những thay đổi nhỏ không đáng kể thì nó sẽ sử dụng mã hóa giữa khung để bổ sung vào những thông tin đã có sẵn. Nếu không có thay đổi nào thì nó sẽ quét mầu lại cho khối đó. Nếu như khối hoàn chỉnh được gửi đi gần vị trí ban đầu của nó trong khung trước, thì bộ nén/giải nén sẽ sử dụng phép bù động để di chuyển toàn bộ khối. Sau đó, nó sử dụng thuật toán DCT(Discrete Cosin Transform: Biến đổi Cosin rời rạc) để tổ chức lại thông tin pixel trong phạm vi mỗi khối thành một dạng dày đặc hơn bằng cách tạo ra một loạt các hệ số toán học tượng trưng cho một số tổ hợp các giá trị pixel. Nó sử dụng phép lượng tử hóa để co dãn và làm tròn các hệ số nhằm tạo ra những hệ số xấp xỉ nhất mà có thể được gửi đi với số lượng bit ít hơn. Cuối cùng, nó sử dụng mã hóa hai chiều và mã hóa thời gian chạy để giảm bớt các chuỗi số không rất dài do phép lượng tử hóa sinh ra. 2.4.2 Một số chuẩn nén video Do sự phát triển nhanh của truyền thống đa phương tiện, các máy camera số, máy ảnh số, các phương tiện giải trí số… vì vậy có rất nhiều chuẩn nén đã được đưa ra. Hiện nay trên thế giới có 2 tổ chức chính thức đưa ra các chuẩn video được áp dụng rộng rãi trên thế giới: MPEG(Motion Picture Expert Group) và ITU(International Telecommunication Union). MPEG đưa ra các chuẩn MPEG-x, còn ITU đưa ra các chuẩn H.26x. Sau đây mô tả một số các chuẩn đó: MPEG-1 Chuẩn cho giai đoạn đầu (MPEG-1) xác định một dòng truyền bit cho video và âm thanh nén được tối ưu hóa để phù hợp với băng thông 1,5 Mb/giây – tốc độ truyền dữ liệu của các thiết bị như CD-ROM, băng âm thanh số (DAT), các đĩa WORM (ghi một lần đọc nhiều lần), đĩa MO (đĩa từ quang) và các kênh truyền thông như ISDN và LAN. Chuẩn này bao gồm 5 phần: Phần hệ thống (11172-1) liên quan đến đồng bộ hóa và ghép bội thông tin nghe nhìn. Phần video (11172-2) đề cập đến kỹ thuật nén video. Phần audio (11172-3) đề cập đến kỹ thuật nén âm thanh. Thử nghiệm tương hợp (11172-4) được thiết kế nhằm tạo nền tảng cho các phương pháp luận để thử nghiệm các dòng truyền bit và tạo nền tảng cho các bộ giải mã để tương hợp được các phần 1, 2 và 3. Mã hóa phần mềm (11172-5) là phần đáp ứng cho khả năng xử lý ngày càng phát triển của máy tính giúp phần mềm có khả năng thực hiện được với 3 phần đầu của bộ chuẩn. Thông số kỹ thuật cho phép ảnh đạt đến kích thước 4095 x 4095 với tần số độ phân giải 60 fps và tốc độ bit lên đến 100 Mb. Chất lượng hình ảnh Video đưa ra tốt, xấp xỉ với hình thức ghi video dưới dạng băng từ. MPEG-2 Giai đoạn 2 (MPEG-2) hiện đang được phát triển. Chuẩn này bao gồm 3 phần và các định nghĩa của 3 phần này đã được hoàn tất năm 1993. Mỗi phần sẽ do một tiểu ban xử lý: Phần hệ thống (13818-1) xác định dạng mã hóa cho âm thanh và video đa kênh gộp và cho các dữ liệu khác để thành một dạng phù hợp để truyền hoặc lưu trữ. Phần video (13818-2) là một phần tốt của MPEG-1 xác định dòng bit mã hóa cho video số chất lượng cao. Phần âm thanh (13818-3) xác định mã hòa âm thanh đa kênh tốc độ chậm. Chuẩn các hệ thống MPEG-2 xác định 2 dạng dòng dữ liệu: dòng lưu thông và dòng chương trình. Dòng lưu thông có thể đồng thời mang được nhiều chương trình và dòng này được tối ưu hóa để sử dụng trong các ứng dụng nơi mà có thể xảy ra tình trạng mất dữ liệu. Dòng chương trình được tối ưu hóa cho các ứng dụng truyền thông đa phương tiện, cho việc xử lý các hệ thống hoạt động trong phần mềm, và cho khả năng tương thích được với MPEG-1. Cả hai dòng này được thiết kế với ý định hỗ trợ rất nhiều các ứng dụng. Dòng lưu thông được thiết kế để truyền tín hiệu truyền hình số và hệ thống điện thoại hình qua vệ tinh, cáp quang, ISDN, ATM,… đồng thời, dòng này cũng được thiết kế để lưu trữ được trên băng video số và trên các thiết bị khác. MPEG-2 hỗ trợ độ các độ phân giải 720x480 và 1280x720 , tốc độ hiển thị 60 frame/s, âm thanh chất lượng tốt. Nó gần như tương thích với tất cả các chuẩn TV(NTSC, HDTV,…). MPEG-2 sử dụng trong lưu trữ dữ liệu video trên DVD-ROM, nó có thể nén 2 tiếng video với chỉ một vài Gigabytes. Tuy nhiên quá trình nén dữ liệu cần tài nguyên tính toán đủ mạnh, trong khi giải nén có thể chỉ cần khả năng xử lý không lớn lắm. MPEG-4 Công việc nghiên cứu về chuẩn MPEG mới dùng để mã hóa các chương trình nghe nhìn với tốc độ bit rất thấp đã chính thức bắt đầu vào tháng 9/1993. Chuẩn này được biết đến với tên MPEG-4, chủ yếu về truyền hình độ rõ nét cao. MPEG-4 bao gồm các chức năng mã hóa các chương trình để truyền qua các kênh với tốc độ rất thấp (176 x 144 x 10 Hz với tốc độ bit lên tới 64 kb/giây) hay để lưu trữ được trong phạm vi dung lượng rút gọn. Thuật toán nén MPEG-4 dựa trên thuật toán nén dữ liệu trong các chuẩn MPEG-1, MPEG-2, và Apple Quicktime. Chuẩn được đưa ra vào tháng 10-1998, trong tài liệu ISO/IEC-14496. H.261 H.261 là chuẩn nén/giải nén dữ liệu do tổ chức ITU đưa ra vào năm 1990 [9], thiết kế để nén và truyền dữ liệu video trên mạng ISDN với datarate là bội số 64kbps. Thuật toán nén dữ liệu được thiết kế cho phép đưa ra dữ liệu nén với tốc độ datarate từ 40kbps đến 2Mbps. Chuẩn hỗ trợ 2 chế độ phân giải CIF và QCIF. H.263 H.263 là một chuẩn nén/giải nén dữ liệu Video do tổ chức ITU đưa ra đầu tiên vào năm 1995 [9]. Được phát triển từ chuẩn H.261, nó được thiết kế cho các ứng dụng video có tốc độ bitrate thấp, và với độ lớn dữ liệu nén đưa ra nhỏ(dưới 64kbps). Tuy nhiên giới hạn đó đang dần được thay thế với khả năng nén ngày càng được nâng cao, đồng thời cho phép hoạt động trên nhiều một miền lớn bitrate khác nhau. H.263 là chuẩn được phát triển tiếp từ chuẩn H.261 đã được đưa ra trước đó, với những cải tiến mới làm tăng hiệu suất hoạt động và khả năng khắc phục lỗi. H.263 hỗ trợ 5 chế độ phân giải: SQCIF, QCIF, CIF, 4CIF, 16CIF. Format NTSC-based PAL-based SQCIF 128 x 96 QCIF 176 x 120 176 x 144 CIF 352 x 240 352 x 288 4CIF 704 x 480 704 x 576 16CIF 1408 x 960 1408 x 1152 Bảng 1: Các chế độ phân giải Với khả năng hỗ trợ cho độ phân giải 4CIF, 16CIF, H.263 đã có thể thích ứng với các ứng dụng có chỉ sổ bitrate cao. Dưới đây là đồ thị thể hiện tương quan giữa độ nén(bit rate) và chất lượng hình ảnh(PSNR) khi áp dụng nén theo chuẩn H.263 [17] : Hình 8: Biểu đồ thể hiện tương quan tỉ lệ nén và chất lượng hình ảnh Hình trên thể hiện tương quan giữa bitrate và chất lượng hình ảnh của video được nén. Thí nghiệm thực hiện nén 3 đoạn Video khác nhau. Với mỗi đoạn video được quay với 2 tốc độ 10 frame/ s và 30 frame /s. Chuẩn nén video sử dụng trong hệ thống xây dựng Với yêu cầu có thể hoạt động trên mạng có băng thông không cao và truyền video theo phương thức trực tiếp(máy camera quay hình, sau đó nén hình và truyền ngay lập tức), vì vậy chuẩn nén video được sử dụng trong hệ thống nhóm xây dựng là chuẩn H.263 2.5 Nén/Giải nén Audio 2.5.1 Một số khái niệm về nén Audio Các file âm thanh stereo chưa được nén yêu cầu khoảng 150KB của đĩa cứng cho mỗi giây. Kích cỡ của file phụ thuộc vào tốc độ lấy mẫu, số bit trong một mẫu, và âm thanh đó là mono hay stereo. Ví dụ: với tốc độ lấy mẫu 22kHz, 16-bit/1 mẫu, âm thanh mono, thì tốc độ dữ liệu sinh ra là 2.65MB/1 phút. Chính vì vậy mà việc nén file âm thanh sử dụng audio codec là phương pháp thích hợp để lưu trữ âm thanh trong đĩa cứng hoặc có thể sử dụng audio Streamming qua một mạng có băng thông giới hạn Audio codec được sử dụng cho các mục đích khác nhau. Một số các codec sử dụng chỉ với mục đích là chỉ có thể nghe rõ để tiếp nhận thông tin được, yêu cầu quan trọng là độ nén cao(DSP Group TrueSpeech hoặc Microsoft Groupe Spécial Mobile [GSM] 6.10)-ví dụ như ứng dụng telephone(voice oriented audio codec). Một số khác thì sử dụng với yêu cầu đảm bảo chất lượng âm thanh trung thực(Fraunhofer Institut Integrierte Schaltungen IIS [FhG] MPEG Layer-3 hoặc Voxware MetaSound)-ví dụ như nghe nhạc(music oriented audio codec), tuy nhiên khi đó dữ liệu nén sẽ lớn và yêu cầu đường truyền mạng có băng thông lớn 2.5.2 Một số chuẩn nén audio Một số chuẩn nén hiện đang được sử dụng [18] : Audio Codec Mô tả Frequency/Sampling Rate CCITT A-Law CCITT A-Law codec tương thích với chuẩn Telephony Application Programming Interface(TAPI) dùng trong cộng đồng châu Âu. Có tên khác là G.711, codec này được hỗ trợ bởi nhiều các thiết bị phần cứng, và có tỉ lệ nén là 2:1 8.000 kHz, 8-bit, Stereo, 15 kbps11.025 kHz, 8-bit, Stereo, 21 kbps22.050 kHz, 8-bit, Mono, 21 kbps22.050 kHz, 8-bit, Stereo, 43 kbps44.100 kHz, 8-bit, Mono, 43 kbps CCITT u-Law Tương tự như CCITT A-Law codec, nhưng tương thích với chuẩn TAPI sử dụng ở Mỹ Tương tự như CCITT A-Law codec. DSP Group TrueSpeech Nén tốt cho những âm thanh không yêu cầu chất lượng cao, và được thiết kế cho chỉ số bitrate thấp đến trung bình. Có datarate thấp hơn GSM 6.10. Nó không có tốc độ nén đáp ứng thời gian thực tuy nhiên có tốc độ giải nén đáp ứng thời gian thực. 8.000 kHz, 1-bit, Mono, 1 kbps GSM 6.10 Có hiệu quả nén tốt và tốt nhất với bitrate từ trung bình đến cao. Tỉ lệ nén là 2:1, nén thời gian thực. GSM tương thích với chuẩn European Telecommunications Standards Institute recommendation 6.10 8.000 kHz, Mono, 1 kbps11.025 kHz, Mono, 2 kbps22.050 kHz, Mono, 4 kbps44.100 kHz, Mono, 8 kbps Microsoft ADPCM Có tỉ lệ nén cao 4:1và đảm bảo yêu cầu thời gian thực. Thích hợp cho stream audio kết hợp với video có bit rate cao. 8.000 kHz, 4-bit, Mono, 4 kbps8.000 kHz, 4-bit, Stereo, 8 kbps11.025 kHz, 4-bit, Stereo, 11 kbps Microsoft G.723.1 Dùng để tạo ra các file ASF, sử dụng để stream audio thông qua mạng Internet. Thích hợp với mạng có băng thông thấp 14.4 đến 28.8 kbps. 8.000 kHz, Mono, 6400 bit/s 0 kbps8.000 kHz, Mono, 5333 bit/s 0 kbps MPEG Layer-3 Sử dụng với những file âm nhạc có chất lượng tốt và có bit rate trong khoảng từ thấp đến trung bình. Sử dụng trên mạng Intranet hoặc mạng Internet. Có khả năng nén cao cho rất nhiều loại file âm thanh vì vậy có bit rate thấp và cần ít tài nguyên CPU. 8 kbps, 8.000 kHz, Mono, 0 kbps16 kbps, 8.000 kHz, Mono, 1 kbps8 kbps, 11.025 kHz, Mono, 0 kbps16 kbps, 11.025 kHz, Mono, 1 kbps18 kbps, 11.025 kHz, Mono, 2 kbps20 kbps, 11.025 kHz, Mono, 2 kbps PCM Tạo ra các dữ liệu âm thanh chưa được nén với bit rate cao. 8.000 kHz, 8-bit, Stereo, 15 kbps11.025 kHz, 8-bit, Mono, 10 kbps44.100 kHz, 8-bit, Mono, 43 kbps48.000 kHz, 8-bit, Mono, 46 kbps Bảng 2: Các codec đang được sử dụng Chuẩn nén được nhóm sử dung: Sau khi tìm hiểu về hạ tầng cơ sở mạng về đường truyền, băng thông, tốc độ truyền thống. Trên cơ sở yêu cầu của hệ thống là cần chất lượng âm thanh không cao, và sử dụng băng thông ít, vì vậy hệ thống xây dựng sử dụng chuẩn GSM 6.10 2.6. Một số khái niệm về tin học y sinh 2.6.1. Chuẩn đoán bệnh từ xa Telemedicine là một từ ghép bắt nguồn từ “tele” trong tiếng Hy Lạp có nghĩa là “từ xa” và “medicine” trong tiếng Latin là “mederi” nghĩa là “điều trị”. Năm 1970, lần đầu tiên khái niệm Telemedicine được dùng nhằm mô tả cung cấp dịch vụ chăm sóc sức khỏe cho các bệnh nhân từ xa thông qua việc sử dụng công nghệ thông tin. Dịch vụ chăm sóc sức khỏe ở đây có thể bao gồm cả chẩn đoán và điều trị, cung cấp thuốc men, tư vấn, dự phòng và phục hồi, bảo hiểm y tế, giảng dạy, nghiên cứu... Ví dụ, một bác sĩ đang ngồi trong phòng làm việc của mình khám cho một bệnh nhân cách đó hàng ngàn cây số. Chỉ cần nháy chuột là bác sĩ đã có trong tay đầy đủ thông tin về bệnh sử, thông tin kết quả thăm khám như: xét nghiệm (xét nghiệm huyết học, sinh hóa, vi sinh, tế bào...), thông tin về chẩn đoán chức năng (điện tim, điện não, hô hấp...), thông tin về hình ảnh (Xquang, siêu âm,...). Đó chính là một ứng dụng của telemedicine. 2.6.2. Các loại dữ liệu trong tin học y sinh 2.6.2.1. Điện tâm đồ Điện tâm đồ là đồ thị ghi những thay đổi của dòng điện trong tim. Quả tim co bóp theo nhịp do điều khiển của một hệ thống dẫn điện nằm trong cơ tim. Những dòng điện tuy rất nhỏ, khoảng 1 phần nghìn volt, nhưng có thể dò thấy được từ các cực điện đặt trên tay, chân và ngực bệnh nhân và chuyển đến máy ghi. Máy ghi điện khuếch đại lên và ghi lại trên điện tâm đồ. Điện tâm đồ được xử dụng trong y học để xét nghiệm bệnh về tim như rối loạn nhịp tim, đau tim, nhồi máu cơ tim v.v... 2.6.2.2 Điện não đồ Điện não đồ EEG (Electroencephalography) là phương pháp đo dòng điện chạy qua các điện cực đặt trên da đầu, đôi khi đặt trục tiếp trên vỏ não. Từ các biến đổi của dòng điện ghi được, có thể suy đoán nhiều hoạt động, tình trạng của não. Với các thông số đó sẽ giúp cho các bác sĩ trong quá trình chuẩn đoán bệnh. Về cơ chế đo Điện Tâm Đồ và cách thu và xử lý dữ liêu từ máy Điện Tâm Đồ cũng như cơ chế, cách thu và xử lý với dữ liệu Điện Não Đồ đã được trình bầy kĩ trong Khoá Luận Tốt Nghiệp của Vũ Văn Tiệp, làm cùng trong đề tài nghiên cứu. Chương 3. Thiết kế hệ thống chuẩn đoán bệnh từ xa 3.1. Tìm hiểu về yêu cầu của hệ thống Thông qua việc tìm hiểu một số yêu cầu của bác sĩ, cũng như phía bệnh nhân trong quá trình khám, chữa bệnh của mình, đồng thời tìm hiểu các hệ thống đã được xây dựng và phát triển ta thấy có những yêu cầu cần phải phát triển cho hệ thống hỗ trợ chuẩn đoán bệnh từ xa bao gồm các chức năng chính sau đây: Phía bác sĩ mong muốn cho thể nhìn thấy bệnh nhân một cách trực quan nhất trong quá trình khám bệnh của mình. Trong quá trình khám bệnh bác sĩ mong muốn có được hình ảnh của bệnh nhân một cách nhanh và chính xác nhất. Nhất là việc khám và chữa bệnh trực tiếp đòi hỏi hình ảnh có thể phóng to, hay thu nhỏ tùy theo thời điểm, đồng thời cũng có thể thay đổi góc nhìn của hình ảnh sao cho thuận lợi nhất để có thể quan sát kỹ hơn mà không phải làm phiền bệnh nhân. Vì vậy hệ thống xây dựng cần phải có khả năng phóng to thu nhỏ, điều chỉnh góc quay của camera trong quá trình khám chữa. Và việc này phải được thực hiện bên phía bác sĩ. Trong quá trình khám thì bác sĩ cũng mong muốn được trao đổi trực tiếp với bệnh nhân thông qua các phương tiện như Audio, chat trực tiếp. Vì những trao đổi này bệnh nhân có thể nói về tình trạng hiện thời của mình cũng như hiện trạng cơ thể cho bác sĩ. Như vậy hệ thống cũng phải đáp ứng khả năng truyền âm thanh cũng như tạo một công cụ phục vụ cho việc trao đổi dạng text từ hai phía mà không phải sử dụng thêm các phần mềm khác. Trong quá trình khám và chữa bệnh thì hai phía cũng có nhu cầu trao đổi các hồ sơ bệnh án cho nhau. Như bệnh nhân muốn chuyển hồ sơ bệnh án, hình chụp X- Quang, hình chụp cắt lớp, hình siêu âm … cho phía bác sĩ. Đồng thời, phía bác sĩ cũng muốn chuyển các chuẩn đoán của mình, đơn thuốc, hướng dẫn điều trị cho bệnh nhân ngay khi có kết quả của quá trình khám chữa. Như vậy, hệ thống của ta phải có chức năng cho phép hai phía trao đổi hồ sơ dữ liệu với nhau trong quá trình khám bệnh. Phía bác sĩ cũng mong muốn có được những số liệu của các máy điện tâm đồ, điện não đồ từ phía bệnh nhân. Và có các số liệu phân tích các số liệu của những máy này để phục vụ cho việc chuẩn đoán được nhanh chóng hơn. Như vậy, hệ thống phải có chức năng ghép nối được với máy điện tâm đồ, điện não đồ và có thể lấy được dữ liệu để truyền qua mạng và có thể phân tích được các tín hiệu số đó thành các chỉ số có ý nghĩa trong việc khám chữa của bác sĩ. Bác sĩ cũng mong muốn có thể tương tác với hệ thống một cách dễ dàng nhất. Như việc dùng thiết bị để điều chỉnh camera mà không phải tương tác trực tiếp với máy tính. Điều này rất hữu ích đặc biệt với những người ít có kinh nghiệm trong sử dụng máy tính. 3.2. Kiến trúc của hệ thống 3.2.1. Kiến trúc tổng thể của hệ thống Hình 9: Kiến trúc tổng thể của hệ thống Mô tả mô hình tổng thể của hệ thống. Hệ thống được phát triển với hai module chính, và các module này được kết nối với nhau thông qua mạng intenet băng thông rộng. Một module phía bác sĩ có vai trò như là server khi chương trình phía bác sĩ được kích hoạt nó sẽ luôn lắng nghe các kết nối đến từ các máy ở phía bệnh nhân và bất cứ khi nào yêu cầu kết nối đến hệ thống server này thì hệ thống sẽ thông báo cho bác sĩ về yêu cầu kết nối. Module phía bác sĩ được kết nối với Joystick để bác sĩ có thể điều khiển camera thông qua Joystick mà không phải thao tác với các hộp thoại trong chương trình. Một module phía bệnh nhân đóng vai trò như một client. Bất cứ khi nào có nhu cầu khám chữa bệnh. Module chương trình này được kích hoạt và bệnh nhân nhập vào IP của máy cần kết nối hệ thống sẽ thông qua mạng internet gửi thống báo yêu cầu kết nối đến bác sĩ. Nếu được phía bác sĩ chấp nhận khám chữa bệnh thì một phiên làm việc bắt đầu với việc hai bên bắt đầu khởi động các module trong hệ thống nhằm thực hiện việc khám chữa bệnh. 3.2.2. Kiến trúc của hệ thống phía bác sĩ: Mµn h×nh Joystick Speaker Microphone Video Streamming Module qu¶n lý Joystick TCP UDP Audio Streamming Chat Hình 10: Mô hình các module bên phía bác sĩ 3.2.3. Kiến trúc của hệ thống phía bên bệnh nhân: Camera Speaker Microphone Máy điện tâm đồ Video Streamming Điều khiển Camera Audio Streamming Quản lý máy điện tâm đồ UDP TCP Chat Hình 11: Mô hình các module bên phía bệnh nhân a. Video streamming: Sử dụng chuẩn nén H263, có thể nén và truyền hình ảnh trên mạng không đòi hỏi đường truyền băng thông cao(dưới 64Kbps). Hình ảnh sẽ được truyền trực tiếp, thời gian thực. Module có chức năng cho phép người sử dụng có thể điều chỉnh được độ nén của dữ liệu video để có thể tăng giảm tốc độ truyền dữ liệu trên mạng, từ đó có thể tuỳ theo chất lượng mạng theo từng thời điểm để có thể điều chỉnh cho phù hợp, đảm bảo việc truyền Video không bị gián đoạn b. Audio Streamming: Module có chức năng thu âm thanh và truyền trên mạng cho bên kia, đồng thời cũng có chức năng nhận các tín hiệu âm thanh truyền trên mạng và đưa ra speaker. c. Chatting: Module cho phép 2 bác sĩ quản lý máy tính có thể dùng text trao đổi thông tin với nhau d. Điều khiển Camera: Sử dụng Camera có thể điều khiển được. Module này có trách nhiệm nhận các tín hiệu điều khiển từ phía bác sĩ(bác sĩ dùng Joystick để điều khiển) và chịu trách nhiệm kết nối tới driver của máy quay để thực hiện các tín hiệu điều khiển đó e. Joystick: Module kết nối với driver của Joystick, bắt các sự kiện chuyển động của Joystick và truyền trên mạng cho bên phía bệnh nhân để có thể điều khiển Camera phía bệnh nhân theo chuyển động của Joystick f. Điện tâm đồ: Các thông tin của máy điện tâm đồ được máy tính tiếp nhận thông qua cổng COM, lưu trữ và truyền trên mạng cho bác sĩ khám bệnh. Bên bác sĩ khám bệnh có nhiệm vụ lưu trữ, hiển thị các dữ liệu này trên một cửa sổ riêng biệt. Module này chia thành 3 module nhỏ hơn: - Module nhận dữ liệu từ máy ECG từ cổng COM. Sử dụng một Thread luôn luôn quét dữ liệu truyền vào từ cổng COM. Nếu thấy dữ liệu truyền vào, thì sẽ đọc dữ liệu đó, sau đó thực hiện thao tác covert sang dữ liệu Digital. - Module lưu trữ, xử lý và hiển thị điện tâm đồ. a. Đọc dữ liệu dạng số ở module nhận dữ liệu tứ máy ECG từ cổng COM và lưu lại dưới định dạng file dùng cho dữ liệu điện tâm đồ b. Xử lý dữ liệu điện tâm đồ để tính toán và đưa ra các thông số phục vụ cho quá trình khám bệnh của bác sĩ. c. Vẽ tín hiệu nhận được dưới dạng đồ thị, đó chính là hình ảnh ECG trên máy tính. - Module truyền và nhận dữ liệu điện tâm đồ a. Dữ liệu nhận từ cổng COM được vẽ thành hình ảnh ECG, và sau đó được truyền đi qua mạng đến máy nhận. b. Máy nhận sau khi nhận được dữ liệu ECG sẽ tái tạo lại hình ảnh đồ thị ECG và hiển thị trên màn hình g. Trao đổi các thông tin về bệnh sử của bệnh nhân: Các thông tin về bệnh nhân(Họ tên, Tuổi, tiền sử bệnh ... ) được truyền tự động từ phía phòng khám bệnh cho phía bác sĩ ở xa. Các thông tin này sẽ hiện tự động trên màn hình máy tính. h.Trao đổi các hình ảnh: Module hướng tới việc trao đổi hình ảnh một cách dễ dàng nhất cho người sử dụng vì nhu cầu về hình ảnh trong chuẩn đoán bệnh là thường xuyên. Bên phía bác sĩ khi cần hình ảnh nào đó(ảnh chụp X-Quang, ảnh chụp CT, ảnh Siêu âm... ), chỉ cần yêu cầu và bên phía bệnh nhân sẽ gửi ảnh lại cho bác sĩ(hình ảnh kĩ thuật số này có thể được lấy từ các máy sinh hình tuân theo chuẩn DICOM hoặc được chụp bằng máy ảnh kĩ thuật số và chuyển tới máy tính). Sau khi nhận được file ảnh do bên bệnh nhân gửi, ảnh sẽ tự động được lưu lại và hiển thị lên ở phía bác sĩ Quản lý conference: Tiếp nhận và xử lý tín hiệu điểu khiển liên quan đến conference như: Yêu cầu kết nối, huỷ bỏ kết nối, …. 3.3. Đặc tả các module xây dựng Bằng cách sử dụng ngôn ngữ UML, các module đã được đặc tả chi tiết trong khóa luận tốt nghiệp của Bùi Đức Tiến, K47CB, làm cùng đề tài nghiên cứu. Chương 4. Triển khai hệ thống 4.1 Giao diện hệ thống Hệ thống được xây dựng theo kiến trúc Client/Server. Do đó phân giao diện được chia thành hai phần để phù hợp với cấu trúc và chức năng tương ứng. Giao diện hệ thống bên Client Giao diện hệ thống bên Server Khi chương trình bắt đầu, giao diện mặc định cho phép hiển thị hình ảnh Video Streaming. Sau đó, thông qua thực đơn chính, người dùng có thể chọn các chức năng tương ứng.. Giao diện chương trình khi bắt đầu: Hình 12: Giao diện mặc định Sau khi phía bệnh nhân kết nối thành công tới phía bác sĩ, thì màn hình Video bên phía bệnh nhân sẽ được bật, và sau đó sẽ được truyền sang phía bác sĩ. Giao diện Video Hình 13: Giao diện Video Giao diện hệ thống bên phía Client và phía server được thiết kế như phần dưới đây. Giao diện tương tác hệ thống Giao diện hệ thống bên Client Giao diện hệ thống bên Server Hình 14: Sơ đồ cấu trúc giao diện của hệ thống 4.1.1. Giao diện hệ thống bên Client Hình 15: Sơ đồ phần cấp Menu của chương trình phía Client 4.1.1.1. Connect Hình 16: Hộp thoại xuất hiện lúc khởi đầu qua trình kết nối 4.1.1. 2. Chatting Hình 17: Giao diện chat phía Client 4.1.1.3. ECG Machine Hình 18: Giao diện ECG 4.1.1.4. ECG From File Hình 19: Giao diện ECG 4.1.2. Giao diện hệ thống bên Server Hình 20: Sơ đồ phần cấp menu phía server 4.1.2.1. Chatting Hình 21: Giao diện chat 4.1.2.2. ECG Online Hình 22: Giao diện Điện tâm đồ phía bác sĩ 4.1.2.3. ECG From Machine Hình 23: Giao diện ECG nhận dữ liệu từ máy 4.1.2.4. Compress Hình 24: Hộp thoại cho phép chỉnh độ nén của dữ liệu Video 4.2. Mô hình truyền dữ liệu của hệ thống 4.2.1. Mô hình Video Streamming Audio Streamming Text ECG Hồ sơ dữ liệu Quản lý conference UDP Socket UDP socket TCP Socket TCP Socket TCP Socket TCP Socket Network Hình 25: Mô hình truyền dữ liệu của hệ thống 4.2.2. Mô tả mô hình truyền dữ liệu Hệ thống được xây dựng nhằm phục vụ nhu cầu khám chữa bệnh từ xa. Đặc điểm của quá trình này đó là nó cần trao đổi rất nhiều loại dữ liệu khác nhau có cả những dữ liệu nhạy cảm của bệnh nhân yêu cầu được bảo vệ an toàn. Do tính đa dạng của các loại dữ liệu trong hệ thống này đặt ra yêu cầu phải xây dựng một mô hình tổng thể để có thể truyền được mọi loại dữ liệu khác nhau. Trong hệ thống của mình chúng tôi đã xây dựng theo mô hình sau đây: Với dữ liệu điều khiển do dữ liệu dạng này có dung lượng rất nhỏ đồng thời đòi hỏi được an toàn và không mất mát chúng tôi dùng giao thức TCP/IP để truyền. Mỗi khi hệ thống khởi động nó luôn tạo một socket loại TYPE_CONTROL và với cổng là PORT_CONTROL và lắng nghe dữ liệu được truyền từ máy đối tác thông qua cổng này. Với dữ liệu Video và Audio do đây là loại dữ liệu có dung lượng lớn đồng thời cho phép mất mát dữ liệu khi truyền qua mạng vì vậy dùng UDP để truyền dữ liệu. Quá trình tạo socket để tiến hành nhận dữ liệu Audio và Video chỉ được thực hiện khi quá trình kết nối từ bệnh nhân đến phía bác sĩ được thiết lập. Hệ thống phía bác sĩ khởi tạo socket để nhận dữ liệu video, bệnh nhân cũng khởi tạo một socket riêng dành cho video để truyền dữ liệu video đến phía bác sĩ. Tương tự với dữ liệu dạng Audio cả hai phía cũng tạo một socket riêng cho audio . Với dữ liệu dạng Text (dùng trong quá trình chat) thì hệ thống cũng tạo môt socket riêng với Type = TYPE_TEXT và cổng dùng để truyền nhận cho nhau là PORT_TEXT. Tương tự với dữ liệu từ máy điện tâm đồ thì hệ thống cũng tạo riêng một đối tượng socket mới để truyền dữ liệu với Type = TYPE_ECG và cổng là PORT_ECG. Khi truyền dữ liệu là hồ sơ dữ liệu thì ta cũng tạo một socket riêng cho dữ liệu này và sử dụng giao thức TCP. 4.3. Xây dựng Module Video Conference 4.3.1 Video streamming 4.3.1.1 Mô hình Video Streamming xây dựng trong hệ thống Mô hình Video Streamming sử dụng trong hệ thống như hình dưới đây: Camera Data source Video codec UDP Socket Network UDP Socket Video codec Data source Desktop Hình 26: Mô hình Video Streamming Hệ thống sử dụng socket UDP riêng để truyền và nhận dữ liệu dữ liệu video. Sau khi thu dữ liệu video từ camera, chương trình tiến hành nén và truyền trên mạng theo giao thức RTP sử dụng UDP socket. Bên nhận sẽ tiến hành giải nén và hiển thị ra màn hình. 4.3.1.2 Bộ nén và giải nén dữ liệu video sử dụng Bởi vì hệ thống quay và truyền trực tiếp hình ảnh cho phía bác sĩ theo thời gian thực(Streamming Live Video), do đó sử dụng chuẩn nén H263 để nén và truyền dữ liệu Video. Thư viện các hàm nén của chuẩn H.263 sử dụng mã nguồn mở [7]. Với một số hàm quan trọng trong thư viện sau: Khởi tạo bộ nén dữ liệu void InitH263Encoder(&cparams); Khởi tạo bộ giải nén void InitH263Decoder(); Khi nhận được một frame ảnh từ camera tiến hành nén và gửi đi: //Chuyển dữ liệu từ định dạng RGB sang định dạng YUV. Bởi vì hàm nén chỉ xử lý dữ liệu video có định dạng YUV, trong khi dữ liệu video lấy từ Camera có dạng RGB ConvertRGB2YUV(IMAGE_WIDTH,IMAGE_HEIGHT,rgb_source ,yuv) //Thiết lập tham số nén cparams.format=CPARAM_QCIF; cparams.inter = CPARAM_INTRA; cparams.Q_intra = 8; cparams.data=yuv; // dữ liệu định dạng YUV // Nén ảnh CompressFrame(&cparams, &bits); Hàm giải nén dữ liệu: DecompressFrame(data,size,rgbdata,buffersize); Kết thúc bộ giải nén: ExitH263Decoder(); Kết thúc bộ nén : ExitH263Encoder(&cparams); Tham số trong việc nén ảnh lưu trữ trong biến cparams là một struct có các thành phần: cparams.format: độ phân giải của frame( hệ thống sử dụng phân giải QCIF ) cparams.inter: chế độ nén( Inter hoặc Intra) cparams.Q_Intra: lượng tử hoá( quyết định tỉ lệ nén dữ liệu ) cparams.data: định dạng dữ liệu nén( sử dụng định dạng YUV ) Module quản lý video streamming cho phép bác sĩ có thể điều chỉnh được độ nén của hình ảnh để giảm/tăng kích thước của dữ liệu truyền trên mạng. Chức năng này được sử dụng trong các trường hợp mạng không ổn đinh, bác sĩ có thể điều trình độ nén phù hợp với băng thông mạng hiện thời để có thể duy trì phiên khám bệnh. Tham số cparams.Q_Intra quyết định tỉ lệ nén này. Tuy nhiên chất lượng hình ảnh thu được bên phía bác sĩ tỉ lệ nghịch với tỉ lệ nén: tỉ lệ nén càng cao thì hình ảnh thu được càng không rõ nét 4.3.1.3 Triển khai video streamming trong hệ thống Thu nhận hình ảnh video từ camera Sử dụng VFW(Video For Windows) API của Windows(thư viện vfw32.lib của MFC). API này được Window cung cấp để thu hình từ các thiết bị Camera. Việc quản lý thu nhận dữ liệu từ Camera được đóng gói vào trong lớp VideoCapture. Các công việc trong quá trình thu nhận dữ liệu Video: khởi tạo ban đầu gồm các việc: kết nối với driver của camera, thiết lập định dạng cho dữ liệu video thu từ máy Initialize() lấy về các tham số định dạng cho ảnh thu được từ máy(thông số được quy đinh bởi driver của máy Camera), định dạng này sẽ được sử dụng cho việc hiển thị hình. Các tham số sẽ này được lưu trong lớp VideoCapture. bắt đầu thu hình StartCapture() dừng thu hình StopCapture() Xử lý khi thu được frame Khởi tạo bộ nén InitH263Encoder(paramater); Khởi tạo bộ chuyển đổi định dạng từ RGB -> YUV InitLookUpTable(); Chuyển đinh dạng cho frame từ RGB -> YUV(bởi vì bộ nén chỉ làm việc với định dạng YUV) ConvertRGB2YUV(); Thiết lập các tham số nén(đã trình bầy ở mục trên) Nén dữ liệu CompressFrame(data, paramater); Sử dụng UDP socket truyền sang bên kia Xử lý khi nhận được dữ liệu video từ UDP socket Khởi tạo bộ giải nén(thực hiện ngay từ khi khởi động chương trình) InitH263Decoder() Thực hiện giảin nén dữ liệu thu đuợc DecompressFrame() Hiển thị hình ảnh nhận được trên màn hình(Trình bày ở bước tiếp theo) Kết thúc bộ giải nén ExitH263Decoder() Hiển thị hình ảnh nhận được Dữ liệu hình ảnh sau khi được giải nén sẽ được hiện thị ra Monitor. Chương trình sử dụng DrawDib API của Window để hiển thị hình ảnh, như vậy sẽ nâng cao việc hiển thị hình ảnh so với các hàm hiển thị sử dụng thư viện GDI, bởi vì nó thao tác trực tiếp với vùng bộ nhớ dành cho video. Các bước thực hiện trong quá trình sử dụng: Tạo một Device Independent Bitmap hdib = DrawDibOpen() Bắt đầu quá trình hiển thị bitmap DrawDibBegin(hdib) Hiển thị bitmap DrawDibDraw(hdib, data, …) Dừng quá trình hiển thị DrawDibEnd(hdib) Huỷ bỏ Device Independent Bitmap DrawDibClose(hdib) 4.3.2 Audio streamming 4.3.2.1 Mô hình Audio Streamming được xây dựng trong chương trình Tương tự như Video Streamming, mô hình Audio Streamming xây dựng trong hệ thống như sau: Micro Speaker Data source Audio Codec Data source UDP Socket Network UDP Socket Audio Codec Data source Data source Micro Speaker Hình 27: Mô hình Audio Streamming Audio Streamming sử dụng một socket UDP dành riêng để nhận và truyền dữ liệu cho Audio. Chương trình sử dụng 2 tiến trình(thread) chạy song song với nhau: record và play.Tiến trình record nhận dữ liệu âm thanh từ micro đã được chuyển sang dạng số, sau đó nén theo chuẩn GSM 6.10 và truyền sang cho bên kia. Thư viện hàm nén và giải nén theo chuẩn GSM 6.10 sử dụng mã nguồn mở [7]. Tiến trình play nhận dữ liệu từ socket và giải nén và đưa ra speaker. Mô hình các tiến trình trong quá trình chạy chương trình như hình dưới: UDP Socket Micro Speaker Record Play Hình 28: Mô hình sử dụng thread thu phát trong quá trình chạy 4.3.2.2 Triển khai trong hệ thống Chương trình sử dụng thư viện winmm.lib của MFC trong đó chứa codec để nén và giải nén audio, hàm lấy dữ liệu audio từ micro và hàm đưa dữ liệu audio ra thiết bị speaker. Chức năng record và play được đóng gói trong hai lớp RecordSound và PlaySound.Quá trình audio streamming được thực hiện trong chương trình như sau: Khi khởi động quá trình thu âm thanh: Kết nối với driver quản lý speaker và micro tạo header đầu tiên Thiết lập tham số cho audio input: tần số lấy mẫu(SamplesPerSec), trong chương trình tốc độ lấy mẫu sử dụng là 22.05kHz định dạng audio input: GSM 6.10 Một số các thông số liên quan: số bit/sample, BlogAlign, … Trong quá thu âm thanh từ micro: Dữ liệu thu được lưu giữ trong hàm OnSoundRecord() của lớp RecordSound. Với mỗi đoạn dữ liệu audio thu được thưc hiện các công việc : Tạo header cho gói tin Đóng gói dữ liệu với header đã tạo Gửi qua mạng sử dụng UDP socket Khi nhận được dữ liệu từ UDP socket, thực hiện các công việc: Lấy dữ liệu âm thanh từ gói tin nhận được Ghi header cho dữ liệu audio đó(GSM 6.10, tần số thu, …) Gửi đến codec của Window, sau khi tiến hành giải nén Windows phát ra speaker (Chú ý: có 2 loại header: 1 loại header để đánh dấu các gói tin truyền trên mạng theo giao thức RTP, 1 loại để ghi các thông tin cần thiết cho việc phát ra speaker để chuyển cho Windows) Sử dụng thread play và record trong quá trình chạy chương trình Tạo tiến trình thu và phát record = new RecordSound(); record->CreateThread(); play = new PlaySound(); play->CreateThead(); Khởi động tiến trình record và play khi bắt đầu conference: record->PostThreadMessage(START_RECORDING); play->PostThreadMessage(START_PLAYING); Ngừng thu, phát âm thanh record->PostThreadMessage(STOP_RECORDING); play->PostThreadMessage(STOP_PLAYING); Huỷ bỏ tiến trình thu phát play->PostThreadMessage(END_THREAD); record->PostThreadMessage(END_THREAD); 4.4. Tìm hiểu về Camera số có khả năng điều khiển 4.4.1 Giới thiệu về camera sử dụng trong hệ thống Camera sử dụng trong hệ thống là camera số, toàn phương, có thể quay với góc độ lớn. Tín hiệu Video ra theo chuẩn NTSC, có thể đưa vào máy tính theo đường S-Video, hoặc đưa trực tiếp ra TV theo đường Video. Hình 29: Camera sử dụng trong hệ thống Hình 30: Khả năng quay của Camera Hình 31: Sơ đồ cách lắp các dây nối của Camera Tín hiệu video do camera thu có thể được đưa vào máy tính theo đường S-Video, hoặc đưa ra TV theo đường video. Tín hiệu điều khiển camera đi ra từ máy tính qua cổng COM và vào camera theo cổng VISCA. Sơ đồ cách nối các dây như trên hình 4.4.2. Độ phân giải của camera Độ phân giải là thông số thể hiện sự rõ nét của hình ảnh do camera thu được. Nó chính là số dòng quét ngang của camera được truyền để có thể sinh ra các frame ảnh. Con số này càng lớn thì ảnh càng rõ. Mặc dù bình thường một vài camera chỉ cần độ phân giải là 380 đến 400 là cho chất lượng ảnh tốt, tuy nhiên một số camera có 600 dòng độ phân giải nhưng hình ảnh sinh ra vẫn có chất lượng xấu bởi vì chất lượng hình ảnh còn phụ thuộc vào chất lượng của thấu kính của camera. Với camera sử dụng trong hệ thống, số dòng quét của nó là 470, cho hình ảnh rõ và có thể đáp ứng tốt cho quá trình khám bệnh từ xa(yêu cầu hình ảnh chất lượng tốt). 4.4.3. Tính nhạy sáng Chỉ số này thể hiện khả năng thu hình trong điều kiện ánh sáng thiếu. Đơn vị đo tính nhạy sáng của camera là Lux . Con số này càng nhỏ thì càng cần ít ánh sáng để camera có thể sinh ra các ảnh. Ví dụ một camera có thể quan sát xuống tới 1 lux , có nghĩa là nó có khả năng quan sát vào thời điểm khoảng 1h trước khi trời tối, với tham số khoảng 0.5 lux camera có thể quan sát vùng sáng lờ mờ vào buổi tối. Với các camera có tham số 0.05 lux thì có thể quan sát các ảnh tốt hơn là mắt người vào buổi tối. 4.4.4. Thấu kính và các tham số của thấu kính Thấu kính là một phần tử quang học dùng để tụ ảnh quang chiếu trên bề mặt nhạy cảm của bộ cảm biến hay các bộ cảm biến của camera. Đặc tính của thấu kính được trình bày trong các phần dưới đây. Tiêu cự Khoảng cách từ vật cảnh tới thấu kính (khoảng cách đối tượng) và khoảng cách từ thấu kính tới ảnh (khoảng cách ảnh) có quan hệ hình học với nhau và tuân theo công thức thấu kính : 1/S0 + 1/S1 = 1/F trong đó: S0: khoảng cách đối tượng S1: khoảng cách ảnh F: tiêu cự thấu kính Độ mở Trong các thấu kính đều có các màn ngăn ánh sáng, ở giữa màn ngăn có một lỗ tròn cho ánh sáng đi qua, kích thước của lỗ này điều chỉnh được. Tùy theo ánh sáng bên ngoài mạnh hay yếu mà điều chỉnh kích thước lỗ của màn ngăn để có được chất lượng hình ảnh tốt. Chiều sâu độ nét của thấu kính Khoảng cách dọc theo trục quang của thấu kính mà mọi vật trong đó đều có ảnh thu được rõ nét được gọi là chiều sâu độ nét của thấu kính. Nếu vật chỉ di động trong khoảng cách đó, không cần điều chỉnh lại thấu kính, ảnh của nó thu được vẫn nét. Để tăng chiều sâu độ nét, ta phải giảm tiêu cự của thấu kính. Đối với thấu kính đã cho, tiêu cự cố định, độ mở của thấu kính càng nhỏ và vật càng cách xa thấu kính thì chiều sâu độ nét càng lớn. 4.4.5.Chức năng điều khiển của Camera Camera sử dụng trong hệ thống có khả năng điểu khiển quay theo ý muốn.Chức năng điều khiển quay camera do phần cứng đảm nhiệm, nhà sản xuất có các API cho người lập trình. Tín hiệu điều khiển truyền từ máy tính, qua cổng COM, đi vào camera theo cổng VISCA, và mạch điều khiển sẽ nhận tín hiệu và điều khiển camera. Có các tín hiệu điều khiển Camera sau: RIGHT(quay phải), LEFT(quay trái), UP(quay lên), DOWN(quay xuống), UP_RIGHT(lên và sang phải), UP_LEFT(lên và sang trái), DOWN_RIGHT(xuống và sang phải), DOWN_LEFT(xuống và sang trái), ZOOM_IN(phóng to), ZOOM_OUT(thu nhỏ), HOME(về vị trí camera lúc mới khởi động). 4.4.6 Lập trình điều khiển camera Chương trình sử dụng TCP socket để nhận và truyền dữ liệu điều khiển camera, bởi vì yêu cầu dữ liệu được đảm nhận dữ liệu điều khiển Camera đúng. Network Module điều khiển Camera TCP socket Camera Hệ thống bên phía bác sĩ Hình 32: Mô hình hoạt động module điều khiển Camera Module điều khiển Camera xây dựng gồm 2 lớp sau: SerialPort class: Giao tiếp với cổng COM Control class kế thừa từ SerialPort Class: tiếp nhận và xử lý các tín hiệu điều khiển Control class SerialPort class cổng COM Camera Tín hiệu điều khiển Hình 33: Mô hình cách lớp điều khiển camera xây dựng Trong quá trình khởi tạo ban đầu cần thực hiện các công việc: Đăng kí sử dụng cổng COM OpenPort(_T("COM1")) // chương trình sử dụng cổng COM1 Bật Camera CAM_Power(true) Đặt chế độ cho Camera: AutoPowerOff: CAM_AutoPowerOff(10) // tắt sau 10’ không hoạt động AutoFocus CAM_FocusAuto() Các hàm quan trọng trong quá trình điều khiển camera : Quay camera: Pan_tiltDriver(CString command, BYTE pan, BYTE tilt) với các tham số: command: lệnh quay ( LEFT, RIGHT, UP, DOWN,…) pan, titl: là các góc độ quay camera(theo phương ngang và theo phương thẳng đứng). Thu nhỏ hình void CAM_Zoom("WideV",2) Phóng to hình: void CAM_Zoom("TeleV",2); Bật/tạm ngừng quay camera: void CAM_Power(bool power) với tham số: power = false -> standby Camera power = true -> bật camera Chương 5. Kết luận 5.1 Các kết quả thu được Trong khoá luận này chúng tôi đã trình bầy các vấn đề liên quan đến lĩnh vực chuẩn đoán bệnh từ xa bao gồm: các khái niệm(Telemedicine, Telediagnostic,…), những hệ thống hiện đang được sử dụng( mạng HIS, PACS, …) , và những vấn đề còn tồn tại khi sử dung những hệ thống trong khám chữa bệnh. Từ đó khoá luận hướng tới giải quyết vấn đề nêu ra bằng cách thiết kế và xây dựng một hệ thống hỗ trợ khám chữa bệnh từ xa đáp ứng tốt những yêu cầu của công tác khám chữa bệnh. Giải pháp mà nhóm đưa ra là xây dựng hệ thống không những cho phép bác sĩ và bệnh nhân có thể trao đổi trực tiếp với nhau bằng hình ảnh và âm thanh thông qua việc sử dụng kĩ thuật Video Conference, mà còn có thể trao đổi các thông tin đa dạng khác: hình ảnh( ảnh chụp X-Quang, ảnh siêu âm), dữ liệu điện tâm đồ, các dữ liệu bệnh sử. Đồng thời hệ thống kết nối với Camera có thể điều khiển và Joystick cho phép bác sĩ có thể điều khiển Camera từ xa sử dụng Joystick, tạo sự thuận lợi cho các bác sĩ trong quá trình khám bệnh. Hệ thống đã được nhóm hoàn thiện, sử dụng ngôn ngữ VC++.Net. 5.2 Những lợi ích hệ thống đem lại Việc sử dụng hệ thống khám chữa bệnh từ xa đem lại rất nhiều lợi ích cho công tác y tế. Những lợi ích cụ thể là : Xoá bỏ hạn chế về không gian cũng như thời gian trong công tác khám chữa bệnh.Việc chẩn đoán và điều trị với ý kiến của các chuyên gia đầu ngành giữa bệnh viện tuyến trung ương và các bệnh viện tỉnh, khu vực sẽ tiết kiệm thời gian cho cấp cứu bệnh nhân. Tạo cơ hội cho nhân viên y tế địa phương nâng cao năng lực chuyên môn. Đối với các bệnh viện tuyến trung ương, đây là giải pháp hữu hiệu cho việc giảm tải bệnh nhân. Đối với người bệnh, công cụ này giúp làm giảm chi phí chi trả, đồng thời cũng tránh được những trường hợp đáng tiếc do đến bệnh viện trong tình trạng quá muộn hoặc đến không đúng bệnh viện. Sự ứng dụng của hệ thống sẽ giải quyết được yêu cầu của khám chữa bệnh là có thể cung cấp cho bác sĩ khám bệnh các thông tin phong phú và đa dạng về bệnh nhân. Từ đó trợ giúp các bác sĩ ra quyết định tốt hơn. Đồng thời sự hoạt động hệ thống cũng cho thấy khả năng chúng ta có thể kết nối thêm nhiều máy móc có thể điều khiển từ xa vào hệ thống. Ví dụ như có thể tổ chức các cuộc phẫu thuật từ xa,... Các dữ liệu về các ca bệnh được lưu trữ trên máy tính, sẽ là nguồn tư liệu quý giá cho việc học tập và nghiên cứu trong lĩnh vực y học. 5.3 Hướng phát triển trong tương lai Hiện tại nhóm mới kết nối máy điện tâm đồ và camera có chức năng điều khiển vào hệ thống khám bênh từ xa. Trong tương lai, nhóm sẽ có thể tiến hành kết nối thêm các thiết bị khác như: máy chụp X-Quang, máy CT, máy siêu âm, … để hỗ trợ thêm nhiều kênh thông tin đa dạng cho việc khám chữa bệnh của các bác sĩ. Đồng thời xu hướng trong tương lai là nghiên cứu và xây dựng chuẩn cho bệnh án điện tử(EMR-Electronic Medicine Record) để từ đó có thể tạo được cơ sở dữ liệu tổng thể cho hệ thống khám chữa bệnh của cả nước trong tương lai, và việc trao đổi dữ liệu trong quá trình khám chữa bệnh được thuận lợi, nhanh chóng và chính xác Hiện tại ứng dụng được sử dụng trên mạng ISDN kết nối giữa các bệnh viện. Thử nghiệm triển khai ứng dụng hệ thống trên mạng thế hệ mới NGN(Next Generation Network). Hiện nay, hạ tầng cơ sở vật chất cho mạng này đã được VNPT cam kết đảm bảo có đủ khả năng cung cấp cho nhu cầu khám chữa bệnh từ xa của ngành y tế. Phụ lục 1: Bảng các thuật ngữ sử dụng Thuật ngữ Nghĩa Bitrate Tốc độ bit Bitstream Dòng bit NTSC Viết tắt của National Television Standard Committee. Là một chuẩn cho tín hiệu video được sử dụng rộng rãi tại Mỹ PAL Chuẩn cho tín hiệu video được áp dụng chung tại Châu Âu RGB Một định dạng cho ảnh thu được từ camera. viết tắt của Red-Green-Blue, mầu của ảnh lưu trữ bởi ba thành phần mầu cơ bản trên YUV Một đinh dạng cho ảnh thu được từ camera, dữ liệu ảnh gồm hai thông tin : độ sáng(Y) và mầu sắc(U,V) Máy CT Thiết bị chụp cắt lớp sử dụng trong y tế NGN Next Generation Network, mạng thế hệ mới, sử dụng với mục đích truyền các dữ liệu hình ảnh, âm thanh, dữ liệu … với chất lượng ổn định, phục vụ cho các mục đích hội thảo từ xa, khám chữa bệnh từ xa… ECG Điện tâm đồ EEG Điện não đồ BCI Viết tắt của Brain Computer Interface. Đây là một thiết bị phần cứng có trang bị phần mềm backend cho phép truyền tín hiệu sóng phức hợp đo từ não người vào máy tính. Tài liệu tham khảo TÀI LIỆU TIẾNG VIỆT Ngô Thị Duyên, “Phục hồi lỗi trong streamming video trên mạng di động”, Luận văn tốt nghiệp, Khoa Công Nghệ Thông Tin, Đại học Công Nghệ, Đại học Quốc Gia Hà Nội, 2005 Đặng Kim Dũng, “Phát triển hệ thống giám sát bằng Camera trên mạng phục vụ cho đào tạo”, Báo cáo tốt nghiệp, Khoa Công Nghệ Thông Tin, Đại học Bách Khoa Hà Nội, 2006 GS.TS. Phạm Thị Minh Đức, “Sinh lý học”, Nhà xuất bản Y Học, 2005 Vũ Duy Lợi: “Mạng thông tin máy tính: kiến trúc, nguyên tắc và hiệu suất hoạt động”, Nhà xuất bản Thế Giới, 2002 TÀI LIỆU TIẾNG ANH James F.Kurose and Keith W.Ross : “Computer Networking: A Top-Down Approach Featuring the Internet”, 2000. Jorge Baztarrica Ochoa: “EEG Signal Classification for Brain Computer Interface Applications”, EPFT, 2002. WEBSITE THAM KHẢO www.moh.gov.vn www.microsoft.com [16] [17] H.263 Video coding [18] Compression Sound File [19]