comparison REDCap FHIR Integration vs. calypr/resource-editor

[bwalsh]

REDCap FHIR Integration vs. calypr/resource-editor

Date: 2026-06-08
Perspective: architecture, agile delivery management, and bioinformatics data stewardship
Repositories compared:

• Local repository: redcap-fhir
• External repository: calypr/resource-editor

Executive summary

Both repositories target FHIR-enabled biomedical workflows, but they embody different product bets.

redcap-fhir is an integration stack: Docker Compose runs a PHP/Apache REDCap-facing web tier, a Flask FHIR bridge API, and MySQL persistence. It is closest to a study-operations environment where REDCap, clinical data pull/data mart support, audit tables, and server-side integration are strategic requirements. Its cost is operational complexity: more containers, more moving parts, licensed REDCap source management, database administration, and custom PHP/Python maintenance.

calypr/resource-editor is a focused React single-page application (SPA) for browsing, viewing, and locally editing FHIR resources from FHIR Aggregator. It is closest to a lightweight bioinformatics resource workbench. Its cost is persistence maturity: current create/update/delete behavior is an overlay in browser local storage by default, with a custom backend plugin contract but no committed backend implementation or git workflow.

For the use case “As a bioinformatician, I need a user interface to edit FHIR resources associated with my project,” resource-editor is the better starting point when the desired product is a simple, modern, FHIR-centric editor. redcap-fhir is the better starting point when editing must be embedded in REDCap workflows, participant/project governance, or clinical-data-ingestion operations.

For the use case “As a data contributor, I need to manage updates to FHIR resources with git commits,” neither repository satisfies the requirement as delivered. resource-editor has the cleaner extension seam for adding a git-backed persistence service because its CRUD provider pattern isolates draft persistence. redcap-fhir has a server-side API and database where git commits could be implemented centrally, but the current persistence path writes to MySQL and/or the upstream FHIR API rather than to a repository-backed change process.

Evidence base and method

The comparison used repository inspection of the local redcap-fhir files and public inspection of calypr/resource-editor on GitHub. The external repository could not be cloned from this environment because direct git clone failed with an HTTP CONNECT 403, so external observations are based on GitHub-rendered repository files and raw file views available through browser access.

Key inspected local evidence includes:

• README.md for stated purpose, quick start, service model, and project structure.
• docker-compose.yml, Dockerfile, and Dockerfile.api for runtime topology.
• src/app.py, src/fhir_client.py, src/cdis_connector.py, src/config.py, and scripts/init.sql for API, persistence, supported resource types, and CDIS-style workflows.
• redcap/index.php for the lightweight REDCap-facing FHIR workspace.

Key inspected external evidence includes:

• calypr/resource-editor repository page and README.
• package.json, Dockerfile, docs/docker.md, vite.config.ts, src/fhirClient.ts, src/localCrudStore.ts, and src/plugins/customBackendCrudProvider.ts from the public GitHub repository.

Repository profiles

redcap-fhir

redcap-fhir describes itself as a Docker-based REDCap instance configured for CRUD operations on FHIR data from FHIR Aggregator. The README defines a three-service local environment: REDCap on port 8080, a FHIR API on port 5000, and MySQL persistence. It also states that licensed REDCap application source code is not included and must be supplied locally, while the checked-in redcap/index.php acts as a lightweight FHIR workspace.

Architecturally, the repository contains:

• A PHP/Apache web tier intended to host REDCap or the included lightweight REDCap-facing workspace.
• A Flask API exposing FHIR CRUD, search, health, supported resources, audit, sync, and CDIS-style endpoints.
• A Python FHIR client that forwards read/search/create/update/delete calls to a configured FHIR base URL.
• MySQL tables for stored FHIR resources, audit log, sync log, CDIS jobs, and adjudication candidates.
• Docker Compose orchestration with named network and persistent MySQL volume.

Bioinformatically, the repository is oriented toward clinical research data operations. It supports common clinical resources plus research-centric resources such as ResearchStudy, ResearchSubject, and Sample. It also includes a lightweight CDIS-style connector with field catalog, clinical data pull, clinical data mart, and adjudication persistence.

calypr/resource-editor

resource-editor describes itself as a React SPA built with Medplum’s React component library for exploring biomedical research data from FHIR Aggregator. Its README lists study browsing, search by identifier, study detail views, ResearchSubject and Specimen drill-through tables, raw FHIR JSON viewing, local create/update/delete overlay behavior, a CRUD provider plugin contract, runtime FHIR server selection, and Vite development proxy support.

Architecturally, the external repository is a frontend-first application:

• React 18, TypeScript, Vite, Mantine, Medplum React/Core/FHIR types, and React Router.
• A thin FHIR client for read/search that applies a local CRUD overlay.
• Browser-local persistence by default through localStorage.
• A CrudProvider interface and custom backend provider template that currently delegates to local storage until TODO-backed API calls are implemented.
• A multi-stage Node-to-Nginx Dockerfile with proxy routes for FHIR and schema upstreams.

Bioinformatically, resource-editor is more directly aligned with FHIR Aggregator exploration. It foregrounds ResearchStudy, ResearchSubject, Specimen, raw JSON, and generic FHIR resource drill-through rather than a REDCap operational deployment.

Use-case fit

Use case 1: “As a bioinformatician, I need a user interface to edit FHIR resources associated with my project”

redcap-fhir fit

Strengths

• Provides a web UI path through redcap/index.php, including generated forms for supported FHIR resource types.
• Has a server-side API capable of forwarding create, read, update, delete, and search requests to a configured FHIR server.
• Can persist created/updated resources and operational metadata to MySQL.
• Better suited when the bioinformatician’s project is already managed in or adjacent to REDCap.
• Includes CDIS-like functionality useful for mapping EHR/FHIR values into study data capture and adjudication workflows.

Limitations

• The included UI is lightweight and custom PHP, not a full modern FHIR form-builder experience.
• Full REDCap usage requires externally supplied licensed REDCap source files.
• The supported-resource list is finite and requires code changes for expansion.
• Validation is basic in the Python FHIR client; it checks resource identity rather than full FHIR profile conformance.
• The stack has more operational prerequisites than a frontend-only editor.

Assessment

redcap-fhir is a moderate fit if the UI is part of REDCap-centric clinical research operations. It is a weaker fit if the primary need is a standalone, low-friction FHIR resource editor for bioinformaticians.

resource-editor fit

Strengths

• The product is explicitly a FHIR resource browser/editor UI.
• Medplum components and FHIR TypeScript types reduce custom rendering burden.
• Study-focused navigation maps well to bioinformatics cohorts and project-associated resources.
• Raw JSON viewing supports expert users who need transparent FHIR payload inspection.
• The SPA can be run locally with npm run dev or deployed as static assets behind Nginx.
• Its CRUD provider contract provides a clear seam for replacing browser-only persistence with project infrastructure.

Limitations

• Default edits are local overlays, not durable project-governed updates.
• A production persistence backend is only templated, not implemented.
• Static frontend builds make some endpoint changes build-time concerns unless proxied or externalized.
• Security, authorization, project membership, and audit workflows require additional backend infrastructure.

Assessment

resource-editor is the stronger initial fit for a bioinformatician-facing FHIR editing UI, especially where project resources are FHIR Aggregator resources and a lightweight app is acceptable. It becomes production-ready only after adding authenticated, durable persistence and governance.

Use case 2: “As a data contributor, I need to manage updates to FHIR resources with git commits”

redcap-fhir fit

Strengths

• Server-side Flask code is already positioned between the UI and upstream FHIR server, so it could implement git-backed write workflows centrally.
• MySQL audit and sync tables provide a basis for tracking operations and statuses.
• Docker Compose already includes persistent infrastructure where a mounted git repository could be added.
• A backend can enforce contributor identity, branch naming, validation, commit signing, and pull-request creation more reliably than a browser-only app.

Limitations

• Current create/update/delete behavior calls the upstream FHIR API and writes resource snapshots to MySQL; it does not create commits.
• No repository layout, JSON canonicalization rules, branch strategy, merge strategy, or pull-request workflow is defined.
• Contributor identity is not authenticated in the current API; CDIS helpers use headers or remote address as request attribution.
• Implementing git safely in the current stack adds significant complexity: filesystem mounts, locking, conflict handling, secret handling, and CI validation.

Assessment

redcap-fhir is a plausible foundation for a centralized git-backed FHIR change manager, but only after a deliberate backend feature investment. Its current state does not satisfy git-commit-based contribution management.

resource-editor fit

Strengths

• The CrudProvider pattern cleanly separates UI editing from persistence.
• A backend provider could post drafts to a git service that validates, writes canonical FHIR JSON files, commits changes, and opens pull requests.
• The SPA’s local overlay behavior is conceptually similar to working-copy drafts, which maps well to a contributor review workflow.
• The frontend has lower operational cost if paired with an existing git-backed API service.

Limitations

• The provided custom backend CRUD provider is only a template and falls back to local storage.
• Browser local storage is not a contributor audit trail and is not suitable for regulated project stewardship.
• A frontend alone should not hold git credentials or perform privileged repository writes.
• No built-in conflict visualization, diff review, branch lifecycle, commit metadata capture, or merge/pull-request handling is present.

Assessment

resource-editor is the better UI foundation for a git-backed contributor workflow because it has a clean persistence abstraction. However, the actual git workflow must be implemented as a backend service.

Architecture comparison

Simplicity

Dimension	redcap-fhir	resource-editor
Runtime shape	Three-service Compose stack: Apache/PHP, Flask/Python, MySQL	Static React SPA served by Vite or Nginx
Primary code languages	PHP, Python, SQL, Docker	TypeScript/React, Docker/Nginx
Persistence	MySQL plus upstream FHIR server	Browser local storage by default; backend plugin seam
Setup path	Docker Compose, database, local REDCap source concern	npm install && npm run dev or Nginx container
Simplicity rating	Medium-low	High

resource-editor is simpler because it minimizes server-side responsibilities and infrastructure. redcap-fhir is intentionally broader and therefore less simple.

Ease of maintenance

redcap-fhir

Maintenance advantages:

• Clear separation between FHIR API code, FHIR client code, CDIS connector code, and deployment scripts.
• Docker Compose makes local operations reproducible.
• MySQL persistence supports operational introspection and future reporting.

Maintenance risks:

• Multiple technology stacks increase team skill requirements.
• Licensed REDCap source management is outside the repository and may vary by installation.
• API validation, authentication, authorization, migrations, and dependency update strategy need hardening.
• Direct table creation from runtime helper code and init SQL can diverge unless migration discipline is added.

resource-editor

Maintenance advantages:

• Modern, cohesive frontend stack.
• Medplum components reduce custom FHIR UI burden.
• TypeScript improves refactoring safety.
• Provider abstraction localizes persistence evolution.

Maintenance risks:

• Frontend dependencies such as React, Vite, Mantine, and Medplum require active dependency hygiene.
• Local storage persistence can create hidden state that is hard to support in multi-user workflows.
• Build-time endpoint configuration can create operational friction unless standardized.
• No backend means production concerns will accumulate in a separate service that must be designed consistently with the frontend.

Infrastructure and lifecycle costs

redcap-fhir

Expected lifecycle costs are higher:

• Compute/runtime: at least three containers and one persistent database volume.
• Operations: database backup/restore, logs, health checks, schema migrations, container patching, REDCap deployment, FHIR endpoint connectivity, and secret management.
• Compliance/security: authentication and authorization must be added or placed in front of the services; REDCap licensing and institutional policies apply.
• Team: requires PHP/REDCap, Python/Flask, MySQL, Docker, FHIR, and clinical research operations knowledge.
• Change management: richer workflow potential, but each new feature touches more layers.

These costs may be justified when the organization needs REDCap integration, clinical data pull/data mart features, auditability, or centralized project operations.

resource-editor

Expected lifecycle costs are lower at the UI-only stage:

• Compute/runtime: static web hosting or a single Nginx container.
• Operations: frontend build/deploy, dependency patching, proxy configuration, and monitoring.
• Compliance/security: production use still requires identity, authorization, audit, and persistence services, but those can be delegated to a backend/API gateway.
• Team: primarily TypeScript/React/FHIR UI expertise.
• Change management: UI iterations can be delivered quickly with a small team.

Costs rise materially once durable multi-user persistence, git commits, validation pipelines, and governance are added; however, those costs can be isolated in a backend service rather than embedded in the UI.

Detailed architecture

redcap-fhir architecture

redcap-fhir is a server-side integration stack. Its default Docker deployment runs a REDCap-facing Apache/PHP container, a Flask-based FHIR bridge API, and MySQL persistence. The PHP layer provides a lightweight REDCap-style FHIR workspace when licensed REDCap source files are not present. The Flask API owns CRUD routing, supported-resource checks, basic resource validation, CDIS helper endpoints, audit-like persistence, and forwarding to the configured upstream FHIR server.

flowchart LR
  User[Research user / REDCap user]
  PHP[Apache / PHP REDCap workspace]
  API[Flask FHIR API]
  DB[(MySQL)]
  FHIR[FHIR Aggregator / FHIR Server]
  CDIS[CDIS mapping / adjudication workflows]

  User --> PHP
  PHP --> API
  API --> FHIR
  API --> DB
  API --> CDIS
  CDIS --> DB
  CDIS --> FHIR

Loading

This architecture is strongest when FHIR editing is part of a REDCap-centered clinical research workflow. It has a real backend, server-side persistence, and room for centralized governance. Its tradeoff is operational complexity: multiple services, database administration, REDCap source/licensing concerns, and a custom PHP/Python integration surface.

resource-editor architecture

resource-editor is a frontend-first React SPA built around FHIR Aggregator browsing and local editing. It uses Medplum React/FHIR types for FHIR-aware UI rendering, a thin FHIR client for search/read operations, and a CRUD provider abstraction for create/update/delete behavior. By default, edits are stored as browser-local overlays rather than written to the upstream FHIR server.

flowchart LR
  User[Bioinformatician / data curator]
  React[React SPA]
  Medplum[Medplum React components]
  Client[fhirClient.ts]
  Overlay[CRUD provider]
  Local[(Browser localStorage)]
  FHIR[FHIR Aggregator / FHIR Server]
  Backend[Optional custom backend]

  User --> React
  React --> Medplum
  React --> Client
  Client --> FHIR
  Client --> Overlay
  Overlay --> Local
  Overlay -. future .-> Backend

Loading

This architecture is strongest as a lightweight FHIR resource workbench. It is easier to extend for a modern editor UX because persistence is isolated behind a CrudProvider interface. Its weakness is that durable, multi-user, governed persistence is not implemented yet.

Does REDCap support automatic form generation for FHIR resources?

The included PHP workspace defines form fields manually for each supported FHIR resource type and then builds a FHIR JSON payload from those definitions. That means it can render “generated” CRUD forms from a local configuration table, but it is not automatically introspecting FHIR R5 StructureDefinitions, implementation guides, profiles, cardinalities, value sets, or constraints.

So the accurate statement is:

redcap-fhir supports lightweight generated forms for a fixed set of configured FHIR resource types. It does not currently implement general automatic form generation from FHIR schemas/profiles.

A production-grade auto-generation feature would need to load FHIR StructureDefinition resources, resolve profiles and extensions, inspect element cardinality and binding metadata, generate appropriate widgets, validate against the selected profile, and preserve round-trip JSON fidelity.

Medplum React components, FHIR servers, schemas, and CRUD

In resource-editor, Medplum React components are best understood as the presentation layer, not the persistence layer. Components such as MedplumProvider, ResourceTable, and CodeableConceptDisplay help render FHIR resources and FHIR datatypes consistently. The actual server interaction happens through fhirClient.ts, which performs HTTP reads and searches against the selected FHIR base URL.

The current flow is:

sequenceDiagram
  participant User
  participant UI as React / Medplum UI
  participant Client as fhirClient.ts
  participant Store as CrudProvider
  participant FHIR as FHIR Server

  User->>UI: Browse/search resource
  UI->>Client: fhirSearch or fhirRead
  Client->>FHIR: GET /ResourceType or /ResourceType/id
  FHIR-->>Client: FHIR Bundle or Resource
  Client->>Store: Apply local overlay / deletion tombstone
  Store-->>Client: Draft override or deleted marker
  Client-->>UI: Effective resource view
  UI-->>User: Render structured FHIR UI

Loading

FHIR schemas should be treated as validation and form-generation inputs, not as the primary data store. The editor should use schemas/profiles to drive field labels, required fields, datatypes, bindings, validation messages, and profile-specific constraints. The FHIR server remains the source for current published resources; the CRUD provider determines how edits are staged, validated, and submitted.

Recommended git-aware CRUD backend

The CRUD interface should evolve from local overlay storage into a git-aware backend provider. The frontend should not hold git credentials or commit directly. Instead, resource-editor should call a backend implementing the same CRUD provider contract.

flowchart LR
  UI[resource-editor SPA]
  Provider[Custom CrudProvider]
  API[Git-aware CRUD API]
  Validator[FHIR validation service]
  Repo[(Git repository)]
  PR[Pull request / review]
  FHIR[FHIR server publication target]

  UI --> Provider
  Provider --> API
  API --> Validator
  API --> Repo
  Repo --> PR
  PR --> FHIR

Loading

Recommended backend responsibilities:

• Store drafts server-side instead of in browser localStorage.
• Canonicalize resources as stable JSON, for example resources/{resourceType}/{id}.json.
• Validate resources against the selected FHIR version and project implementation guide.
• Create branches, commits, and pull requests for submitted changes.
• Track contributor identity, commit metadata, review status, validation results, and conflicts.
• Return branch, commit, pull-request, and validation metadata to the UI.
• Treat deletes as explicit tombstones or removing canonical JSON files through review.

This preserves the best part of resource-editor: a clean FHIR editing UX. It also adds the missing governance layer: git history, review, validation, provenance, and reproducible release management.

XXXXXXXX

Agile delivery implications

redcap-fhir

redcap-fhir supports larger, operations-heavy epics:

• REDCap/FHIR integration hardening.
• CDIS mapping and adjudication workflows.
• Project-level audit and reporting.
• Server-side git-backed resource change management.
• Institutional deployment and security controls.

Agile risk is integration drag. Stories will have dependencies across UI, API, database, containerization, REDCap policy, and external FHIR services. The team should plan spikes for REDCap licensing/deployment, authentication, FHIR validation, and git conflict handling before committing to delivery dates.

resource-editor

resource-editor supports faster UI-focused increments:

• Add resource-type-specific editing screens.
• Improve study/cohort navigation.
• Add draft review and JSON diff UX.
• Swap local storage for a backend CRUD provider.
• Integrate schema/profile validation feedback.

Agile risk is mistaking a useful prototype for governed persistence. The team should explicitly split “editor UX” stories from “durable write governance” stories and define acceptance criteria for audit, identity, validation, and git commit behavior.

Bioinformatics assessment

Strengths for bioinformatics users

redcap-fhir is stronger when the user journey crosses REDCap project data, clinical data pull, adjudication, and operational persistence. It is well positioned for translational research teams that need to reconcile FHIR resources with study capture forms.

resource-editor is stronger when the user journey starts with FHIR Aggregator research resources and requires a lightweight interface for browsing, inspecting, and editing resource JSON. The emphasis on ResearchStudy, ResearchSubject, Specimen, and raw FHIR payloads is closer to bioinformatics exploration and curation.

Gaps for bioinformatics governance

Both repositories need additional capabilities for production bioinformatics stewardship:

• Project/collection scoping of resources.
• Authentication and role-based authorization.
• FHIR profile validation beyond basic resource identity.
• Provenance capture using FHIR Provenance/AuditEvent or an equivalent audit model.
• Dataset release/version tagging.
• Reviewable diffs and approval workflow.
• Git-backed canonical JSON storage if commits are required.
• Integration tests against representative FHIR resources and profiles.

Recommendation

Recommended near-term path

Use resource-editor as the primary UI foundation for the bioinformatician-facing FHIR resource editor, and add a backend persistence service that implements git-backed draft management. The backend should own repository credentials, canonical JSON formatting, FHIR validation, branch/commit creation, conflict detection, and pull-request creation.

Use selected redcap-fhir concepts and/or services when REDCap workflow integration is required, particularly for clinical data pull/data mart/adjudication scenarios. Do not make REDCap the default dependency for a generic bioinformatics FHIR editor unless REDCap project workflow is a core requirement.

Target architecture for git-backed FHIR editing

A pragmatic target architecture would include:

1. Frontend: resource-editor SPA for browse, edit, diff, draft, and submit workflows.
2. Persistence API: a small backend service implementing the CRUD provider contract.
3. Git workspace service: server-side repository clone with locking, branch lifecycle, canonical FHIR JSON file layout, commit metadata, and pull-request integration.
4. FHIR validation service: profile-aware validation using project implementation guides.
5. Audit/provenance store: durable events for who changed what, why, and under which validation result.
6. Optional REDCap adapter: integrate with redcap-fhir only for projects that require REDCap forms, CDIS-style pulls, or adjudication.

Decision matrix

Decision question	Recommended choice
Need a quick standalone FHIR UI?	resource-editor
Need REDCap-embedded operations?	redcap-fhir
Need git commits for every resource update?	Neither as-is; build backend workflow
Want lowest infrastructure footprint?	resource-editor
Want centralized server-side persistence now?	redcap-fhir, with hardening
Want easiest path to modern editor UX?	resource-editor
Want clinical data pull/data mart/adjudication features?	redcap-fhir

Implementation roadmap

Phase 0: product framing

• Define canonical resource file layout, for example resources/{resourceType}/{id}.json.
• Define branch naming, commit message, reviewer, and merge policies.
• Define project/resource scoping and user roles.
• Select required FHIR version and implementation guides.

Phase 1: harden editor UX

• Adopt or fork resource-editor for the UI.
• Add explicit project context and resource collection navigation.
• Add schema/profile validation feedback.
• Add JSON diff before submit.
• Add draft lifecycle states: draft, submitted, rejected, merged.

Phase 2: implement git-backed provider

• Implement backend endpoints corresponding to the CRUD provider contract.
• Persist drafts server-side rather than in browser storage.
• On submit, write canonical JSON, run validation, create branch and commit, and open a pull request.
• Return commit/branch/pull-request metadata to the UI.
• Add conflict detection when upstream JSON changes.

Phase 3: integrate governance

• Add authentication and role-based authorization.
• Add audit/provenance events.
• Add automated validation CI checks on pull requests.
• Add release tagging for curated FHIR resource sets.

Phase 4: optional REDCap integration

• Use redcap-fhir where study teams need REDCap workflows.
• Expose approved FHIR resources to REDCap projects or map them through CDIS-style pulls.
• Keep the git-backed resource repository as the canonical governed source when commit traceability is the driver.

Conclusion

resource-editor is the cleaner and lower-cost starting point for a bioinformatician-facing FHIR resource editing UI. redcap-fhir is the broader integration environment for REDCap-centric clinical research operations and has more server-side infrastructure that could support governed workflows, but at higher lifecycle cost.

For git-commit-managed FHIR updates, neither repository is sufficient as delivered. The best architectural move is to combine the resource-editor UI model with a small authenticated backend that implements git-backed persistence, validation, audit, and review. redcap-fhir should be treated as an integration companion for REDCap/CDIS use cases rather than the default editor foundation.