Please please please go into these areas with humility. Having worked for health tech companies in SF for a decade, I've seen so many people come from Google/Facebook/Mozilla/Ticketmaster/eBay to healthcare in order to "disrupt" and "fix" it. Their disruption or fixes are many times illegal, impractical, vaporware, or completely ignore industry standards and so can't speak the same language as all the other tools in the ecosystem. It generally doesn't end well if you don't deeply partner with stakeholders and domain experts.
What's that about?
A good way to approach is to partner with a domain expert to understand the following aspects.
1. Know about various stake holders that make up a business process. Understand each of their incentives. Some actors standout explicitly but some do not, such as regulators.
2. The value add by different player/stake holder in the chain.
3. Location of power centres. No one will explicitly call it out but you will be able to figure it out.
Also, at the end of the day automation is making someone (or part of someone) redundant. Make sure you identify that person and be subtle about your messaging to them.
All of this takes time so in olden days there used to be a role called "system analysts". Their job was to go deep into the problem domain, untangle all the above for you and help you define product. These analysts are typically ex-workers in the same domain so they have seen everything first hand. Given the nature of their job their role is not fungible in that you can't take one person and make them move around to be system analyst in different domains. Somewhere along the way system analyst role disappeared and they were replaced by fungible "product managers". These PMs have a generic set of product development skills such as UX, user retention optimisation etc., But they lack the domain knowledge. And they are expected to be fungible. If a PM changes job once every 3 years into a different domain they can at best do a superficial job.
Of the top of my head here are two examples.
There's this software called Docon (https://docon.co.in) used by small-setup medical doctors and physicians. The value add for doctors is very clear. It saves them time and all the hassle. What is good about Docon is it requires zero actions by the patient or any one else. So Doctors are happy to be using it. It is a nifty little tool to automate key parts of doctors' workflow.
Now let me talk about JIRA. It is mainly targeted towards management and execs. Because, let's face it, they have a genuine problem of not having clear view into project development state. They can't see how their quarterly projects are shaping up at different zoom levels. To that end I would say JIRA does a reasonably good job. Where JIRA fails spectacularly is it requires leaf level works to massively disrupt their workflow. Not only does it require them to use JIRA for daily updates and what not it also forces a way of agile development which comes with its own set of baggages.
True many startups in health are trying scammy payment models, but hospital bills often aren't much better unfortunately.
Personally my life has been positively improved by 23andme when they could still list health research, or by "zany" microbiome/probiotics startups years before the medical establishment caught up. Obviously these fields should be regulated, but properly so without just providing an excuse for regulatory capture for existing players.
0: https://www.nytimes.com/2021/07/19/health/alzheimers-drug-ad... 1: https://www.crossfit.com/health/the-great-statin-scam-time-t... 2: https://www.vox.com/the-big-idea/2017/12/28/16823266/medical... 3: https://www.theatlantic.com/health/archive/2017/02/when-evid...
Faxes are common in healthcare, and it's a common punch line from newcomers. But there's a series of standards that have been iterated on since the late 80s/early 90s that are finally getting to a place where they can eliminate faxes. There's standards for how to transmit data between EHRs, standards for how to store and represent data, and a standard API for 3rd parties to be able to write/read that data.
Regardless of these standards, you can already share data between hospitals using the same EHR -- so epic-to-epic (epic is the largest EHR vendor in the US) data sharing has been happening for a decade without any faxes. Unfortunately, there's a ton of different players in this game, so getting to a place where everyone has adopted the standards takes a long time, and the system still needs to keep running while this switch happens. To be clear, this is a common problem throughout tech: is it possible to run a native android app on iPhone? Do you think Google and Apple will ever make it possible to do that?
I can think of at least one medical company that builds their own technology and managed to paint themselves into a corner by not working from within the system. They just hire a bunch of engineers, who hear about how faxes run healthcare, so they say "cool, I can digitize the faxes" without bothering to consider or learn about other standards that are being developed. This leads to proprietary data models, with proprietary data representation, all transmitted using outdated technology. The engineers quit and go back to non-health tech, and tell their friends that health tech is so frustrating because it's so dated (make sure to bring your fax machine when you start your new job!).
But, really, the problem was never faxes. The problem is that healthcare is way more complicated, with way more stakeholders than consumer tech. You can't just launch a new product and iterate on the bugs later; people's lives are at stake, so the whole industry is heavily regulated. But if you enter with humility, recognizing that there is too much information for one person to know, but know that your skills are welcomed and needed. Take time to learn about things like HL7, FHIR, and clinical ontologies. And partner-- not just a quick knowledge sharing session-- actually partner with the domain experts, then there's a whole world of fascinating possibility out there.
Now the heart of that is 5 lines of python. It could be written by anyone after a days "starting from zero" coding experience.
But actually solving that in real world is a mess of just trying to access the data - it's her data and she only wants to see her bits. But the level of effort is ridiculous.
Anyway my point is that solving problems like software for doctor's offices is not the point - that's just building another silo. A doctor who has (secure) access to a industry wide common open data layer can do all the work to run their office themselves.
In short we are trying to solve the wrong problem - usually because proprietary code is not a profitable as proprietary data
Bingo. This is why Google et al. would never sell your data; they just keep it for themselves and merely sell to advertisers the ability to precisely target you (“pick a demographic down to the shampoo brand and we can target your ads to it”). But those advertisers (or anyone else) will never see a single iota of your data. It’s simply too valuable.
Next, when you click an ad, the advertiser knows which medical problems you have (because that's where they targeted their ad at).
Google has a data leak, and nobody seems to care about it.
Square is not the only player doing service appointment payments.
But we (society) should have a standard representation of a calendar event, standard access to bank accounts and so on so that all she needs to go is write five lines
Once the data is free we won't need proprietary co e
I have a brick and mortar small business that takes appointments, have monthly recurring services and did not use Square appointments. We did everything manually to handle calendar appointments, invoice, charging for payments. Found out after a few months the time is not worth the savings and rather just get a service like Square. I thought maybe his client was the same and was trying to help.
But hey maybe Square was very obvious for your brick and mortar service based business and I'm one of the few "ignorant and stupid one".
I don't think he was necessarily saying that you should sacrifice yourself to your own idea of the pointless "greater noble good".
Build a stamp database, an app to record baseball cards, automatically conjugate latin verbs, make a recipe database that can give you a list of what can be made with a given set of ingredients, make a 3d anatomical viewer based on the BodyPart3D database, make a catalog of open source projects for a given combination of JavaScript technologies, make a periodic table that shows the 3D orbital structure of the atom involved, calculate and visualise knitting patterns, simulate an H-Bomb or global thermonuclear war...
Do it in Golang, write it in Rust or Haskell or PHP, or with a shell script if you have to...
Run it on baremetal, on a VM, in a unikernel, deploy it in a k8s cluster, or nomad, or docker-compose or host it on a microcontroller if that fits...
But for a change focus on the problem and not the tools.
This is basically an education / culture problem. I'm sure in two hundred years, people will recognize that 'sort' or 'uniq' is really elemental functionality like a saw or a hammer, and baking it all into one giant saw-hammer-sanding machine that's really only good for making tables, and occasionally eats your cat, is just not the way to go. Until that point, I don't think that some plucky new startup is going to magic away all the problems. I mean, obviously there are some crazy low-hanging fruit out there, but the fundamental issue starts with how people are using computers in the first place.
I'm currently building a company that is replacing Excel at some of the biggest commercial real estate firms, which is "impossible" by your standards.
Or NASA when Lee Deforest claimed flight to the moon was impossible "regardless of all future advances."
Or when Einstein claimed ""There is not the slightest indication that nuclear energy will ever be obtainable."
Etc. etc.
Not to be pedantic, but was Einstein incorrect at that time/in the future? Were there any actual indications that nuclear energy would be obtainable at that time?
Einstein didn't seem to say, "Obtaining nuclear energy is absolutely impossible, and can never be achieved." All he said was that there is not the _slightest indication_.
I am sorry if this comes off as being semantical, but I just want to make sure I am not misinterpreting you or what Einstein said.
As for the other points, yes. Those were great examples.
The quote is of course completely out of context, and looks a lot like something one throws at annoyingly overeagle people. Also, I imagine the context for saying it only existed because nuclear fission seemed perfectly plausible and just over the horizon. It was technically correct, nobody could imagine a Manhattan Project at that time, and it wasn't obvious that it was even possible, but there was a clear possibility.
That’s exactly the point. And yet the Manhattan project was less than a decade away.
Lord Kelvin said his quote in 1895. Deforest said his in 1926. In the myopic timeframe they were all technically correct.*
The GP stated that all those other problems were “obviously” intractable, but whose to say they won’t be solved under some ambitious effort in the next 20 years?
*Aside: All three examples come from the same place in terms of being plausible in the timeframe they were made yet wrong in hindsight. I wonder if people are more fiercely defending the Einstein quote because he’s more revered in popular culture. It’s interesting that his quote is the only one being defended.
I guess my point is only that all those famous quotes probably just meant "shut-up and give me some space, journalist, I have some immediately pressing problems to solve", and probably nobody undesrtood them as anything else at the time too.
Anyway, my favorite of those is the Michelson's famous "physics is complete" one, that basically meant "let me do the experiment first, then we can talk about the results", but is excellent out of context.
It may be fair to read it as a scientist essentially saying "we have no evidence it's possible." But as I read it, the addition of "ever" came across as saying he thought it was an unsolvable problem rather than one that had yet to come upon a solution.
Amazing book by the way, there was a cheap reprint published a few years ago.
It’s easy and weak to just throw up ones hands and say it’s too hard but I don’t want to live in a society where 100% of people take that approach.
"Build software for doctors' offices and medical groups!"
A problem that needs to be solved is _____________?
"Help lawyers crawl out of their low-tech holes!"
A problem that needs to be solved is _____________?
"Work on software to revolutionise public classrooms!"
A problem that needs to be solved is _____________?
Let us know when can provide even a single answer to any of these questions.
As other commenters point out, answering them means actually talking the people who will be using the software, or working in their shoes in these industries, before anyone starts programming anything.
If anyone is interested I recorded a 90 minute podcast with a lead developer + ops engineer who created a custom electronic medical record system for an Ophthalmology clinic (eye care).
It's at: https://runninginproduction.com/podcast/99-a-custom-electron...
We talked all about using Rails to help consolidate 9 separate 3rd party solutions into a monolithic server rendered Rails app that the clinic uses internally to manage all of their patients. We also chatted about transitioning from Elastic Beanstalk to self managed EC2 instances to using Kubernetes with EKS.
Development is a nightmare