GSoC 2024 @ OpenMRS: Week 7 | Multiple Dynamic Patient Identifier & Room Database🎉

Hey everyone! 👋

I hope you’re all doing great! This week has been quite an exciting one for me, packed with new enhancements and some cool implementations. Let’s dive right into the updates! 🤓

Last week, we successfully implemented custom patient identifier selection in our app. This week, we took it a step further by adding multiple patient identifier type selections. This feature required some significant enhancements to our application.

🛠️ Implementation Details

Previously, we were using preferences to store the single selected identifier type and the list of fetched unique identifiers. However, to support multiple identifier types and their corresponding lists of fetched unique identifiers, using preferences became too messy. So, we decided to integrate a database into our application.

💾 Database Integration

We integrated RoomDatabase with our Android app, following the steps mentioned in the official documentation.

Entities Created:

• IdentifierType
• IdentifierTypeModels

We wrote the required queries (based on our business logic) to the DAO.

🧩 IdentifierManager & PatientIdentifierManager Modifications

Based on our new data layer, we modified the IdentifierManager to store the fetched identifier types in the database. We also updated the logic for fetching the NextIdentifier so that once an identifier value is fetched from the database, it is deleted to ensure only unique identifiers are added to the patient resource.

📝 Embedding Identifiers in the Questionnaire

When a questionnaire is fetched by the user, we embed it with non-unique identifier type questions (e.g., Hospital ID number). Initially, these were not converting well when extracted from the questionnaire response and saved to the patient resource.

To resolve this, we now modify the identifier to the appropriate format before saving it as a patient resource, ensuring compatibility with the OpenMRS backend.

For unique identifier types that require server-fetching, these are embedded before the patient is saved, with the help of PatientIdentifierManager.

🔄 Complete Flow

1. Installation: The app automatically fetches the available identifier types from the server.
2. Selection: Users can select the required identifier types using the identifier type selection screen.
3. Fetching Identifiers: If unique identifiers are needed, they are fetched from the server.
4. Questionnaire: When a user opens a questionnaire, non-unique identifier types are embedded.
5. Saving: Once the questionnaire is saved, identifiers are modified, and unique identifier types are embedded.
6. Final Save: The patient is saved with the appropriate identifiers.

Check out the code changes. 🧑‍💻

🎥 Demo Video

We’ve reached the halfway point in our GSoC 2024 journey! All contributors at OpenMRS presented their projects’ progress in wonderful presentation videos. These videos are very insightful and give a glimpse into ongoing developments at OpenMRS and in the healthcare domain. You can check them out here.

[embed]

🔮 Plans for Next Week

• Redesigning the sync functionality of the app.
• Enhancing the offline functionalities of the application.

Thanks for following along on this journey! Stay tuned for more updates. 😊

Thank you for reading! Please feel free to reach out to me regarding absolutely anything! Especially anything regarding healthcare, full stack development, FHIR, OpenMRS Android, Open Health Stack, a song recommendation, etc. 🎵

You can find me on LinkedIn or OpenMRS Talk and check out my projects on GitHub.�