I’m Amrita P. , a dev/1 contributor. I’ve been contributing to OpenMRS for ~3 months. I’m preparing my GSoC 2026 proposal for the Patient Visit Summary Printing project and had a few questions after going through the project wiki and requirements:
1. Target module — The project mentions Java, Hibernate, and Spring as the tech stack. Should this be built as a new report type within an existing module, or as a separate standalone module?
2. Print UX — The wiki mentions “preview before print” as a consideration. For the GSoC scope, would a simple click-to-print flow (button → PDF → browser print dialog) be sufficient, or is a preview/edit modal expected?
3. Section configurability— Should sections like vitals, diagnoses, medications, etc. be configurable at deploy-time (through server-side configuration), or should clinicians be able to select/deselect sections at print-time?
4. Data scope within a visit — Should the summary pull data from all encounters within the visit, or only specific encounter types (e.g., only form-backed encounters)?
5. Billing section — The mockup includes a billing summary. How should sites that don’t use a billing module be handled? Should it gracefully hide, or is billing considered optional for the initial scope?
6. Coordination — I noticed there’s ongoing work on O3 forms printing. Are there any conventions or coordination points I should be aware of to avoid conflicts?
Any guidance from the mentors or community members would be really helpful. Thank you!
▎ 1. Target module — The project mentions Java, Hibernate, and Spring as the tech stack. Should this be
built as a new report type within an existing module, or as a separate standalone module?
We plan to use the patientdocuments module to generate this, as it already has a standard setup for generating such documents.
▎ 2. Print UX — The wiki mentions “preview before print” as a consideration. For the GSoC scope, would a A simple click-to-print flow (button → PDF → browser print dialog) be sufficient, or is a preview/edit
modal expected?
Yeah. If users can preview the template, that would also be a plus.
▎ 3. Section configurability
The idea of sections being configurable is great, as this allows users to decide what shows up in the final report. The more flexible the report generation is, the better.
▎ 4. Data scope within a visit
The same rules about reports being flexible apply here.
▎ 5. Billing section
Within the scope of this GSoC project, we should try to focus more on generating a report for the
clinical information. This report needs to be flexible, some implementations might need billing while
others may not. So the idea of sections being configurable is great, allowing users to decide what shows
up in the final report. The code needs to be written in a way that we can support any module in the
future, not only billing.
If I’m missing something, I think @ibacher or @veronica can weigh in.
Thank you @wikumc. I just want to reiterate that configurability is key, as different implementations may need tailored summaries — varying not only in clinical content but also in administrative information like billing. The summary should be designed to accommodate this flexibility.
Welcome, and thanks for the detailed questions! Here’s some guidance based on typical GSoC scope and OpenMRS conventions:
Target module For GSoC, it’s usually simpler and safer to implement this as a new report type within an existing module (like the Patient Visit module) rather than a standalone module. This ensures easier integration and reuse of existing APIs and data models.
Print UX A simple click-to-print flow (button → PDF → browser print dialog) is generally sufficient for the initial scope. A full preview/edit modal can be considered an enhancement if time permits, but it’s not required for GSoC.
Section configurability At first, server-side deploy-time configuration is preferred. Allowing clinicians to toggle sections at print-time is nice-to-have, but it can complicate the frontend and should be optional for the initial implementation.
Data scope within a visit Typically, the summary should include all encounters within a visit, to give a complete snapshot. If certain encounter types are irrelevant, these can be filtered via configuration.
Billing section Billing should be optional. If a site doesn’t use billing, it’s fine to hide the section gracefully. The module should not fail if billing data is missing.
Coordination with O3 forms printing Yes, it’s a good idea to check existing O3 printing conventions (like naming, CSS for PDFs, and ESM module structure). Coordinate with the developers working on forms printing to avoid duplication of code and inconsistent UI patterns.
Overall, for GSoC, aim for a minimal viable feature set that works end-to-end and is configurable enough to handle the main use cases. Additional enhancements (preview modal, per-user section selection, billing integration) can be follow-ups or stretch goals.