One Patient Record.
Every Care Model.
A proposed single, secure and interoperable web-based Electronic Medical Record and enterprise health platform designed for JCRC’s private, programme and research patient populations — with flexible billing, laboratory integration, Navision connectivity, telemedicine, multi-site standardisation and real-time management intelligence.
Cash • MOU • Insurance
Study Billing • USD Rates
Subsidised • Hybrid Billing
ALIS • Navision • MoH
DIGITAL CORE
What JCRC Said It Needs
The proposed platform architecture below is directly aligned to the operational concerns, expectations and constraints raised during the consultation.
Fragmented Current EMR
The existing IDI-origin EMR has been heavily customised but does not effectively support JCRC’s increasingly diverse clinical and financial workflows.
Multiple Patient Categories
Private, corporate/MOU, insured, research and programme patients require fundamentally different clinical, billing and reporting behaviours.
Complex Billing
Cash, insurance, corporate billing, study-specific research rates and subsidised programme services must coexist within one encounter framework.
Weak Management Reporting
Management needs immediate answers to fundamental questions such as patients seen, revenue generated, payer mix and programme performance.
Disconnected Systems
Finance, laboratory, insurance and clinical systems currently operate independently, forcing manual reconciliation and fragmented analysis.
Multi-Site Standardisation
JCRC wants one standard web platform across HQ, Mbarara, Fort Portal and Bulum rather than disconnected branch systems.
Security Before Speed
Reliability, data protection, security vetting and implementation assurance take precedence over rushing deployment.
Cost-Conscious Modernisation
Funding reductions make high recurring subscription costs unattractive. JCRC requires sustainable ownership and operating costs.
Executive Health Operations Dashboard
The management view should answer critical operational questions instantly without manual consolidation.
Patients Seen. Money Made. Services Delivered.
The central management dashboard directly addresses the consultation requirement for fast access to patient volumes and financial performance without spreadsheet-based manual compilation.
One EMR — Multiple Patient & Payer Models
The new architecture does not force every patient into one billing model. The patient receives one longitudinal clinical record while individual encounters may follow different financial rules.
Private Cash Patient
Patient receives services and settles eligible charges directly at point of care.
DIRECT PAYCorporate / MOU Patient
Example: an eligible Bank of Uganda patient receives care while the institution is billed according to the MOU.
ORGANISATION PAYSInsured Patient
Insurance eligibility, authorised services, claim preparation and reimbursement tracking are linked to the clinical encounter.
INSURANCEResearch Participant
Clinical activity is associated with the correct study and can use study-specific tariffs, including approved USD-denominated rates.
STUDY PAYSProgramme Patient
Programme-covered services or medicines are automatically distinguished from patient-paid services within the same encounter.
PROGRAMMEHybrid Patient
One visit may include free programme medicines, cash-paid laboratory work and another service charge assigned to a sponsor.
MULTI-PAYERTelemedicine Patient
Future remote consultation connects to the same clinical record, orders, prescriptions and billing engine.
REMOTE CARELongitudinal JCRC Patient
The same person may participate in different care models over time without creating fragmented clinical identities.
ONE PATIENT IDUnified Electronic Medical Record
The proposed EMR is web-based, branch-independent and designed around logical clinical workflows rather than fragmented menu navigation.
Master Patient Index
Prevent duplicate records across branches, programmes and patient categories.
Clinical Documentation
Structured and narrative notes, diagnoses, observations and follow-up.
Pharmacy & Prescribing
Clinical prescriptions with payer and programme eligibility logic.
Appointment Management
Branch, provider, research, programme and telemedicine appointments.
Clinical Documents
Referral notes, attachments, signed forms and patient documentation.
Clinical Alerts
Allergy, interaction, programme, protocol and follow-up alerts.
Research Overlay
Study participation is managed without creating a separate clinical identity.
Analytics by Design
Every structured encounter supports management and research reporting.
Multi-Payer & Hybrid Billing Engine
The billing engine is central to solving JCRC’s current inability to analyse revenue consistently across cash, MOU, insurance, research and programme-funded care.
One Clinical Encounter — Multiple Possible Payers
Each service line can carry its own payer, tariff, currency, subsidy and accounting allocation.
| Service | Patient Type | Responsible Payer | Tariff | Currency | Finance Posting |
|---|---|---|---|---|---|
| Programme Medicine | Programme | Programme Fund | Covered | N/A | Programme Cost Centre |
| Additional Laboratory Test | Programme | Patient | Standard | UGX | Private Revenue |
| Research Protocol Visit | Research | Study | Study Rate | USD | Study Cost Centre |
| Corporate Consultation | MOU | Corporate Organisation | MOU Rate | UGX | Receivable |
ALIS & Laboratory Integration
JCRC’s existing ALIS environment and connected laboratory machines represent important investments. AL.JCRC is designed to integrate rather than disrupt them.
EMR sends authorised laboratory orders to ALIS and receives validated results.
Preserve ALIS interfaces to connected laboratory analysers and instruments.
Support traceability, quality controls, validation, auditability and laboratory governance aligned to accreditation requirements.
Real-time TAT indicators, overdue tests and management alerts.
Only authorised validated results are returned to the patient record.
Reagent consumption can trigger stock thresholds and procurement requirements.
Laboratory services can be associated with programmes or individual studies.
Completed chargeable tests can flow through the billing engine and Navision.
Microsoft Navision Financial Integration
The EMR handles clinical charge creation and payer allocation. Navision remains the authoritative ERP for accounting, receivables and financial reporting.
Patient Receivables
Approved financial transactions can post to the appropriate Navision accounts.
Corporate Accounts
MOU and institutional bills consolidate by corporate customer.
Study Cost Centres
Research services can be attributed to correct studies and grants.
Management Revenue
Dashboard combines clinical activity with authorised financial data.
AL.JCRC Enterprise Health Architecture
The platform becomes the clinical and orchestration layer connecting established specialist systems through controlled interfaces.
AL.JCRC Unified EMR Core
Single web-based clinical, financial and interoperability platform.
One JCRC Platform Across All Sites
A central web architecture prevents each branch from independently acquiring a different clinical system.
JCRC Headquarters
Central clinical, administrative, research and management environment.
Mbarara
Same workflows, master data, security and reporting architecture.
Fort Portal
Central configuration with controlled local operational permissions.
Bulum
Standardised web access rather than independent branch-specific EMR deployment.
AL.JCRC is designed specifically to avoid a future where different branches operate different clinical applications such as Clinic Master, Smartell, Zia or other independent platforms that create additional interoperability, training and reporting problems.
Telemedicine-Ready Architecture
Telemedicine is treated as a future-facing capability rather than a standalone clinical silo.
Remote Care Connected to the Same Patient Record
JCRC may deploy native teleconsultation functionality or integrate a secure third-party telemedicine provider. In either scenario, consultation documentation, prescriptions, diagnostic orders, billing and follow-up should remain part of the same longitudinal EMR.
Native Option
Secure integrated video consultation directly within AL.JCRC.
Third-Party Option
API integration to an approved telemedicine platform.
AL.JCRC Clinical Session
Ministry of Health & Government Interoperability
JCRC’s increasing alignment with Government of Uganda and the Ministry of Health should be reflected in technical architecture, reporting standards and interoperability capability.
Government Compatibility
API-ready architecture for approved government reporting and health-information systems.
Interoperability
Standards-based exchange should be preferred over closed proprietary data silos.
National Reporting
Structured data should support approved national health reporting requirements.
Partnership Evidence
The formal proposal should include only verified Atine Labs government and Ministry of Health engagements before presentation.
The consultation specifically identified previous government and Ministry of Health partnerships as an important selling point. AL.JCRC therefore reserves this area for documented references, case studies, letters, deployed systems or other evidence that Atine Labs is authorised to present. No unverified government partnership claim is inserted into this prototype.
Clinical-Grade Security & Reliability Framework
The consultation explicitly rejected rushed implementation. AL.JCRC therefore assumes formal security assessment, reliability testing, controlled migration and staged acceptance before production deployment.
Proposed Phased Delivery Model
This reflects the consultation recommendation to introduce value progressively rather than attempting a disruptive institution-wide big-bang replacement.
Requirements, workflows, legacy data, ALIS, Navision, security, branches and stakeholder validation.
Registration, patient identity, triage, consultation, prescriptions, orders and notes.
Cash, MOU, insurance, pricing, receivables and Navision.
Study billing, programme subsidies, hybrid workflows and specialised reporting.
Dashboards, telemedicine, broader interoperability, branch rollout and advanced analytics.
Build In-House vs Strategic Outsourcing
The internal proposal is expected to compare these alternatives. AL.JCRC can be positioned as a collaborative model rather than a vendor lock-in proposition.
In-House Development
Offers direct institutional control but requires sufficient software engineering capacity, product ownership, security expertise, clinical informatics capability, testing and permanent maintenance resources.
HIGH INTERNAL OWNERSHIPTraditional Outsourcing
Can accelerate delivery but may introduce vendor dependency, high subscriptions and limited flexibility if procurement focuses on a closed off-the-shelf application.
VENDOR DEPENDENCY RISKProposed Partnership Model
JCRC retains institutional ownership and governance while Atine Labs provides architecture, engineering, customisation, integration, security and controlled knowledge transfer.
RECOMMENDED MODELGiven the funding environment and concern about recurring subscription expenditure, the commercial proposal should favour a transparent implementation and customisation cost combined with a proportionate maintenance/support structure. An appropriate option would be a one-time implementation and configuration fee followed by lower annual support tiers based on agreed sites, services or support scope, rather than an escalating per-patient subscription model.
JCRC Online Demonstration Plan
The next meeting should demonstrate the platform through realistic JCRC personas rather than a generic software feature presentation.
Demo 1 — MOU Patient
Register a corporate patient, verify eligibility, perform consultation, order laboratory services and bill the institution rather than the patient.
Demo 2 — Research Participant
Enrol a participant, perform a protocol visit, send an ALIS laboratory request and bill services to a study using study-specific rates.
Demo 3 — Hybrid Programme Patient
Show programme-funded medicines together with an additional paid service within the same patient encounter.
Demo 4 — Executive Dashboard
End by showing total patients, revenue by payer, laboratory performance, sites and management reporting.
| Demo Priority | What to Show | Consultation Requirement | Status |
|---|---|---|---|
| 1 | Multi-patient workflows | Private, programme and research | CORE |
| 2 | Billing engine | Cash, MOU, insurance, research, hybrid | CORE |
| 3 | Laboratory management | ALIS, machines, CAP orientation | CORE |
| 4 | Navision API flow | Finance interoperability | SHOW |
| 5 | Management dashboard | Patients seen / money made | SHOW |
| 6 | Security model | Thorough vetting | EXPLAIN |
| 7 | MoH interoperability | Government alignment | EXPLAIN |
The consultation notes call for an online demonstration after the following week, targeting the Friday approximately two weeks from the consultation date. The exact calendar date should be confirmed with Emma rather than hard-coded into the platform until formally agreed.
The internal observation that access to a key stakeholder has taken approximately three months also reinforces the need for the demo to be self-explanatory, decision-oriented and strong enough to circulate internally after presentation.
Atine Labs™ — Technology Partner for the AL.JCRC Pilot
AL.JCRC is being developed as a pilot architecture demonstrating how JCRC could consolidate clinical, laboratory, financial, research and programme workflows while retaining interoperability with established enterprise systems.
Institutional ownership:
Joint Clinical Research Centre
Proposed platform:
AL.JCRC Unified EMR & Enterprise Health Intelligence Platform
Pilot architecture and development:
Atine Labs™
Atine Labs™
Where Technology Meets GovernanceDigital Solutions • Public Impact • Global Reach