
Doctors ask engineers to spend more time in the hospital before building apps - brandonb
https://www.cnbc.com/2018/12/27/doctors-are-asking-technologists-from-google-to-shadow-them-before-they-build-medical-apps-.html
======
oomkiller
Unfortunately the problem is much greater than engineers not understanding
doctors and other clinical staff, in my experience. For startups that want to
sell to health systems and similar-sized/larger entities (really this is the
minimum size that can work for most startups, practice sales usually have more
friction than value), you unfortunately have to focus on the buyer, which is
very rarely someone who is "in the trenches." Best case scenario, having
software that is compelling to the end users can help you get your foot in the
door early on, but actual adoption will only happen if you can convince the
business stakeholders of your value.

In the US healthcare system, clinicians and the business often have opposing
objectives and values. This is starting to change with value based care
becoming more popular, but it's still all about providing what the business
wants, it just happens to align with the clinicians more these days. You'll
still need to support IE9 due to that botched Vista upgrade, build out a
custom EMR integration, and deliver whatever random feature the sales folks
promised (can you automatically fax things?) before you can move on to the
features that the clinicians actually want.

The system itself is how we ended up with billing-driven documentation EHRs
like Epic. Paradoxically, due to massive adoption, I think Epic and Cerner are
some of the only places where real innovation could happen. I think even huge
companies like Apple, Amazon, and Google will have a hard time breaking into
the space, no matter how much cash they throw at it. For them, the only answer
is to go fully vertical like Kaiser-Permanente, but I doubt they have the
stomach for this.

~~~
analog31
I'm sure I'm being naieve, but could we just get rid of billing altogether if
we nationalize the health care system? I have to recount an anecdote. My mom
was hiking in a foreign country, and got injured. She hobbled to the next
town, and found a clinic. They treated her and were ready to let her go. She
said:

Q: Okay, how do I pay?

A: You don't _pay_ for health care.

Q: I'm American. I'm not part of your health care system.

A: That's all well and good, but we have no way of knowing how much to charge
you, how to take your money, or where to send it. Have a nice vacation.

The clinic probably maintained some accounting records, but they simply had no
billing system.

~~~
ams6110
Somebody will be paying, and will want adequate and auditable documentation
about what they are paying for. The potential for fraud is too great. Medicare
and states all have to watch for fraud in their claim payments.

~~~
SolarNet
Sure, but adequate and auditable documentation need not involve the patient
nor money. Just a "here is the medical care we dispersed, on this date, to
this person, it took these resources, these people administered the care." No
following up every record for payments, no arguing with insurance companies
over the price.

And also, what abuse? If medical care is free and drugs are cheap, the only
real abuse is drug abuse (by either seekers or medical personnel). With free
access to proper care those drug abuse problems will sharply decrease, killing
the market (the cause of the other half of drug abuse).

The only reason there is medicare fraud to worry about right now is because
not everyone is supposed to be on it, the "fraud" is attempting to get free
health care. Which wouldn't exist if everyone had it.

~~~
chii
> And also, what abuse?

a clinic could mis-report (over-report?) how many patients they treated,
and/or the procedure. They can then claim back more money than they actually
spent, netting easy profit.

~~~
emilfihlman
Solved by not allowing money to enter the circle. Results in you needing to
sell the drugs/things you overcount on, which is rather easy to track and find
out.

~~~
jdminhbg
> Solved by not allowing money to enter the circle.

This is not possible without socializing the entire economy. At some point,
you have to pay doctors, nurses, staff, equipment manufacturers, etc.

~~~
chobeat
If they are public employees, they have sort of a standardized salary coming
straight from the healthcare ministry/department/whatever where the specific
hospital just administer the HR part. You still think in a for profit manner,
where healthcare in most countries is not a for-profit endeavour. As long as
it works, it's fine, even if it's a net negative. You try to limit the money
you waste and inefficiencies, but not by pulling levers on the staff salaries.

~~~
marcinzm
>You still think in a for profit manner, where healthcare in most countries is
not a for-profit endeavour.

And in the US it's not.

Assuming that you can simply remake a massive chunk of the economy (hospitals,
doctors, nurses, clinics, etc, etc) to be government owned is silly. People
will protest, lobbyists will be paid and it won't happen. If your only
solution to the problems people point out is essentially magic then, no, it's
not a valid solution.

------
gforge
I am an orthopedic surgeon during the day and at night I write code. I just
don't believe that spending a few hours watching surgery actually helps. You
need to really work with the software, a solve daily problems and be aware of
what problems are trivial software fixes.

For instance, when I sign lab results I get to see the references for twenty
year old subjects. It would be much more helpful to see the patients last lab
result (in 60+% of the cases this is available).

Another example is in the ER where we have a list of all the patients. There
is a column for my name so that I know which cases I am handling,
unfortunately that column is too the far right and only visible after resizing
the other columns. This setting is also not saved so each time I open the list
I have to resize over and over again. If you could move that column to the
left would be great, or even just bold font my patients' name.

The major problem that I see is that we have:

\- huge monolithic software that make any change a living nightmare

\- all changes are treated as we were doing open heart surgery. Most stuff we
do is trivial but having a standard that high makes it almost impossible to
deploy updates - especially the minor changes that really would change things.

\- 80% of users complain about the software but very few understand the
underlying problem.

\- much of our software is spec driven - I can sign my lab results and I can
see the patients in the ER, no one bothered to add the last tweaks to actually
make it easy.

~~~
ivan_gammel
All that you mention points to lack of proper UX design process as part of
SDLC. Observation is part this process, it is important and better not to be
skipped, because it can provide very useful insights, but it’s just a single
stage of research - there are more techniques and methods to solve problems
that you mention.

~~~
gforge
Yes, there have been numerous people pointing out this in this thread. I think
that UX design is viewed as frosting on the cake instead of the thing that
actually makes it work. Unfortunately I think one of the issues is that the
SDLC is broken.

For some reason we keep getting features that few of us actually requested but
that often make sense in that they are life saving, that is if people actually
used them. I have a ton of indicators flashing all-over the place and after a
while your brain simply adapts and ignores them. I doubt that anyone has
actually done any analysis to see if these tools actually save lives.

I've been involved in some projects when I've spent 30 minutes with UX people
and then never heard back from them. When the final product arrives it is full
of annoying flaws, e.g. the latest software I was involved in the work flow
is: 1\. click on "open software" from the patient chart 2\. a new window opens
where I manually have to click on "log in" (note, I'm not adding a password)
3\. the UI goes into authentication 4\. the UI goes back to the login screen
5\. the UI asks me a question that I _always_ answer the same thing to 6\. I
actually get to the data I was interested in

The most annoying part is number 4 - if I accidentally click on "log in"
everything breaks and I have to close the window and redo everything from
start.

Most of these UX issues fall under the category - murder by a thousand cuts.
It is mentally tiring to be faced with all these issues but none of them is
like open heart surgery where one mistake can be fatal. What happens is that
doctors/nurses become tired and don't put the effort into the patient
interaction where the actual value in healthcare is created. I'm pretty sure
that bad UX in the end kills many more patients through this than
malfunctioning critical hardware.

I truly wish that people in this forum that create health-care software think
of UX and actually use their software more than just "I clicked through and
everything works". Your bosses will probably never ask for UX features because
they have a deadline, but you are in charge of designing and during that
process it is easy to fix many of these annoyances (e.g. just disable the log
in button).

------
samstave
I am biased, but I spent almost half a decade building/designing systems for
Healthcare. I had direct interaction with the users, the vendors and the
actual go-live planning for a number of facilities.

Healthcare has a lot of issues, EPIC was a stone-walling garden, Siemens
wanted to steal stuff, OpenVista was a non starter, Philips talked a big talk
but never followed through, Not everyone was truly HL7 compliant, Users didnt
believe on Apps on the iphone/ipod-touch as the screens were too small and the
average age of users was ~57, The number of employees in a large hospital is
in the thousands, Patient Entertainment systems were snake-oil-jokes, "medical
grade" devices were a fraud, and selling into them at this time was a unique
process for every hospital -- and while the users (clinical staff) really
really want to (and do) provide good care, training 1,000+ Staff/Nurses on
your new tech is very daunting.

Obviously we have made a ton of progress in tech in healthcare, but finding a
way to consume more time with staff/processes can be a difficult problem to
figure out access.

Silicon valley needs an actual research hospital for tech - if I were throwing
my billionaire last name on SFGH/UCSF/Oakland etc's hospitals - I'd do a lot
more than just buying the name of the building - seeking how to work together
to make an SV research hospital happen in an innovative way.

(We had a fully integrated HL7 iphone app which could interact with OpenVista,
and other systems like Vocera and Philips and Siemens systems. We had a
channel to work with hospitals around here but the screen size and costs of
providing handhelds to nurses were too high for 2007. YC Turned us down, Epic
and Cerner would allow integrations... We opensourced it to Openvista.)

~~~
m0zg
I think eventually we'll have to sidestep most of this fraud entirely by
enabling self-serve early diagnostics and cranking up the doctor-replacing
technologies to the max. Machines are good at recognizing patterns in non-
adversarial environments not starved for compute. There's every possibility
that they could do diagnostics better than a human could. Treatment will be up
to human doctors for the foreseeable future, though.

Too bad Theranos salted the earth for much of this innovation for the next
decade. But it's still happening, starting with EKG and ultrasound.

~~~
assblaster
>But it's still happening, starting with EKG and ultrasound.

Whole-body ultrasound? How would an AI understand how to interpret images with
low signal:noise? Who will be performing the actual ultrasound image capture?
Who will be ordering the imaging tests? How will an AI understand a patient
that can't meaningfully interact with an AI?

What's the utility of "EKG" [sic] for diagnosing non-cardiac problems? Or, do
you come from the perspective that all medical problems can be diagnosed with
an ECG, urine analysis, ultrasound (of what?), blood test, and CT scan? Do you
realize that an ECG is more complex than a single vector ECG via Kardia
mobile?

I thought we were trying to reduce healthcare costs, but you're recommending
over-utilization of expensive diagnostics?

Why are you limiting treatment to doctors only, why not have AI do everything?

Everything you've written demonstrates an extremely limited understanding of
the practice of medicine, a characteristic far too common shared by those who
are trying to "disrupt" medicine.

~~~
m0zg
Sure, I realize there's much that the current tech does not cover. But you
gotta start somewhere, and through extremely wide deployment tens of thousands
of lives will be saved, and important feedback will be collected to improve
products. $400 watch that does a dozen other things and that the user would
buy even if it didn't have ECG is not "expensive diagnostics".

This is where things are at, whether you like it or not, especially for the
working poor who can't afford to fork over a few hundred dollars every time
something feels "off". The current crop of devices is not affordable to them,
but 5-10 years from now they'll be bundled in cereal boxes. Hook up sensors to
wearables, catch diseases early and at a massive scale, cure or treat them
before they get extremely expensive. To me it looks like it's the only way out
of the ripoff "healthcare" scheme we're in right now. I'm pretty convinced the
solution to the US healthcare problem will be technological in nature.

And don't tell me universal healthcare will fix things. It won't, because US
doctors (unlike their counterparts elsewhere) expect to be earning a pretty
penny after they go through the trouble (and expense) of educating themselves
for a decade, and that's not going to change. There simply needs to be less
demand for doctors, and the ones that remain should be able to use their time
efficiently.

~~~
whymauri
Smart/Self-serving diagnostic tools occasionally fail for legal feasibility
reasons before they are adopted by the market. Consider a smart heart
monitoring system, maybe connected to a canary that will alert a healthcare
professional or first responders if something is amiss. Absolutely nobody
wants to be liable for misdiagnosing acute symptoms, which may lead to death
or false positives.

It doesn't even have to be acute symptoms, either. A large healthcare company
a friend worked at was working on a smart heart monitor that for some reason
they wanted to connect to an app. In their head, the app would be used by both
the patient and their doctor who would check on the patient. If they have a
lot of patients, that's an overwhelming amount of data streaming in 24/7\. The
time commitment to really evaluate those data for anomalies was too high, as
were the stakes. Doctors were scared that if they missed something they might
be held liable for unrelated medical emergencies which is terrifying for them.
At the time, algorithms were really not good enough to catch the really subtle
markers of an impending medical problem. At least according to the guy that
told me this, he was a biomed/hardware engineer not a programmer or
statistician by any means.

Even if you had some legalese associated with the product to make this a non-
issue, doctors still wouldn't trust the idea. So they pivoted the technology
to something else that was more traditional. It is much harder to pursue
justice for an algorithm than a human. I guess what I want to get at here is:
sometimes the software and hardware are working as intended, but subtleties
can be lost on the technical side (programmers, biomed engineers) can kill a
product. Stuff like market research, liability and legality, and public
perception of the tech.

~~~
m0zg
Sure, there will be cases where your device will say "I'm at a loss here, go
see a doctor". The point is, right now the majority of (very expensive!)
doctor visits are a total waste of everyone's time, and your money.

There's no rational reason why I need to drive to a lab for bloodwork or
simple diagnostics, and have a human do it: a robot at a local convenience
store should be able to do the job. There's no rational reason why I need a
doctor to misdiagnose my elbow pain as something requiring surgical
intervention (I just stopped using my laptop in bed and it went away). Another
doctor ordered a ($900) MRI to diagnose pain in my left shoulder and then told
me I have a SLAP tear there based on extremely blurry results (again $$$$,
surgical intervention, and 6 months of recovery). Bullshit, bud, I don't -
it's a non-dominant arm, and I'm someone who doesn't do a lot of throwing or
work above shoulder level. It was that dang laptop in bed again. Someone with
weaker critical thinking skills and google-fu would be thousands of dollars
poorer thanks to taking that doctor's "advice". In fact they could end up with
a permanently fucked up shoulder and elbow, too.

Did you know that medical errors are the third leading cause of death in the
US, right after heart attack and cancer? Seems to me that "human" doctors are
also a dangerous proposition.

~~~
assblaster
>The point is, right now the majority of (very expensive!) doctor visits are a
total waste of everyone's time, and your money.

Honestly, what are you talking about? A doctor's visit costs between $0 and
$150, depending on insurance/government, and it is a focused encounter to
determine the source of a medical complaint and a most likely effective
treatment for that problem.

You want to stick a one-lead ECG on someone and expect that it's supposed to
spit out a diagnosis, or heaven forbid, a recommendation to see a doctor who
can actually figure out how to diagnose and treat the patient.

Your statement in fact points to the uselessness of this proposed medical
device if it can't actually figure out what's going on and instead will send
you to an actual expert (physician). How reliable would it be for everything
else it "diagnoses"?

~~~
m0zg
>> A doctor's visit costs between $0 and $150

And who do you think covers the remaining $150-infinity?

>> You want to stick a one-lead ECG

You're not arguing in good faith. Goodbye.

~~~
assblaster
>You're not arguing in good faith. Goodbye.

You haven't come up with a single situation where a non-cardiac medical
problem can be diagnosed solely with a handheld single vector ECG.

You don't mention anything about false positives or false negatives,
sensitivity, specificity, pathophysiology, anatomy, pharmacology, diagnostics,
or medical decision making.

You have no understanding of how your magical tech device would bridge every
aspect of the practice of medicine, but you make an audacious claim with a bit
of hand waving, saying "this will work better than physicians, and cost far
less".

------
zdware
I worked a tiny bit over a year around 2013 at a hospital network and was on a
team that maintained custom integrations with Cerner, an EHR system.

It was by far one of the coziest jobs I ever had. Low stress environment,
redundant meetings, etc. But development of any kind of god awful. It was
extremely sluggish, lots of red type, and seemed to follow a manual QA
approach over any sort of automated testing. Things were just too lax in
general.

Myself and another junior developer left after we noticed that an intermediate
engineer on our time hadn't committed in over 3 months.

My point of this story is that hospitals didn't seem to attract/retain
passionate software developers. With high turnover or apathetic developers,
most software built custom for hospitals is probably Frankensteined.

~~~
maxsilver
Agreed, this mirrors my experience in healthcare. Hospitals pay the highest
amount of money, for the lowest quality of software (regardless of whether
developed internal, or purchased through healthcare software vendors).

The jobs are easy, and you can go months without doing any real work
whatsoever. The company might not even care (since for hospitals, sales cycles
are often measured in years, and minor upgrade cycles are often measured in
months).

But this kills any desire to do anything. Almost no developer with any
motivation or skills, wants to work somewhere where they do nothing useful and
have no real work to do -- even if the pay is good, you can literally feel
your brain rot out, and you start to be worried you'll never get hired at a
"real job" ever again.

It's just a bad cycle of events all around.

~~~
freedomben
This was my experience in government work too. For every three engineers that
accomplished nothing, there was one doing real work. Most good engineers would
work there for 6 months or less and then flee in boredom or fear of not
finding work at a "real job" again. The good engineers that stayed often found
a niche they really liked, and were worshipped as rock stars by management and
stakeholders, so they were pretty happy.

------
commandlinefan
More time? I wish I was given _any_ time with my users so I could actually
understand what features would make their lives easier. I actually did get to
spend about two hours with some actual users of my software a month ago and I
noticed that they were scrolling up and down a lot. I asked if it would make
their workflow quicker if I made the save button float in the lower-right
corner of the browser (I.e. position: fixed). They said, “you can do that? Oh
my God, that would be amazing!” It took two seconds of CSS and has saved them
hours already.

~~~
derekp7
The problem is that it may take 2 seconds of CSS, but it is a software change
that then requires the product to be revalidated, along with the matching
paperwork (functional design doc, software design, technical design, customer
support documentation and training material) and validation evidence to be
submitted to your official document control system. And this process can take
days, weeks, or months, depending on how complicated (due to extreme CYA) your
compliance department makes the process. And the company compliance folks want
to go overboard as they want to make sure the FDA auditors are happy the next
time there is a surprise audit.

~~~
commandlinefan
Oh absolutely - it was as simple as a fix can be, given (perfectly legitimate)
quality control concerns, but it never would have happened if I hadn’t had a
rare opportunity to actually observe how they work.

------
mothsonasloth
From software development classes in School to University, we were told the
most powerful method of requirements gathering was observation.

Yet in my whole professional life I've never had a chance to do it despite
putting the idea forward.

One of my old colleagues who managed to observe a client was met with
hostility and questions from the people he was observing.

Other times clients want to dictate and have no dialogue in defining
requirements.

~~~
ken
When I was developing internal software at a big company, I went to observe
some actual users at the company. (I thought what we were building didn't make
sense, so I wanted to see if they actually used it that way.) I got a tongue
lashing from management for that one! "You're a developer. You're not supposed
to talk to users."

The entire project, of course, was eventually cancelled.

~~~
maxxxxx
I see that a lot too. There are a lot of well-paid managers whose only role is
to be middlemen between engineers, customers and other departments and they
protect that role jealously.

I agree that some developer probably shouldn't be talking to customers but
overall they should. I have had many occasions where we received a spec and
after discussion with users quickly saw how we could meet their needs in a
much simpler way than the middlemen had come up with.

------
LeonB
My neighbor’s son is a doctor who needed some software written. He learned to
write the software and now runs a software business (in addition to being a
doctor). I guess it was easier than trying to bring developers in. Ive seen
the same thing with a pilot who learned programming to write an incident
management system for airlines. Only once the software was successful did he
seek advice from ‘professionals’. Learning to code is not the deepest skill
around.

~~~
m0zg
>> Learning to code is not the deepest skill around.

Neither is learning to fly a plane. What's prized is the ability to do it in
such a way as to not crash. The same applies to software engineering.

~~~
Novashi
Healthcare has lots of low-hanging fruit that's solved by simple CRUD apps,
and those can be reasonably maintainable (and secure) if you build it using
easy frameworks and well-known patterns that are commonly found in tutorials
lying about the internet.

It'll be so simple that it's equally maintainable.

The real issue is adoption, but that's expedited if you're a doctor who's also
a software developer and makes it easier to sell.

------
pragone
I’m not at all surprised.

As a semi retired software engineer and currently 4th year Med student, I
still maintain a dream of building a usable EHR that puts the clinical,
patient-focused side of things first. Currently implementations allow for
increased billing recovery, but at a cost to both doctors and patients.

I just don’t know how you’d start in competing with something like Epic or
Cerner, from a business side of things.

~~~
qudat
Healthcare is a heavily regulated industry and as such only large companies
are able to successfully navigate the bureaucracy. The only way to usurp
coercive monopolies is by creatively destroying it (e.g. uber)

~~~
EpicEng
It's more nuanced than that. I've spent 13 years working for two successful
healthcare/biotech companies, both having attained FDA clearance (one class I
and two class III devices) while I was there. I was brought on as the 21st
employee and then the 17th employee. At no time could these have ever been
considered large companies.

Products like LIMS and hospital systems are hard to replace because of vendor
lock in and the cost to replace it all, not regulatory hurdles.

------
AngeloAnolin
This is so true.

One of my previous professional experience was working for a company that
delivered a complete hospital information system that was used in two of the
biggest health institutions in the Middle East.

Initial software development was done offsite, but then, the owner and CTO of
the company thought it more wise to bring in the developers on-site. On-site
here meant that our team was provided an actual area in the hospital where we
were given freedom to observe, collect and synthesize as much information
related to the system we were building.

One major challenge we faced was that, for example, we have three doctors all
specializing in the same category, i.e. cardiologist. All of them would have
different ways of wanting how the technology will support their process. One
would want information laid out in a different manner, with quicker access to
other information he need from other facets of the system. There's just no way
to standardize a specific process. This lead to us delivering solutions that
allow the doctors to customize as much as they can of the application based
off their preferred procedures.

Being there in the hospital itself I would say has tremendously helped the
team deliver a lot of innovative functionality that I have still yet to see at
this day and age. I was interfacing HL7 data with Siemens and GE Radiology and
providing the doctors to automatically perform dictation through Philips
Dictaphone - where the recording is sent to an offshore transcription company
in Asia, and the data returned and tied to the actual radiology exam it is
designated for - all under intense security, compliance, and anonymity.

I've also observed through working in different hospitals, there is a lot of
variations in the workflows, hence the necessity for engineers to actually be
present and on-site. This provides the developers a real-world picturesque
view of what needs to be built that will make every hospital staff (doctors,
nurses, aides) become very productive.

~~~
Scoundreller
A problem with so many local customizations becomes apparent when it’s upgrade
time. You must do several X the testing and there’s a higher risk of something
breaking.

~~~
AngeloAnolin
Customization happens at the user level. We architected and designed the
application to allow for this flexibility.

------
sonnyblarney
Maybe we need a profession, you know, people who create experiences ... maybe
we can call them 'UX designers' or 'UI designers' or something. Where they
investigate how people use and relate to information before the Engineers
build stuff.

Maybe I'm just crazy!

~~~
nradov
They have UX designers. The problem is those designers don't necessarily
understand clinical workflows. That takes years of experience.

~~~
aasasd
Jakob Nielsen was writing for decades now that the first job of an interface
designer is to sit down with future users and see how they do their work.
(Always _users_ , more than one.)

It doesn't take years of experience in the target field. It just takes hours
of watching and listening and figuring out what people are actually trying to
do.

~~~
nradov
I am familiar with Jakob Nielsen's writings, and I stand by my statement.
Effective UX design in the medical field takes years of experience. It's far
more complex than most other business domains because every medical specialty
has different requirements and there are so many edge cases. No one is capable
of learning that stuff in a few hours.

------
mehrdadn
Worth reading: _How Medical Tech Gave a Patient a Massive Overdose_ (39x)

[https://news.ycombinator.com/item?id=18145853](https://news.ycombinator.com/item?id=18145853)

------
danieltillett
I have often wondered if it would be better to just hire professional data
entry people to follow the doctor around and enter all the information into
the system. Does it really make sense paying someone $500K a year to peck and
tap into a EHR?

~~~
tivert
> I have often wondered if it would be better to just hire professional data
> entry people to follow the doctor around and enter all the information into
> the system.

Those data people are called "medical scribes," my doctor has started using
one. Seems like they're mostly pre-med college students looking to get
exposure to healthcare environments.

[https://en.wikipedia.org/wiki/Medical_scribe](https://en.wikipedia.org/wiki/Medical_scribe)

~~~
danieltillett
Sounds ideal - they can even remind the doctors to wash their hands before
touching the patient.

~~~
tivert
> Sounds ideal - they can even remind the doctors to wash their hands before
> touching the patient.

I don't think doctors (or anyone else for that matter) is going to tolerate
being followed around by an assistant who's going to nag them about how to do
their job.

------
starpilot
With any of these tech inroads into non-tech fields, the issue is always
communicating to the non-tech people that your solution has value, and not
developing the tech solution itself. If you're a salesman walking into a
person's house, telling them they live their life wrong, and your (expensive)
solution will fix it, good luck with that.

------
Trisell
It also doesn’t help that to break into this market you have to overcome years
of customization and millions upon millions of dollars in sunk costs that
management isn’t likely to throw out for something that “works better for
clinicians.” Not to mention the cost of retraining entire hospitals worth of
staff to use the new system.

~~~
brent_noorda
So true. After over 30 years as a programmer, I recently switched to being a
nurse in a hospital where half the day (it seems) is spent charting in the
very old DOS legacy charting system. No one would write a system like that
today, but with thousands of people muscle-memory trained on the old system,
what reasonable argument could be made for a change?

------
gaius
Similar problem in the UK
[https://www.theregister.co.uk/2018/01/18/nhs_buntu_trademark...](https://www.theregister.co.uk/2018/01/18/nhs_buntu_trademark_cease_and_desist/)

The issues the NHS has with IT (with the glaring exception of WannaCry) are
related to the vast fortunes they expend with outsourcing companies for custom
software that doesn’t work. Doing the same thing but on Ubuntu won’t be any
better. But the engineers don’t care, they have an ideological axe to grind so
they focus on something irrelevant.

------
gregjor
Example of a more general problem: developers not understanding the business
domain. Developers often blame “poor requirements” for schedule and budget
overruns, but they didn’t spend any time learning the business domain.

~~~
hyperman1
If you do learn the business, you have to explain to management why you wasted
all that time. You cant say your application is cheaper in user errors,
downtime, maintenance, licences, change requests etc... as that would mean all
the other expensive software is garbage.

~~~
gregjor
Domain expertise is not wasted time. It makes the difference between a useful
application and a pile of code. Developers should not assume they know more
about a business domain than the people working in it.

~~~
bobthepanda
Isn’t that the job of a product manager, though? To figure out what the
product should actually do?

~~~
Barrin92
tacit knowledge especially in an hands-on field like medicine where patients
are involved cannot be conveyed by a manager with a power point presentation.

This compartmentalisation in the name of efficiency is actively harmful.
Developers should get out more and get first hand experience of the
environments they develop software for.

~~~
freedomben
Could not agree more. It's a bit like the game of telephone that many of us
played as children. The more hops in the connection, the greater ability for
knowledge loss and distortion.

I once had a PM tell us to do a feature a certain way, despite engineers
saying we thought it was dumb. We shipped and had lots of user complaints, and
lost millions of dollars ultimately in lost revenue due to cancellations that
we think were at least in part to this. We eventually reversed course but much
damage had been done.

Afterward there was a witch hunt (which I staunchly oppose, but I digress). It
turned out that the PM had taken the word of another PM who in turn heard from
another that had gone on location and misunderstood what the customer was
saying. To save a few thousand bucks the company only sent one person and
expected them to brief everybody else on their findings. In hindsight I'm sure
that skinnier travel budget wasn't so worth it.

------
mgamache
I work on a telemedicine product using Google Glass Enterprise and the current
version of our product was shaped greatly from feedback provided by one early
user (physician). It really focused our use cases and made the product much
better. That being said, optimizing the current medical process will only get
you so far. It will probably not result in large disruptive positive changes.
Those will have to come from outside the current process.

~~~
DoreenMichele
_It will probably not result in large disruptive positive changes. Those will
have to come from outside the current process._

Rest assured that anything that makes a significant impact on health will
cause people to completely freak out if it hasn't been vetted via the current
medical system, even though this vetting process kills a lot of therapies that
people then lament that they wish they had access to.

~~~
mgamache
Balancing safety vs progress is tricky. Additionally, people's perception of
risk is also really bad so the resulting choices are sub-optimal.

~~~
DoreenMichele
I'm well aware of that. I have a form of cystic fibrosis. I used to be on
multiple maintenance drugs. I currently manage my condition with diet and
lifestyle and no longer take medication.

I also no longer belong to any CF lists. It's too much drama. I was constantly
attacked and, among other things, accused of irresponsibly endangering lives
for trying to talk to people about what I found helpful.

------
anoncoward111
Sounds like doctorsplaining. A better idea would be to hire nurses and
technicians who spend thousands of hours in the trenches and let them tell you
everything that really goes on.

~~~
romwell
>Sounds like doctorsplaining

Sounds like userblaming. Works wonders when the users aren't the ones choosing
the software to use, or have much input.

~~~
heyjudy
Absolutely. It's vital to listen carefully to users and think broadly and
wisely. The programmer must understand what the users have to deal with in
order to provide something useful to them. If not, the user will hate the
result, it will make them miserable, cost the employer time to redo it and the
cost of not being able to do what needs doing (or worse) without software.

tl;dr: get to something most useful soonest by quick, small iterations until
it's satisficing. No BDU project fails, and no assumption fails.

------
macjohnmcc
When I was a programmer at a non software company I would frequently sit with
the users and watch how they used the existing software or how they did a task
that we were considering creating software to help with. It was a great way to
make a useful product right away rather than get back and lot of negative
feedback about how it doesn't do what they need or expect if the software was
written without that insight.

------
abalone
To what extent is this an exclusively American problem? How much of the health
care “tech” opportunity is tied to managing the complicated multi-party
bureaucracy of the U.S. system?

The article highlights how docs are spending too much time doing “desktop
medicine” related to paperwork and billing. There’s a whole layer of
adminstrative staff at every hospital doing this stuff too.

If we get Medicare For All someday, what will the impact be on the healthcare
tech startup space?

For example I met someone at a bar the other day whose startup was all about
managing medical bills. Consumers can scan their bills and they’ll look for
optimizations and payment plans and budgeting or something. This would just go
poof under M4A.

------
gesman
I managing projects that specifically integrating Epic data with dozens of
clinical healthcare applications, HR data, medications access data as well as
provider behavior data to offer security, privacy and unified monitoring
capabilities for privacy and compliance officers in healthcare.

It really does helps to “eat our own dog food” and spend time in hospitals.

For example I spent few days in large New York hospital studying operations of
secure drug dispensing cabinets before building solution for medications
security analytics.

Tons of interesting data with valuable insights on how narcotics are secured
and accessed.

------
msaharia
Also true for EdTech startups who have never talked to students or teachers.

------
gdubs
This is the Design Thinking approach IDEO pioneered and continues to pursue.
It’s also how Apple approached their retail store, for instance, by composing
a team made up not just of the designers, but also people who worked in retail
on the ground floor and understood the reality of the problem they were
solving.

------
paulie_a
Ideally every developer should have to spend a significant amount of time
actually interacting with their customer, and in this case the customers
customer. It would give a different perspective about that feature that is
being built. It sounded good in a planning meeting and will never be used in
the real world.

------
otto_ortega
I'm have the desire to make an attempt of developing a new type of EMR system,
putting special focus on the documentation part of things.

Is there any health care practitioner around here with time for a 15-minutes
phone interview or willing to exchange a few emails so I can better understand
his/her needs?

------
tyingq
One issue with software at hospital is that the various departments buy what's
best for them, with little regard to interop needs with other departments.

So, admissions, for example, buys what they want, and don't care about the
integration with, say, radiology.

~~~
Scoundreller
You could also make the same complaints about the vendors for each.

It’s fun when some systems handle a bed-swap gracefully. But others don’t.

Or what happens when you figure out who your John Doe is and how to propagate
that.

------
Ice_cream_suit
IBM's Watson has killed trust in medical software for a generation.

~~~
Scoundreller
It never got that far in my opinion.

------
sys_64738
And always question assumptions. Those are your enemy and the area where most
things are wrong or missed.

------
known
Hope ML/AI will capture/automate vital/undocumented knowledge that is orally
passing thru generations e.g.
[https://en.wikipedia.org/wiki/Stereotypes_of_Jews#Jewish_mot...](https://en.wikipedia.org/wiki/Stereotypes_of_Jews#Jewish_mother)

------
fiatjaf
This applies to all kinds of "apps", not only hospital-related ones.

------
Beefin
If any doctors want to discuss app development, I’m very open

~~~
DoreenMichele
I'm not a doctor, but I run a small, low activity list called Health Techies.
Anyone here is welcome to shoot me a join request:

[https://groups.google.com/forum/#!forum/health-
techies](https://groups.google.com/forum/#!forum/health-techies)

------
franzwong
Engineers ask doctors to spend more time / resources on building healthcare
tech.

------
deytempo
As a programmer, it always flatters me when I am referred to as an “engineer”

------
dayaz36
Click bait title. Actual title should be: "Doctors are asking Silicon Valley
engineers to spend more time in the hospital before building MEDICAL apps"

------
sys_64738
Software developers are incredibly poor at gathering requirements. The best
choice for gathering those requirements is to have a management consultant who
does nothing but study business process and document the current clinical
process. Once that's documented then you can discuss what needs to change from
that document to extract the core requirements. Having a software person
shadow a medical professional will only lead to the medical professional
telling the software person what they think is needed.

In other words, decouple system analysis from system design.

~~~
protomyth
_Software developers are incredibly poor at gathering requirements._

I've had the opposite experience. Good software developers are good at
gathering and understanding requirements. The information loss from management
consultants and software developers is pretty nasty. Frankly, if the the
people coding the system are going off a requirements document that they
didn't have a hand in then you might as well outsource the development. If the
software developers don't become domain experts then you should be worried
about the correctness of the software.

I often wonder if the general dislike of DSLs is caught up in this separation.

