Cha tôi là bác sĩ. Ông khăng khăng viết một cơ sở dữ liệu để lưu trữ thông tin bệnh nhân không quan trọng, không có nền tảng lập trình [đóng]

Vì vậy, cha tôi hiện đang trong quá trình "hack" cơ sở dữ liệu bằng FileMaker Pro, một công cụ dữ liệu dựa trên GUI để thực hành (4 bác sĩ) nhỏ của mình. Cơ sở dữ liệu sẽ được sử dụng để giúp giảm bớt gánh nặng báo cáo từ các máy y tế, hợp lý hóa một quy trình khá vụng về.

Anh ta không có nền tảng lập trình, và dường như đang làm mọi thứ trong khả năng của mình để không học mọi thứ một cách chính xác. Anh ta có các kiểu dữ liệu trùng lặp, không có mối quan hệ thực thi cơ sở dữ liệu (ràng buộc khóa chính / ngoại khóa) và hàng tá vấn đề khác. Anh ấy làm tất cả bằng tay thông qua công cụ GUI bằng video Youtube.

Vấn đề của tôi là, trong khi tôi muốn anh ấy thành công 100%, tôi không nghĩ anh ấy thích hợp để xử lý các loại quyết định này. Làm thế nào để tôi thuyết phục anh ta rằng nếu không có một số loại giáo dục trong các chủ đề này, một giải pháp hack cùng nhau là một ý tưởng tồi? Anh ấy có thể khá bướng bỉnh và tôi nghĩ anh ấy xem những loại công việc này là "trẻ em chơi"

Làm thế nào tôi nên tiếp cận điều này? Có phải đó là một ý tưởng tồi - hay tôi đúng khi nghĩ rằng anh ta nên thuê một DBA / nhà phát triển phù hợp để xử lý việc này để nó không trở thành một cơn ác mộng bảo trì?

Lưu ý: Tôi là một nhà tư vấn phát triển trong 4 năm và tôi đã thấy những chia sẻ của tôi về việc triển khai khách hàng đau đớn.

Cập nhật:

Vì vậy, một vài năm sau, và tôi đã có thời gian để suy nghĩ về câu hỏi này. Cuối cùng, cha tôi đã thực hiện một giải pháp bằng Google Docs, FileMaker Pro và một số móc email. Anh ta tự mình thiết lập mọi thứ, và anh ta nói rằng anh ta đang nhận được giá trị to lớn từ nó.

Nếu bạn là một nhà phát triển có kinh nghiệm, có lẽ bạn đang đọc mô tả và co rúm đó. Nhưng tôi đã học được một bài học khá hay từ toàn bộ thực tế - rằng mọi người chỉ quan tâm đến kết quả, chứ không quan tâm đến việc thực hiện. Tất cả những gì cha tôi quan tâm là thực tế ông không cần phải nhập thông tin bệnh nhân vào giấy thủ công và thay vào đó có thể nhanh chóng điền vào biểu mẫu tài liệu Google. Điều tuyệt vời là anh ấy đang muốn thuê một người phát triển cơ sở chỉ tập trung vào tự động hóa trong quá trình thực hành của mình.

Tôi đã thiết kế các giải pháp chăm sóc sức khỏe trong nhiều năm. Tôi sẽ không đi vào tất cả các lý do khác nhau mà cha bạn không nên làm điều này; hầu hết các lý do mang tính học thuật: có nghĩa là, nếu bạn đã ở trong ngành đủ lâu, bạn sẽ biết những thứ này như thế nào và ném tuyết vào cuộc sống của chính họ.

Thay vào đó, cha của bạn, là một bác sĩ, cần phải hiểu lý do nghề nghiệp và thực tế, không học thuật, lý do tại sao những gì ông đang làm là nguy hiểm và có thể đe dọa đến tính mạng; nguy hiểm cho đồng nghiệp của anh ta, nguy hiểm cho sự riêng tư và danh tính của bệnh nhân của anh ta, và nguy hiểm cho việc hành nghề của anh ta từ góc độ pháp lý.

Nguy hiểm là nhiều mặt:

1. quyền riêng tư của bệnh nhân (HIPAA, ARRA, Sử dụng có ý nghĩa, Tuân thủ HITECH)
   • các trường được coi là trường xác định bệnh nhân là gì (nhiều chuyên gia trong ngành không hiểu điều này và chỉ vì bạn loại bỏ một số trường rõ ràng như họ, địa chỉ, mã zip, vẫn còn nhiều trường khác sẽ tạo ra nó dễ dàng liên kết dữ liệu lâm sàng với một bệnh nhân cụ thể, điều này, bản thân nó rất khó, có những công ty ngoài kia kiếm được rất nhiều tiền để nhận dạng dữ liệu lâm sàng - bản thân nó là cả một miền).
2. HIPAA, HITECH và luật mới hơn nêu rõ cách thức
   • kiểm toán nên được thực hiện
   • an ninh nên được thực hiện
   • yêu cầu mật khẩu
   • dữ liệu khi nghỉ ngơi nên được mã hóa
   • dữ liệu truyền đi phải được mã hóa và làm thế nào
   • bạn phải xem xét các điều khiển nếu bạn đang sử dụng bất kỳ loại dịch vụ lưu trữ nào (IaaS, PaaS)
   • Bạn có BAA và DSA thích hợp không
   • Làm thế nào để những người lưu trữ máy chủ của bạn kiểm soát truy cập
   • làm thế nào để họ xử lý nhiều người thuê nhà (bạn sẽ ngạc nhiên về cách một số thực thể lớn này KHÔNG xử lý việc này một cách thích hợp)
   • nếu bạn chấm dứt hợp đồng với những người lưu trữ cơ sở hạ tầng của bạn, họ sẽ đảm bảo xóa dữ liệu của bạn vĩnh viễn như thế nào (quy định của NIST)
3. các kiểm soát quản lý tại chỗ cho sự phát triển của bạn là gì
   • bạn có một sdlc tại chỗ không
   • Bạn có truy xuất nguồn gốc từ các yêu cầu để mã đến QA không
   • bạn có xác nhận việc sử dụng ứng dụng / thiết bị y tế của bạn không
4. phần mềm của bạn có phải là QA không và bạn có môi trường Kiểm tra chấp nhận người dùng (UAT) không
   • Làm thế nào để bạn bảo vệ môi trường này, bởi vì bạn sẽ sử dụng dữ liệu bệnh nhân thực sự
5. Có phải anh ta sẽ xử lý bệnh nhân, nếu anh ta định dùng cơ sở dữ liệu của mình để báo cáo?
   • Chính phủ có các biện pháp kiểm soát chặt chẽ để trao đổi dữ liệu này với Sàn giao dịch thông tin y tế (HIE)
   • Điều này dẫn đến việc anh ta sẽ thực hiện trao đổi của riêng mình như thế nào nếu anh ta muốn tận dụng kho lưu trữ dữ liệu lâm sàng (CDR)
6. anh ta có hiểu các quy định NIST cụ thể mà anh ta cần tuân thủ để bảo mật dữ liệu không
   • chẳng hạn như xóa dữ liệu vĩnh viễn (nếu sử dụng cơ sở hạ tầng được lưu trữ)
7. bạn đã đề cập anh ta sẽ lấy dữ liệu từ máy y tế
   • Anh ấy có hiểu các tiêu chuẩn thiết bị y tế mới của FDA không?
   • bắt đầu từ năm 2013, bất kỳ hệ thống kỹ thuật số nào hiển thị dữ liệu từ các thiết bị y tế đều có thể được phân loại là thiết bị y tế ... điều này có nghĩa là anh ta phải đáp ứng các yêu cầu quy định của FDA đối với các thiết bị y tế
8. đội và nhân viên của anh ấy sẽ đưa ra quyết định y tế dựa trên dữ liệu trong cơ sở dữ liệu của anh ấy chứ?
   • ông đã phát triển một mô hình dữ liệu lâm sàng vững chắc, đủ linh hoạt để xử lý các yêu cầu luôn thay đổi (ví dụ, các tiêu chuẩn mã hóa từ ICD-9 đến ICD-10 đến ICD-11)?
   • Làm thế nào anh ta sẽ phiên bản mô hình dữ liệu và giữ nó đồng bộ với dữ liệu (nghĩa là, nếu anh ta thay đổi mô hình dữ liệu lâm sàng, làm thế nào dữ liệu cũ hơn sẽ được trình bày?)
   • hệ thống của anh ta có thể tạo ra một ảnh chụp nhanh chính xác của dữ liệu lâm sàng như đã thấy vào ngày mà một quyết định lâm sàng được đưa ra không? Có những hậu quả pháp lý nếu anh ta không thể
   • anh ta có biết sự khác biệt giữa xóa thực và xóa logic và ý nghĩa đối với mô hình dữ liệu của anh ta không; theo yêu cầu lưu trữ của mình; để thực hành chính sách của mình?
   • anh ta có một giải pháp từ vựng tại chỗ để xử lý tất cả các dịch vụ khác nhau mà anh ta sẽ cần sử dụng không; phần lớn dữ liệu cần được mã hóa (trái ngược với văn bản miễn phí), bởi vì anh ta sẽ muốn tận dụng CDR của mình để tạo ra các báo cáo tuân thủ ICD-9. Và sau đó anh ta cần phải tính đến việc thay đổi các tiêu chuẩn này; ví dụ: ICD-9 đến ICD-10.
   • đối với từ vựng, thuật ngữ hoặc Từ điển dữ liệu sức khỏe (tất cả các từ đồng nghĩa cơ bản), anh ta sẽ thực hiện như thế nào và đảm bảo rằng thuật ngữ cũ vẫn có thể được đưa ra cho các quyết định lâm sàng cũ?
9. anh ta sẽ được lưu trữ dữ liệu dị ứng?
   • định nghĩa 'thuật ngữ y tế' hoặc 'từ vựng' của anh ấy sẽ được lưu trữ như thế nào?
   • anh ta sẽ tích hợp với các hệ thống thuật ngữ khác như LOINC và Ngân hàng dữ liệu đầu tiên chứ?
   • anh ta có hiểu biết về các dịch vụ thuật ngữ (ví dụ: Từ điển dữ liệu sức khỏe)
10. anh ta sẽ muốn có dữ liệu giao tiếp vào hệ thống của mình và có thể ra ngoài để trao đổi thông tin y tế (HIE) không?
    • Nếu vậy, anh ta có hiểu HL7 và tác động của nó đối với cơ sở dữ liệu của anh ta không?
    • anh ta có hiểu công cụ giao diện và tất cả những gì đi cùng với điều đó không?
11. Anh ấy có hiểu làm thế nào để xác định lại thông tin?
    • điều này rất quan trọng trong giai đoạn phát triển và giai đoạn sửa lỗi

Đây chỉ là một vài câu hỏi, và không có nghĩa là nó nên được coi là một danh sách toàn diện. Và với mỗi câu trả lời sẽ có vô số câu hỏi khác.

Trong cơ sở dữ liệu chăm sóc sức khỏe, không nên xóa hoặc ghi đè dữ liệu trước đó. Điều này có nghĩa là sẽ không bao giờ bị 'xóa khỏi nơi ...' hoặc 'bộ cập nhật ...'. Thay vào đó bạn sẽ chỉ có chèn. Bạn có thể tưởng tượng làm thế nào điều này thay đổi mô hình dữ liệu và các truy vấn của bạn. Bây giờ bạn có thể sáng tạo và đưa ra các giải pháp khác nhau để đạt được mục tiêu này, nhưng thực tế vẫn là đây là một yêu cầu duy nhất cho kho lưu trữ dữ liệu lâm sàng chăm sóc sức khỏe.

Chỉ cần thêm một suy nghĩ liên quan đến khía cạnh đe dọa tính mạng của vấn đề này:

Ví dụ, hãy lấy thông tin dị ứng; Tôi nâng cái này lên vì các tổ chức đã làm việc này bằng kỹ thuật số trong nhiều năm đã học được rằng các quy trình của họ cần phải đảm bảo rằng dữ liệu dị ứng được ghi lại và chúng ta không thể cho rằng vì công nghệ đã thu thập dữ liệu trong cơ sở dữ liệu nên nó hoàn toàn chính xác . Đây là lý do tại sao bệnh nhân được yêu cầu dị ứng mỗi lần khi họ chuyển từ khoa này sang khoa khác, ngay cả trong cùng một bệnh viện. Dị ứng của bệnh nhân không thể bị xóa (cập nhật lên một hàng xóa thông tin cũ). Một quyết định lâm sàng dựa trên dữ liệu kỹ thuật số cần nắm bắt những gì đã được 'trình bày' cho bác sĩ lâm sàng tại thời điểm quyết định.

Tôi biết nhiều điều này dường như được hướng đến một tổ chức lớn. Tuy nhiên, các bộ phận quy định không. Và trong mọi trường hợp, Hệ thống thông tin chăm sóc sức khỏe vốn đã phức tạp. Kỹ thuật hệ thống chăm sóc sức khỏe phụ thuộc và công nhận chuyên môn và kinh nghiệm của các bác sĩ lâm sàng giỏi. Tuy nhiên, có một sự không phù hợp trở kháng lớn hơn trung bình (để mượn thuật ngữ từ công nghệ ORM) trong lĩnh vực Chăm sóc sức khỏe CNTT ... Tôi mạo hiểm nói lớn hơn vì mọi miền đều có sự không phù hợp.

Chúc may mắn!

Một giải pháp hack cùng nhau không phải lúc nào cũng xấu. Nếu nó giải quyết vấn đề của anh ta, tôi sẽ không làm cho nó quá nhiều. Có lẽ có 10 giải pháp đã được hack cùng nhau trong File Maker và Access cho mọi giải pháp cơ sở dữ liệu chuyên nghiệp. Rốt cuộc, đó là những gì Filemaker và Access dành cho. Chắc chắn, hầu hết các giải pháp hack cùng nhau là khủng khiếp dưới mui xe. Nhưng họ tồn tại để giải quyết vấn đề, không giành chiến thắng trong các cuộc thi sắc đẹp. Thường thì phạm vi của các giải pháp này phát triển và đó là khi ai đó được thuê để xây dựng một giải pháp chuyên nghiệp.

Những gì bạn có thể làm để giúp cơ hội thành công của anh ấy là thể hiện sự quan tâm đến dự án của anh ấy và đề nghị ngồi xuống và giúp anh ấy xác định cơ sở dữ liệu và duyệt qua mọi thứ. Nếu anh ta không muốn sự giúp đỡ của bạn ... hãy bỏ nó và để anh ta được. Bạn sẽ làm gì, cha của bạn? Nếu / khi anh ấy vượt lên trên đầu, anh ấy sẽ cho bạn biết.

Một điều khác cần xem xét là nếu đây là một vấn đề phổ biến giữa các bác sĩ, bạn có thể có một cơ hội kinh doanh rất tốt trong việc tạo ra một giải pháp chung chung.

Là một nhà thiết kế phần mềm với hơn 25 năm kinh nghiệm, tôi vẫn có thể thấy sự hấp dẫn trong việc tự mình làm một cái gì đó. Giải thích mọi thứ cho một người không thành thạo trong ngành đó có thể là một trở ngại rất lớn.

Vậy điều gì sẽ xảy ra nếu cơ sở dữ liệu không được chuẩn hóa hoặc có thể được thực hiện nhanh hơn? Rất nhiều phần mềm không quan trọng (đặc biệt là trong thời đại nhanh nhẹn) tuân theo nguyên tắc wabi-sabi. Nó làm những gì nó cần làm và không còn nữa.

Xin đánh giá cao rằng không phải tất cả các phần mềm phải hét lên cùng với giao diện hoàn hảo, truy cập cơ sở dữ liệu nhanh như chớp và GUI vô nhiễm.

Vấn đề của tôi là, trong khi tôi muốn anh ấy thành công 100%, tôi không nghĩ anh ấy thích hợp để xử lý các loại quyết định này.

Nhà làm phim đã bắt đầu như một cơ sở dữ liệu mà bất kỳ ai cũng có thể sử dụng, và nó vẫn hoạt động rất tốt trong vai trò đó. Nếu cha của bạn biết những gì ông muốn và cảm thấy thoải mái khi đặt nó cùng nhau, bạn lo lắng về điều gì? Nếu nó hoạt động theo cách anh ta muốn, anh ta thắng. Nếu nó không hoạt động theo cách anh ta muốn, anh ta sẽ sửa nó.

Bạn có quyền lo lắng nếu anh ta xây dựng cơ sở dữ liệu cho tất cả các bác sĩ làm việc cho Kaiser Permanente, nhưng nếu anh ta chỉ xây dựng một công cụ để sử dụng trong thực tế của mình thì có vẻ như anh ta có thể chính xác là người phù hợp để xử lý những người này quyết định.

Đừng để hoàn hảo là kẻ thù của tốt.

Lời khuyên của tôi là giả vờ điều này không tồn tại nếu không nó sẽ khiến bạn phát điên. Tôi có một người họ hàng đã làm một điều tương tự với danh sách khách hàng của anh ấy, và những gì anh ấy tự tạo ra là một điều quái dị. Ban đầu tôi đề nghị giúp đỡ và anh ấy nghĩ rằng trích dẫn của tôi (có giảm giá "gia đình" quá lớn) là thái quá. Sau khi xem nó, tôi đề nghị một loạt các thay đổi, mà anh ấy yêu cầu tôi thực hiện để đổi lấy "một vài loại bia". Gia đình hay không, Homie không chơi trò đó. Tôi nói với anh ấy anh ấy nên thuê một người để làm điều đó, nhưng anh ấy không bao giờ làm. Tôi phải loại bỏ hoàn toàn khỏi nó và giả vờ nó không tồn tại, chỉ để giữ cho sự tồi tệ của dự án không ăn thịt tôi.

Bạn nên để anh ấy thử. Tuy nhiên, bạn nên làm cho anh ấy nhận thức được thực tế rằng, khi anh ấy gặp bế tắc, đó là vấn đề của anh ấy và bất kỳ nhà phát triển nào anh ấy quyết định thuê vào thời điểm đó, sẽ phải bắt đầu lại từ đầu.

Tôi thích hack nhiều thứ với nhau, như đồ nội thất và thậm chí cả hệ thống ống nước. Tôi thích nó và tôi thấy không có gì sai với nó. Tôi thậm chí không bao giờ dám yêu cầu một thợ thủ công lành nghề nhảy vào cho tôi khi tôi gặp khó khăn, đơn giản vì tôi nghĩ rằng họ sẽ ném lên khi nhìn thấy những sáng tạo của tôi.

Vì vậy, hãy để cha bạn làm những gì ông thích, nhưng cố gắng để ông hiểu những rủi ro. Chỉ cần giải thích với anh ta, rằng tại một thời điểm nào đó anh ta thuê một nhà phát triển được đào tạo để "chỉ thêm một tính năng nhỏ", nó giống như yêu cầu các thợ thủ công có kinh nghiệm "chỉ sửa một vài thứ" trong một ngôi nhà nơi hầu hết các hệ thống dây điện và ống nước đã được thực hiện với băng keo, lá nhôm, plasticine và đức tin tốt.

ông thấy những loại công việc này là "trẻ em chơi"

Tôi là một nhà tư vấn phát triển của 4 năm

Vì hạnh phúc của riêng bạn và sự phát triển cá nhân của cha bạn, hãy để ông thất bại. Câu trả lời của John rất vững chắc và bạn nên đề cập đủ để cha bạn không hiểu sai về luật pháp, hoặc ít nhất là đủ để ông biết rõ hơn. Nhưng toàn bộ điều "khiêm tốn" này không phải là thứ bạn có thể giảng cho mọi người và mong họ học nó. Đó là một bài học cuộc sống rất quan trọng để cố gắng hết sức và thất bại hoàn toàn. Thất bại là một giáo viên rất mạnh mẽ. Và anh ta có thể có được sự tôn trọng đối với nghề nghiệp của con trai mình.

Và này, nếu anh ta xoay sở để có được thứ gì đó hoạt động đủ tốt (và không vi phạm bất kỳ luật nào), thì tất cả sẽ càng tăng thêm sức mạnh cho anh ta.

Đó là việc của anh ấy. Và nếu anh ấy quyết tâm, anh ấy sẽ làm cho nó hoạt động. Và rất nhiều người đã kết hợp các giải pháp từ các công nghệ khác nhau để làm cho công việc hoạt động.

Cách đây nhiều năm, tôi đã xem lại mã của một người bạn của tôi, người đã kết hợp một ứng dụng web với PHP và một số phần mềm bảng thông báo. Ông đã tùy chỉnh nó rất nhiều để đáp ứng nhu cầu của mình. Mã là một sự gớm ghiếc. Ngoài việc chỉ là dạng bình thường thứ 1, anh ta có các thẻ HTML với dữ liệu trong cơ sở dữ liệu của mình. Không tách MVC. Nhưng Chúa phù hộ anh. Ứng dụng của anh ấy đã hoạt động và anh ấy đã có thể trả các hóa đơn của mình với thu nhập từ trang web đó.

Lời khuyên của tôi cho anh ấy là: Nếu bạn hài lòng với ứng dụng của mình để có doanh thu càng lâu càng tốt, thì đừng tái cấu trúc nó bằng các kỹ thuật thiết kế phần mềm tốt và để yên "đủ tốt". Nếu bạn muốn phát triển ứng dụng của mình để cung cấp nhiều dịch vụ hơn và có thêm doanh thu, thì bạn sẽ phải trả tiền và cấu trúc lại mã. Ông bầu đi với người cũ. C'est la vie.

Nếu bây giờ bố bạn không cảm thấy đau đớn về sao chép dữ liệu và tính toàn vẹn dữ liệu yếu, thì sau này ông sẽ học được giá trị của những gì bạn đang nói.

Tôi nghĩ rằng câu trả lời cho câu hỏi của bạn chủ yếu phụ thuộc vào mức độ quan trọng đối với hoạt động y tế của anh ấy là ứng dụng này. Anh ta sẽ lưu trữ ở đó chỉ một số dữ liệu bệnh nhân mà anh ta thấy hữu ích hoặc bất kỳ trục trặc nào của ứng dụng này có thể gây hậu quả nghiêm trọng? Nếu nó có thể có hậu quả nghiêm trọng thì anh ta không nên làm điều đó nhưng vì chúng ta không sống trong một thế giới hoàn hảo thuyết phục anh ta rằng đó không phải là một ý tưởng tốt có thể là vấn đề hoàn toàn khác.

Vì bạn là một nhà tư vấn phát triển, tôi sẽ đề nghị cung cấp cho anh ta sự giúp đỡ trong QA và quá trình thử nghiệm. Bằng cách này, bạn sẽ giữ mối quan hệ tốt với cha mình vì bạn đang "giúp đỡ" anh ta nhưng đồng thời bạn có thể chắc chắn rằng ứng dụng của anh ta đang làm những gì được cho là phải làm hoặc thậm chí tìm ra một vấn đề mà anh ta sẽ không thể giải quyết vì vậy anh sẽ tìm kiếm giải pháp chuyên nghiệp hơn.

BTW Tôi đã thấy khá nhiều ứng dụng khủng khiếp đang thực hiện công việc của họ và không có lời giải thích tại sao nó khủng khiếp sẽ thuyết phục bất cứ ai thực hiện bất kỳ thay đổi thực sự nào trong đó.

Là một kỹ sư phần mềm mới về hưu cho một nhà cung cấp chăm sóc sức khỏe phi lợi nhuận lớn, tôi mạnh mẽ khuyên bạn nên tìm kiếm một bệnh viện hoặc thực hành lớn gần đó can rằng đối với một mức phí hợp lý cho phép anh ta để chia sẻ hệ thống hồ sơ y tế điện tử của họ đáp ứng các yêu cầu đối với sáng kiến sử dụng có ý nghĩa (và các chương trình khuyến khích khác của chính phủ).

Tôi biết rằng, Epic Epic, ( http://Epic.com ) hỗ trợ khách hàng của họ cho phép các nhà cung cấp nhỏ hơn chia sẻ hệ thống của họ và tôi tưởng tượng một số đối thủ cạnh tranh của họ cũng làm như vậy. Cerner là đối thủ cạnh tranh lớn nhất của họ, nhưng một số người khác được thảo luận tại http://www.beckershospitalreview.com/healthcare-inif-tĩ/50-things-to-ledge-about-epic-cerner-meditech-mckesson-athenahealth-and- other-Major-ehr-Investors.html

Có 75% trợ cấp từ CMS cho loại chia sẻ đó. Chúng tôi đã chuyển tiền trợ cấp cho khách hàng bằng cách thực hiện giá thuê bao 25% chi phí của chúng tôi.