SINA EMR · Research date: 2 November 2026, Cairo · Planning deliverable

One clinical platform, with every identified requirement retained

20 visual workspaces, fictional patients, and interactive examples for all 48 feature groups. Open locally; no installation required.

Role-specific desktop and mobile samples

The prototype now models 20 roles, assigned-patient scope, private drafts, countersigning, patient release, named sharing, temporary read-only approvals, expiry and revocation. All 48 roadmap feature groups remain recorded.

Read the role and sharing model · Explore the full mobile example

Prototype controls demonstrate behavior only; production authentication and server-side authorization are still required.

Recommendation: extend the existing Surgical Tracker and Social Leads into one clinical platform. Preserve their working features, introduce a shared patient and encounter model, and add voice, drugs, references and external connections in gated phases. Keep PostgreSQL portable and large files in private object storage. Do not merge several complete EMR codebases.

This review covers your nine-slide concept, the two repository snapshots, the ClinicMind video concept, DIME, 12 Egyptian-market platforms, four international products and seven open-source projects. It is a bounded public-source survey, not a census of every EMR or a download of proprietary databases. No production code or source deck was changed.

1. What your deck and apps already establish

Source	What to preserve	Gap to close
Slides 1–2: vision and benchmarks	Surgical workspace, familiar layouts, specialty context.	Translate design inspirations into verifiable requirements; benchmark names do not prove parity.
Slide 3: Today	Appointments, cases, attention flags, named coordinator, Cairo time.	Connect real queues, task ownership and escalation rules.
Slide 4: patient record	ID separate from name; overview/notes/photos/documents; allergy verification; lead provenance.	Build longitudinal encounters, medication reconciliation and shared identity.
Slide 5: surgical case	Consultation → preparation → procedure → recovery, consent and clearance status.	Join existing drains, complications, revisions and outcomes into one episode.
Slides 6–7: connected and mobile	Social Leads → EMR → Case Tracker → follow-up; role access; mobile tasks.	The apps are still separate implementations. A common identity/access layer must precede automatic record sharing.
Slides 8–9: rollout and sources	Fictional prototype, clinical model, permissions, audit, privacy and integration work.	Move safety foundations ahead of the real-patient pilot; retain source attribution.
Surgical Tracker	Offline local records, Supabase synchronization, photos, surgical follow-up, reports, settings and imports.	Code includes cloud support despite older roadmap wording. Current synchronization and storage need clinical-grade verification; no EXE wrapper was established.
Social Leads	Lead attribution, collaboration, consultations, surgery conversion, amounts/currencies, reminders, team reports and imports.	Source labels are not direct Meta/TikTok/Snapchat integrations. Conversion does not yet establish a unified clinical record.
ClinicMind video concept	Voice-to-note, patient communication, scheduling, finances, automation, feedback and old-record imports.	Transcript/product claims are inspiration, not independently tested guarantees; AI output must be reviewed.
DIME	Patient portal, clinical intelligence, hospital/lab/imaging/payer exchange and research.	Public feature claims do not establish accessible APIs, validated AI or contracts with Egyptian providers.

Inspected repository heads: Tracker 7a217ce3839034b5a51821eb7d57ec9d616bfb41; Social 4caf93cd20a3f84701e68ef3bdc5079e6a0f5a3d. “Observed” means code/document evidence, not runtime or production certification.

2. The integrated patient and delivery pipelines

Enquiry / referral → shared patient identity → booking and clinic queue → consultation + photos/audio/documents → reviewed note + references → quotation / prescription / surgical plan → preparation and consent → procedure → drains / complications / recovery → patient follow-up → outcomes and billing → permitted reporting and research

Scouting feeds the requirement register continuously during active development. It does not automatically add code, import content, activate integrations or expand the current release. Features stay recorded when deferred. No recurring background scouting has been scheduled by this deliverable.

Phase	Work	Exit gate
0 — Scout and baseline	Capture sources, rights and full feature parity. Read-only discovery can run alongside design.	Gate: agreed register, current-app snapshots, synthetic migration fixtures and licensing shortlist.
1 — Shared clinical foundation	Shared identity, roles, audited clinical records and lead-to-patient linkage; preserve existing UI and functions.	Gate: tenant isolation, data integrity, source traceability and tested recovery before real patient pilot.
2 — Complete surgical workflow	Carry forward tracker features, media, offline synchronization, Windows packaging and reversible migration.	Gate: no feature regression, conflict/restore tests and supervised clinic workflow acceptance.
3 — Voice, drugs and references	Audio first, then reviewed transcription; rights-cleared Egyptian catalogue and reference search.	Gate: licences, provenance, Arabic/English clinical evaluation and clinician release controls.
4 — Clinic operations and patient engagement	Quotes, financial reconciliation, inventory, staff workflow, WhatsApp and portal.	Gate: communication consent, reconciliation, escalation ownership and partner access.
5 — External exchange and measured scale	One real lab or imaging partner first; calendar/social/payment/payer adapters as contracts allow.	Gate: sandbox-to-production evidence, failure recovery, load targets and total cost measured.
6 — Hospital, advanced specialties and research	Preserve DIME-scale hospital and research ambitions as explicit later scope.	Gate: separate clinical/service readiness and research governance; do not hold the clinic launch for these.

3. Architecture and cost recommendation

Default: retain the existing interface and PostgreSQL model while introducing a shared application service for clinical writes, permissions, audited changes and integration jobs. Use private object storage for photos, audio and documents; keep metadata and authorization in the clinical database. Web, PWA and Windows access the same service. The desktop client needs an explicitly designed encrypted offline subset and conflict workflow.

A Windows executable is compatible with a Supabase-backed application. Tauri documents static-export Next.js support. Packaging does not create offline synchronization, secure local storage or automatic updates by itself.

Option	When to choose it	Cost/operational implication
Existing Supabase	Fastest route while current scale and service terms remain suitable.	Measure database, storage, egress, auth, backups and realtime use; switching providers is not inherently a saving.
Managed PostgreSQL such as Neon + object storage	Strong alternative when you want database portability and separate file economics.	Auth, authorization, jobs, synchronization and support still need a solution. Compare total cost, not database bill alone.
AWS RDS PostgreSQL + S3	When recovery, availability, network controls and operational support justify greater complexity.	Include standby capacity, backups, transfer, monitoring and engineering effort.
Other managed PostgreSQL / self-hosted PostgreSQL	Evaluate DigitalOcean or a managed/self-hosted deployment only with region, recovery and support requirements defined.	Self-hosting lowers some invoices but transfers patching, incident response, restore and uptime work to you.
Medplum bounded evaluation	Test one patient → encounter → attachment → permission workflow if FHIR becomes central.	Compare migration complexity and total operating cost before replacing the existing backend. Do not keep competing clinical sources of truth.

Cost model: database compute + retained records/backups + file GB-months + requests/transfer + recorded/transcribed audio minutes + AI processing + messages + monitoring/support. Start with recorded audio; make transcription and summaries optional per encounter. Compress delivery copies without destroying clinically necessary originals; generate thumbnails once; load media on demand. Use queues for OCR, transcription and imports. Add replicas or partitioning only after measured bottlenecks.

Illustration, not a quote: 10,000 patients × 20 photos × 2 MB ≈ 400 GB. Ten recorded minutes per patient at 64 kbit/s ≈ 48 GB; 100,000 transcription minutes are a separate expense. This excludes replicas, backups, thumbnails and documents. R2 pricing can inform object-storage comparison, but medical-data contracts, region and retention requirements must be checked separately.

Define expected clinics, concurrent staff, patients/year, photos and audio minutes/encounter, retention, availability and recovery targets before selecting a provider. Validate access isolation, concurrent bookings, offline conflicts, bulk imports and full database-plus-file restores with synthetic data. A patient-count claim alone is not a scalability test.

4. Data and integration acquisition pipeline

Discover public source → record owner/licence/access → obtain authorized export or API → raw staging with provenance → validate and normalize → deduplicate/map → clinical or administrative review → versioned publish → monitor updates → rollback

Data / connection	Acquisition route	Release condition
Egyptian registered drugs	EDA registry and authorized exports; Dwaprice API is a commercial candidate, not a vetted feed.	Confirm bulk rights, coverage, updates, attribution and offline/AI rights. Never infer live stock availability from registration.
Medical references	EDA formulary; licensed specialty sources; NICE reuse terms; commercial sources such as UpToDate/Lexidrug under their contracts.	Store full text only when permitted. Validate interactions/dosing independently of generative summaries.
Terminology	WHO ICD API, LOINC, SNOMED licensing.	Check version and territory/use terms; code mapping requires review. Do not presume Egypt-specific SNOMED rights.
Patient chart imports	Only clinic-authorized exports, with previews and reconciliation.	Identity match, provenance, malware checks for attachments, migration rollback and audit. No national patient-record harvesting.
Lab / PACS / payer / booking	Contracted partner endpoint and sandbox; FHIR/HL7/DICOM where supported.	Verified endpoint coverage and real partner acceptance. A vendor mentioning a standard is not API entitlement.
Medicolize / Dentolize webhooks	Public docs describe outbound events; feature enablement required, maximum five endpoints, five-second timeout, no failed-delivery retries.	Fast durable capture, signature verification where enabled, reconciliation/backfill. Determine what cannot be recovered before relying on the feed.
Open-source code	Selected upstream components after exact-revision licence and dependency review.	Maintain notices and obligations, security review, tests and upgrade ownership; a public GitHub binary is not an open-source licence.

5. Egyptian-market scouting

Twelve reviewed platforms, including two adjacent booking services. Claims below are vendor-published unless public technical documentation is explicitly identified. They are not a ranking or proof of market share.

Platform and evidence	Ideas worth preserving	Integration / uncertainty
DIME Describes itself as Egyptian and designed for Arabic/English Egyptian healthcare workflows.	Longitudinal clinical memory; HIS/EMR/HIE separation; Patient portal; Cross-provider longitudinal records	Vendor claims FHIR R4 standards-based APIs; no public operational API tested or developer access established. Open: Certification, uptime, actual integrations, data export and partner access need independent evidence. Source 1
Medicolize / Dentolize Egypt page names New Cairo team; surgical page lists Egyptian client examples (vendor claims).	Versioned surgical quotation through consent and booking; Case-level deposits and installments; Separate clinical and photo-publication consent; Standardized before/after photos attached to procedure; Implant batch/expiry and case profitability; Automatic postoperative review schedule; Doctor shares from performed services; Clinic-owned WhatsApp conversation history	PUBLIC TECHNICAL DOCUMENTATION: outbound webhooks for patient, invoice, payment, procedure, operation and expense events. Account API feature must be enabled; full permissions required; maximum 5 endpoints; 5-second timeout; failed deliveries are NOT retried; optional HMAC-SHA256 signature. This is not proof of a complete bidirectional EMR API. Open: Commercial API entitlement, backfill/reconciliation/export, read/write API coverage, event completeness. Source 1 · Source 2 · Source 3
Helix Explicit Egypt product page; claims data for Egyptian clinics stored in Egypt.	Egyptian Arabic/English ambient scribe; Role-specific bilingual UI; Mapped laboratory send-outs and returned results	Vendor specifically names Health360 lab network send-outs/results mapping. Explicitly says no Egyptian Tax Authority e-invoice/e-receipt integration today. Public endpoint documentation not established. Open: Clinical screens described as English only; hosting/compliance and scribe accuracy claims unverified; partner coverage/contract needed. Source 1
TabeebPlus Designed for Egypt/GCC; Egyptian payment options published.	Separate cloud and fully offline desktop editions; Doctor commissions; Queue and waitlist; Patient portal; Excel migration	Enterprise tier advertises APIs/webhooks; insurance and tax connections advertised but no technical endpoints verified. Pharmacy and lab products explicitly labelled Soon: do not count as delivered. Open: Cloud/desktop synchronization not demonstrated; no assumption that separate products share an offline sync engine; tax and insurer claims need proof. Source 1 · Source 2
TabeebHub Explicitly built for doctors/clinics in Egypt; EGP plans.	Reception-to-assistant-to-doctor queue states; Draft/final prescription release to patient; Patient app with phone verification; Branch cash drawers; Web plus downloadable desktop/mobile clients	Public site links Windows download on GitHub, but downloadable binary does not establish open-source licensing. No public third-party API verified. Open: Offline support, desktop code licence, external API, export and audit completeness. Source 1 · Source 2
ClinBeam Egypt/MENA positioning, EGP and Egyptian contact number.	Staff-driven waiting display; Dental chart to treatment stages to billing; Installments; Batch/expiry inventory; Permission-aware branch switching	Messaging requires enabled feature and configured provider. Search snapshot mentioned API/FHIR but current opened homepage did not establish technical API; treat as unverified. Open: Hosting, backups, migration formats and actual offline capability explicitly require confirmation; no automatic payment integration inferred from manual InstaPay subscription collection. Source 1
ClinicPro (clinicpro.me) Cairo/Alexandria, EGP and PayMob named on Egypt page.	Arabic numeral input; Per-user language and RTL; Bilingual printed prescriptions/receipts; Excel export and audit log on paid plan	PayMob card payments advertised; no general API verified. Open: Do not confuse with getclinicpro.com (separate product found); database isolation and operational controls not tested. Source 1
Health Vision HIS / Inovexis Cairo office and Arabic-first Egyptian market positioning.	Specialty templates with structured fields and free text; Cashier end-of-day reconciliation; Partial payments/refunds; Branch and doctor revenue analysis	Drug database/dose helpers and insurance workflows advertised; no public API or drug feed licensing established. Open: Drug source, integration contracts, clinical validation, export and hosting details. Source 1
Aegis EMR / Naghamy Health Explicit Egypt/KSA/UAE target; operator identifies as Wyoming US LLC, not an Egyptian-incorporated vendor.	Modular EMR, voice and prescription products; Clinician review of generated notes; Arabic/English dictation; Explicit disclosure of transient audio and external AI processors	Marketing describes FHIR R4 readiness, not tested endpoints. MediVoice page names AssemblyAI via OpenRouter and Groq preview/fallback and warns local upload deletion does not mean provider zero retention. Open: 25k Egyptian drugs claim needs coverage/source licensing audit; renal/dose checks need validation; API access/hosting contracts not verified. Source 1 · Source 2
ClinicsAdmin EGP subscriptions via Egyptian bank/e-wallet methods; Arabic/English product.	HR/payroll alongside clinic workflows; Data export on cancellation; Per-clinic database isolation claim; Doctor-specific reporting	No public technical API established; full export advertised, format/attachments unverified. Open: Promotion validity, storage limits, payroll localization, restore evidence and actual export completeness. Source 1
Vezeeta Official about page explicitly lists Egypt operations.	Patient discovery/acquisition; Appointment confirmations; Multiple clinic schedules; Treatment-plan communication	Adjacent booking/practice-management platform. No public integration API or permission to mirror doctor listings verified. Potential partner connector, not assumed accessible. Open: Partner integration, booking reconciliation, export and depth of clinical charting. Source 1 · Source 2
CliniDo Official FAQ confirms Cairo and Upper Egypt service including Assiut, Minya, Sohag and Qena.	Home visits and home lab collection booking; Online consultations; Family/proxy booking; Confirmation with clinic details	Adjacent booking platform, not verified as full EMR. Doctor app/onboarding advertised; no public developer API established. Open: Booking API, lab partner agreements, clinical records scope and commercial access. Source 1

Discovery queue, not yet reviewed: Clinit, Medastik, E-Doctor, MEGACARE / Megamind, PaxeraHealth imaging, Dawaaka Rx (early-stage adjacent prescription verification, not full EMR). Extend coverage by specialty, hospital size and Egyptian implementation evidence; record duplicates and products without technical documentation. No claim to have found every local vendor.

6. International and open-source scouting

Product	Useful pattern	Integration evidence
Epic	Single perioperative record spanning pre-, intra- and postoperative documentation; Patient portal care plans, remote monitoring, appointments and one-time record sharing; Specialty modules with outcomes and operational reporting Apply: Design a surgical episode with stage-specific checklists, patient follow-up tasks, and a controlled export/share workflow.	Official FAQ confirms FHIR read/write and SMART OAuth patient/provider, standalone/EHR launches. open.epic fetch timed out; API access still requires registration, local organization enablement and resource-specific validation. Source 1 · Source 2 · Source 3 · Source 4
Oracle Health	Role-specific organizer and longitudinal encounter/medication timelines; Voice-assisted chart review and generated summaries; Patient portal with plain-language explanations and clearly marked AI source citations Apply: Prepare a source-linked previsit summary, chronological medication changes and explicit AI labeling. Evaluate Arabic/English locally.	Public Millennium FHIR R4 and EHR API catalogue. DSTU2 unsupported. Do not assume new EHR products expose every Millennium endpoint; confirm contracted product and operation. Source 1 · Source 2 · Source 3
athenaOne	Connected EHR, practice management, billing and patient engagement; Partner marketplace for additional workflows; Published device integration menu, including Windows-specific ADM connections Apply: Keep an integration catalogue with support owner, cost, supported devices/OS, consent scope and failure recovery; connect scheduling and financial events to clinical workflow.	Official site directs developers to portal; portal rendered no readable text in browser search. Endpoint details not verified; US integrations do not imply Egyptian network access. Source 1 · Source 2 · Source 3 · Source 4
ModMed	Plastic-surgery photo annotation, surgical forms/consents and reusable preferences for implants/anesthesia; Cosmetic quotes, inventory, before-and-after galleries and patient communications; Specialty voice documentation whose approved note content can support downstream orders Apply: Highest specialty-fit benchmark: photo taxonomy and annotations, separate treatment/teaching/marketing consent, procedure quote versioning, implant and inventory traceability, approved voice-to-note flow.	Public tailored FHIR R4 API docs for patients/appointments/clinical information; vendor registration/certification applies. US coding and prescribing integrations require Egyptian adaptation. Source 1 · Source 2 · Source 3 · Source 4 · Source 5

Open project	Role and licence	Recommendation / caveat
OpenEMR	Full EMR and practice-management application GPL-3.0	Study established encounter, scheduling, billing and portal workflows; evaluate as alternative foundation rather than merging entire application into tracker. PHP application with its own architecture. GPL obligations need review before copying/distributing code. Existing certification is not certification of a modified Egyptian deployment.
OpenMRS	Modular EMR platform core; choose/configure distribution and modules MPL 2.0 with Healthcare Disclaimer	Patient/encounter/concept architecture and modular clinical forms; platform alternative for facility-led deployment. Core alone is not finished clinic UX. Check individual module licences, Arabic completeness and clinical configuration.
Bahmni	Integrated EMR/hospital system; cited repo is frontend component Cited frontend LICENSE: MPL 2.0 with Healthcare Disclaimer; full distribution mixed licences	Integrated registration, clinical services, labs, inpatient, stock, billing and PACS workflow reference. Do not label whole Bahmni stack one licence. Official page describes ongoing AGPL-to-MPL transition; review each component and exact revision. Frontend includes AngularJS and React.
Medplum	FHIR healthcare development platform and components, not turnkey Egyptian EMR Apache-2.0	FHIR datastore, TypeScript SDK, React clinical UI components, versioned resource-driven automation; strong candidate for a bounded architecture spike. Hosted services and optional features have separate availability/terms; Bots disabled by default on hosted accounts. Existing lab/prescribing integrations do not imply Egyptian support.
HAPI FHIR	Java FHIR client/server library and infrastructure component Apache-2.0	FHIR validation, exchange adapters and a FHIR service when an actual partner requires it. Not an EMR or authorization/compliance solution by itself; avoid adding Java infrastructure until needed.
OHIF	Web medical imaging viewer MIT	DICOM study viewing and annotation, integrated with partner imaging archive when necessary. Not an archive, ordinary photo gallery or full EMR. Requires appropriate image source and deployment validation; derivative products' clearance does not confer clearance on our deployment.
Synthea	Synthetic patient generator, not EMR Apache-2.0	Generate non-real test patients, histories and FHIR fixtures for imports, load tests and integration demos. Default demographics are US-oriented; not representative Egyptian clinical evidence or real patient data. Localize fixtures and add manual surgical/media/conflict cases.

Selection: study OpenEMR/OpenMRS/Bahmni for complete clinical workflows; evaluate Medplum only as an architectural alternative; use HAPI when FHIR exchange justifies it; use OHIF when a real DICOM source exists; use Synthea for synthetic tests with Egyptian surgical fixtures. No repository was executed, clinically validated or adopted through this scouting exercise.

7. Full retained feature register — 48 capability bundles

Phase numbers sequence delivery; they do not delete scope. “Partial” means related foundations exist but the full requirement is not established. “New” means proposed scope. Acceptance statements are future release gates, not tests already passed.

ID / phase / evidence	Capability and retained scope	Source and acceptance
F001 · Phase 0 New	Evidence and scope register Record feature, source, evidence level, licence, Egyptian relevance, dependencies, owner, phase and acceptance result. Scout additional vendors through a discovery queue; preserve deferred scope.	User; scouting Gate: Every prior source has mapped requirements; no vendor claim silently becomes a delivered feature.
F002 · Phase 0 Observed code/docs	Migration and regression baseline Inventory both apps, schema, permissions, exports, attachments and existing user flows. Test fictional cases before migration; retain rollback and reconcile counts.	Tracker; Social Gate: Export/import round trip preserves relationships, amounts, notes and attachments.
F003 · Phase 1 Partial	Shared patient and clinic identity Separate internal patient UUID, displayed patient ID and name. Link lead, consultation, operation and encounter without copying identities; deduplicate with review, never automatic name-only merging.	Deck; Tracker; Social Gate: Two patients with the same name stay separate; reviewed merges remain reversible and audited.
F004 · Phase 1 Partial	Permissions and audit Clinic/branch boundaries, named staff roles, least privilege, session/device controls, access logs, immutable clinical sign-off plus amendments, archived records and recovery. Replace legacy hardcoded administrator assumptions.	Deck; Tracker; Social; DIME Gate: Cross-clinic reads and attachment access fail; every signed change has an author and amendment trail.
F005 · Phase 1 Partial	Clinical chart Allergies with unknown/unverified status, medication reconciliation, problems, vitals, procedures, specialty templates, free text, documents and chronological encounters. Patient-reported, AI-drafted and clinician-verified data remain distinct.	Deck; DIME Gate: Unknown allergy is never rendered as no allergies; each chart assertion has provenance.
F006 · Phase 1 Partial	Today and mobile workspaces Clinic day, arrival/waiting states, appointments, surgical cases, overdue follow-ups, attention tasks and named owners; persistent patient context and side-by-side chart detail.	Deck; Tracker Gate: Staff can find today’s patient, owner and next task on desktop and phone.
F007 · Phase 1 Partial	Languages and presentation Arabic/English, RTL, Arabic numeral entry, per-user language, Cairo local time with DST, bilingual printouts, existing themes and light/dark/system preferences.	Tracker; Social; local scouting Gate: Arabic names, numbers, layout and Cairo timestamps survive imports, exports and printing.
F008 · Phase 1 Observed code/docs	Lead acquisition and attribution Meta, TikTok, Snapchat, word-of-mouth and referrals; campaign/referrer/hospital, source sections, configurable fields/tabs/results, Other notes and sample-data flags. Source tracking is not evidence of a direct social-network API.	Social Gate: Attribution follows a converted lead without duplicate patient creation.
F009 · Phase 1 Observed code/docs	Lead collaboration and reminders Assignments, E164 phone validation, follow-up dates, threaded comments/replies/reactions, field notes, attachments, mentions, notifications, push, last-seen and contextual reminders.	Social Gate: Mentions and reminders respect permissions and deliver once with visible failures.
F010 · Phase 1 Observed code/docs	Consultation-to-surgery conversion Consultation date/type/fee/attendance, booking and completion, linked surgery, moderator notification and safe undo/archive; preserve source, coordinator and history.	Social; Deck Gate: Conversion is idempotent; undo never destroys signed clinical history.
F011 · Phase 2 Partial	Surgical episode Consultation → preparation → procedure → recovery; multiple procedures, surgeon, urgency, duration, checklist, clearance and consent status. Unscheduled cases remain unscheduled.	Tracker; Deck; Epic Gate: One episode links all visits, media, complications, revisions and outcomes.
F012 · Phase 2 Observed code/docs	Case search and editing Patient ID/name, surgeon/outcome/date filters, status chips, quick surgeon creation, custom procedure lists and configurable checklists; preserve historical checklist labels after edits.	Tracker Gate: Renaming a template cannot erase completed checklist evidence.
F013 · Phase 2 Partial	Appointments and queue Month/day agenda, walk-ins, duplicate prevention, scheduled/done/no-show/cancelled, reschedule/cancel, waitlist, stage-based reception/assistant/doctor queue and approximate wait times.	Tracker; Video; local scouting Gate: Concurrent booking attempts cannot reserve one exclusive slot twice.
F014 · Phase 2 Observed code/docs	Drains and wound review Drain counts, insertion/removal dates, days-in-place alerts, removal/undo, filters, linked visits and clinician-configured wound-check suggestions.	Tracker Gate: Rules are configurable; completing a visit cannot silently change drain status.
F015 · Phase 2 Observed code/docs	Complications and follow-up Complication type, Clavien-Dindo, date, management steps, resolution; configurable milestone grid/list, revision/reoperation history and linked case timeline.	Tracker Gate: Overdue and unresolved issues remain visible with a named owner.
F016 · Phase 2 Observed code/docs	Outcomes and surgical reporting Success/failure/recurrence/reoperation/lost/deceased/ongoing, follow-up completion, procedure/surgeon analysis, complication and drain metrics, monthly volume and 6/12/24/all trends.	Tracker; DIME Gate: Metric definitions and denominators are visible; missing follow-up is not counted as success.
F017 · Phase 2 Partial	Clinical photos Before/after, angle and milestone taxonomy, annotation, thumbnails and on-demand loading, quality-appropriate originals, metadata handling and patient/case linkage. Preserve existing local capture and photo milestones.	Tracker; Deck; ModMed Gate: Image identity, orientation and quality survive upload/download and offline synchronization.
F018 · Phase 2 Partial	Consent scopes Separate treatment, clinical photography, patient sharing, teaching, research and public marketing permissions; retain version, signer, time and withdrawal handling.	Tracker; Deck; Medicolize Gate: Marketing export is blocked without the relevant permission.
F019 · Phase 2 Partial	Windows application and offline use Web/PWA and signed Windows EXE share the backend. Tauri is a candidate for existing static-export Next.js. Encrypt selective local records; durable sync queue, conflict review, device revocation and signed updates.	User; Tracker; Tauri Gate: Offline edits, reconnect, conflicting edits and interrupted updates preserve records; packaging alone is not offline support.
F020 · Phase 2 Partial	Import, export and recovery JSON backup/restore, CSV/XLSX, legacy Google Sheets/Drive assets, images/PDF OCR preview, deduplication and mapping. Preserve consultation/surgery/comment/history exports and printable ID-only reports.	Tracker; Social; Video Gate: Restore database and files together; reconcile orphan files, row counts and relationships.
F021 · Phase 2 Partial	Reliable synchronization Replace clinically unsafe silent newest-write-wins where necessary with record versions, conflict resolution, retry/idempotency, deletion tombstones and attachment reconciliation.	Tracker; Social Gate: Two devices editing the same clinical note cannot silently overwrite each other.
F022 · Phase 3 New	Voice recording Record, pause, upload, playback and link audio to the correct patient/encounter; recording consent, access controls, retention and processing-provider records. Raw recording works without AI.	User; Video Gate: Failed transcription never loses the original authorized recording; retention removes all applicable copies.
F023 · Phase 3 New	Clinical transcription and draft notes Egyptian Arabic/English and mixed language; speaker handling, source-linked draft notes and summaries, clinician correction/sign-off and measured terminology/negation accuracy.	User; Video; local scouting Gate: Pilot evaluation includes drug names, doses and negation; no automatic signed chart or prescription.
F024 · Phase 3 New	Egyptian drug catalogue Brand/generic names and aliases in Arabic/English, ingredient, strength, form, route, manufacturer, registration, price with date, availability separately, source/version and licensed offline subset.	User; EDA; EDDB; Dwaprice Gate: Provenance and update date shown; absent or stale information is explicit; duplicate formulations reconciled.
F025 · Phase 3 New	Medical reference library Licensed guidelines, specialty protocols, ICD mapping, lab terminology and source-linked search. Separate public links from licensed full text; versioned documents and update/review queue.	User; EDA; WHO; LOINC; NICE; SNOMED Gate: Every answer links its source/version; content rights permit storage, display and any AI processing.
F026 · Phase 3 New	Prescriptions and clinical decision support Draft/final prescriptions, bilingual print/share, allergy and interaction checks, formulary/coverage checks, dosing aids and risk scores only through validated rules or licensed knowledge.	DIME; local scouting; User Gate: Clinician releases prescriptions; clinically validated checks fail visibly when unavailable.
F027 · Phase 3 New	AI assistant and previsit summaries Typed/voice queries over authorized records, timelines, schedule and finances; cited previsit summaries, uncertainty and audit. Consequential actions use explicit reviewed previews.	Video; DIME; Oracle Gate: Assistant cannot cross clinic boundaries or silently send, cancel, prescribe or amend.
F028 · Phase 4 Partial	Versioned surgical quotes Procedure packages, quote revisions, consent/acceptance linkage, deposits/installments, multi-procedure charges and case-level balance.	Social; Medicolize; ModMed Gate: Accepted quote version remains reproducible after later price changes.
F029 · Phase 4 Partial	Clinic finances Invoices/receipts/PDFs, income/expenses, refunds, salaries/payroll, doctor commissions, cash drawers, daily reconciliation and case profitability. Preserve original currency plus dated EGP conversions.	Social; Video; local scouting Gate: Ledger reconciles receipts/refunds; historical exchange rates do not change posted totals.
F030 · Phase 4 Partial	Team operations Tasks and recurring schedules, per-person ownership, natural-language proposed automations, reminders/digests, staff rosters and theatre/room/equipment reservations.	Tracker; Social; Video; DIME Gate: Automation previews targets and triggers; retries cannot duplicate an action.
F031 · Phase 4 Partial	Analytics and personalization Source and staff conversion comparisons, team profiles/rankings, operational dashboards, patient satisfaction/return metrics, Command/Inbox/Off views and configurable clinic lists.	Social; Tracker; Video Gate: Reports respect roles; conversion and clinical outcomes use distinct definitions.
F032 · Phase 4 New	Inventory and implants Consumables, batches/serials/expiry, case usage, stock movements, implant recall traceability and cost allocation.	Medicolize; ModMed; local scouting Gate: An implant lot can be traced to every affected case with audited stock adjustments.
F033 · Phase 4 New	WhatsApp and communication Clinic-owned history, approved hours/location/service/price FAQ, dialect/tone configuration, booking requests, notifications, follow-up reminders and staff escalation.	Video; Medicolize Gate: Use authorized messaging access and opt-in; clinical ambiguity routes to staff.
F034 · Phase 4 New	Patient portal Appointments, record/lab/imaging access, medication and adherence/refill requests, secure messaging, postoperative questionnaires/photos, task queue and satisfaction forms.	DIME; Epic; Video Gate: Patient submissions remain unverified until reviewed; critical responses have escalation owners.
F035 · Phase 4 New	Family and emergency access Guardian/proxy permissions, controlled sharing and revocation, emergency card with provenance for allergies, blood group, conditions and contacts.	DIME; local scouting Gate: Guardian access is scoped; unverified blood group is explicitly labelled.
F036 · Phase 5 Partial	Calendar and notification adapters Preserve one-way prefilled Google Calendar links; separately implement consented bidirectional sync, conflict handling and notification delivery receipts.	Tracker; Video Gate: Calendar cancellations reconcile without duplicate bookings; one-way links are not labelled full sync.
F037 · Phase 5 New	Social and booking adapters Meta/TikTok/Snapchat acquisition and Vezeeta/CliniDo partner connections only after API entitlement and field mapping; manual import fallback.	Social; local scouting Gate: A real sandbox event maps to the correct source/lead and deduplicates retries.
F038 · Phase 5 New	Lab integrations Orders, specimen status and results with patient match, units/reference ranges, abnormal/critical flags, corrections and acknowledgement; LOINC mapping where appropriate.	DIME; local scouting Gate: Duplicate/corrected results and unit mismatches are tested with one contracted provider.
F039 · Phase 5 New	Imaging integrations PACS/DICOM/DICOMweb and OHIF when required; separate diagnostic images from ordinary clinical photography, retain study identifiers and reports.	DIME; open scouting Gate: Authorized study access and patient matching tested; viewer alone is not an archive.
F040 · Phase 5 New	Hospital and device exchange FHIR R4, HL7 v2 ADT, encounter/observation/document mappings and supported vitals devices; source timestamps, reconciliation and integration monitoring.	DIME; global scouting Gate: A partner accepts the exchanged resources; standards support alone is not connectivity.
F041 · Phase 5 New	Payments, taxation and insurance Payment processor reconciliation; separately scoped Egyptian e-invoice/e-receipt integration, eligibility, preauthorization, claims, denial worklists, formulary and benefit rules.	DIME; local scouting Gate: Each provider contract and applicable requirements verified before activation; no inferred ETA or payer access.
F042 · Phase 5 New	Durable integration gateway Signed webhook intake, deduplication, fast acknowledgement after durable capture, job queue, retries, dead-letter visibility and scheduled reconciliation.	Webhooks; athenaOne Gate: Lost/out-of-order events are recovered; upstream no-retry delivery is covered by available backfill or an explicit gap.
F043 · Phase 6 New	Hospital operations Admissions/discharge/transfer, inpatient care, bed utilization, staffing, patient flow, monitoring and operational KPIs.	DIME Gate: Ward workflows and recovery plans validated before hospital-wide rollout.
F044 · Phase 6 New	Advanced specialties Cardiology/nephrology/pulmonology longitudinal analytics, cath-lab hemodynamics, angiography and interventions; specialty outcome measures and validated risk scores.	DIME Gate: Specialty clinician owns acceptance and data interpretation.
F045 · Phase 6 New	Research and population health Consent-governed deidentified exports, cohorts/registries/trial screening, aggregate outcomes and pharmacovigilance. Research controls separate from care access.	DIME Gate: Reidentification risk assessed; approvals and purpose restrictions enforced before export.
F046 · Phase 6 New	Clinical AI improvement Feedback collection, offline evaluation, version tracking, shadow testing and controlled releases; no automatic training or live clinical behavior change from patient feedback.	DIME Gate: Updated models pass an independent clinical evaluation and can be rolled back.
F047 · Phase 1 Partial	Storage, recovery and operating cost Portable PostgreSQL records plus private object storage for photos/audio/documents, encrypted backups, point-in-time recovery, measured restore tests, retention, observability and budget alerts.	User; architecture recommendation Gate: Recovery exercise restores both clinical records and attachments within agreed recovery targets.
F048 · Phase 5 New	Scale and reliability Indexes and bounded queries, background media/AI/import jobs, connection pooling, pagination, per-clinic limits, read replicas when measured, availability and disaster recovery.	User; architecture recommendation Gate: Load tests meet agreed concurrent-user, response-time and recovery targets with measured monthly cost.

8. Immediate implementation order and unresolved decisions

Freeze current-app parity and create fictional migration fixtures; decide shared identity and clinical record ownership.
Implement clinic access boundaries, audit, signed-note amendments and tested database-plus-media recovery.
Connect lead → patient → consultation → surgical episode while preserving tracker and Social Leads functions.
Complete clinical media, safe offline conflicts and Windows packaging; pilot with supervised workflows.
Add recorded audio, then reviewed transcription; obtain drug/reference licences in parallel.
Expand operations and patient engagement; integrate one actual external partner before adding an integration catalogue full of assumed connections.

Open decisions: deployment region and medical-data terms; clinic and user load; retention/recovery targets; Egyptian drug/reference licence and update access; first lab/imaging/messaging partner; independent clinical evaluator. These block the dependent production features, not prototype work or source scouting.

Not verified: live app operation, production security, clinical accuracy, vendor certifications/uptime, commercial API access, full export completeness, comprehensive market coverage or right to copy proprietary medical content. The collected “data” is a structured research inventory and feature register, not patient data or a harvested proprietary library.

Companion file: sina-emr-feature-register.json includes the complete source registry, repository snapshots, capability bundles and scouting records, including published pricing observations and uncertainty notes. All prices are snapshots, not purchasing recommendations or quotes.