This isn't my first insurance company. The typical experience in insurance is that those tools mostly only come out once someone already has the expensive probl

This isn't my first insurance company. The typical experience in insurance is that those tools mostly only come out once someone already has the expensive problem, and are used to manage the cost of it after the fact, rather than prevent it from happening in the first place. Also most insurance companies aren't really set up to do preventive work to the extent we do (which involves home visits from nurses and other clinical staff, staying in touch and proactively reaching out when there seem to be problems, etc. etc.), largely because they consist of essentially competing divisions which each own a subset of the data and responsibilities and jealously guard against every other division. I worked in a company like that, once upon a time -- everyone had very clearly-defined limits to their responsibilities (well beyond what privacy rules required) and even just contacting someone in a different department to make them aware of a problem or pass along a suggestion would trigger turf-war consequences. I'm very happy to now be working with the opposite of that. Finally, it's worth noting that although there are a lot of dismissive comments about tech in this thread (and some of it I can understand -- most of what we do is internal-facing and harder to promote as a result), the perspective inside is pretty different. It's true there's not a ton we're doing that's cutting edge and "sexy" tech (though we have open-sourced some neat tools for temporalizing SQLAlchemy's ORM), but that's because health care hasn't yet caught up to just the boring everyday things we take for granted. There's an example that really drove it home for me, from about six months ago. Claims are obviously a big part of what we're about, and so we have an internal team that reviews processed claims for accuracy. They have to check against a pretty complex set of Medicare claim-processing rules, part of which involves rules about combinations of medical procedures (i.e., Procedure A might be allowed but only if alongside Procedure B, or A might only be allowed without B, or A and B might just be independent and can both appear or not appear). The canonical source for that data is... gigantic Excel spreadsheets of all the procedure codes and rules. And so the claims-review team would open up Excel, type in a code, wait five minutes while it churned to find the code, then repeat for the next code, etc. An engineer saw this and spun up a two-day project to ingest those spreadsheets (on an ongoing basis, since they change over time) into a database and wrap a search interface around them which allowed punching in all the codes and getting back a list of rules and an indicator of whether they'd been violated. To tech people that's so mundane it almost puts you to sleep, and makes you say "wait, that's it?". But to healthcare people, it was a gigantic step forward. So many people from health backgrounds came from places that never let them work side-by-side with tech staff and figure out what was possible (or where all tech was outsourced to vendors with opaque planning and feature-request processes), which is why so much of healthcare tech feels decades out of date. So just having tech and medical/insurance people in the same room, working and talking together every day, acts as a pretty impressive multiplier compared to traditional insurance companies.