The research, architecture, and evidence behind the products.
This is Gotham Coders' working knowledge library: completed concept-validation research, technical white papers, product engineering case studies, qualification evidence, architecture documents, workflow studies, and engineering notes.
4
Completed research papers
Clinical Intelligence, Revenue Integrity, and architecture
5
Product case studies
G-HIMS and GC-ERP engineering studies
12
Technical evidence documents
Architecture, readiness, security, workflows, and tests
3
Engineering notes
Practical architecture and system-design writing
Completed research
Research before product claims.
These papers were developed to test the core product theses against commercial evidence, peer-reviewed research, operating constraints, interoperability realities, and falsifiable pilot designs.
Clinical Intelligence·Completed research
From Fragmented Records to Clinical Context
Concept-validation research paper·Completed • September 2026·19 pages • 32 references
Evidence review for Patient Context Intelligence: how longitudinal, source-linked clinical context can reduce record fragmentation and support better clinician review without turning AI into an autonomous clinical authority.
Reviews commercial and implementation evidence across Elation, Banner, Qualified Health, Carta, Navina, Regard, Pieces, and related systems.
Synthesizes evidence on missing information, context fragmentation, clinician cognitive burden, and source-linked summarization.
Frames Clinical Intelligence as a separate product wedge from Revenue Integrity.
Expanded research paper·Completed • September 2026·Peer-reviewed evidence + Pakistan context
Expanded validation paper adding peer-reviewed evidence, Pakistan-specific operating constraints, implementation feasibility, interoperability considerations, cost structure, and a falsifiable pilot design.
Adds academic and implementation evidence beyond commercial case studies.
Tests feasibility under emerging-market hospital constraints rather than assuming ideal infrastructure.
Defines a pilot design that can prove or disprove the core Patient Context Intelligence thesis.
Research · Pakistan · Pilot design · Interoperability
Clinical Intelligence Technical Architecture & Implementation White Paper
Technical white paper·Completed • Version 1.0·29 pages • prototype → Hospital-0 → production
End-to-end architecture for a portable longitudinal clinical-context platform, including data ingestion, provenance, missing-information detection, AI gateway controls, offline behavior, security, infrastructure, APIs, and staged delivery.
Covers FHIR, SMART, CDS Hooks, HL7, DICOMweb, provenance, longitudinal state, and AI gateway boundaries.
Separates deterministic clinical truth from probabilistic AI assistance.
Maps prototype, Hospital-0, and production/full-product evolution with infrastructure and cost considerations.
Architecture · FHIR · HL7 · AI governance · Offline-first
Concept-validation research paper·Completed • September 2026·16 pages • 25 references
Research into hospital revenue integrity failures that remain invisible even after billing software is installed: advances, unallocated payments, subledger/GL mismatch, cut-off, interface gaps, credits, staffing, and reconciliation.
Treats payment, revenue, receivables, and general-ledger truth as distinct states that require deterministic reconciliation.
Frames the product wedge as Continuous Patient Revenue Reconciliation rather than generic billing automation.
Separates financial control logic from AI assistance and keeps reconciliation deterministic.
How the architecture responds to real operational problems.
These are Gotham Coders-owned engineering studies. They document the problem, architecture decision, and current evidence without presenting simulations or repository tests as customer deployments.
01.
G-HIMS · Clinical Intelligence
Building Patient 360 from canonical clinical events
A longitudinal patient surface built as a governed projection rather than a manually assembled dashboard. The architecture connects encounter stages, diagnostics, medication, knowledge status, and evidence history without letting the read model become the source of truth.
Clinical information is distributed across encounters, departments, orders, results, medications, and operational systems. A useful patient view must consolidate context without destroying provenance.
Architecture decision
Use server-owned clinical events and canonical projections to build Patient 360, then layer knowledge-status and discharge-readiness intelligence above the governed record.
An offline architecture that treats disconnection, replay, identity remapping, shared workstations, conflict handling, and encrypted local clinical data as first-class operational behavior.
Hospitals cannot assume uninterrupted connectivity, yet duplicate writes, stale identity, or unsafe replay can be worse than downtime.
Architecture decision
Use encrypted local projections, a durable transactional outbox, stable command identity, replay-safe server commands, causal conflict handling, and explicit physical-device qualification.
Current evidence
The repository includes offline sync engine, vector clocks, local secure storage, reconciliation services, P6 completion tests, and a real-device qualification runbook.
Connecting care activity to revenue integrity without merging authority domains
A hospital workflow model where clinical actions create attributable operational and financial consequences while clinical truth and accounting truth remain separately governed.
Billing mismatches appear when services, fulfillment, charges, invoices, payments, and ledger postings are disconnected from the clinical events that caused them.
Architecture decision
Model patient, encounter, order, fulfillment, charge, invoice, payment allocation, adjustment, settlement, subledger, and GL as connected but independently controlled event states.
Current evidence
G-HIMS includes clinical-financial interoperability tests, double-entry financial services, billing/invoice surfaces, diagnostic revenue controls, and reconciliation-oriented architecture.
A manufacturing-first ERP architecture where customer demand, procurement, inventory, production, quality, logistics, finance, and audit remain connected through domain events instead of cross-module direct mutation.
Traditional ERP implementations can become collections of screens where operational consequences are reconciled after the fact.
Architecture decision
Give each domain ownership of its business rules, connect consequences through events/workflows, and preserve immutable inventory and financial ledgers.
Current evidence
Repository contains Sales/CRM, Procurement, WMS, MES, QMS, EAM, Finance, HR, Logistics, traceability, cross-module workflows, and broad automated test suites.
Multi-tenant ERP with immutable ledgers and reliable domain events
A control architecture combining tenant-scoped database policy, append-only inventory movements, immutable posted journals, reversal-based correction, event envelopes, and transactional outbox/inbox reliability.
RLS · Immutable ledgers · Outbox · Audit
Problem
Enterprise systems need to explain who changed critical state, why it changed, and how the correction propagated—without allowing silent history rewrites.
Architecture decision
Enforce tenant context at the database/service boundary, keep financially significant records append-only, and use correlation/causation IDs with reliable event delivery.
Current evidence
GC-ERP documents PostgreSQL RLS, site restrictions, immutable inventory/financial ledgers, event envelopes, secret sanitization, and outbox/inbox reliability patterns.
We separate repository verification, simulation, integration readiness, external qualification, and live deployment evidence so the public story stays proportional to what has actually been proven.