Project DMP 2025: Update of FHIR 4 APIs modules

Summary

The current FHIR R4 module in openIMIS is monolithic and tightly coupled, with real-time data transformation causing significant performance bottlenecks. It is difficult to maintain, scale, or extend due to its complex structure and synchronous processing model.

Current Issues with the FHIR R4 Module

• Monolithic Architecture
  All FHIR resources are bundled together, making the codebase bulky and hard to manage.

• Lack of Asynchronous Processing
  All operations are handled synchronously, leading to timeouts and poor performance during high-load scenarios.

• Slow Performance
  The current synchronous and tightly coupled design results in latency and slower throughput.

• Poor Maintainability and Scalability
  Difficult to isolate, update, or scale individual FHIR resources without impacting the entire module.

Objectives

1. Break down the FHIR R4 module into smaller, modular Django apps.

2. Implement asynchronous background processing for resource conversion.

3. Improve overall performance and reduce load on the main application.

4. Make the codebase easier to maintain, test, and extend.

5. Enable better scalability for future FHIR resource additions.

Task Issue

https://github.com/openimis/openimis-be-api_fhir_r4_py/issues/196

Pull Requests

https://github.com/openimis/openimis-be-api_fhir_r4_py/pull/197

Weekly Learnings & Updates - C4GT DMP

Week 1

• Onboarding meeting with mentors to discuss the project.

• Attended my first developers’ call.

• Set up the project locally.

Week 2

• Discussed the project milestones with Patrick.

• Read about the OpenIMIS system and FHIR compliance.

Week 3

• Worked on resolving issues and errors while setting up the openimis-backend-core.

• Discussed workers, tasks and ways to simulate asynchronicity.

Week 4

• Modularized each FHIR resource into a separate Django app.

• Suggested to review how endpoints are defined.

• Advised to do all development locally.

Week 5

• Worked on a separate branch and pushed the updated changes there.

• Successfully separated each FHIR resource into individual Django modules.

  • This ensures that future modifications to a specific endpoint are easier and more accessible for developers.

Week 6

• Completed mid-term evaluation → (Mid-term evaluation slides).

• Discussed next steps, focusing mainly on introducing asynchronicity for FHIR endpoints.

Week 7

• Faced issues as local development broke again → troubleshooting with Patrick.

• Suggested to explore the FHIR forum and learn about bundles.

Weeks 8 & 9

• Continued working on the asynchronous part of the FHIR API.

• Learned about GraphQL and how it is implemented in backend-core.

Week 10

• Discussed incorporating <task_id> for various FHIR endpoints.

  Open

  

  Sample Implementation of API calls

• Received feedback that the above diagram is not FHIR compliant.

• Suggested to wrap <task_id> inside the code field of OperationOutcome.

Week 11

• Worked on incorporating <task_id> inside the OperationOutcome resource.

Week 12

• Completed Final Evaluation → (Final evaluation slides)
  
  

Resources

https://github.com/openimis/openimis-be-api_fhir_r4_py

https://github.com/openimis/openimis-be_py

https://fhir.openimis.org/

https://pypi.org/project/openimis-be-api-fhir-r4/