Introduction: The Healthcare Challenge
Miscommunication is a common issue in everyday life, in the case of healthcare, it can have serious consequences. In clinical settings such as general practice, telehealth, and urgent care, accurate communication between patients and healthcare professionals is critical for safe and effective diagnosis and treatment.
One of the most important steps in any consultation is collecting information about a patient’s symptoms. However, this process can be disrupted when patients struggle to describe their symptoms clearly, or when time constraints prevent doctors from asking detailed follow-up questions.
This can result in:
- Incomplete clinical records
- Misdiagnosis or delayed diagnosis
- Longer consultation times
- Increased risk to patient safety
Example of Doctor and Patient Miscommunication:
The challenge lies in patients’ understanding of how to describe and measure their symptoms. Often, they spend extra time trying to answer general medical questions, which can lead to delays and reduce the time healthcare professionals have to focus on more critical aspects of patient care.
To help address these issues, I propose building a Symptom Pre-Fill API, a backend tool that allows patients to enter key health information before their consultation. This system would support clinicians (including GPs, nurses, and specialists) by providing structured, relevant symptom data ahead of time. The goal is not to replace human interaction, but to enhance it by giving doctors a clearer starting point and reducing repetitive questioning.
The Problem
In one study, researchers compared the symptoms patients wrote on intake forms with those doctors recorded during the consultation. Alarmingly, in one out of every three cases, at least one patient-reported symptom was not documented by the physician (Pakhomov et al., 2008). This kind of information loss is surprisingly common and can occur due to time pressure, unclear descriptions, or differences in how symptoms are expressed and interpreted.
While personal health tracking tools are becoming more popular, they are bringing their challenges. A 2014 study found that not all self-reported data is clinically useful, and physicians often need to filter through irrelevant information to find what truly matters (West et al., 2014).
When general practitioners (GPs) are rushed or must rely on incomplete or misunderstood patient input, it can lead to:
- Missed or overlooked symptoms
- Rushed or superficial interviews
- Inaccurate or unstructured medical notes
As noted in the RACGP’s Clinical Information System guide:
“High-quality health records support good patient care and facilitate:
• safe clinical decision making
• effective communication between health professionals
• trusting partnerships with patients
• coordination and continuity of care.”
— The Royal Australian College of General Practitioners (RACGP)
These issues highlight a clear need for better tools that are able to support accurate, structured symptom reporting to improve communication, reduce the cognitive load on both patients and doctors, and ultimately lead to better outcomes.
Attempted Resolution: The Symptom Pre-Fill API
To address the communication gap between patients and healthcare providers, I developed a backend Symptom Pre-Fill API. This tool helps the patients to enter structured symptom data (e.g. pain severity, duration, affected areas) before their consultation. The goal is to provide doctors with concise, relevant health information in advance, helping them better prepare for and focus on the in-person discussion.
This approach offers a balance between efficiency and clinical accuracy, without replacing the human interaction that is central to medical care.
Key Features
- Customizable Forms: Healthcare providers can tailor symptom questions based on condition types or clinical focus (e.g., flu-like symptoms, chronic pain, mental health). This flexibility improves data relevancy and patient engagement.
- Multiple Choice & Input Validation: The system offers structured input options (e.g., yes/no, severity scales, duration pickers) and validates user entries. This minimises ambiguity and ensures the completeness and consistency of patient-provided data.
- Secure Data Storage: Patient submissions are stored in a MongoDB database using data sanitisation and access control. Sensitive health data is encrypted in transit, and authentication is implemented to restrict access to authorised healthcare staff only.
- Summary Generation: Upon form submission, the system compiles responses into a short, structured summary. This is made available to the healthcare provider before the appointment, enabling quicker and more informed consultations.
Technical Implementation
The project was built using the following stack:
- Node.js: A fast and scalable JavaScript runtime, ideal for building lightweight APIs.
- Express.js: A minimalist web framework for Node.js that simplifies routing, middleware, and request handling.
- TypeScript: A typed superset of JavaScript that adds static type checking, making the codebase more reliable, maintainable, and less prone to runtime errors.
- MongoDB: A NoSQL database that supports flexible, schema-less data storage. This makes it suitable for storing diverse patient inputs, where fields may vary depending on the symptom type.
- Mongoose: An ODM (Object Document Mapper) used for validating data, defining symptom schemas, and maintaining consistency.
The API design follows RESTful principles, to integrate easily into future front-end interfaces or existing clinical information systems (CIS). It includes endpoints for creating, updating, and retrieving symptom data, all with secure request handling and validation.
API Example Diagram
The following flowchart illustrates how the Symptom Pre-Fill API serves both the patient and healthcare provider sides of the consultation process. Patients begin by submitting structured symptom data through a secure endpoint. This data is then stored in the backend database. Later, authorised medical staff can access this information using a secure, authenticated dashboard to review and prepare for the consultation.
Ethical and Privacy Considerations
Handling sensitive patient data demands strict adherence to ethical standards and privacy regulations. The Symptom Pre-Fill API prioritises patient safety, data confidentiality, and compliance with healthcare laws with the following:
- Data Minimisation: Only essential symptom data is collected to avoid unnecessary exposure of personal health information.
- Informed Consent: Patients must be informed about how their data will be used, stored, and shared with healthcare providers.
- Access Control: The system implements JWT-based authentication ensuring only authorised healthcare professionals can access patient records.
- Data Security: All data is transmitted over encrypted HTTPS connections. Sensitive fields are sanitised and stored securely in MongoDB with appropriate user-level access restrictions.
- Auditability: Changes and submissions are logged to maintain an audit trail with accountability and error tracking.
- Patient Safety: The API serves as a clinical support tool, not a diagnostic replacement. Clear disclaimers inform users and providers that clinical judgment remains paramount.
By integrating these principles, the API respects patient autonomy and privacy while fostering trust between patients and healthcare providers.
Skills Gained
This project helped me develop self-learning skills by completing an end-to-end coding solution using a programming language I had not used before. It was my first time working with TypeScript. While I initially struggled with type declarations and route handler syntax (e.g., needing to specify Promise<any>), I was able to debug and resolve these issues independently.
More importantly, I learned that real-world development requires collaboration, especially when designing tools for broad use in sectors like public health. I also became more confident using REST APIs, TypeScript typing, and Mongoose schemas.
Challenges and Future Work
There were several challenges I faced during this project:
- Learning TypeScript: I was unfamiliar with TypeScript initially and had to spend time understanding type declarations and resolving errors.
- Design Complexity: This project covers both patient-facing and doctor-facing workflows. It was confusing sometimes to separate logic for different user types (e.g., who submits data and who reviews it).
In the future, I plan to:
- Build a frontend for patients to prefill symptoms using this API
- Allow hospitals to customise the form by department (e.g., cardiology vs dermatology)
- Support multi-language forms
- Create an admin dashboard for doctors to review submissions
- Integrate with Electronic Health Records (EHR) systems
References
- McCabe, R. and Healey, P.G., 2018. Miscommunication in doctor–patient communication. Topics in cognitive science, 10(2), pp.409-424.
- Hayes, A.J., Pool, R., Roughley, C., Scholes, S., Sharifi, L., Woodside, R., Reilly, S., Roberts, P., Salter, T. and Singleton, L., 2018. Communication and Miscommunication: Handover between Junior Doctors. Reinvention: An International Journal of Undergraduate Research, 11(1).
- Morgan, S., 2013. Miscommunication between patients and general practitioners: implications for clinical practice. Journal of Primary Health Care, 5(2), pp.123-128.
- Beckingsale, T. B., & Greiss, M. E. (2011). Getting off on the wrong foot: Doctor–patient miscommunication: A risk for wrong site surgery. Foot and ankle surgery, 17(3), 201-202.
- Serguei Pakhomov, Jacobsen, S.J., Chute, C.G. and Roger, V.L. (2008). Agreement between Patient-reported Symptoms and their Documentation in the Medical Record. The American journal of managed care, [online] 14(8), p.530. Available at: https://pmc.ncbi.nlm.nih.gov/articles/PMC2581509