Darshan Desai has worked in other industries before, writing software in both enterprise SaaS and finance spaces. But since starting in healthtech, he’s noticed a difference in the way his role as a developer at the company works.
“As a developer in the healthcare tech space, you have to really be fairly cross functional and work with different groups of people,” he said. “Because you’re dealing with regulations and a lot of legal handcuffs, shipping a product ends up taking a lot of different folks.”
Desai works as a software developer at Chapter, a healthtech startup that compares and recommends Medicare plans for its users. Desai said he gets a lot of satisfaction out of helping users navigate the complicated Medicare landscape and seeing the impact his work can have on users’ lives.
What Is It Like to Work as a Developer in Healthtech?
- Patient data is highly regulated. HIPAA introduces unique challenges for developers, who often need to find creative strategies and write more custom code.
- Developers need to interface with older systems. Many technology interfaces in healthcare are outdated and slow to change.
- Understanding the user is especially important. A product’s success depends on how well it integrates with users’ existing processes.
- A sense of making a difference. Many developers feel satisfaction and excitement working in healthcare.
Because the healthcare industry encompasses everything from clinical visits to medical software, developers who work in different areas and at different companies will have a variety of experiences. But the developers that Built In spoke with all talked about how rewarding the work can be. At Chapter, Desai has seen first-hand how technology can make healthcare processes much easier and faster, and he enjoys doing work that helps make users’ lives less stressful.
But software development in the healthcare industry also poses unique challenges. Desai said being a developer in healthtech means wearing a lot of different hats and taking on diverse responsibilities. That’s because existing technical infrastructure is often outdated, and it takes bringing everyone’s skills to the table to create good products that will benefit real users.
Even more than in other industries, software developers working in healthtech must build strong relationships with end users, learn how to work within strict legal regulations and build many technical tools from scratch.
All Developers in Healthcare Are Affected by HIPAA
Regulations around patient data affect everything healthtech companies do. Non-compliant companies are subject to significant fines and even prison time for severe violations. The law that governs all this is the Health Insurance Portability and Accountability Act of 1996, known in the industry as HIPAA, which outlines privacy, security and breach notification standards for all protected health information.
“HIPAA leads to a very different way of building out some of the software,” Desai said. Not only do software products have to protect patient data from leaking out externally, but they also have to tightly restrict and track internal employees’ access.
That has big implications on how software is architected and developed, and also on the availability of external tools development teams can rely on. In many industries, software development piggybacks off the work of existing products and libraries created by other developers, both from open source and enterprise products. But in the privacy-conscious healthcare industry, developers can’t just use any tool that’s available online. Tools have to be approved for HIPAA compliance, and many simply are not equipped to handle the necessary security and logging concerns HIPAA requires. That results in a much more limited pool of tools available for developers, and the ones that exist are usually more expensive.
“There’s a higher barrier of entry,” Desai said. “It’s harder to start a healthcare tech company because you just need more capital to get HIPAA compliance.”
Chapter is currently dealing with that issue managing their own customer data platform. There are many CDP products available, but none HIPAA compliant, so for now, developers have created workarounds and internal systems for storing that information until one becomes available.
HIPAA Concerns Are Especially Important for Internal Data
At ESO Solutions, where Jessica O’Connell works as a senior software development engineer, all developers are required to complete annual HIPAA training. The company helps hospitals share patient care data with emergency medical services like ambulance and fire response teams, so developers are well acquainted with the challenges of wrangling patient data under HIPAA.
ESO’s annual training gives its employees a foundation for understanding the purpose and responsibilities of HIPAA, but the real education occurs on the job, when developers deal with the real-world implications of the law on software development. One effect is that development environments, where developers have access to data and do the bulk of their work, must mask all protected health information so employees cannot see personally identifiable information.
“So having completely scrubbed databases and no identifying data about any patients,” O’Connell said. “Any piece of information that would be an identifier, like first name, last name, address, phone number, any kind of personal information, we just swap it out.”
O’Connell said the company’s old process was to “scrub” the development environment databases by removing any identifiable information that can be removed, substituting others with random strings, and breaking links across tables to prevent developers from executing data queries. That might involve actions like removing names and replacing addresses with random strings.
“This has to be secured, and there can’t be any points where this data is traveling over the internet in plain text.”
Those processes help the company stay HIPAA-compliant, but doing so introduces new challenges developers have to work around. One of ESO’s primary services is providing EMS companies and hospitals with patient care data that gives insight into patients’ entire care experience, from before their EMS pickup all the way to when they are discharged from the hospital.
“It links your pre-hospital care to the outcome you’ve had at the hospital, and it will give feedback to the EMTs on how well they did and how it impacted what happened to the patient while at the hospital,” O’Connell said.
Having enough data and the right data for each patient is essential to that service, but it’s tricky to accomplish — patient data comes from many disparate sources and needs to be pieced together by ESO developers. Because they aren’t allowed to access identifiable patient data in the development environment, developers have to find creative ways to compile patient data so the information is accurate and compliant with HIPAA.
These challenges are common in healthtech software development, and any system that has the possibility of dealing with protected health information needs to be accounted for.
“From the beginning, we have to mark the components in our system that are going to be interfacing with [protected health information],” said Michael Wilkinson, a software developer for Intelligent Medical Objects, a platform that streamlines data entry workflows for physicians. “This has to be secured, and there can’t be any points where this data is traveling over the internet in plain text.”
IMO’s product has a search component where physicians can input a patient’s health concerns to find corresponding resources. That search capability opens up a potential source of incoming protected health information, so developers have to assume that all information coming in from the search input is protected data. HIPAA compliance also requires healthtech companies to carefully track all interactions with protected health information, including internal interactions by developers and other employees.
“Any point where it’s going to be accessible, intentionally or unintentionally, by someone within the system, there needs to be accountability built in — so we know if it was accessed, who it was accessed by and if they had the means to do so,” Wilkinson said.
That means developers have to build out robust logging systems, so any interaction with protected health information can be recorded and traced back in the event of a breach.
Healthtech Developers Need to Deal With Older Systems
Software development in healthcare also requires interfacing with systems that aren’t standard in other industries and are often significantly older and out of date.
“The main method of integrating with hospitals is using a really old file format called HL7,” O’Connell said. “It’s a way hospital center systems integrate with other systems.”
No other industry uses the standard, so support for troubleshooting can be spotty. The format is delimited text files that need to be parsed by developers and, according to O’Connell, can be challenging to work with. Finding the right pieces of information is sometimes difficult, especially when hospitals send different versions of the format that have alternative structures.
Like most things in healthtech, the difficulties of interfacing with hospital data are slowly changing. O’Connell said there is a push for hospitals to adopt the new FHIR format, which allows developers to connect using APIs and bring hospital-data interactions into the modern age.
Old technology processes in healthcare can manifest in different ways. Desai said that until recently, Chapter developers could only get the data they needed about drug prescription plans from the Centers for Medicare and Medicaid Services shipped through physical mail.
“Prescription drug data would change every month, and the only way for developers to get access to that data was getting mailed a 512 megabyte flash drive,” Desai said. “CMS would mail it as a flash drive when we first started, and that’s how we would get data from them.”
Covid finally forced CMS to modernize that process to avoid delays in the mail delivery system. Developers are now able to download the data off the CMS website.
Getting Customer Needs Right Is Most Important
Healthtech developers often emphasize the importance of understanding customer needs in the industry. Systems are often complex and interdependent, easily disrupted by new processes that can create frustrations for healthcare workers if they aren’t well designed. Each healthtech company’s success depends on how well its product can fit within existing healthcare processes.
Developers trade cautionary tales about creating products that hinder rather than help users. Since working in healthtech, O’Connell started noticing healthcare workers’ frustrations when interacting with her own healthcare providers.
“I would go to the doctor’s office, and they would complain about their software,” O’Connell said. “They had engineers designing it, not UI engineers — it makes a big difference when you invest in the way you input data as well as how you capture it.”
“Knowing that your software is helping get people better healthcare, you can take pride in that.”
Jessica Emond, director of communications at IMO, said physicians sometimes experience burnout when using poorly designed software tools.
Wilkinson said products should be designed intuitively so they cater to the users and not the other way around. “The thing [users] care about most is they want to spend as much time away from the computer, and with the patient, as possible,” he said. “So anything we can do to make it so that our applications are intuitive, and faster and work the first time.”
“You want your application to be performant,” said Eswar Chennupati, who also works as a software developer at IMO. “You think, ‘What can I do to make the applications better? How can we design it better?’”
ESO tries to get ahead of this problem by recruiting people who have worked in the types of roles the company’s users work in. Many employees have backgrounds in emergency services and now work at ESO as product managers to shape how products are developed.
“We have ex-fire chiefs, we have EMTs … some people even used our software before we hired them,” O’Connell said. “They know how to prioritize what needs to come first … We need to increase our feature set in the right order to most effectively help [EMT] customers and give them what they need, as fast as possible in the best order.”
This close connection to the product’s users contributes to developers’ sense of satisfaction working in the industry, and some developers also find its regulatory and technical hurdles exciting because they are opportunities for developers to make significant impacts.
“One thing I like about working in healthcare is the helping people aspect,” O’Connell said. “Knowing that your software is helping get people better healthcare, you can take pride in that.”
