Skip to main content

Functional Requirements - Ghasi Electronic Health Record (EHR)

Document Version: 1.1
Date: March 21, 2026
Project: Ghasi Electronic Health Record System

Status and relationship to legacy EMR file​

This document is the canonical system-level functional requirements baseline for the Ghasi EHR.

  • The earlier legacy EMR requirements file (EMR_FUNCTIONAL_REQUIREMENTS.md) is legacy and is intended to be removed later for clarity.
  • Any requirements that were still relevant to the Ghasi EHR have been migrated here.
  • Content that is not in scope for the current Ghasi EHR module library is explicitly labeled as such (to avoid accidental implementation).

Source of truth and alignment rules​

To prevent drift between system requirements and module specifications:

  • This document defines system-level and cross-cutting requirements (security/privacy, interoperability baselines, licensing enforcement, localization/RTL, and administrative governance).
  • Each module’s detailed requirements, data model, and APIs live in the module spec at specs/modules/<module>/SPEC.md.
  • If a module-level detail in this document conflicts with a module spec, treat the module spec as authoritative for module behavior, and treat this document as the platform baseline the module must comply with.
  • Cross-cutting enforcement points are traced in per-module and MVP2 TRACEABILITY_MATRIX.md files (see Appendix A).

Table of Contents​

  1. Introduction
  2. System Overview
  3. Core EHR Functional Requirements (Always-on baseline)
  4. Module Activation and Licensing Requirements
  5. Compliance Requirements
  6. Integration and Interoperability Requirements
  7. Non-Functional Requirements
  8. User Roles and Permissions
  9. Additional Functional Requirements
  10. System Administration and Configuration
  11. AI Platform and Assistive Capabilities
  12. Appendix A: Requirement Traceability Matrix
  13. Appendix B: Glossary
  14. Document Control

1. Introduction​

1.1 Purpose​

This document defines the detailed functional requirements for the Ghasi Electronic Health Record (EHR) system, aligned with WHO guidance and international standards for medical data exchange, safety, and privacy.

1.2 Scope​

The Ghasi EHR is a modular healthcare information system designed to manage longitudinal patient records across outpatient and inpatient settings, and to support secure, standards-based interoperability with existing Health Information Systems.

For an explicit definition of what is always-on vs optional in this repository, see:

1.3 Definitions and Acronyms​

  • EHR: Electronic Health Record
  • EMR: Electronic Medical Record (legacy term; not the canonical product name for this repository)
  • HMIS: Health Management Information System
  • WHO: World Health Organization
  • HL7: Health Level Seven International
  • FHIR: Fast Healthcare Interoperability Resources
  • ICD: International Classification of Diseases
  • SNOMED CT: Systematized Nomenclature of Medicine Clinical Terms
  • LOINC: Logical Observation Identifiers Names and Codes
  • DICOM: Digital Imaging and Communications in Medicine

2. System Overview​

2.1 System Vision​

A comprehensive, modular EHR system that enables healthcare providers to deliver quality care through efficient patient data management, safe clinical workflows, clinical decision support, and seamless integration with healthcare ecosystems.

2.2 Key Principles​

  • Core baseline: A deployable EHR must ship with an always-on Core EHR baseline (see CORE_EHR_DEFINITION.md).
  • Modularity: Optional modules can be licensed and enabled/disabled by tenant/facility scope.
  • Compliance: Support privacy, auditability, and safety requirements; local policy controls drive enforcement.
  • Interoperability: Standards-based integration (HL7 FHIR, HL7 v2 where applicable, IHE profiles, DICOM/DICOMweb).
  • Scalability: Support from small clinics to large hospital networks.
  • Security: Defense-in-depth, strong identity/access controls, and tamper-evident auditing.
  • Usability: Efficient clinical UI with RTL/mixed-direction support per regional profile.

2.3 Regional baseline (Phase 1)​

For Afghanistan + UAE and RTL/localization assumptions, see REGIONAL_PROFILE.md.

3. Core EHR Functional Requirements (Always-on baseline)​

The Core EHR baseline is an always-on bundle and maps to the module specs listed in CORE_EHR_DEFINITION.md.

3.1 Patient Management​

3.1.1 Patient Registration​

FR-PM-001: The system shall allow registration of new patients with the following mandatory fields (deployment-configurable):

  • Unique Patient Identifier (auto-generated)
  • Full Name (First, Middle, Last)
  • Date of Birth
  • Gender
  • Contact Information (Phone, Email, Address)
  • Emergency Contact Details
  • National ID/Passport Number (where applicable)

FR-PM-002: The system shall support patient search by:

  • Patient ID
  • Name (fuzzy matching)
  • Date of Birth
  • Phone Number
  • National ID

FR-PM-003: The system shall detect and prevent duplicate patient records using:

  • Phonetic name matching algorithms
  • Date of birth verification
  • National ID cross-referencing
  • Manual merge capability for duplicates (with audit trail)

FR-PM-004: The system shall maintain patient demographic history with:

  • Audit trail of all changes
  • Timestamps and user identification
  • Ability to view historical data

FR-PM-005: The system shall support multiple patient identifiers:

  • Facility MRN (Medical Record Number)
  • National Health ID (where available)
  • Insurance ID (if payer modules are licensed)
  • Previous facility identifiers

3.1.2 Patient Demographics​

FR-PM-006: The system shall capture extended demographic information (optional and configurable):

  • Ethnicity and Race
  • Language preferences
  • Religion
  • Marital status
  • Occupation
  • Education level
  • Socioeconomic indicators (as per deployment policy)

FR-PM-007: The system shall support patient photo upload as an optional configuration.

3.1.3 Patient Portal Access​

FR-PM-008: The system shall support patient portal access as an optional module and/or deployment feature, including:

  • View permitted portions of the record
  • Request appointments
  • View results released to patient
  • Communicate with care team
  • Update demographics (subject to verification policies)

Module specification: ../modules/patient-portal/SPEC.md

FR-PM-009: The system shall support multi-script patient identity capture and display, including entry of names in local scripts and optional Latin transliteration, and shall preserve the exact entered spelling.

FR-PM-010: The system shall support capturing patient preferred language (from a deployment-configured language set) and use it as the default for patient-facing communications (portal, SMS/email reminders) subject to consent and policy.

3.2 Clinical Documentation​

3.2.1 Longitudinal Health Record​

FR-CD-001: The system shall maintain a longitudinal health record for each patient including:

  • Medical history
  • Surgical history
  • Family history
  • Social history
  • Allergy and adverse reaction records
  • Current and past medications
  • Immunization records (if the Immunizations module is licensed)
  • Problem list (active and resolved)

FR-CD-002: The system shall support structured and unstructured clinical notes:

  • SOAP format
  • Progress notes
  • Consultation notes
  • Discharge summaries (when inpatient workflows are in scope)
  • Procedure notes
  • Custom templates by specialty

FR-CD-003: The system shall provide clinical note templates with:

  • Customizable fields by specialty
  • Auto-population from prior encounters (configurable)
  • Macro/shortcut support for common phrases

3.2.2 Vital Signs and Measurements​

FR-CD-004: The system shall record vital signs:

  • Blood Pressure (Systolic/Diastolic)
  • Heart Rate
  • Respiratory Rate
  • Temperature (Celsius/Fahrenheit)
  • Oxygen Saturation (SpO2)
  • Height and Weight (with automatic BMI calculation)
  • Head Circumference (pediatric)
  • Pain Scale (0-10)

FR-CD-005: The system shall display vital signs trends with:

  • Graphical representations
  • Abnormal value alerts (configurable thresholds)
  • Comparison with previous visits
  • Pediatric growth charts (WHO standards) (when enabled)

3.2.3 Problem List Management​

FR-CD-006: The system shall maintain a problem list with:

  • ICD-10/ICD-11 coding
  • SNOMED CT mapping (where licensed/available)
  • Problem status (active, resolved, inactive)
  • Onset date and resolution date
  • Severity indicators
  • Problem notes and comments

FR-CD-007: The system shall link problems to:

  • Medications prescribed
  • Orders and procedures
  • Clinical encounters
  • Outcomes and goals (if Care Plans module is licensed)

3.2.4 Medication Management​

FR-CD-008: The system shall support medication ordering with:

  • Drug database with generic and brand names (source is deployment-configurable)
  • Dosage, route, frequency specification
  • Start date, end date, and duration
  • PRN (as needed) orders with conditions
  • Refill authorization
  • Pharmacy routing hooks (when enabled)

FR-CD-009: The system shall provide medication safety checking:

  • Drug-drug interactions
  • Drug-allergy checking
  • Drug-condition contraindications
  • Duplicate therapy alerts
  • Dosage range verification
  • Pregnancy/lactation warnings (where available)

FR-CD-010: The system shall maintain medication history:

  • Current medications
  • Past medications with discontinuation reasons
  • Medication adherence tracking (optional)
  • Adverse drug reactions

FR-CD-011: The system shall support e-prescribing where required by deployment policy.

NOT IN SCOPE (Phase 1 AFG/UAE baseline unless explicitly required): US-specific eRx standards such as NCPDP SCRIPT.

3.2.5 Allergy and Adverse Reaction Management​

FR-CD-012: The system shall record allergies with:

  • Allergen type (medication, food, environmental)
  • Reaction severity (mild, moderate, severe, life-threatening)
  • Reaction manifestations
  • Onset date
  • Verification status (patient-reported, clinician-verified)

FR-CD-013: The system shall display allergy alerts prominently:

  • Warnings during medication ordering
  • Visual indicators on patient header
  • Alert override with mandatory documentation

3.3 Clinical Orders and Results​

3.3.1 Laboratory Orders​

FR-OR-001: The system shall support laboratory test ordering:

  • Standard test catalog with LOINC codes (where available)
  • Individual and panel orders
  • Urgency levels (routine, urgent, stat)
  • Clinical indications and diagnosis codes
  • Collection instructions
  • Specimen type and requirements

FR-OR-002: The system shall interface with Laboratory systems via adapters (where applicable):

  • Electronic order transmission (HL7 ORM or equivalent)
  • Result reception (HL7 ORU or equivalent)
  • Specimen tracking
  • Order status updates

FR-OR-003: The system shall display laboratory results:

  • Tabular and graphical formats
  • Normal value ranges with highlight of abnormal results
  • Trend analysis over time
  • Critical value alerts
  • Result comments and interpretations
  • Previous result comparisons

3.3.2 Radiology Orders​

FR-OR-004: The system shall support imaging orders and result review via adapters (where applicable).

FR-OR-005: The system shall support PACS integration patterns (DICOM/DICOMweb) where deployed.

Module specification: ../modules/radiology-pacs/SPEC.md

3.3.3 Other Clinical Orders​

FR-OR-006: The system shall support additional order types (configurable):

  • Nursing orders
  • Diet orders
  • Therapy orders
  • Consultation orders
  • Procedure orders

FR-OR-007: The system shall provide order sets and protocols:

  • Evidence-based order bundles
  • Specialty-specific protocols
  • Admission/discharge order sets (when inpatient workflows are in scope)
  • Customizable by institution

3.4 Scheduling and Appointments​

3.4.1 Appointment Management​

FR-SC-001: The system shall provide appointment scheduling with:

  • Provider/resource availability calendars
  • Multiple appointment types
  • Duration configuration by appointment type
  • Overbooking controls
  • Recurring appointment patterns

FR-SC-002: The system shall support appointment search and booking by:

  • Provider
  • Department/specialty
  • Location
  • Date range
  • Appointment type

FR-SC-003: The system shall manage appointment waitlists (optional enhancement):

  • Priority-based queuing
  • Automated patient notification for cancellations

FR-SC-004: The system shall provide automated appointment reminders via configured channels:

  • SMS
  • Email
  • Patient portal notifications

3.4.2 Check-in and Registration​

FR-SC-005: The system shall support patient check-in:

  • Front desk check-in interface
  • Insurance verification (if Insurance/Claims modules are licensed)
  • Co-payment collection recording (if Billing module is licensed)
  • Demographic update prompts

FR-SC-006: The system shall maintain appointment status tracking:

  • Scheduled
  • Checked-in
  • In Progress
  • Completed
  • No-show
  • Canceled (with reason)

3.5 Billing and Financial Management (Optional add-on)​

NOT ALWAYS-ON: In this repository’s default packaging, billing/claims/insurance are optional licensed add-ons (see CORE_EHR_DEFINITION.md).

3.5.1 Charge Capture​

FR-BL-001: The system shall support charge capture with:

  • ICD-10/ICD-11 diagnosis codes
  • Procedure codes (deployment-configurable)
  • Charge master integration (where applicable)
  • Quantity and modifiers
  • Provider and location specification

NOT IN SCOPE (Phase 1 AFG/UAE baseline unless explicitly required): US-specific procedure code sets such as CPT/HCPCS.

FR-BL-002: The system shall link charges to:

  • Patient encounters
  • Orders and procedures
  • Diagnosis codes (automatic validation)
  • Insurance coverage (if payer modules are licensed)

3.5.2 Claims Management​

FR-BL-003: The system shall generate and manage claims using deployment-configured payer/authority formats and adapters.

NOT IN SCOPE (Phase 1 AFG/UAE baseline unless explicitly required): US-centric claim formats and transactions such as EDI 837 and CMS-1500/UB-04.

FR-BL-004: The system shall manage claim denials:

  • Denial tracking and categorization
  • Appeal workflow
  • Denial analytics and reporting

3.5.3 Patient Billing​

FR-BL-005: The system shall generate patient statements:

  • Itemized billing statements
  • Multiple statement formats
  • Aging reports (configurable buckets)
  • Payment plan management
  • Financial assistance tracking

FR-BL-006: The system shall process payments (where billing is deployed):

  • Multiple payment methods (deployment-configurable)
  • Payment posting to patient accounts
  • Refund processing
  • Receipt generation
  • Payment reconciliation

3.5.4 Insurance Management​

FR-BL-007: The system shall maintain insurance information (if Insurance module is licensed):

  • Multiple insurance plans per patient
  • Eligibility verification via adapters
  • Pre-authorization tracking
  • Coverage determination
  • Coordination of benefits (where applicable)

3.6 Reporting and Analytics (Optional capability)​

NOT IN SCOPE (current module library): There is no dedicated Reporting/BI module specification under ../modules/ yet. Treat this section as future/backlog unless a customer scope requires it.

3.6.1 Clinical Reports​

FR-RP-001: The system shall provide standard clinical reports where deployed:

  • Patient visit summaries
  • Medication lists
  • Problem lists
  • Immunization records (if module is licensed)
  • Continuity of Care Document (CCD) where applicable

3.6.2 Administrative Reports​

FR-RP-002: The system shall provide administrative reports where deployed:

  • Appointment statistics
  • Provider productivity
  • Patient demographics

3.6.3 Quality Measures​

FR-RP-003: The system shall support quality measure reporting where deployed:

  • WHO health indicators
  • Deployment-configured quality dashboards

3.6.4 Public Health Reporting​

FR-RP-004: The system shall support public health reporting via standards/adapters where required:

  • Immunization registries
  • Notifiable disease reporting

3.6.5 Custom Reporting​

FR-RP-005: The system shall provide report builder tools where deployed:

  • Export to PDF/Excel/CSV
  • Scheduled report generation
  • Access control on report definitions and outputs

3.7 Clinical Decision Support (CDS) (Optional capability)​

NOT IN SCOPE (current module library): There is no dedicated CDS module specification under ../modules/ yet. Treat this section as future/backlog unless a customer scope requires it.

3.7.1 Alerts and Reminders​

FR-CDS-001: The system shall provide clinical alerts where configured:

  • Drug interaction alerts
  • Allergy alerts
  • Duplicate therapy alerts
  • Abnormal lab value alerts

FR-CDS-002: The system shall provide preventive care reminders where configured.

3.7.2 Clinical Guidelines​

FR-CDS-003: The system shall support guideline content integration where configured (e.g., WHO-aligned protocols).

FR-CDS-004: The system shall provide order set recommendations where configured.

3.7.3 Risk Calculators​

FR-CDS-005: The system shall include clinical calculators where deployed.

3.8 Document Management​

Module specification: ../modules/document-management/SPEC.md — template-backed PDF generation, DocumentReference / Binary persistence, scanning/upload, and audit. System-level FR-DM-* below remain the cross-cutting baseline; module FR-DMS-* refine implementation.

3.8.1 Document Scanning and Indexing​

FR-DM-001: The system shall support document upload and scanning where deployed:

  • Integration with scanning devices
  • OCR (optional)
  • Document indexing and association with patient records

FR-DM-002: The system shall manage document types and metadata.

3.8.2 Document Retrieval and Viewing​

FR-DM-003: The system shall provide document viewing and secure sharing/printing with audit logging.

3.9 Pharmacy (Future module)​

NOT IN SCOPE (current module library): No Pharmacy module spec exists under ../modules/. Preserve as future requirements only.

FR-PH-001: The system shall manage pharmacy inventory where deployed.

FR-PH-002: The system shall support dispensing workflow where deployed.

FR-PH-003: The system shall support pharmacy integrations via adapters where deployed.

3.10 Laboratory Information System (LIS) (Optional add-on module)​

Module specification: ../modules/laboratory-lis/SPEC.md

FR-LIS-001: The system shall manage laboratory operations where deployed.

FR-LIS-002: The system shall support a laboratory test catalog where deployed.

3.11 Inpatient (Future module)​

NOT IN SCOPE (current module library): No Inpatient module spec exists under ../modules/. Preserve as future requirements only.

FR-IP-001: The system shall manage admission, discharge, and transfer workflows where deployed.

FR-IP-002: The system shall provide bed management where deployed.

FR-IP-003: The system shall support nursing workflows where deployed.

FR-IP-004: The system shall provide nursing flowsheets where deployed.

FR-IP-005: The system shall manage surgical services workflows where deployed.

3.12 Emergency Department (Future module)​

NOT IN SCOPE (current module library): No Emergency Department module spec exists under ../modules/. Preserve as future requirements only.

FR-ED-001: The system shall support ED-specific workflows where deployed.

FR-ED-002: The system shall provide ED tracking where deployed.

4. Module Activation and Licensing Requirements​

FR-MOD-001: The system shall support modular architecture with:

  • On-demand module activation
  • License key validation
  • Module dependency management
  • Feature toggle capabilities
  • Per-module user permissions

FR-MOD-002: The system shall provide license management:

  • License assignment by organization/location
  • User license tracking
  • License expiration notifications
  • Concurrent user license enforcement
  • Trial license support

FR-MOD-003: The system shall enforce module activation state at runtime such that:

  • Disabled modules are hidden from navigation and workflows.
  • Corresponding APIs reject requests with a clear “module not licensed/activated” error.

FR-MOD-004: The system shall support module activation scopes at minimum per tenant/organization, and optionally per facility/location, with explicit dependency validation.

FR-MOD-005: The system shall provide an administrative audit log for licensing and module state changes including: who changed what, when, from/to state, and the effective scope.

FR-MOD-006: The system shall support safe module deactivation rules:

  • Prevent deactivation when it would break required regulatory retention or critical patient safety workflows (configurable policy).
  • When deactivation is allowed, preserve existing data and restrict access according to policy (e.g., read-only historical access vs hidden).

FR-MOD-007: The system shall expose a “license and feature capabilities” endpoint for client applications to dynamically render UI based on current entitlements.

5. Compliance Requirements​

5.1 WHO Alignment​

FR-COMP-001: The system shall support WHO-aligned standards and reporting where required by deployment policy:

  • ICD-11 diagnosis classification
  • ATC drug classification (optional)
  • Immunization schedules (if Immunizations module is licensed)
  • WHO surgical safety checklist (if OR workflows are in scope)
  • WHO health metrics and indicators

5.2 Data Privacy and Security Standards​

FR-COMP-003: The system shall support privacy/security safeguards aligned with HIPAA principles where applicable.

FR-COMP-004: The system shall support GDPR-aligned controls where applicable.

FR-COMP-005: The system shall support data localization configuration:

  • Country-specific data residency rules
  • Cross-border transfer controls

FR-COMP-011: The system shall support consent and disclosure controls for patient data sharing, including capturing consent state, effective dates, scope (data categories / recipients), and revocation, and enforce it in access control and exports when configured.

FR-COMP-012: The system shall support “minimum necessary” access and segmentation of sensitive data when required by local policy, including audit trails for access.

FR-COMP-013: The system shall support patient record access reporting (accounting of disclosures) where required, including the ability to export an access log for a patient over a date range.

5.3 Interoperability Standards​

FR-COMP-006: The system shall support:

  • HL7 v2.x messaging (ADT, ORM, ORU, SIU) via adapters where applicable
  • HL7 FHIR R4 or later
  • CDA/CCD/C-CDA where required by partners

FR-COMP-007: The system shall support applicable IHE profiles where required by partners (e.g., PIX/PDQ/XDS/ATNA).

FR-COMP-008: The system shall support DICOM standards (and DICOMweb) where imaging integration is deployed.

FR-COMP-009: The system shall support standard terminologies where licensed/available:

  • SNOMED CT
  • LOINC
  • RxNorm (region-dependent)
  • ICD-10/ICD-11

NOT IN SCOPE (default Phase 1): US-only billing code sets such as CPT/HCPCS unless explicitly required by a customer.

5.4 Certification and Regulatory Requirements​

FR-COMP-010: The system shall support electronic signatures and auditability aligned with applicable local regulations.

6. Integration and Interoperability Requirements​

6.1 System Integration Capabilities​

FR-INT-001: The system shall provide integration mechanisms:

  • RESTful APIs (FHIR-based where feasible)
  • HL7 v2 messaging via integration engine/adapters
  • File-based integration (CSV, XML, JSON) via adapters

FR-INT-002: The system shall document APIs:

  • OpenAPI specifications for non-FHIR endpoints
  • FHIR capability statement

6.2 Third-Party System Integration​

FR-INT-003: The system shall support integration (where applicable) with:

  • HIE/HIO
  • National patient registries
  • National or regional HMIS platforms
  • Public health agencies
  • Laboratory and imaging partners
  • Medical device vendors (vital signs monitors, etc.)

FR-INT-004: The system shall support SSO where deployed:

  • SAML 2.0
  • OAuth 2.0 / OpenID Connect
  • LDAP/Active Directory integration

6.3 Data Import and Export​

FR-INT-005: The system shall support data migration and portability:

  • Import from legacy systems via mapped extracts
  • Standardized export formats
  • Bulk export (FHIR Bulk Data Access) where applicable

FR-INT-006: The system shall provide a standards-based FHIR server interface (FHIR R4 or later) for in-scope data exchange.

FR-INT-007: The system shall support event-driven interoperability using FHIR Subscriptions (or equivalent) to notify external systems when key resources change.

FR-INT-008: The system shall support SMART on FHIR style authorization patterns (OAuth 2.0/OIDC) for third-party app integration.

FR-INT-009: The system shall support DICOMweb integration (where PACS is used) for imaging access.

FR-INT-010: The system shall support terminology services for code validation/lookups using a configured terminology backend.

FR-INT-011: The system shall support import/export of clinical documents using CDA/CCD/C-CDA and/or IHE XDS patterns when required by partners.

FR-INT-012: The system shall support configurable adapter-based integrations (HL7 v2, files, APIs) to connect to country- and payer-specific exchanges without hard-coding a single national format.

7. Non-Functional Requirements​

7.1 Performance​

FR-NFR-001: The system shall meet performance targets (deployment-specific):

  • Page load time < 2 seconds (95th percentile) (target)
  • Search results < 1 second (target)
  • API response time < 500ms (95th percentile) (target)

FR-NFR-002: The system shall support horizontal scaling and multi-tenancy.

7.2 Security​

FR-NFR-003: The system shall implement security measures:

  • RBAC
  • Optional ABAC for sensitive data
  • MFA
  • Session timeout

FR-NFR-004: The system shall encrypt data:

  • Data at rest
  • Data in transit

FR-NFR-005: The system shall provide audit logging:

  • Authentication events
  • Data access logs
  • Data modification logs
  • Export/print activities
  • Break-glass access logging (where enabled)

FR-NFR-006: The system shall support disaster recovery (RTO/RPO targets are deployment-specific).

7.3 Usability and Localization​

FR-NFR-007: The system shall provide user-friendly interfaces:

  • Responsive design
  • Accessibility compliance (WCAG 2.1 AA)

FR-NFR-008: The system shall support multiple languages and RTL per REGIONAL_PROFILE.md, including bidirectional/mixed-direction content and RTL-safe print/PDF output.

7.4 API edge, offline/sync, design system, and AI governance​

FR-NFR-009: The system shall expose browser and external partner HTTP traffic only through a managed API gateway (Kong or equivalent) in production deployments, with TLS termination and policy plugins (authentication, rate limiting, request limits, correlation IDs) as defined in deployment baseline — application upstreams shall not be directly reachable from the public internet for those consumers.

FR-NFR-010: The system shall support offline-first or intermittently connected clinical and operational workflows where a module explicitly declares them, including client-side queuing, idempotent replay (e.g. client mutation identifiers), server authority for global invariants, and documented conflict handling per OFFLINE_FIRST_AND_CLIENT_SYNC.md.

FR-NFR-011: Automated tests for externally visible APIs shall include contract verification through the same gateway path clients use (in addition to direct upstream tests where helpful), and modules with offline support shall include sync/offline test scenarios per TESTING_STANDARDS.md.

FR-NFR-012: The system shall support hierarchy-scoped white-labeling (themes, logos, typography, design tokens, and token presets where product policy defines them) for platform, tenant, and org levels without breaking RTL or accessibility baselines.

FR-NFR-013: The system shall support multiple enterprise IAM providers (e.g. Keycloak, Okta, Auth0) via standards-based protocols (OIDC/OAuth2, SAML where required) consistent with the IAM module specifications.

FR-NFR-014: Optional AI-assisted capabilities (e.g. documentation support, speech-to-text, imaging helpers) shall be license-gated, auditable, and subject to privacy and safety review; they shall not bypass consent, ABAC, or minimum-necessary rules. Detailed platform rules: AI_PLATFORM.md and §11 below.

FR-NFR-015: The system shall degrade gracefully when the AI orchestration layer or external model providers are unavailable (clear UI state, no silent corruption of drafts, optional queue-for-retry per module policy).

FR-NFR-016: The system shall enforce per-tenant (and optionally per-org-node) quotas and rate limits on AI API usage to control cost and abuse.

FR-NFR-017: Assistive AI interactions should meet latency targets appropriate to clinical workflow (deployment-specific SLOs); slow paths should stream or show progress rather than block indefinitely.

FR-NFR-018: Default logging for AI operations shall exclude raw PHI in unstructured application logs; where retention of prompts/responses is required, it shall use protected storage and retention rules configured per tenant and jurisdiction.

8. User Roles and Permissions​

FR-USER-001: The system shall support role definitions consistent with clinical and administrative workflows (see module specs for detailed role interactions).

FR-USER-002: The system shall provide granular permissions:

  • Module-level access
  • Feature-level access
  • Data-level access (patient, department, location)
  • Break-the-glass emergency access (where enabled)

9. Additional Functional Requirements​

9.1 Workflow and Task Management​

FR-WF-001: The system shall provide workflow automation and task assignment.

FR-WF-002: The system shall support a provider/task inbox with prioritization and due dates.

9.2 Communication and Collaboration​

FR-COM-001: The system shall provide secure messaging:

  • Provider-to-provider messaging
  • Provider-to-patient messaging (where patient portal is enabled)

Module specification: ../modules/messaging/SPEC.md

FR-COM-002: The system shall support care team coordination features where required by workflow.

9.3 Patient Engagement​

FR-PE-001: The system shall support patient education content and after-visit summaries where deployed.

FR-PE-002: The system shall enable remote monitoring integrations where deployed.

9.4 Research and Quality Improvement​

FR-RES-001: The system shall support de-identified data export subject to policy/consent.

FR-RES-002: The system shall support quality reporting and benchmarking.

9.5 Mobile Capabilities​

FR-MOB-001: The system shall support mobile access patterns where deployed (provider and/or patient).

9.6 Localization and Regionalization​

FR-L10N-001: The system shall support a deployment-configurable list of supported languages and deterministic fallback rules (user preference → facility default → tenant default).

FR-L10N-002: The system shall support both LTR and RTL UI layouts and correctly render bidirectional text in clinical and administrative workflows.

FR-L10N-003: The system shall support locale-aware date entry and display formats, including configurable calendar options where required by deployment policy.

FR-L10N-004: The system shall support facility-specific time zones and correct time display across scheduling, clinical events, and audit logs.

FR-L10N-005: The system shall support multi-currency configuration and formatting per tenant, and integrate tax/VAT configuration where billing is used.

FR-L10N-006: The system shall support correct RTL rendering in generated documents (PDF/print/export), including text shaping, line breaks, font embedding, and mixed-direction content.

10. System Administration and Configuration​

FR-ADM-001: The system shall provide configuration tools:

  • Organization hierarchy
  • Location/department management
  • Provider/resource management

FR-ADM-002: The system shall support controlled customization:

  • Template management
  • Custom fields (where allowed)
  • Workflow configuration (where enabled)

FR-ADM-003: The system shall provide monitoring visibility for integrations and errors.

FR-ADM-004: The system shall provide data quality tools including duplicate detection and merges with audit trail.

11. AI Platform and Assistive Capabilities​

Architecture: AI_PLATFORM.md
Stance: Assistive-first — human accountability for the clinical record; autonomous diagnosis/treatment automation is not in scope unless a future validated clinical decision support (CDS) program is explicitly specified and licensed.

FR-AI-001: The system shall support hierarchy-scoped enablement of AI features (platform defaults, tenant overrides, optional org-node overrides) integrated with the Licensing service so unlicensed features return consistent denial responses.

FR-AI-002: Before building model context that includes PHI, the system shall enforce access policy (RBAC/ABAC), consent where applicable, and minimum necessary retrieval; cross-tenant data MUST NOT be retrievable into a model context.

FR-AI-003: Browser and mobile clients shall not hold vendor model API keys; all model access SHALL flow through server-side orchestration behind Kong (or equivalent gateway) per ARCHITECTURE_BASELINE.md.

FR-AI-004: AI-generated content that becomes part of the authoritative clinical or legal record SHALL require explicit user acceptance (and signing where module policy requires signatures) before persistence as final; drafts SHALL be distinguishable from finalized entries.

FR-AI-005: The system shall persist provenance metadata for accepted AI-assisted artifacts where policy requires, including at minimum timestamp, actor, feature identifier, and model/provider version (exact fields defined in module technical requirements).

FR-AI-006: The system shall emit audit records for AI operations (e.g. invocation, acceptance, rejection, provider failure) suitable for compliance review; default audit payloads SHALL avoid raw prompt text containing PHI unless a tenant explicitly enables a secured retention mode.

FR-AI-007: Patient-facing AI capabilities (e.g. portal education) SHALL use a separate trust boundary and stricter consent and content policy than clinician-facing assistive features.

FR-AI-008: In offline or degraded connectivity, AI features that require cloud inference SHALL follow documented degrade or queue behavior per module spec; local/on-device inference SHALL only be used when tenant policy and security review allow.

FR-AI-009: Default: tenant PHI SHALL NOT be used to train third-party foundation models unless explicit contractual agreement, legal review, and tenant configuration opt-in are recorded.

FR-AI-010: Features that constitute regulated clinical decision support (e.g. diagnostic or therapeutic recommendations intended to drive care) SHALL be explicitly scoped, validated, and licensed separately; they SHALL NOT be implied by generic documentation-assist features.

Appendix A: Requirement Traceability Matrix​

System-to-module traceability is maintained per bounded context:

  • Each module: specs/modules/<module>/TRACEABILITY_MATRIX.md
  • Interoperability aggregate: specs/architecture/interop/TRACEABILITY_MATRIX.md

Appendix B: Glossary​

Definitions of medical and technical terms used throughout the document.

Document Control​

VersionDateSummary
1.12026-03-21Added §11 FR-AI-001..010, FR-NFR-015..018, AI platform baseline reference.