GSOC 2026 Comprehensive Fhir Facade Layer to OpenELIS

Hi everyone!

I am absolutely delighted to be joining you as a GSoC 2026 student.

I view the project I’m working on as the “circulatory system” of our software—facilitating the vital flow of data between systems. To get this right, I’m calling on the community: grab your microscopes (your eyes), your software reagents, and your analyzers (AI and automated tools). I’ll be leading this operation, but I’m relying on your expertise to ensure I don’t miss a beat!

The Mission

My focus is building a Comprehensive FHIR Facade on top of OpenELIS-Global to take our interoperability to the next level. This isn’t just about the code in the develop branch; it’s about strengthening our entire ecosystem.

Our Roadmap & Resources

To keep this operation transparent, we will be focusing on two main pillars outside of the core repository:

  1. Updating the Implementation Guide: We will be refining our documentation and standards here: Home - OpenELIS GLOBAL2 Implementation Guide v0.1.0

  2. Advancing the Resource Mapping: The “DNA” of our facade layer is being mapped out in real-time. You can track our progress and the logic behind our FHIR resource mapping here: :backhand_index_pointing_right: The FHIR Facade Mapping Sheet

I am eager to collaborate, learn, and contribute to making OpenELIS-Global more connected than ever. Please feel free to reach out with feedback on the mapping or the IG—I look forward to working with you all!

3 Likes

FHIR QuestionnaireResponse Data Model

FHIR QuestionnaireResponse Data Model
│
├── System User (admin)
│   └── Creates and manages questionnaires/responses
│
├── Patient
│   │
│   ├── Person
│   │   ├── Name: John Doe
│   │   ├── City: Kampala
│   │   └── Email: john@gmail.com
│   │
│   └── Patient Record
│       ├── Gender: Male
│       ├── DOB: 1992-12-12
│       ├── National ID: 1234
│       └── FHIR UUID
│
├── Questionnaires
│   │
│   ├── Maternal Health Intake
│   │   │
│   │   └── Items
│   │       └── Maternal Assessment (GROUP)
│   │           └── Pregnancy Status (BOOLEAN)
│   │               ├── Initial Value = FALSE
│   │               └── Weeks Pregnant (INTEGER)
│   │                   └── Complications? (BOOLEAN)
│   │
│   ├── HIV Intake
│   │   │
│   │   └── Items
│   │       └── HIV Assessment (GROUP)
│   │           └── Risk Behaviour (GROUP)
│   │               └── Unprotected Sex? (CHOICE)
│   │                   ├── Answer Options
│   │                   │   ├── YES
│   │                   │   └── NO
│   │                   ├── Initial Value = NO
│   │                   └── Number of Partners (INTEGER)
│   │
│   └── General Clinical Intake
│       │
│       └── Items
│           └── Patient Details (GROUP)
│               └── Vitals (GROUP)
│                   └── Blood Pressure (TEXT)
│
├── Questionnaire Responses
│   │
│   ├── Response #1 (COMPLETED)
│   │   └── Maternal Health Intake
│   │       ├── Pregnancy Status = TRUE
│   │       ├── Weeks Pregnant = 28
│   │       └── Complications = FALSE
│   │
│   ├── Response #2 (COMPLETED)
│   │   └── HIV Intake
│   │       ├── Unprotected Sex = FALSE
│   │       └── Number of Partners = 2
│   │
│   └── Response #3 (IN_PROGRESS)
│       └── General Clinical Intake
│           └── No answers yet
│
└── QuestionnaireResponse Answer Storage
    │
    ├── Response Item
    │   └── Represents Question Instance
    │
    └── Response Answer
        ├── valueBoolean
        ├── valueInteger
        ├── valueString
        ├── valueDate
        └── Other FHIR Answer Types

Database Relationship View

system_user
    │
    ├── questionnaire
    │       │
    │       └── questionnaire_item
    │               │
    │               ├── questionnaire_item_initial
    │               │
    │               ├── questionnaire_answer_option
    │               │
    │               └── questionnaire_item
    │                       │
    │                       ├── questionnaire_item_initial
    │                       ├── questionnaire_answer_option
    │                       └── questionnaire_item
    │
    └── questionnaire_response
            │
            ├── patient
            │       │
            │       └── person
            │
            └── questionnaire_response_item
                    │
                    └── questionnaire_response_answer

FHIR Resource Mapping

OpenELIS Tables                         FHIR Resource

patient + person              ─────► Patient

questionnaire                 ─────► Questionnaire

questionnaire_item            ─────► Questionnaire.item

questionnaire_item_initial    ─────► Questionnaire.item.initial

questionnaire_answer_option   ─────► Questionnaire.item.answerOption

questionnaire_response        ─────► QuestionnaireResponse

questionnaire_response_item   ─────► QuestionnaireResponse.item

questionnaire_response_answer ─────► QuestionnaireResponse.item.answer

Data Flow

Patient
   │
   ▼
Questionnaire
   │
   ├── Questionnaire Items
   │     ├── Initial Values
   │     └── Answer Options
   │
   ▼
QuestionnaireResponse
   │
   ▼
Response Items
   │
   ▼
Answers
   │
   ▼
FHIR QuestionnaireResponse Resource

Key Takeaway

The hierarchy follows:

Patient
→ Questionnaire
→ Questionnaire Items
→ Initial Values / Answer Options
→ QuestionnaireResponse
→ Response Items
→ Answers

This mirrors the FHIR Questionnaire and QuestionnaireResponse structures and supports nested questions, default values (initial), answer choices (answerOption), and typed answers (Boolean, Integer, Text, Date, etc.).

Hello community,

This PR introduces Questionnaire pr dedicated database tables for Questionnaire, QuestionnaireItem, QuestionnaireItemInitial, QuestionnaireAnswerOption, QuestionnaireResponse, QuestionnaireResponseItem, and QuestionnaireResponseAnswer within OpenELIS.

Instead of retrieving Questionnaire and QuestionnaireResponse data from the external/co-resident FHIR store, OpenELIS now persists and queries these resources directly from its own database.

Why This Change?

Previously, OpenELIS is relying on the co-resident HAPI FHIR store for Questionnaire and QuestionnaireResponse persistence and retrieval. While functional, this introduced several limitations:

1. Reduce Dependency on the FHIR Store

Questionnaire and QuestionnaireResponse are will now be core OpenELIS entities. Storing them in the application database removes the requirement to make external FHIR API calls for routine operations and reduces dependence on the availability of the FHIR store.

2. Improve Query Performance

FHIR QuestionnaireResponse resources contain deeply nested structures (item, answer, nested item hierarchies) that are expensive to search and index efficiently in a generic FHIR repository. The FHIR specification itself notes the complexity of indexing and searching QuestionnaireResponse content.

Using relational tables allows OpenELIS to:

  • Execute direct SQL queries.

  • Filter responses efficiently.

  • Support pagination and search without FHIR resource traversal.

  • Reduce serialization/deserialization overhead.

3. Simplify OpenELIS Business Logic

The questionnaire workflow is will now be managed entirely within OpenELIS:

  • Questionnaire creation

  • Questionnaire updates

  • Answer option management

  • Initial value management

  • QuestionnaireResponse capture

  • QuestionnaireResponse retrieval

This removes the need to convert between database objects and FHIR resources during normal application operations.

4. Better Support for LIS Workflows

Questionnaires and responses are frequently used as operational data within OpenELIS. Storing them in relational tables enables:

  • Faster reporting

  • Easier joins with patient records

  • Simpler auditing

  • Direct database access for troubleshooting and analytics

5. Preserve FHIR Compatibility

Although the data now now be stored in OpenELIS tables, the structure closely mirrors the FHIR model:

OpenELIS Table FHIR Element
questionnaire Questionnaire
questionnaire_item Questionnaire.item
questionnaire_item_initial Questionnaire.item.initial
questionnaire_answer_option Questionnaire.item.answerOption
questionnaire_response QuestionnaireResponse
questionnaire_response_item QuestionnaireResponse.item
questionnaire_response_answer QuestionnaireResponse.item.answer

This allows OpenELIS to continue exposing FHIR-compliant resources while using a more efficient persistence mechanism internally.

Result

Questionnaire and QuestionnaireResponse data will now be :

  • Stored directly in the OpenELIS database.

  • Queried through OpenELIS services and DAOs.

  • No longer dependent on the co-resident FHIR store for routine CRUD operations.

  • Still capable of being represented as FHIR resources when exposed through the FHIR API.

This provides improved performance, reduced system complexity, and better alignment with OpenELIS workflow requirements.

CC @Moses_Mutesasira , @mherman22

Other relevant pull requests

  1. Introducing Facade Search Implemented querying from clinlims
    Built practitioner search facade querying the database by Isabirye1515 · Pull Request #3720 · DIGI-UW/OpenELIS-Global-2 · GitHub
  2. Storage Location Facade, and service layer enhancement
    Adding Storage location provider by Isabirye1515 · Pull Request #3563 · DIGI-UW/OpenELIS-Global-2 · GitHub
  3. Device in Analyzer facade, require review
    Adding device provider by Isabirye1515 · Pull Request #3560 · DIGI-UW/OpenELIS-Global-2 · GitHub
  4. Diagnostic Report facade
    Adding Storage location provider by Isabirye1515 · Pull Request #3563 · DIGI-UW/OpenELIS-Global-2 · GitHub
  5. For maintainability , separating to specific provider service
    Added Provider specific transformation Service for Maintainablity by Isabirye1515 · Pull Request #3595 · DIGI-UW/OpenELIS-Global-2 · GitHub
  6. Some updated in the observation transform
    Update observation to include performer by Isabirye1515 · Pull Request #3675 · DIGI-UW/OpenELIS-Global-2 · GitHub

@Moses_Mutesasira , @mherman22 , other collegues please review