Suggestions & Next Steps for the Patient ID Stickers

[jnsereko (Joshua Nsereko)]

Background

The current implementation of Patient ID sticker printing relies on frontend logic, which can introduce delays in PDF generation. To improve performance and maintainability, its recommended to shift the sticker generation process to the backend. Configuration can look like this

Suggestions

1. Move Sticker Processing to the Backend

• Shift PDF generation from the frontend to the backend to improve performance and reliability.
• Use a dedicated OpenMRS module (openmrs/openmrs-module-webservices.rest ) for handling sticker creation.

2. Implement a REST API for PDF Generation

• Create an API endpoint that accepts sticker configuration as JSON and returns a PDF.
• Ensure the API can handle multiple sticker layouts and configurations dynamically.

3. Store Configurations in System Settings

• Move sticker printing configurations from the frontend to OpenMRS system settings.
• Ensure settings are easily configurable for different implementations.

4. Update Frontend to Use the New API

• Remove frontend-based sticker configurations.
• Modify the frontend to request PDF stickers from the backend and display/download them accordingly.

5. Validate Design and Performance

• Ensure backend-generated PDFs match the existing sticker layout.

Next Steps

Task	Action Required
Interact with other interested implementors	Interact with other organizations for further requirements gathering
Select the backend module	Identify the best OpenMRS module for handling PDF generation
Develop REST API	Create an endpoint that generates and returns sticker PDFs
Move configurations to system settings	Store all sticker-related configurations in OpenMRS settings
Update frontend integration	Modify the frontend to request PDFs from the backend
Test and validate	Ensure PDF output matches expected design and performance

Questions

What do you think about the above?
Which other Patient ID sticker features/requirements would you need in your organization?

cc @grace @vasharma05 @ibacher @mksrom @michaelbontyes

[ibacher (Ian Bacher)]

@jnsereko If you want to solicit feedback on the design here, I think rather than focusing on the implementation details, we need to focus on what the actual input looks like and what sort of output it can generate. That’s where people will have requirements. The technical stuff is just details.

All that said, I’m not sure that system settings are the appropriate place to store these. Again this goes to requirements: does everyone only need a single format or do we need the format to be flexible / adaptable to something about the location / patient / user / etc.

[jnsereko (Joshua Nsereko)]

@ibacher

we need to focus on what the actual input looks like and what sort of output it can generate. That’s where people will have requirements.

My initial thought was to pass a JSON configuration Object and return a PDF that looks like in the screen cast below.

[mksrom (Romain Buisson)]

Hi @jnsereko , thanks for bringing up that topic. I really would love to see proper printing functionality available with configurability.

IMO, it looks like leveraging on the OpenMRS Module Reporting and its REST API could already bring us a long way. This has the advantage to not be specific to patient sticker, but be easily extendeded to patient card, prescription, referral letter, consent forms…

To keep your focus on the sticker, you could design a configurable dedicated report, possibly brought by its ow module (openmrs-module-printingtemplates? or something) that others could leverage on.

What do you think?

Those patient cards and stickers need likely to be highly configurable. Not a single facility will want the same layout. Let alone paper format constraints, logos, barcodes, QR codes, patient picture…

[jnsereko (Joshua Nsereko)]

@mksrom

you could design a configurable dedicated report, possibly brought by its ow module (openmrs-module-printingtemplates? or something) that others could leverage on.

Thank you @mksrom. I prefer this approach.
Would it be equally fast (or even faster) like passing a JSON configuration Object and returning a PDF?

We are primarily focused on the approach that ensures the least processing time. Given that nurses handle thousands of patients daily, it is crucial that the PDF is generated and available immediately upon clicking the print button.

[mksrom (Romain Buisson)]

That I can’t quite tell. In both cases you would need to retrieve the patient data from the backend. I’m pretty sure such a small report can be instantly generated by the Reporting module.

The added value of using the Reporting framework is that it’s already there, it’s highly tested and testable, highly configurable and the functionality (ability to generate and print OpenMRS Reports from the UI) will become reusable everywhere else in O3.

@mseaton might know better for the technical details.

[mksrom (Romain Buisson)]

Additionally, regarding the configurability of a backend report, we have done something similar in our Common Reports (eg, Antenal Report) module where a configuration JSON is provided as config to the report using the jsonkeyvalues domain of Iniz:

configs/openmrs/initializer/jsonkeyvalues/antenatalReportConfig.json

[michaelbontyes]

Hi @ibacher , @mksrom , @mseaton , @fiona, can you schedule a call together this week to decide on the approach, estimate, and assign some time? Would this Friday at 8:00 am EDT / 2:00 pm CET work for you? Thanks