I would agree with this. The actual tech isn't all that difficult, you just need a very large and flexible database with a functional front-end, detailed process automation and business rules, hardened security, and high reliability. All very well-worn and established elements that can be found pretty readily even in the open source software space. It's the aforementioned integrations, as well as the overall implementation, that will be seriously difficult, especially with all of the unique requirements, extensive compliance, and regulatory pressures that make the kind of software development oversights that might be embarrassing in less complex projects potentially criminal here, or at the very least very damaging and expensive for the developers, their customers, and possibly even their customers' patients.
So the development of any given ePHI system is very high-risk, exceedingly tedious, difficult and time-consuming (aka, expensive), and from my own experience as an I.T. consultant, the potential customer base is going to be full of healthcare orgs who are likely already entrenched within an existing solution, one that has likely been integrated with several other operational services, and one that the lead will almost certainly be very reticent to switch from, considering the huge workload, expense, and disruption to routines that such a migration necessarily involves. That means it could take a very long time to pull in new customers, so you'll need deep cash reserves to maintain development and operational budgets while the initial sales, onboarding, and subsequent support takes place.
I have gone through such a migration process for a very small healthcare provider, and even in a small clinic with a single doctor, it was extremely involved. I am a fierce proponent of open source software and a DIY ethos, but at least in this specific genre of software, I think the larger established players are ultimately the only ones adequately prepared to pull it off properly.
So the development of any given ePHI system is very high-risk, exceedingly tedious, difficult and time-consuming (aka, expensive), and from my own experience as an I.T. consultant, the potential customer base is going to be full of healthcare orgs who are likely already entrenched within an existing solution, one that has likely been integrated with several other operational services, and one that the lead will almost certainly be very reticent to switch from, considering the huge workload, expense, and disruption to routines that such a migration necessarily involves. That means it could take a very long time to pull in new customers, so you'll need deep cash reserves to maintain development and operational budgets while the initial sales, onboarding, and subsequent support takes place.
I have gone through such a migration process for a very small healthcare provider, and even in a small clinic with a single doctor, it was extremely involved. I am a fierce proponent of open source software and a DIY ethos, but at least in this specific genre of software, I think the larger established players are ultimately the only ones adequately prepared to pull it off properly.