Technical Docs

Problem

An abnormal screen is not finished care. In this demo, people wait between the result, the review, the referral, the visit, and a verified outcome. Those gaps are easy to miss when each step lives in a different system.

CareTrack is a fictional prototype for the Future Health Digital Innovation Challenge. It shows the screening-to-care loop. It does not diagnose or prescribe.

Solution

Every actionable result gets a next step, an owner, and a verified outcome. Coordinators work the list. Family physicians decide. Clinics return what happened. Programme managers see whether the loop closed, without using names on the dashboard.

Priority, reminders, and the Loop Health Score are rules in the browser. A clinician confirms every AI suggestion.

User roles

Care Coordinator: contact details and the workflow for the whole panel.

Family Physician: the full record for their own patients, including the accept, change, or reject decision.

Specialist/Clinic: only referrals sent to their clinic.

Programme Manager: dashboards and governance. Patient names are hidden. The screen says Access limited for your role.

There is no password. The header switches the demo role.

Care journey

Result, doctor review, referral, appointment, care received, and back to the family physician. A booked appointment is not completed care.

My Care Journey is the patient view, including Arabic. The person can change consent there. If reminder consent is withdrawn, the case says Contact by care team only.

Architecture

The picture below is the intended shape of a live service. This prototype keeps everything in the browser.

Data model

A person has demographics, insurance, consent, and one or more screening results. A result has a stage, a due date, an optional clinician decision, and an optional case outcome.

Referrals, simulated messages, barriers, contact attempts, outreach drafts, consent records, and audit events are separate rows. They are stored only in this browser under himforward-caretrack-v1.

FHIR mapping

The FHIR samples page builds fictional FHIR R4 JSON for one person: Patient, Observation, ServiceRequest, Appointment, Task, Encounter, Consent, AuditEvent, and a Bundle.

Observation codes are example LOINC and SNOMED codes for the demo. They are not a live terminology service.

AI rules and safety

Priority uses the result, cancer-screening type, how many abnormal risk findings are open, age 60 or older, and days waiting. It does not use nationality, gender, or insurance.

The suggestion names a next step. A family physician accepts, changes, or rejects it. A change or a reject is an override. The app never diagnoses or prescribes.

Governance shows the override rate, a bias check, and a way to report a safety concern into the audit log.

Privacy and consent

All people and clinics are fictional. Data is saved only in this browser.

Three consent purposes are recorded: care coordination and data sharing, reminders by the chosen channel, and de-identified programme statistics. Each shows granted or withdrawn, the date, and the method.

The design is meant to align with UAE and Abu Dhabi health data rules (to be confirmed with DoH). A live service would plan encryption and hosting in-country. That is not built here.

Scalability

The prototype holds 30 fictional adults on one device. A pilot would move the same model to a server, with worklists paged by owner and area.

Reminders would leave the browser only after consent, through a gateway. The rules engine can stay deterministic so a clinician can see why a case is Priority 1.

Integration with Malaffi/Sahatna/EMR

A live design would read results from EMRs and screening labs through Malaffi, map them with FHIR R4, and write the next step back. The patient view could later sit beside a Sahatna-style app.

None of those connections are live. The FHIR page is a sample for an integration conversation.

Pilot plan

A small pilot would pick one screening pathway, one family-medicine list, and one clinic. Staff would use the worklist for a few weeks, with consent captured before any real reminder.

Success would be a higher share of verified care within the target time, and an override log that clinicians trust. This demo uses 20 March 2026 as its clock.

Business model

Draft: a programme subscription for the care team that closes the loop, not a fee per diagnosis. A health authority or a screening programme would be the customer.

Clinics would not pay to be ranked. In-network and area rules stay visible. Pricing is not set in this prototype.

What is built vs planned

Built in this prototype: fictional panel, roles, priority, referrals, simulated reminders, drop-off risk, My Care Journey, outcomes, Loop Health Score, consent, audit, governance, guided judge stories, and FHIR samples.

Planned, not built: live Malaffi or EMR feeds, real SMS, WhatsApp, or voice, in-country hosting, accounts, and a production terminology server.