Medical PACS
A healthcare platform for telemedicine and teleradiology
Business context
Medical PACS is an American teleradiology and telemedicine platform that allows private hospitals and clinics to upload, store, and download their medical images like radiograms or ultrasound snapshots from a safe cloud storage.
Having implemented telemedicine functionality, Medical PACS started growing actively. We helped the company shake up its organizational and technical structures to support rapid scaling, proper user feedback processing, improved customer satisfaction, enhanced staff performance, and optimized product delivery.
Business challenge
Recently, Medical PACS learned that their satisfaction rate had dropped to 55%. The reason was that the company’s development team spent weeks processing user feedback. And the team’s backlog was crowded with new tasks, so they couldn’t react quickly to requests for fixes, improvements, and new features.
The very first solution was ramping up, and Medical PACS came to Yalantis with such a request. But after we conducted an in-depth analysis of the company’s organizational and technical structures, we discovered additional issues that were less obvious. To get rid of all of the discovered issues, we provided a more optimized solution than just ramping up. You can find more details on the solution provided below.
Auditing the clients organizational structure and processes
To provide the best solutions for the client’s business challenges, we had to audit the client’s organizational structure and technical processes. That is why we attracted our solution architect, project manager, and a business analyst to conduct a detailed investigation of:
How the client’s business operates
What the client’s development team consists of
Who dictates the changes into the product
What development and communication processes are established
Operational and development process maps
Organizational and technical bottlenecks
Possible improvements to the organizational and technical structures
Implementation roadmap for these improvements
Discovering
operational issues
Having conducted the process audit, we discovered that:
Our client used the same channel for collecting user feedback and getting new feature requests— the support form in the platform interface.
Our client’s team responded to user feedback and added new functionality only with new releases, so some end users had to wait for an issue to be resolved until the next release, which could happen in a month’s time.
The product owner could request new feature implementations in the middle of development sprints, affecting sprint deadlines and commitments to end users.
The client’s development team wasn’t chunked, and all team members developing different parts of the product were present on each other’s daily, grooming, and retrospective meetings.
With broken commitments, aggressive deadlines, and plenty of meetings, the client’s development team was demotivated and underperforming.
Solutions to fix operational processes
During the pandemic, Medical PACS had to quickly adapt to new market reality. That’s why the company was evolving the core product and adding new features only for some audiences in parallel. And there appeared different groups of people providing new requirements. To ensure high development performance and top product quality, we followed our stakeholder, change, and requirement best practices.
Stakeholder management
To obtain clearly defined business requirements for the product, we needed to define the main stakeholders. We discovered three groups of stakeholders: our clients themselves, represented by the product owner and CTO, end users, and third-party integrations. We had to manage input from all of these stakeholders and satisfy their needs during product development and support.
Implementing parallel workflows to efficiently handle development
To properly manage the inputs of all stakeholder groups, we developed the following requirement processing flows:
Core flow to further evolve the main functionality of Medical PACS
Support flow to maintain and support features
implemented only for certain groups of end users
In this way, we ensured delivery of new functionality for both the core product and separate features requested by end users. You can find more details on each flow below.
Core flow
The product owner and CTO of Medical PACS were the main source of new feature requests for the core platform. To properly handle these requests, our business analysts carefully analyzed the information received and developed artifacts to meet the client’s requirements, budget, and time constraints. Only after having validated the artifacts with our client and made the necessary changes did we add these artifacts to the development backlog.
The core flow also includes working with third parties to process information related to integrations. Our solution architect or the Medical PACS product owner are supposed to supply updates from third-party services to our technical team. This is necessary for situations when third-party services roll out a product update or a new feature that Medical PACS wants to implement. Here’s what the communication process looks like:
Support flow
As there appeared new features from the end-users, aside from the core product, it became necessary to support new functionalities. We built the feedback loop to ensure that all of the end-user feedback is properly collected and processed.
Change and requirement
management
With multiple streams of new project details and requirements, our business analysts needed to know how each new requirement impacted the entire system. That’s why they applied the requirement traceability method and created an informative requirement architecture map. The map clearly demonstrates how each newly added requirement links with related requirements and influences the overall software solution.
Want to see such a requirement architecture map?
Please enter your email address, and we’ll send the map straight to your inbox.
Transferring the process
ownership to the client
Once we set up parallel processes for requirements processing and development, we shared our experience from other healthcare projects and held a series of workshops for the client to:
Work in the new environment
Process and differentiate new functionalities for the core and support flows
Avoid the possible manual issues
Identifying technical bottlenecks
Having audited the technical structure of Medical PACS and considering the new market reality, we understood that the company needed to optimize testing procedures, and properly establish integration and delivery processes.
Implementing continuous integration and delivery for parallel development
As Medical PACS turned into a platform with a core product and extra features that can be urgently added because of the end-user feedback and feature requests, we faced the need for parallel development of two different functionality scopes:
Feature delivery according to the release plan by our clients
New functionality along with improvements and bug fixes
We had to follow the delivery timelines for the feature roadmap and to provide stable and prompt release fixes for the app in production. And, in addition to the client’s team ramping up, we implemented the industry-standard environment map:
A development environment in which developers can easily deploy new functionality, fixes, and improvements
A staging environment where QA engineers can perform required testing
A pre-production environment where tested and improved product versions are released and tested one more time for quality and stability
Speeding up development
for the support flow
The core development flow is predictable: features are released to pre-production according to the release plan and roadmap, or on demand if necessary. This way, nothing is lost between different development flows and platform functionality is delivered in a timely manner. But with the support flow, bug fixes, improvements, and other urgent requests need to be implemented faster.
To speed up the implementation of urgent fixes and feature requests, we strengthened the environment architecture by adding multiple servers instead of a single staging server. This allowed Medical PACS to work with multiple tasks at once, delivering improvements, fixes, and new functionality much faster than before.
Increasing testing
speed with automation
Our quality assurance experts carefully studied our client’s testing processes and realized that regression testing was one of the biggest bottlenecks in the production pipeline. This testing was performed manually, and with different product versions it took too much time.
To save the client’s time on product delivery, our test automation engineers built an automation testing framework that allowed the company to:
Run automatic tests at any time and in parallel
Change testing scenarios (for example, start testing right from image uploading instead of registering a new account)
Implement case changes on all testing levels (For instance, if we add a crop function for uploading medical images and a test for it, the automation testing framework will also check image comparison functionality)
This not only allowed the company to save a lot of time but also reduced human errors. In addition, we made the automatic tests part of the CI/CD system so that each new development commitment automatically triggers a new test.
Enhancements delivered
Optimized user feedback processing
It took weeks or months to process end user feedback and implement bug fixes and feature requests.
Now it takes two days for Medical PACS to process high-priority tickets from end users and one day for urgent bug fixes and updates.
Increased customer satisfaction
A customer satisfaction survey showed that only 55% of users were enjoying the platform.
Medical PACS conducted a new customer satisfaction survey that showed an 87% satisfaction rate.
Enhanced team performance
The company’s whole development team was involved in all meetings and sessions, losing precious time on unnecessary meetings.
Having chunked development teams for parallel development, team members spend 70% less time on synchronization meetings.
Improved employee satisfaction
Previously, the employee satisfaction index (ESI) was 43%, and developers felt demotivated.
With improved collaboration, adherence to the Agile methodology, and less time spent on unnecessary meetings, the development team’s satisfaction has grown to 85%.