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.
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.
Epic is often compared to Salesforce, which is to say even if there is a better localized app for a specialty (of which there are many in healthcare), the next questions are: How do integrate this into the other apps, how does it get into the record, how can people in other specialties receive information downstream to act appropriately from medical side to billing side. Then there's the last non-app part, what is the cost structure, what are the hardware requirements, who's going to watch it when it goes down, what disaster recovery strategies are available, what downtime-protocols should be followed when it goes down and up, who can I call when there's a problem I need fixed now, and finally who out there is already using it and demonstrated success with it?
I used to work at Epic and have seen in the field the requirements the immediate people need as I listed above. Billing driven documentation is an accurate way to label it. The software is implemented to maximize revenue for the hospitals and organizations, without reliable targeted information coverage agencies won't pay for what was supposedly done. There are whole teams in health care and applications from suites like Epic for such teams just for refining billing. A physician knows what they are ordering for a patient, a temp worker downstream refining billing data doesn't, therefore prioritizing accurate data from the physician will result in better likelihood of obtaining claims downstream. That however competes with the immediate need of the patient.
Standards like SMART-on-FHIR [1] and CDS Hooks [2] have the potential to allow innovation developed outside of Epic and Cerner inside of those products. Both of those vendors even have "App Stores" [3] [4]. So far, though, there aren't a lot of apps in these stores, and none of my doctors (all of whom work for large academic medical centers and use Epic) have access to any third-party apps - so I do wonder whether the vendors (or their customers) may be putting up roadblocks that are slowing adoption.
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.
> For startups that want to sell to health systems and similar-sized/larger entities (...), you unfortunately have to focus on the buyer, which is very rarely someone who is "in the trenches."
This is my current experience. The person bankrolling the project delivers lists of requirements, and nearly half of them end up being removed later when someone "in the trenches" either says they don't need/want it or it's too confusing of a feature.
Another part of the problem? "Confusing features" for doctors includes some very standard app features, like back buttons and refresh buttons. This honestly frightens me. We had to remove the back button -- which was requested by the buyer -- because it became a patient safety issue.
It’s true that Epic and Cerner are the dominant players when it comes to hospital EMRs, but they have less of an influence in outpatient settings outside of academic medical centers.
For larger outpatient practices that are participating in value based programs (ACOs, care bundles, etc.), such as the type apple amazon or google may choose to work with or, less likely, build, there’s less of a need to rely existing EHR vendors and a greater likelihood to rely on a variety of tools that are able to interact with each other.
The trend is for more and more care to move outpatient. There’s opportunity for innovation there.
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.
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.
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.)
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.
We had a fully integrated HL7 iphone app which could interact with OpenVista, and other systems like Vocera and Philips and Siemens systems.
So you were attempting to provide charting capabilities on the first generation iPhone? Honestly even now with larger screens, etc I can't imagine that working well on anything smaller than a tablet, and HL7 would only be a selling point to potential partners or investors - 90+% of potential end users wouldn't have a clue about it. You might as well say "our app supports JSON and EDI!"
In 2007 that would have been a dancing bear - amazing to see, but not because of how well it dances.
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.
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.
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.
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.
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.
One of the things that worries me about the not quite professional developing software of this nature is does it actually follow the regulations and restrictions that medical software needs to follow. HIPAA is not an easy thing to navigate and has deep implications on how data itself is stored.
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.
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.
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.
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?
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
[+] [-] oomkiller|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] cordite|7 years ago|reply
I used to work at Epic and have seen in the field the requirements the immediate people need as I listed above. Billing driven documentation is an accurate way to label it. The software is implemented to maximize revenue for the hospitals and organizations, without reliable targeted information coverage agencies won't pay for what was supposedly done. There are whole teams in health care and applications from suites like Epic for such teams just for refining billing. A physician knows what they are ordering for a patient, a temp worker downstream refining billing data doesn't, therefore prioritizing accurate data from the physician will result in better likelihood of obtaining claims downstream. That however competes with the immediate need of the patient.
[+] [-] bm98|7 years ago|reply
[1] http://docs.smarthealthit.org/ [2] https://cds-hooks.org/ [3] https://apporchard.epic.com/ [4] https://code.cerner.com/apps
[+] [-] megablast|7 years ago|reply
[+] [-] tracker1|7 years ago|reply
[+] [-] sli|7 years ago|reply
This is my current experience. The person bankrolling the project delivers lists of requirements, and nearly half of them end up being removed later when someone "in the trenches" either says they don't need/want it or it's too confusing of a feature.
Another part of the problem? "Confusing features" for doctors includes some very standard app features, like back buttons and refresh buttons. This honestly frightens me. We had to remove the back button -- which was requested by the buyer -- because it became a patient safety issue.
At least we don't have to target IE9.
[+] [-] dr_|7 years ago|reply
For larger outpatient practices that are participating in value based programs (ACOs, care bundles, etc.), such as the type apple amazon or google may choose to work with or, less likely, build, there’s less of a need to rely existing EHR vendors and a greater likelihood to rely on a variety of tools that are able to interact with each other.
The trend is for more and more care to move outpatient. There’s opportunity for innovation there.
[+] [-] chapium|7 years ago|reply
[+] [-] gforge|7 years ago|reply
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|7 years ago|reply
[+] [-] samstave|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] fencepost|7 years ago|reply
So you were attempting to provide charting capabilities on the first generation iPhone? Honestly even now with larger screens, etc I can't imagine that working well on anything smaller than a tablet, and HL7 would only be a selling point to potential partners or investors - 90+% of potential end users wouldn't have a clue about it. You might as well say "our app supports JSON and EDI!"
In 2007 that would have been a dancing bear - amazing to see, but not because of how well it dances.
[+] [-] zdware|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] commandlinefan|7 years ago|reply
[+] [-] derekp7|7 years ago|reply
[+] [-] BurningFrog|7 years ago|reply
With some effort and/or ingenuity, you can probably take time with your users, one way or another.
[+] [-] mothsonasloth|7 years ago|reply
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.
[+] [-] LeonB|7 years ago|reply
[+] [-] m0zg|7 years ago|reply
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.
[+] [-] maxlybbert|7 years ago|reply
[+] [-] shagie|7 years ago|reply
[+] [-] sergiotapia|7 years ago|reply
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.
[+] [-] pragone|7 years ago|reply
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.
[+] [-] AngeloAnolin|7 years ago|reply
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.
[+] [-] sonnyblarney|7 years ago|reply
Maybe I'm just crazy!
[+] [-] mehrdadn|7 years ago|reply
https://news.ycombinator.com/item?id=18145853
[+] [-] danieltillett|7 years ago|reply
[+] [-] tivert|7 years ago|reply
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
[+] [-] fencepost|7 years ago|reply
[+] [-] briandear|7 years ago|reply
[+] [-] starpilot|7 years ago|reply
[+] [-] Trisell|7 years ago|reply
[+] [-] gaius|7 years ago|reply
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|7 years ago|reply
[+] [-] hyperman1|7 years ago|reply
[+] [-] magicalhippo|7 years ago|reply
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.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] commandlinefan|7 years ago|reply
Weren’t given any time to learn it. FTFY.
[+] [-] mgamache|7 years ago|reply
[+] [-] anoncoward111|7 years ago|reply
[+] [-] romwell|7 years ago|reply
Sounds like userblaming. Works wonders when the users aren't the ones choosing the software to use, or have much input.
[+] [-] heyjudy|7 years ago|reply
[+] [-] jboogie77|7 years ago|reply
[+] [-] macjohnmcc|7 years ago|reply
[+] [-] abalone|7 years ago|reply
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.