Failed Architecture – Building medical patient record management

Standard

In the last article, we witnessed how a simple task of building a static website can throw some unique challenges. Every application has its own quirks which need special attention and hence an architect must not hesitate to reiterate the solution. An architect must spend rigorous time on investigating the functional aspects of an application. What may sound a brilliant solution for one problem, may not be fit under all circumstances. There was no better era than what we are witnessing now in the architecture space. People are discussing Microservices architecture, Event sourcing, Serverless architecture, Blockchain etc., each trying to solve problems enforced by expectations placed by today’s Problem domain. Choosing an incorrect pattern or architecture style will lead to many problems including rigid systems, unmanageable infrastructures, traceability issues, debugging challenges, upgrade chaos. The list is unending and most of us have already experienced pain at some point in time. With this article, we will raise the expectation bar than the previous problem and look at poor architecture built for Managing Patient Record, Reminder system.

It was 9 o’clock in the morning, Kelly just recollected that she was supposed to have a medicine dose for her diabetes treatment at 8:30 a.m. She just nodded and looked in the mirror, asking herself “Why am I missing the medicine dose?”. It has been a nightmare for Kelly to remember medicine schedule. With variety of tablets and liquids to consume, Kelly was already fed up. She also missed few appointments with a doctor(Dr. Jones) due to hectic work schedule. Kelly couldn’t help herself and thrashed out all frustration in front of Dr. Jones. The problem was pretty serious, as Kelly’s health was not showing any improvements from last one month. Dr. Jones realized this problem is experienced by many of his patients and also his fellow colleagues reported similar issues. Dr. Jones thought of finding a solution and contacted Mr. Freddy (Software architect) to build a system which can help patients to manage medicine schedules, appointments with doctors and manage a family health information. Freddy was excited to build the solution and he had the first meeting with Dr. Jones to discuss problem domain. Dr. Jones said

I need a system which helps my patients to keep track of their medical records. Records include managing medicine schedules, medical history, medical appointments, family health information. I would also like to include a section which can help to spread awareness about latest situations. Plus, it should enable users to order Medicines. The system will be used by both Medical practitioners and their staff along with Patients. So make sure, it is accessible via web and mobile app both.

Freddy was quite happy to have Dr. Jones on his client portfolio because Dr. Jones was highly respected in Medical world and owner of hospital chains throughout the state. He knew this application can bring him a fortune. He quickly jumped to building a sketch of what might sound a good Solution to the problem.

Medical System

Medical System

Freddy also mentioned that there is a Network Access Storage used to store static data like images, scripts, styles, documents etc. It is shared by all the application servers and web servers. Freddy gave a walk-through of the architecture to Dr. Jones and convinced him that the given architecture is the best fit for his requirements. Freddy also mentioned he will be building a web portal to provide a customized experience for patients. Plus a hybrid mobile app which will work on major Mobile Platforms. The hybrid technology will also save time and money. Dr. Jones was quite confident about Freddy and he never thought of having a second opinion about the proposed architecture.

Freddy kick-started the project with 6 developers having 2-3 years of experience and two technical leads with 8 years of experience. Technologies he used were mostly from a commercial vendor and required development licenses. He also employed 2 members for manual testing. Things started rolling on. The development team had less experience of writing code based on SOLID principles, plus they also missed the importance of writing good Unit test cases. Testing team, on the other hand, relied heavily on Manual testing and had no willingness to automate things. The laziness of both the parties overshot 6 months development to 12 months. With lots of debates and heated arguments, too many things were de-scoped to meet launch dates. Finally, the launch date arrived and Dr. Jones started marketing the new mobile App – MedicineAssistant.

Marketing made best efforts and soon the application download cross 10,000 installs on both Android and iOS platform. Dr. Jones was happy to see his dream shaping up. But, there was a bad news. Users started reporting problems,

  • Sometimes application screen will go blank and app needs to be restarted several times.
  • Data was not reliably stored and need to be reentered again.
  • App consumes lot of internet bandwidth and battery.
  • Alerts are not reliable. Most of the time it doesn’t ring.
  • Registration process is pain. Requires a lot of information. Confirmation process is designed poorly.
  • The experience across Web and mobile is not consistent.

Developers started addressing tickets and started patching the system. Unfortunately, due to lack of quality Unit test cases, patches introduced additional bugs. The system needs to be taken down several times to apply new patches. This further hampered user experience. Dr. Jones was growing anxious about the application.

One day Dr. Jones was treating Bob (our famous celebrity). Bob mentioned that he has launched a new site and it’s going well. Dr. Jones out of curiosity explained his situation with MedicineAssistant and asked if Jim (our super architect) can help in this situation. Bob introduced Jim to Dr. Jones.

Jim took the responsibility of reviving the application and started investigating the architecture, development practices, contingency plans, deployment procedures etc. He realized the application was not designed to handle the scale plus lack of quality development practices has jeopardized the application health. He shared his primary observations with Dr. Jones

Architecture

  1. While there are provisions to distribute the load, there is high contention on Database. It is shared across all application servers.
  2. API used for Mobile and Desktop are same. Hence the amount of data transferred between mobile clients and API is consuming power and bandwidth.
  3. No physical separation of modules (Monolith) forcing deployment of an entire application.
  4. Modules are highly coupled with each other.

Development

  1. Developers lack understanding of well-defined principles – SOLID, DRY etc. The application has been poorly coded.
  2. The absence of Unit test cases makes it hard to detect bugs injected due to change.
  3. No well-defined processes for Code Review, documentation, onboarding, analysis.

Operations

  1. Manual deployment requires efforts to publish new changes.
  2. There are no sufficient tools to monitor the health of application and infrastructure nodes.
  3. Poorly coded queries are putting the heavy burden on Database.
  4. Circuit-breakers, caches etc are not utilized and hence the system is always under heavy stress.

Troubleshooting

  1. Logging statements are not associated with Co-relation ID and hence logs are difficult to parse for given request.
  2. Data is not logged sufficiently to trace the cause of the problem.
  3. Debugging an issue requires deploying entire application.
  4. Parity between production-development environment is high

Jim clearly expressed his views and said,

Unfortunately, I have to say this, but this is failed architecture. There are many concerns with the application. We can still revive this application. By next week, I will be ready with the plan.

Be Sociable, Share!

Leave a Reply

Your email address will not be published. Required fields are marked *