Những vấn đề có xu hướng phát sinh khi làm việc với các tin nhắn HL7?

Tôi đang thử nghiệm một sản phẩm cho các doanh nghiệp chăm sóc sức khỏe và chúng tôi đang làm việc với các tin nhắn HL7. Tôi thấy mọi người than vãn về một câu hỏi khác về các vấn đề với HL7 nhưng không đề cập đến chi tiết cụ thể. Ai đó có thể cho tôi một số ý tưởng về những vấn đề hoặc lớp vấn đề chúng ta nên tìm kiếm cụ thể không?

Chúng tôi đang sử dụng một số thư viện được sử dụng tốt để phân tích cú pháp. Nếu chi tiết cụ thể về những điều này hoặc những gì chúng tôi đang làm sẽ hữu ích, vui lòng cho tôi biết trong các nhận xét và tôi sẽ thêm vào câu hỏi nếu tôi có thể.

Tôi giả sử bạn đang giao dịch với HL7 v2.x

HL7 tự nguyện vô cùng linh hoạt. Điều đó có lợi thế lớn nhưng cũng giới thiệu những thách thức. Một quy tắc cơ bản cần ghi nhớ là mỗi lần thực hiện sẽ khác nhau. Nếu bạn triển khai cùng một sản phẩm trong 2 môi trường khác nhau (ví dụ 2 bệnh viện), quy tắc trao đổi dữ liệu có thể sẽ khác. Sản phẩm của bạn phải sẵn sàng đáp ứng các yêu cầu ẩn đó nếu bạn muốn có thể chia tỷ lệ số giao diện HL7 mà nó sẽ tương tác.

Trong hầu hết các hệ thống chăm sóc sức khỏe đối phó với HL7, chúng tôi đang phải đối mặt với danh sách một phần các thách thức phổ biến này:

• Mỗi hệ thống có thể giải thích ý nghĩa của từng phần dữ liệu. Ngoài ra bối cảnh và quy trình công việc có thể ảnh hưởng đến ngữ nghĩa. Tôi thấy một số hệ thống sử dụng số tài khoản (PID.18) hoặc số truy cập (PV1.19) để xác định bệnh nhân tuân thủ một số quy trình làm việc lâm sàng. Loại khoảng cách ngữ nghĩa đó có thể sẽ có một số tác động đến cách hệ thống nhận dữ liệu này xử lý nó.
• Bắt buộc so với tùy chọn: Vì một phần dữ liệu có thể được trao đổi để đạt được một số mục tiêu trong một số bối cảnh khác nhau, hầu hết các phân đoạn và trường được ghi lại dưới dạng tùy chọn trong tài liệu chính thức (và một số trình phân tích cú pháp). Tuy nhiên, để đáp ứng quy trình công việc cụ thể, các sản phẩm chăm sóc sức khỏe có thể sẽ thêm các quy tắc ràng buộc dữ liệu và thư giãn một số thứ khác. Hầu hết thời gian, một trường hợp phân tích từng trường hợp cần phải xảy ra để xác định chúng.
• Bảng: HL7 cung cấp một số danh sách các giá trị được đề xuất cho một số trường. Chẳng hạn, danh sách giá trị được đề xuất cho giới tính dài 6 ... Rõ ràng, hầu hết các hệ thống không triển khai cả 6 nhưng chiến lược ánh xạ của bạn là gì nếu bạn nhận được một thứ bạn không hỗ trợ trả trước?
• Phân đoạn và trường có thể được tùy chỉnh: Độ dài trường, loại dữ liệu và các thuộc tính định nghĩa khác có thể được tùy chỉnh. Bạn cần ánh xạ nó tới một số cấu trúc dữ liệu mà bạn biết mà không mất thông tin quan trọng.

jlmorin

www.caristix.com

Một vài vấn đề mà tôi gặp phải:

• Một số tổ chức có thể sử dụng các phiên bản khác nhau của HL7, vì vậy bạn sẽ gặp sự cố tương thích ("đi bộ chéo"). Chắc chắn bạn sẽ gặp phải vấn đề này nếu bạn tham gia vào bất kỳ hoạt động chuyển dữ liệu liên tổ chức nào.
• Không có tiêu chuẩn ngữ nghĩa (đối với v2.x, tôi nghĩ rằng v3 có thể đã bắt đầu giải quyết vấn đề này), vì vậy ngay cả khi bạn biết dữ liệu nào sẽ có trong một trường cụ thể, bạn có thể không biết ý nghĩa chính xác hoặc biểu diễn của các byte đó.
• HL7 là một tiêu chuẩn không chuẩn. Nó hỗ trợ nhà cung cấp cụ thể Z-segmentsđược sử dụng rộng rãi và hoàn toàn độc quyền.
• HL7 v2.x (nhiều giá trị của x vẫn được sử dụng ngoài tự nhiên) là định dạng độc quyền không phải là XML, vì vậy bạn sẽ cần một trình phân tích cú pháp HL7 để làm việc với nó. (Điều này, bạn biết vì bạn đã có một thư viện phân tích cú pháp HL7 chỉ bao gồm nó cho những người khác)

Vấn đề đầu tiên là đảm bảo mọi người đều biết HL7 là gì.

Đó là một cách để thay thế các lập trình viên [y tế | thanh toán | bảo hiểm] và tiết kiệm tiền [dược phẩm | ngân hàng | công ty bảo hiểm].

Đó là nếp nhăn trên tất cả các vấn đề bình thường trong phát triển phần mềm.

1. Creep phạm vi
2. Thông số kỹ thuật chưa đầy đủ
3. Thông số kỹ thuật độc quyền không hợp lệ "Không thể thay đổi"

Vì vậy, bạn liên hệ với [Nhà thuốc | Ngân hàng | Công ty bảo hiểm], người muốn tiết kiệm tất cả số tiền họ có thể từ giao diện HL7 đến cơ sở sử dụng phần mềm của bạn. Hợp đồng của bạn là với cơ sở, hợp đồng của họ là với nhà thuốc, [Nhà thuốc | Ngân hàng | Công ty bảo hiểm] không biết phần mềm của bạn hoạt động như thế nào, cơ sở không có manh mối gì về HL7 và bạn bị đánh dấu tại nhà thuốc vì họ liên tục nói với bạn rằng phần mềm của bạn bị lỗi.

Tôi tin rằng vấn đề với HL7 là nó chủ yếu được thực hiện với giá rẻ. HL7 3.0 có thể không bao giờ thành hiện thực vì nó sẽ không bao giờ kiếm tiền.

Nếu bạn định "trả tiền cho HL7", hãy nhớ rằng bạn cũng đang trả tiền cho HL [1-6]. Giao diện SOAP không phải là HL7. Trình phân tích cú pháp tin nhắn HL7 không phải là HL7, cũng không phải là trình tạo tin nhắn.