The Form Designer project aims to create a versatile drag-and-drop interface builder that leverages existing web components from LibreHealth Toolkit and OpenMRS O3, enabling rapid development of healthcare forms and interfaces that interact with FHIR and LibreHealth REST APIs.
This application builds upon the existing ecosystem of web components, which provide standardized, reusable UI elements specifically designed for healthcare applications. The designer will allow healthcare organizations to create custom forms and interfaces without writing code, while maintaining compliance with healthcare data standards and workflows.
The form designer will integrate seamlessly with both FHIR-compliant systems and the LibreHealth REST API, supporting real-time data binding and form validation. The project will leverage modern web technologies to create a responsive, intuitive interface that can handle complex healthcare data structures while remaining accessible to non-technical users.
Key features of the designer will include:
Dynamic component palette featuring all available web components from both LibreHealth Toolkit and O3
Real-time preview of forms with live data binding capabilities
Built-in templates for common healthcare workflows and forms
Export functionality for created forms in standard formats
Integration with existing authentication and authorization systems
Support for complex validation rules and conditional logic
Ability to save and share form templates across organizations
The deliverables of the project are as follows:
Develop a drag-and-drop interface that supports all existing web components from LibreHealth Toolkit and O3
Create a robust data binding system that can handle both FHIR resources and standard REST API endpoints
Implement a template system for commonly used healthcare forms
Build an export system that generates clean, maintainable code
Develop comprehensive documentation and tutorials for form creation
Create an extension system for adding custom components and validators
Preliminary tasks
Create a prototype demonstrating basic drag-and-drop functionality with simple components
Implement data binding with a sample FHIR resource
Develop the core layout engine for the designer
Create basic form templates for testing
A developer working on this project needs to have skills in:
Modern JavaScript (ES6+) and TypeScript
Web Components specifications and custom element creation
Experience with drag-and-drop interfaces and layout engines
Understanding of FHIR resources and healthcare data structures
Knowledge of REST APIs and data binding patterns
Familiarity with build tools and modern web development workflows
The project will significantly reduce the time and technical expertise required to create healthcare forms while ensuring standardization and interoperability across different healthcare systems. By leveraging existing web components, the designer will maintain consistency with the broader LibreHealth ecosystem while providing the flexibility needed for custom healthcare workflows.
I’m Sujal Tripathi, a 3rd-year CS student from India with a strong background in JavaScript, React, and MERN stack development. I’m very interested in this project for GSoC 2026.
I have a few questions to get started:
For the preliminary task, are there specific existing LibreHealth Toolkit web components I should use to build the drag-and-drop prototype?
Is using a framework like Lit acceptable for web components, or should I stick to vanilla Custom Elements?
I’m already exploring the GitLab repo. Looking forward to your guidance!
Hello @namratanehete and @parumenon1
I am Gargi Vishnoi , a CS-AI 2nd year student with a good knowledge of java and java script , i am interested in contributing to this project for GSoC 2026.
I have started exploring the repository and project idea and would love guidance on how I can begin contributing.
Work on the starter task and start drafting your proposal. Start early, your proposal is going to go through drafts. Those who just dump proposals and then go radio silent are rarely chosen.
I’d love to start working on the starter task and begin exploring the codebase. However, I couldn’t find the repository link for this project. Could you please share the GitHub repository or point me to the contribution guidelines so I can get started?
I’m Sujal, and I’m planning to apply for the Form Designer project for GSoC. I’ve been working through the preliminary tasks and have a prototype nearly ready to share — it covers the drag-and-drop functionality, the core layout engine, and basic form templates. I’ll be pushing it to GitHub very soon.
While building it out, a few technical questions came up that I’d love clarity on before finalizing my proposal:
Web Components integration: The project mentions sourcing components from both LibreHealth Toolkit and OpenMRS O3. Are these already published as standard Custom Elements, or will part of the work involve wrapping/adapting them into a common interface the designer can consume consistently?
Drag-and-drop engine: Is there a preferred DnD library already in use within the LibreHealth ecosystem (e.g., SortableJS, interact.js), or is that decision open to the contributor?
FHIR data binding scope: For the real-time binding feature, should the designer support binding against live FHIR endpoints during preview, or is the expectation to validate against a local FHIR resource schema/mock first? I haven’t tackled this part of the preliminary task yet and want to make sure I approach it correctly.
Export format: When the spec mentions “standard formats” and “clean, maintainable code” — is the target output raw HTML/JS using the web components, a JSON form schema (like O3’s form schema), or ideally both?
Extension system: Is there an existing plugin or registry pattern in LibreHealth that the custom component/validator extension system should conform to, or is this largely greenfield architecture?
I want the proposal to reflect decisions that fit the existing ecosystem rather than assumptions. Will share the GitHub link as soon as the prototype is up.
Hi @namratanehete and @parumenon1 — I’m working on my proposal for the Form Designer project and have a couple of questions.
I’ve made two contributions to get familiar with the codebase before writing the proposal:
MR !149 — Replaced WCT with @web/test-runner (CI fix in progress)
MR !150 — Created FhirFetchMixin replacing iron-ajax with native fetch
For the proposal — regarding form schema export, should the primary target be a custom JSON format first with FHIR Questionnaire export as an extended goal, or should we target FHIR Questionnaire directly from the start?
Also I have a working prototype for the drag-and-drop canvas — happy to share the link for feedback.
Hi @namratanehete@parumenon1@sunbiz — I have been working on my proposal for the Form Designer project and wanted to share the architecture I have planned before finalizing.
I am planning to divide the project into 4 core components:
Component Palette (reads component-registry.json) → Canvas (HTML5 drag-drop, renders form-field-wrapper elements) → Properties Panel (configures fhirPath, label, required) → FhirDataBinder (single fetch, distributes data to all fields by fhirPath)
I have also attached the architecture diagram above.
A few design decisions I would love your feedback on before I finalize:
Component Registry — static component-registry.json file vs auto-discovering components from packages/ at build time. Which approach fits better with the existing project structure?
FHIR Data Binding — reuse FhirFetchMixin from MR !150, or use a Lit Reactive Controller approach?
Export Format — custom JSON schema first with FHIR Questionnaire as extended goal, or target FHIR Questionnaire directly from day one?
I have also submitted two contributions — MR !149 (modern test framework) and MR !150 (FhirFetchMixin). Happy to discuss any part of this in more detail!
Hi Sujal, great questions and thank you for your consistent enthusiasm.
For the preliminary approach, it may help to keep the prototype focused on a basic drag-and-drop canvas, a small starter palette of components, a simple config/properties panel, and binding to one FHIR resource like you have done.
On Lit vs vanilla Custom Elements: I think Lit should be acceptable and could speed up development while making state and rendering easier to manage. For the component registry, a simple component-registry.json could be a good starting point. @sunbiz or @namratanehete might be able to help answer in more detail.
Thank you so much for the clarification, this really helps.
I’ll keep the prototype focused on the basics as you suggested: drag‑and‑drop canvas, a small starter palette, a simple properties panel, and binding to a single FHIR Patient resource.
For the implementation, I will use Lit for the designer shell components (canvas, palette, properties panel, data binder) and start with a simple component-registry.json file for listing the available Toolkit components.
I’ll update my proposal to reflect this and share the draft link here once it’s cleaned up, in case you have any other suggestions.
I have completed my GSoC 2026 proposal draft for the “Web Component-based Drag-and-Drop Form Designer” project. I have incorporated the feedback shared by @parumenon1 earlier in the discussion thread — using Lit, starting with component-registry.json, and building the local prototype first.
Hello, I’m Nagajyothi, a B.Tech Computer Science student interested in contributing. May I work on this issue? Please guide me on how to start. Thank you.
Hi @r0bby, thank you for the feedback! I have converted the proposal to a Google Doc with inline commenting enabled and replaced all code screenshots with actual code blocks.
Updated proposal: GSOC26 Proposal - Google Documenten
Please review, then i will upload my updated proposal in pdf on website
— Sujal Tripathi
GitLab: 
I am Gargi Vishnoi , a CS-AI 2nd year student with a good knowledge of java and java script , i am interested in contributing to this project for GSoC 2026.
I have started exploring the repository and project idea and would love guidance on how I can begin contributing.
