4 ms·

> As far as I can tell, there's no economic incentive for health care systems to undergo these transformations willingly Yes. Thing is, say you have shitty sof

> As far as I can tell, there's no economic incentive for health care systems to undergo these transformations willingly Yes. Thing is, say you have shitty software and see 20 patients in one day. Say you have fantastic software - you'll probably still only see 20 patients a day. The cost of upgrading is usually not justified if it doesn't hit the bottom line. I'm trying to tackle this by making a system where improving it isn't a huge risk, or cost. For example, it has an extensible user interface - imagine something like atom text editor, or even browser extensions. Say you look at the immunization screen all day, and hate it. Find / build a small extension to arange it how you want, without changing any of the back-end system, and then share it to a registry for other people in your situation. Easy win. I'm actually designing this system within the context of primary care in New Zealand. We have a socialized healthcare system, which is honestly very effective. Everybody pays for it via tax, and resources are evenly distributed. We even bulk purchase generic drugs for the entire country. There isn't so much of an evil incentive to ensure all their 'customers' stay sick, but instead funding is a bit hard to come by. Funding happens regionally, and building national healthcare software systems is a huge task nobody but the government is willing to try. The market is so small (population of 4mill) that vendors can usually make more money elsewhere - so getting NZ tailored solutions is rare. This is why I think the opportunity is in making a crowdsourced system, as opposed to a 'product' to sell.

fny 10y ago
I have no idea what the market is like in New Zealand, so my insights there are limited, but a lot of EMR systems in the US have a similar notion of customizability built into the interface. Epic, the largest EHR vendor in the US, for example, doesn't sell a one size fits all solution. Hospitals develop their own GUIs and workflows within Epic, but again, hospital administrators make all the UX/UI decisions while optimizing for documentation that bolsters billing. Again, the doctors lose. For small practices, this might be a viable solution, but then again, they'd probably rather purchase a complete IT solution than something that handles medical records alone. Also, have you looked at OpenMRS?[0] They have a module system that allows you to develop extensions to the EHR.[1] If you're looking for your thesis to have a big impact, I'd really recommend getting in touch with an organization like OpenMRS or Partners Healthcare to see how you can extend their platforms. If you want an introduction, drop me a note: faraz dot yashar at the gmail. [0]: https://openmrs.org https://openmrs.org [1]: https://modules.openmrs.org/ https://modules.openmrs.org/
- ryanSrich 10y ago
  The reason why so many EHRs are poorly designed is in part because they are so flexible. Don't under estimate the ego of a physician to think their way is superior to the way the doctor down the road does something. The EHR model will eventually lose because its one sided. Consumers and patients are completely left out of the picture and EHRs have no incentives right now to change. Beyond that companies like Epic are operating on outdated business models. The days of the black box of data that lives inside the four walls of the health system are numbered. Consumers won't deal with a dumpster fire of technology once they have the choice. Digital health will win once the barriers of compliance and interoperability are broken down.
  - iheartmemcache 10y ago
    SQL has 'interoperability' re: an ANSI standard. Theoretically you should be able to get off all those old Oracle contracts right? Eventually there are little nuanced things that users end up building their workflow completely around. Even if you change no functionality and just slightly alter the GUI, you're going to have complaints that something is broken. Inertia is your #1 vendor lock in feature. EPIC is as golden as Oracle just due to resident incumbency. #2 is the whole risk aversion thing. Any platform migration is going to have political risk attached to it. Nike won't move away from Oracle even if Postgres can do everything it can line for line because paying the $200k maintenance fee each quarter is a cheap recurring cost compared to the political risk of a failed project. That's not even factoring in #3, the little features here and there which are value-adds to the platform and not part of the standard. I've inherited projects where my firm offers to support O&M for some poorly written ASP 1.1 Classic software. We'll go in, patch some business-logic bug, and get a phone-call later that afternoon asking to rollback our fix. Turns out their users had integrated bugs into their workflow such that when the software operates "properly" (i.e. 'to spec') it actually breaks things (i.e. stops operating in an expected fashion).
    - fny 10y ago
      While I strongly agree with points 2 and 3, SQL standards are useless when hospitals invent their own schemas and data governance. Looking for serum creatinine? Good luck without local knowledge. There are probably 30 tables (not exaggerating) for that lab, and the closest you can get without chasing 7 people for info is grepping all the table names for "/CREA/".* *Based on a true story.

fny 10y ago

I have no idea what the market is like in New Zealand, so my insights there are limited, but a lot of EMR systems in the US have a similar notion of customizability built into the interface. Epic, the largest EHR vendor in the US, for example, doesn't sell a one size fits all solution. Hospitals develop their own GUIs and workflows within Epic, but again, hospital administrators make all the UX/UI decisions while optimizing for documentation that bolsters billing. Again, the doctors lose. For small practices, this might be a viable solution, but then again, they'd probably rather purchase a complete IT solution than something that handles medical records alone. Also, have you looked at OpenMRS?[0] They have a module system that allows you to develop extensions to the EHR.[1] If you're looking for your thesis to have a big impact, I'd really recommend getting in touch with an organization like OpenMRS or Partners Healthcare to see how you can extend their platforms. If you want an introduction, drop me a note: faraz dot yashar at the gmail. [0]: https://openmrs.org https://openmrs.org [1]: https://modules.openmrs.org/ https://modules.openmrs.org/

ryanSrich 10y ago
The reason why so many EHRs are poorly designed is in part because they are so flexible. Don't under estimate the ego of a physician to think their way is superior to the way the doctor down the road does something. The EHR model will eventually lose because its one sided. Consumers and patients are completely left out of the picture and EHRs have no incentives right now to change. Beyond that companies like Epic are operating on outdated business models. The days of the black box of data that lives inside the four walls of the health system are numbered. Consumers won't deal with a dumpster fire of technology once they have the choice. Digital health will win once the barriers of compliance and interoperability are broken down.
- iheartmemcache 10y ago
  SQL has 'interoperability' re: an ANSI standard. Theoretically you should be able to get off all those old Oracle contracts right? Eventually there are little nuanced things that users end up building their workflow completely around. Even if you change no functionality and just slightly alter the GUI, you're going to have complaints that something is broken. Inertia is your #1 vendor lock in feature. EPIC is as golden as Oracle just due to resident incumbency. #2 is the whole risk aversion thing. Any platform migration is going to have political risk attached to it. Nike won't move away from Oracle even if Postgres can do everything it can line for line because paying the $200k maintenance fee each quarter is a cheap recurring cost compared to the political risk of a failed project. That's not even factoring in #3, the little features here and there which are value-adds to the platform and not part of the standard. I've inherited projects where my firm offers to support O&M for some poorly written ASP 1.1 Classic software. We'll go in, patch some business-logic bug, and get a phone-call later that afternoon asking to rollback our fix. Turns out their users had integrated bugs into their workflow such that when the software operates "properly" (i.e. 'to spec') it actually breaks things (i.e. stops operating in an expected fashion).
  - fny 10y ago
    While I strongly agree with points 2 and 3, SQL standards are useless when hospitals invent their own schemas and data governance. Looking for serum creatinine? Good luck without local knowledge. There are probably 30 tables (not exaggerating) for that lab, and the closest you can get without chasing 7 people for info is grepping all the table names for "/CREA/".* *Based on a true story.