๐ช๐ต๐ฎ๐ ๐ฃ๐ฟ๐ผ๐ฑ๐๐ฐ๐๐ถ๐ผ๐ป-๐ฅ๐ฒ๐ฎ๐ฑ๐ ๐ ๐ฒ๐ฎ๐ป๐ ๐ณ๐ผ๐ฟ ๐๐ฒ๐ฎ๐น๐๐ต๐ฐ๐ฎ๐ฟ๐ฒ ๐ฆ๐ผ๐ณ๐๐๐ฎ๐ฟ๐ฒ
A small bug in most apps causes an inconvenience. In healthcare software, a bug costs lives.
We audited our systems to find what makes software safe for clinical use. Here are the lessons we learned.
Use medical standards, not opinions. Our early vital-sign alerts used custom ranges. We realized custom ranges are dangerous. We moved all thresholds to the NEWS2 standard. Do not invent your own constants in a regulated field. Use established medical scores.
Fix your time logic. We used UTC for daily reports and billing. This caused issues with local facility reporting. We moved all systems to roll over at the local midnight of each facility. You must account for Daylight Saving Time changes.
Let the database enforce truth. Two requests might try to admit the same patient to one bed at the same millisecond. Application code often fails to catch this race condition. We added a partial unique index in Postgres. This allows the database to reject the second write. Application guards provide error messages. The database provides truth.
Test for security failures. We performed adversarial audits. We logged in as one user role to try and read data from another. If a user tries to access data they do not own, the system should return a 404 error instead of a 403 error. This prevents attackers from knowing a record exists.
None of these technical fixes make for a good marketing screenshot. We prefer to be slow and correct rather than fast and sorry.
We are building BioMedixAI in public. We will share more notes as we progress.
Source: https://dev.to/nazmulhd10/what-production-ready-actually-means-for-healthcare-software-2ei3