I have worked for a company developing HMS/EHR and a hospital implementing/integrating these systems.
Before you think "my startup can do better" understand the core problem: legal and actual processes. Medical is heavily regulated, not only at the point of care, but likewise on the administrative side.
In the event of an adverse effect the hospital and medical team(s) involved must be able to provide clear track record of following the protocols. The administrative team must have the data to provide all the required metrics.
Suppose a simple bloodwork protocol: nurse draws blood, delivers to lab, lab does analysis, results are funky, lab releases invalid report indicating rejected sample, doctor issues redoing of bloodwork, nurse draws blood again and so on. Sample rejection is recorded somewhere, distorts statistics for admin, costs time. In practice, in the event of suspected badly drawn sample nurse is internally informed of that to redeliver the sample, lab releases clean report, sample vial is recorded as discarded by nurse, business goes on.
Medical is FULL of these tiny optimizations around protocols. However, any HMS must follow the protocol, implement safeguards against divergence from protocol, yet to be user friendly it must accommodate all those deviations while still providing "correct" track record with eventually consistent timestamps and so on.
Timings can be very important. For example at ER priority levels dictate not only queue ordering, but also time to care. With HMS implemented it becomes crucial to record times correctly (both from CYOA and metrics standpoints), therefore from the perspective of user, the HMS becomes first priority over caring for patient. Users inevitably complain :)
In certain protocols timings also play a huge role in determining care type. Discharge a patient in x hours and it is outpatient care, fail to discharge patient in x hours and the case promotes to inpatient care, with all the associated complexities of care and documentation. Patient returns in x hours - it's the same case. Fail to provide care in x hours - different treatment protocol.
Readers may think "just provide sane defaults for common case and let staff explicitly record uncommon cases". That simply does not work. Defaults are defaults and users submit defaults. Having insane defaults actually prevents hospital admin/it/legal from being overwhelmed with correcting submitted data. Users complain.
It's ugly. You have to juggle between good care, actual processes, legally required processes, metrics and what not to make the system usable and correct where every user is adversary.
EDIT to add:
On top of all that, every hospital has unique implementation of processes and structures. The differences may not necessarily be major, but there are differences.
Any HMS that intends to become a commodity instead of custom project for a single hospital or department must be highly customizable. first, high customizability typically misses optimization (especially workflow optimization) opportunities. Second, implementing HMS is akin to implementing SAP: the end result is amalgamation between core product developed by a vendor and implementation by hospital admin/legal/it. Many here have either first-hand experience or close knowledge why implementing ERPs (HMS is an ERP) typically lead to barely usable monstrosities. The stakeholders at organization typically have neither working understanding of underlying processes and policies and how they tie together nor will to implement processes and policies more suitable to be managed via ERP.
Before you think "my startup can do better" understand the core problem: legal and actual processes. Medical is heavily regulated, not only at the point of care, but likewise on the administrative side.
In the event of an adverse effect the hospital and medical team(s) involved must be able to provide clear track record of following the protocols. The administrative team must have the data to provide all the required metrics.
Suppose a simple bloodwork protocol: nurse draws blood, delivers to lab, lab does analysis, results are funky, lab releases invalid report indicating rejected sample, doctor issues redoing of bloodwork, nurse draws blood again and so on. Sample rejection is recorded somewhere, distorts statistics for admin, costs time. In practice, in the event of suspected badly drawn sample nurse is internally informed of that to redeliver the sample, lab releases clean report, sample vial is recorded as discarded by nurse, business goes on.
Medical is FULL of these tiny optimizations around protocols. However, any HMS must follow the protocol, implement safeguards against divergence from protocol, yet to be user friendly it must accommodate all those deviations while still providing "correct" track record with eventually consistent timestamps and so on.
Timings can be very important. For example at ER priority levels dictate not only queue ordering, but also time to care. With HMS implemented it becomes crucial to record times correctly (both from CYOA and metrics standpoints), therefore from the perspective of user, the HMS becomes first priority over caring for patient. Users inevitably complain :)
In certain protocols timings also play a huge role in determining care type. Discharge a patient in x hours and it is outpatient care, fail to discharge patient in x hours and the case promotes to inpatient care, with all the associated complexities of care and documentation. Patient returns in x hours - it's the same case. Fail to provide care in x hours - different treatment protocol.
Readers may think "just provide sane defaults for common case and let staff explicitly record uncommon cases". That simply does not work. Defaults are defaults and users submit defaults. Having insane defaults actually prevents hospital admin/it/legal from being overwhelmed with correcting submitted data. Users complain.
It's ugly. You have to juggle between good care, actual processes, legally required processes, metrics and what not to make the system usable and correct where every user is adversary.
EDIT to add:
On top of all that, every hospital has unique implementation of processes and structures. The differences may not necessarily be major, but there are differences.
Any HMS that intends to become a commodity instead of custom project for a single hospital or department must be highly customizable. first, high customizability typically misses optimization (especially workflow optimization) opportunities. Second, implementing HMS is akin to implementing SAP: the end result is amalgamation between core product developed by a vendor and implementation by hospital admin/legal/it. Many here have either first-hand experience or close knowledge why implementing ERPs (HMS is an ERP) typically lead to barely usable monstrosities. The stakeholders at organization typically have neither working understanding of underlying processes and policies and how they tie together nor will to implement processes and policies more suitable to be managed via ERP.