Suggestions & Next Steps for the Patient ID Stickers

Development
,
1

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.
  1. 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.
  1. Store Configurations in System Settings
  • Move sticker printing configurations from the frontend to OpenMRS system settings.
  • Ensure settings are easily configurable for different implementations.
  1. 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.
  1. 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

2 Likes
2

@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.

3

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

Screenshot 2025-03-13 at 16.33.01
Screenshot 2025-03-13 at 16.33.011294×932 15.3 KB

1 Like
4

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…

1 Like