GSoC 2026: Patient Visit Summary Printing — Project Updates & Discussion

Community GSoC
1

Hello everyone!

I’m Amrita, and I’ll be working on Patient Visit Summary Printing for OpenMRS O3 this summer as part of GSoC 2026. I’ll be using this thread to share weekly progress updates, ask questions, and have discussions throughout the project. Feel free to follow along, drop feedback, or just say hi :grinning_face_with_smiling_eyes:

What this project is about

Right now, if a clinician at an OpenMRS-powered facility wants a printed summary of a patient’s visit — for a referral, discharge, insurance, or just the patient’s own records — there’s no built-in way to generate one from O3.

This project adds that capability to the existing openmrs-module-patientdocuments module. The goal is a pluggable, configurable PDF pipeline that lets any deployment customize what shows up in their visit summaries without changing Java code.

How it works (high level)

The module uses an XML → XSLT → Apache FOP → PDF pipeline (same infrastructure the module already uses for patient ID stickers). Each section of the visit summary — vitals, diagnoses, allergies, medications, labs, visit notes — is a pluggable component that implements the VisitSummarySection SPI.

This means:

  • Deployers can toggle sections on/off via config

  • Deployers can customize which concepts appear (e.g. which vitals to include) without touching code

  • External modules (like a billing module) can plug in their own sections just by implementing the interface and registering a Spring bean

  • The XSLT stylesheet controls layout, so facilities can adjust page sizes (A4/A5/A6), add their logo, and customize formatting

Key goals

  • A working, production-ready visit summary PDF accessible from O3’s patient chart

  • Pluggable section architecture using Spring SPI (VisitSummarySection → TypedSection<T> → concrete sections)

  • Configurable via Initializer (concept references, section toggles, ordering)

  • Clinical safety: clear distinction between “no data recorded” and “data fetch failed” in the PDF output

  • Frontend print button integrated into O3’s visit detail view

Resources

Thank you to my mentors @wikumc and @nethmi, and to the community for all the support so far :yellow_heart:

Looking forward to a great summer of building and learning! :sunflower:

cc: @wikumc @nethmi @ibacher @dkayiwa @veronica @dennis @jayasanka @bawanthathilan @beryl

2

Community Bonding Period Update :books:

The community bonding period wraps up today and coding starts tomorrow, so here’s a quick look back at what these past few weeks looked like.

Dev environment setup

Got the module building and running locally on Windows + WSL2 + Docker with the O3 distro. Now I can build, deploy, and test PDF generation end-to-end!

About the very first PR of this project…

The architecture took shape through review. I raised my proof-of-concept as a draft PR early in bonding. It’s been through several rounds of review and the architecture evolved a lot through those discussions — the renderer went from hardcoding all section calls by name to a properly pluggable SPI where each section owns its own XML rendering. Along the way I also learned about using concept maps over hardcoded UUIDs, making clinical data lists extensible so different deployments can customize what shows up without touching code, and following existing module conventions for config keys. The PR is now out of draft and ready for review.

My biggest takeaway…?

Honestly, the most valuable learning came from the review discussions. One thing that really stuck with me was around error handling, I initially thought silently skipping a section when data fetching fails was graceful handling. But from a clinical perspective, there’s a huge difference between “this patient has no allergies” and “we couldn’t fetch the allergy data.” A clinician reading the PDF might assume it’s safe to prescribe something the patient is actually allergic to. That changed how I think about edge cases in healthcare software — every design decision carries real responsibility.

A note to my mentors​:yellow_heart:

A huge thank you to @wikumc and @nethmi for being incredibly patient and supportive throughout the bonding period. The reviews and discussions pushed me to think deeper, not just about making code work, but about why design decisions matter when the software is used in clinical settings. I’ve learned more in these few weeks than I expected, and I’m going to do my best to make this project something the community can genuinely use.

Now what’s next…?

Week 1 (May 25 – Jun 1): Addressing the remaining review feedback on the PR and working towards getting the first minimal working PDF merged — patient info + vitals with the full pipeline working end-to-end.

Excited to get building! :rocket: