3 ms·

That's imprecise shorthand on my part. s/"FANG Calibre"/"objectively talented and used to/capable of negotiating good compensation"/. There's a degree of Stockh

That's imprecise shorthand on my part. s/"FANG Calibre"/"objectively talented and used to/capable of negotiating good compensation"/. There's a degree of Stockholm Syndrome in healthcare tech where people don't know what a well-developed product or codebase looks like. It's unlikely to change from the top, so getting more technical folks with higher leverage into the field is IMO the next-best option. And yes things are changing at a glacial pace, but they are changing. For example, my province is developing a new patient portal [1] out in the open. AFAICT, they seem to be doing everything aboveboard: CI, code quality standards, documentation and proper testing, etc. Yet if you look at another team in the same org (ministry of health), you'll find non-existent dev practices, oodles of VBA, or (even worse) some slow+buggy third party system put in place by one of the procurement vampires (IBM, CGI, Deloitte, you know the bunch). The biggest difference? The former project has a dedicated, US Digital Service-style team of skilled and hopefully better-compensated dev(ops) people who know how to deliver good software. [1] https://github.com/bcgov/healthgateway https://github.com/bcgov/healthgateway

sidlls 6y ago
I think, in fact, you have it exactly backwards. You are very unlikely to find a decision making authority (person or committee) in a medical practice who gives the slightest bit of consideration for the development practices or code quality of software they're considering. These people have three things on their mind (in no particular order): 1) does this product meet this organization's requirements under our regulatory compliance policies; 2) does this product (including installation, maintenance, and training costs) fit within my budget; 3) is this product widely known and trusted by my peers at other medical practices. Notice something? The word "software" doesn't appear in that even once. They literally don't care. The result is that companies develop products (software) on the cheap, and that results in the quality issues that exist. Improving the quality of the code base and development practices is solving a problem the purse-holders (customers) don't have.
- BadInformatics 6y ago
  I agree that all the factors you've listed are in play, but they are far from the only ones involved in decision making. Perhaps this is a regional thing, I've never experienced (and have no wish to) what the US EMR market is like. Some complaints/feedback I did receive from doctors and clinic admins while working for an EMR vendor: 1. Your system is buggy/unintuitive and we hate using it. 2. We're not upgrading or moving to your new system because of 1). 3. We're moving to competitor X because they have Y feature. 4. [conversely] We came from competitor X because their EMR is slow/buggy/lacks features. 5. We signed up because the docs/office assistants liked [hero feature] in the sales demo. So yes, 0 mentions of the word "software". However, all of these are directly related to the software itself. There's a reason flashy new companies can swoop in and steal some market share (at least where I am). Even more importantly, there are many tech-related reasons why some companies start floundering and drop out of the market: - bad foundations (most EMRs were created by doctors with limited dev experience) - rampant tech debt driven by feature-driven development - lack of knowledge about testing/CI These are not theoretical problems. More than once, we incurred regulatory fines and SLA penalties in excess of the "cost of doing business" threshold. After a pretty major patient data screw-up, upper management even relented and gave the dev(ops) team time/money to clean up their act. Regulatory and bureaucratic inertia may insulate health IT companies from software engineering issues, but there's a limit to everything and they can sure as hell bleed.

sidlls 6y ago

I think, in fact, you have it exactly backwards. You are very unlikely to find a decision making authority (person or committee) in a medical practice who gives the slightest bit of consideration for the development practices or code quality of software they're considering. These people have three things on their mind (in no particular order): 1) does this product meet this organization's requirements under our regulatory compliance policies; 2) does this product (including installation, maintenance, and training costs) fit within my budget; 3) is this product widely known and trusted by my peers at other medical practices. Notice something? The word "software" doesn't appear in that even once. They literally don't care. The result is that companies develop products (software) on the cheap, and that results in the quality issues that exist. Improving the quality of the code base and development practices is solving a problem the purse-holders (customers) don't have.

BadInformatics 6y ago
I agree that all the factors you've listed are in play, but they are far from the only ones involved in decision making. Perhaps this is a regional thing, I've never experienced (and have no wish to) what the US EMR market is like. Some complaints/feedback I did receive from doctors and clinic admins while working for an EMR vendor: 1. Your system is buggy/unintuitive and we hate using it. 2. We're not upgrading or moving to your new system because of 1). 3. We're moving to competitor X because they have Y feature. 4. [conversely] We came from competitor X because their EMR is slow/buggy/lacks features. 5. We signed up because the docs/office assistants liked [hero feature] in the sales demo. So yes, 0 mentions of the word "software". However, all of these are directly related to the software itself. There's a reason flashy new companies can swoop in and steal some market share (at least where I am). Even more importantly, there are many tech-related reasons why some companies start floundering and drop out of the market: - bad foundations (most EMRs were created by doctors with limited dev experience) - rampant tech debt driven by feature-driven development - lack of knowledge about testing/CI These are not theoretical problems. More than once, we incurred regulatory fines and SLA penalties in excess of the "cost of doing business" threshold. After a pretty major patient data screw-up, upper management even relented and gave the dev(ops) team time/money to clean up their act. Regulatory and bureaucratic inertia may insulate health IT companies from software engineering issues, but there's a limit to everything and they can sure as hell bleed.