18 ms·

Doctors ask engineers to spend more time in the hospital before building apps

366 points by brandonb 8y ago

mothsonasloth 8y ago
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.
- freedomben 8y ago
  I once was in a position where I could observe, and I can confirm that: > the most powerful method of requirements gathering was observation. But the vast majority of my time has been at companies where engineers are never cleared to travel to meet with customers and gather information. It's insanity IMHO. It was the one bright spot about doing contract wor.
- vishnugupta 8y ago
  Agreed. The problem though is that university curriculum hasn't caught up with the reality yet which is a role called 'Product Manager'. While I was in college there was a mention of 'System Analysts' whose job was roughly matched that of product managers of today. In general though, I doubt any reasonably sized company will let engineers gather requirements. The divide between product manager and engineer has only hardened over last few years or so.
- ken 8y ago
  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 8y ago
    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.
  - gaius 8y ago
    The entire project, of course, was eventually cancelled Been there, done that. Once spent months working on a project but when I finally got to talk to the users they told me it didn’t do what they wanted and even if it did they wouldn’t change their working practices (union rules maybe?) At the end of the year the manager who had assigned me this project dinged me on my appraisal for not having delivered it.
pragone 8y ago
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.
- warent 8y ago
  I worked for a little bit with these guys on this product called phrHero which focuses on making these EHRs more much more patient-friendly using the new FHIR protocol. https://www.phrhero.com/ https://www.phrhero.com/ I don't work with them anymore due to some fundamental differences (it's been almost a couple of years) but thought it was related to what you're talking about and possibly something you'd be interested in. Possibly the only way you could compete with Epic or Cerner is to innovate on things in a way that can't be denied. It wouldn't be the first time slow giant companies fall because they did not advance, but it is much harder because the barrier to entry is absolutely enormous.
- Para2016 8y ago
  Epic lets you change provider context to Emergency department, internal medicine, etc. I think they just need to make the provider context suck a whole lot less. Epic Haiku (mobile) is a pathetic joke as well. Nevermind, I think you're right actually, the whole thing needs to be burned to the ground and built completely different. The only thing Epic has going for it is that it's not Cerner.
  - fencepost 8y ago
    The only thing Epic has going for it is that it's not Cerner. They also have that they're not eClinicalWorks or descended from Medical Manager (Intergy), that has to count for something!
- chapium 8y ago
  Dont beat them, join em. Build a solution to a problem and integrate it into one of their html5 modules. Both systems offer breadth, not depth when it comes to solving problems.
mehrdadn 8y ago
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
oomkiller 8y ago
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.
- tracker1 8y ago
  Exactly.. short of the parent company of a hospital also owning a software company for the software this likely won't happen. Even then, software engineers RARELY get to interact with the people using said software for any meaningful time... It's usually meetings with your PM, Manager, their manager, and maybe the same on the other side. That's like 3-6 layers of separation in this telephone game.
  - gaius 8y ago
    Didn’t Massachusetts General develop MUMPS in-house?
- 8y ago
starpilot 8y ago
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.
sys_64738 8y ago
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 8y ago
  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.
- sonnyblarney 8y ago
  I would opt for a talented experience designer over a consultant. The goal is not to 'document how it's done'. The goal is to understand 'what problems are being solved, and possibly how to do them better'. Someone analyzing horses and coaches might have requested more horses or coaches, when really what was needed was this new thing called 'a car'. So someone who is thoughtful, organized, who can communicate, and who understands technology. Would be a good start. Without any kind of professional discipline however, it's hard to find and evaluate such people.
- magicalhippo 8y ago
  > Software developers are incredibly poor at gathering requirements. Customers are also often incredibly poor at defining their requirements, at least in my experience. Like having undocumented routines which are only recalled by that one employee once they have to actually perform them, once a year or so. Of course it's usually a really critical, time-sensitive issue when they discover that the routine they never told us about hasn't been implemented and thus cannot be done... almost never fails that.
deleted 8y ago
[deleted]
sys_64738 8y ago
And always question assumptions. Those are your enemy and the area where most things are wrong or missed.
Trisell 8y ago
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.
- EpicEng 8y ago
  This is the largest factor by far. I am convinced I could write a better LIMS than exists today. I am not convinced I could sell it.
- brent_noorda 8y ago
  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?
gesman 8y ago
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.
sonnyblarney 8y ago
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 8y ago
  They have UX designers. The problem is those designers don't necessarily understand clinical workflows. That takes years of experience.
  - aasasd 8y ago
    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 8y ago
      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.
- canada_dry 8y ago
  Hey, there's a concept! But, for companies that can't/won't (I consulted for one that wouldn't even hire professional BAs - they expected line staff to write the specs)... at least have the PMs and programmers go spend several hours in the client's dept. (around month-end is usually good) to get a feel for how things actually work.
msaharia 8y ago
Also true for EdTech startups who have never talked to students or teachers.
commandlinefan 8y ago
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 8y ago
  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.
  - fiatjaf 8y ago
    Doesn't apply if you're doing software the right way: just yourself, for small clients.
  - commandlinefan 8y ago
    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.
- BurningFrog 8y ago
  > I wish I was given _any_ time with my users With some effort and/or ingenuity, you can probably take time with your users, one way or another.
samstave 8y ago
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.)
- chiph 8y ago
  At a previous job we integrated with Vocera. Fun easter-egg with them - ask it to "Beam me up". https://www.vocera.com/solutions-support/easter-eggs https://www.vocera.com/solutions-support/easter-eggs > costs of providing handhelds to nurses were too high for 2007 Perhaps you should have looked at integrating with the Ascom handsets.
  - samstave 8y ago
    We did, but Ascom were generally viewed as being ugly and the "blackberry" of handsets, and had their own issues. I can't recall the details too clearly now - but I think at that time, Vocera was also the new sexiness in the market and so most hospitals were going Vocera.
otto_ortega 8y ago
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?
macjohnmcc 8y ago
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.
danieltillett 8y ago
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?
- fencepost 8y ago
  Hiring a medical assistant to effectively take dictation and record things in the EMR happens, but far more common are voice recognition systems and templating (which leads to its own set of issues). Long additional hours charting are another thing that happens - most doctors I know seem to spend at least a couple extra hours charting, dealing with labs, etc after they've seen their last patients for the day.
- tivert 8y ago
  > 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
  - uberduber 8y ago
    They even have eScribes from foreign countries through video chat. One of my doctors has one from the Phillipines which was familiar with his very uncommon EMR. The scribe company gave him an iPad to video chat.
  - danieltillett 8y ago
    Sounds ideal - they can even remind the doctors to wash their hands before touching the patient.
    - tivert 8y ago
      > 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.
deytempo 8y ago
As a programmer, it always flatters me when I am referred to as an “engineer”
LeonB 8y ago
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 8y ago
  >> 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 8y ago
    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.
- sergiotapia 8y ago
  Scott Adams calls this the "talent stack". https://blog.dilbert.com/2016/11/28/the-trump-talent-stack/ https://blog.dilbert.com/2016/11/28/the-trump-talent-stack/ Basically: individually these skills might not produce truly impressive results. Combined they produce great value. I have yet to figure out what my second "talent" in my talent stack could be. When I do figure it out I have a feeling things come much quicker.
- maxlybbert 8y ago
  Coding isn’t hard. Writing maintainable code is. And most people learn that only after they have to modify a large system they wrote themselves.
mgamache 8y ago
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 8y ago
  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 8y ago
    Balancing safety vs progress is tricky. Additionally, people's perception of risk is also really bad so the resulting choices are sub-optimal.
    - DoreenMichele 8y ago
      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.
tyingq 8y ago
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 8y ago
  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.
franzwong 8y ago
Engineers ask doctors to spend more time / resources on building healthcare tech.
dayaz36 8y ago
Click bait title. Actual title should be: "Doctors are asking Silicon Valley engineers to spend more time in the hospital before building MEDICAL apps"
Beefin 8y ago
If any doctors want to discuss app development, I’m very open
- DoreenMichele 8y ago
  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
Ice_cream_suit 8y ago
IBM's Watson has killed trust in medical software for a generation.
- Scoundreller 8y ago
  It never got that far in my opinion.
AngeloAnolin 8y ago
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 8y ago
  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 8y ago
    Customization happens at the user level. We architected and designed the application to allow for this flexibility.
paulie_a 8y ago
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.
gforge 8y ago
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 8y ago
  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 8y ago
    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).
known 8y ago
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_mother https://en.wikipedia.org/wiki/Stereotypes_of_Jews#Jewish_mot...
jeklj 8y ago
There is a whole chain of people involved before software gets designed, or built, or deployed. If you’re making software for healthcare institutions then that should include people with medical expertise.
fiatjaf 8y ago
This applies to all kinds of "apps", not only hospital-related ones.
gdubs 8y ago
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.
abalone 8y ago
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.
gregjor 8y ago
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.
- deleted 8y ago
  [deleted]
- magicalhippo 8y ago
  At work we make a program which essentially makes and sends electronic declarations, which fall under government rules and regulations. I had zero domain knowledge when I joined. However the majority of our support team were hired from our customers, and they know the domain very well. We include them when we need to implement new rule changes and other features, to make sure we don't miss things. After a few years of working here I of course have a lot more domain knowledge, but it's always helpful to be able to quickly run some questions past someone who knows the domain well should I happen to get some doubt in the middle of coding.
- commandlinefan 8y ago
  > they didn’t spend any time learning the business domain Weren’t given any time to learn it. FTFY.
- hyperman1 8y ago
  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 8y ago
    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.
anoncoward111 8y ago
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.
- jboogie77 8y ago
  The only nurses who spend more time behind the computer than doctors are those who are shopping. Unfortunately the doctor profession has turned from patient caregiver to note taker
- romwell 8y ago
  >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 8y ago
    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.
- heyjudy 8y ago
  I've worked in biomedical informatics IT at a clinical research university. I think it's reasonable to understand what the user's goals and priorities are by going to the point of use, Genchi Genbutsu (現地現物), in order to tailor something to make work processes smoother and better. I wouldn't hold off on assuming anything negative without more listening to understand them.
gaius 8y ago
Similar problem in the UK https://www.theregister.co.uk/2018/01/18/nhs_buntu_trademark_cease_and_desist/ https://www.theregister.co.uk/2018/01/18/nhs_buntu_trademark... 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.
zdware 8y ago
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 8y ago
  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 8y ago
    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.

366 points by brandonb 8y ago

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.

freedomben 8y ago
I once was in a position where I could observe, and I can confirm that: > the most powerful method of requirements gathering was observation. But the vast majority of my time has been at companies where engineers are never cleared to travel to meet with customers and gather information. It's insanity IMHO. It was the one bright spot about doing contract wor.
vishnugupta 8y ago
Agreed. The problem though is that university curriculum hasn't caught up with the reality yet which is a role called 'Product Manager'. While I was in college there was a mention of 'System Analysts' whose job was roughly matched that of product managers of today. In general though, I doubt any reasonably sized company will let engineers gather requirements. The divide between product manager and engineer has only hardened over last few years or so.
ken 8y ago
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 8y ago
  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.
- gaius 8y ago
  The entire project, of course, was eventually cancelled Been there, done that. Once spent months working on a project but when I finally got to talk to the users they told me it didn’t do what they wanted and even if it did they wouldn’t change their working practices (union rules maybe?) At the end of the year the manager who had assigned me this project dinged me on my appraisal for not having delivered it.

pragone 8y ago

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.

warent 8y ago
I worked for a little bit with these guys on this product called phrHero which focuses on making these EHRs more much more patient-friendly using the new FHIR protocol. https://www.phrhero.com/ https://www.phrhero.com/ I don't work with them anymore due to some fundamental differences (it's been almost a couple of years) but thought it was related to what you're talking about and possibly something you'd be interested in. Possibly the only way you could compete with Epic or Cerner is to innovate on things in a way that can't be denied. It wouldn't be the first time slow giant companies fall because they did not advance, but it is much harder because the barrier to entry is absolutely enormous.
Para2016 8y ago
Epic lets you change provider context to Emergency department, internal medicine, etc. I think they just need to make the provider context suck a whole lot less. Epic Haiku (mobile) is a pathetic joke as well. Nevermind, I think you're right actually, the whole thing needs to be burned to the ground and built completely different. The only thing Epic has going for it is that it's not Cerner.
- fencepost 8y ago
  The only thing Epic has going for it is that it's not Cerner. They also have that they're not eClinicalWorks or descended from Medical Manager (Intergy), that has to count for something!
chapium 8y ago
Dont beat them, join em. Build a solution to a problem and integrate it into one of their html5 modules. Both systems offer breadth, not depth when it comes to solving problems.

mehrdadn 8y ago

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

oomkiller 8y ago

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.

tracker1 8y ago
Exactly.. short of the parent company of a hospital also owning a software company for the software this likely won't happen. Even then, software engineers RARELY get to interact with the people using said software for any meaningful time... It's usually meetings with your PM, Manager, their manager, and maybe the same on the other side. That's like 3-6 layers of separation in this telephone game.
- gaius 8y ago
  Didn’t Massachusetts General develop MUMPS in-house?
8y ago

starpilot 8y ago

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.

sys_64738 8y ago

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 8y ago
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.
sonnyblarney 8y ago
I would opt for a talented experience designer over a consultant. The goal is not to 'document how it's done'. The goal is to understand 'what problems are being solved, and possibly how to do them better'. Someone analyzing horses and coaches might have requested more horses or coaches, when really what was needed was this new thing called 'a car'. So someone who is thoughtful, organized, who can communicate, and who understands technology. Would be a good start. Without any kind of professional discipline however, it's hard to find and evaluate such people.
magicalhippo 8y ago
> Software developers are incredibly poor at gathering requirements. Customers are also often incredibly poor at defining their requirements, at least in my experience. Like having undocumented routines which are only recalled by that one employee once they have to actually perform them, once a year or so. Of course it's usually a really critical, time-sensitive issue when they discover that the routine they never told us about hasn't been implemented and thus cannot be done... almost never fails that.

deleted 8y ago

[deleted]

sys_64738 8y ago

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

Trisell 8y ago

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.

EpicEng 8y ago
This is the largest factor by far. I am convinced I could write a better LIMS than exists today. I am not convinced I could sell it.
brent_noorda 8y ago
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?

gesman 8y ago

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.

sonnyblarney 8y ago

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 8y ago
They have UX designers. The problem is those designers don't necessarily understand clinical workflows. That takes years of experience.
- aasasd 8y ago
  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 8y ago
    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.
canada_dry 8y ago
Hey, there's a concept! But, for companies that can't/won't (I consulted for one that wouldn't even hire professional BAs - they expected line staff to write the specs)... at least have the PMs and programmers go spend several hours in the client's dept. (around month-end is usually good) to get a feel for how things actually work.

msaharia 8y ago

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

commandlinefan 8y ago

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 8y ago
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.
- fiatjaf 8y ago
  Doesn't apply if you're doing software the right way: just yourself, for small clients.
- commandlinefan 8y ago
  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.
BurningFrog 8y ago
> I wish I was given _any_ time with my users With some effort and/or ingenuity, you can probably take time with your users, one way or another.

samstave 8y ago

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.)

chiph 8y ago
At a previous job we integrated with Vocera. Fun easter-egg with them - ask it to "Beam me up". https://www.vocera.com/solutions-support/easter-eggs https://www.vocera.com/solutions-support/easter-eggs > costs of providing handhelds to nurses were too high for 2007 Perhaps you should have looked at integrating with the Ascom handsets.
- samstave 8y ago
  We did, but Ascom were generally viewed as being ugly and the "blackberry" of handsets, and had their own issues. I can't recall the details too clearly now - but I think at that time, Vocera was also the new sexiness in the market and so most hospitals were going Vocera.

otto_ortega 8y ago

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?

macjohnmcc 8y ago

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.

danieltillett 8y ago

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?

fencepost 8y ago
Hiring a medical assistant to effectively take dictation and record things in the EMR happens, but far more common are voice recognition systems and templating (which leads to its own set of issues). Long additional hours charting are another thing that happens - most doctors I know seem to spend at least a couple extra hours charting, dealing with labs, etc after they've seen their last patients for the day.
tivert 8y ago
> 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
- uberduber 8y ago
  They even have eScribes from foreign countries through video chat. One of my doctors has one from the Phillipines which was familiar with his very uncommon EMR. The scribe company gave him an iPad to video chat.
- danieltillett 8y ago
  Sounds ideal - they can even remind the doctors to wash their hands before touching the patient.
  - tivert 8y ago
    > 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.

deytempo 8y ago

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

LeonB 8y ago

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 8y ago
>> 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 8y ago
  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.
sergiotapia 8y ago
Scott Adams calls this the "talent stack". https://blog.dilbert.com/2016/11/28/the-trump-talent-stack/ https://blog.dilbert.com/2016/11/28/the-trump-talent-stack/ Basically: individually these skills might not produce truly impressive results. Combined they produce great value. I have yet to figure out what my second "talent" in my talent stack could be. When I do figure it out I have a feeling things come much quicker.
maxlybbert 8y ago
Coding isn’t hard. Writing maintainable code is. And most people learn that only after they have to modify a large system they wrote themselves.

mgamache 8y ago

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 8y ago
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 8y ago
  Balancing safety vs progress is tricky. Additionally, people's perception of risk is also really bad so the resulting choices are sub-optimal.
  - DoreenMichele 8y ago
    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.

tyingq 8y ago

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 8y ago
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.

franzwong 8y ago

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

dayaz36 8y ago

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

Beefin 8y ago

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

DoreenMichele 8y ago
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

Ice_cream_suit 8y ago

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

Scoundreller 8y ago
It never got that far in my opinion.

AngeloAnolin 8y ago

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 8y ago
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 8y ago
  Customization happens at the user level. We architected and designed the application to allow for this flexibility.

paulie_a 8y ago

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.

gforge 8y ago

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 8y ago
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 8y ago
  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).

known 8y ago

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_mother https://en.wikipedia.org/wiki/Stereotypes_of_Jews#Jewish_mot...

jeklj 8y ago

There is a whole chain of people involved before software gets designed, or built, or deployed. If you’re making software for healthcare institutions then that should include people with medical expertise.

fiatjaf 8y ago

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

gdubs 8y ago

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.

abalone 8y ago

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.

gregjor 8y ago

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.

deleted 8y ago
[deleted]
magicalhippo 8y ago
At work we make a program which essentially makes and sends electronic declarations, which fall under government rules and regulations. I had zero domain knowledge when I joined. However the majority of our support team were hired from our customers, and they know the domain very well. We include them when we need to implement new rule changes and other features, to make sure we don't miss things. After a few years of working here I of course have a lot more domain knowledge, but it's always helpful to be able to quickly run some questions past someone who knows the domain well should I happen to get some doubt in the middle of coding.
commandlinefan 8y ago
> they didn’t spend any time learning the business domain Weren’t given any time to learn it. FTFY.
hyperman1 8y ago
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 8y ago
  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.

anoncoward111 8y ago

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.

jboogie77 8y ago
The only nurses who spend more time behind the computer than doctors are those who are shopping. Unfortunately the doctor profession has turned from patient caregiver to note taker
romwell 8y ago
>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 8y ago
  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.
heyjudy 8y ago
I've worked in biomedical informatics IT at a clinical research university. I think it's reasonable to understand what the user's goals and priorities are by going to the point of use, Genchi Genbutsu (現地現物), in order to tailor something to make work processes smoother and better. I wouldn't hold off on assuming anything negative without more listening to understand them.

gaius 8y ago

Similar problem in the UK https://www.theregister.co.uk/2018/01/18/nhs_buntu_trademark_cease_and_desist/ https://www.theregister.co.uk/2018/01/18/nhs_buntu_trademark... 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.

zdware 8y ago

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 8y ago
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 8y ago
  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.