Bounded Context & System Boundaries

The Dental Clinic domain operates as an autonomous clinical bounded context within the Obelaw enterprise ecosystem. It establishes explicit linguistic and systemic boundaries around dental operatory care, patient odontograms, periodontal assessment matrices, treatment plan sequencing, chairside encounters, dental laboratory fabrication orders, and infection control instrument traceability.

Maintaining clean boundaries ensures that clinical accuracy, chairside safety guards, and tooth-level business invariants are shielded from central billing structures, bulk warehouse purchasing, diagnostic imaging storage mechanics, and enterprise human capital management.

---

1. Subdomain Classification & Strategic Investment

Applying the strategic classification methodology from Vlad Khononov’s Learning Domain-Driven Design, the capabilities associated with running a modern dental clinic are partitioned based on business differentiation and systemic complexity:

flowchart TD
    subgraph CoreDomain["Core Domain: High Complexity & Strategic Differentiation"]
        OdontogramEngine["Anatomical Odontogram & Charting Engine"]
        PerioMatrix["Periodontal Probing & Attachment Loss Matrix"]
        TreatmentPlanning["Phased Treatment Planning & Informed Consent"]
        EncounterExecution["Operatory Clinical Encounter & Safety Gates"]
        LabOrderLifecycle["Dental Laboratory Prosthetic Workflow"]
    end

    subgraph SupportingDomain["Supporting Domain: Custom Operational Capabilities"]
        ChairScheduling["Multi-Resource Operatory & Chair Scheduling"]
        SterileTracking["Sterilization Batch & Cassette Lifecycle Tracking"]
        DentalPreAuth["Tooth-Level Fee Schedule & Pre-Authorization Intake"]
    end

    subgraph GenericDomain["Generic Domain: Standardized / Off-the-Shelf Integration"]
        PatientMaster["Patient Demographics & Identity (CRM)"]
        LedgerBilling["General Ledger & Fiscal Invoicing (Accounting/FMS)"]
        ConsumablesPurchasing["Supply Chain & Bulk Consumables (Inventory)"]
        ImagingArchive["DICOM PACS Radiographic Image Storage"]
        ClinicianCredentials["Staff Credentialing & Payroll (HCM)"]
    end

    CoreDomain -.->|Coordinates with| SupportingDomain
    SupportingDomain -.->|Integrates via ACL / Events with| GenericDomain

Strategic Classifications Explained

• Core Domain: The Odontogram, periodontal charting engine, phased treatment planning, chairside clinical execution, and dental lab tracking represent the practice’s primary competitive advantage and clinical liability zone. These require custom, high-fidelity tactical DDD modeling.
• Supporting Domain: Operatory chair scheduling (with room turnover buffers), sterile cassette autoclave tracking, and dental pre-authorization intake complement the core clinical workflows. They are custom-built to support dental operations without defining the primary business differentiator.
• Generic Domain: Generic enterprise problems (billing ledgers, payroll, bulk procurement, DICOM file storage) are delegated to external or platform contexts. The Dental Clinic context integrates with them via formal Anti-Corruption Layers (ACL) and domain event contracts.

---

2. In-Scope Operational Capabilities

The Dental Clinic bounded context is strictly responsible for the following clinical and practice workflows:

• Patient Dental Charting (Odontogram): Permanent (32-tooth) and deciduous (20-tooth) anatomical mapping, tooth-surface modeling (Mesial, Distal, Occlusal/Incisal, Buccal/Facial, Lingual/Palatal), supernumerary tooth identification, and historical versus proposed tooth restorations.
• Periodontal Charting Matrix: 6-point pocket depth probing per tooth, bleeding on probing (BOP) registration, suppuration flags, plaque indices, gingival margin recession, clinical attachment loss (CAL), furcation involvement classifications, and tooth mobility grades.
• Phased Treatment Planning: Multi-stage clinical treatment plans (Urgent/Emergency, Disease Control, Restorative/Endodontic, Surgical/Prosthodontic, Maintenance), procedure line item definitions, tooth/surface assignment, procedure sequencing, and patient informed consent state management.
• Multi-Resource Operatory Scheduling: Booking synchronized dental chair (operatory) slots, attending dentists/specialists, dental hygienists/assistants, specialized equipment, and mandatory post-treatment room disinfection turnover buffers.
• Clinical Encounter (Chairside Session) Execution: Managing the operatory visit lifecycle (Check-in, Seating, Clinical Examination, Medical Alert Review, Local Anesthesia Administration, Procedure Execution, Material Lot Logging, Provider Signature, Dismissal).
• Dental Laboratory Prosthetic Orders: Specifications for indirect restorations (crowns, bridges, veneers, onlays, dentures, surgical guides, clear aligners), substrate and material recipes (Zirconia, Lithium Disilicate, PFM), shade selection (VITA Classical, 3D Master), digital scan file (STL/PLY) or physical impression tracking, try-in verification, and seating confirmation.
• Sterile Cassette & Infection Control Tracking: Autoclave sterilization cycle parameters, biological spore test verification, chemical indicator checks, sterile cassette barcode generation, and chairside cassette scanning.
• Dental Fee Estimation & Pre-Authorization Intake: CDT/ADA procedure code assignment, tooth-surface fee calculation, insurance pre-determination tracking, and patient copayment estimation.

---

3. Out-of-Scope Boundaries

To maintain domain cohesion and prevent monolithic coupling, the Dental Clinic context explicitly excludes generic enterprise responsibilities:

Out-of-Scope Concern	Correct Ownership	Architectural Rationale
Patient master identity, contact details, marketing, and CRM lead tracking	CRM / Patient Master	Dental Clinic references patient identity via a foreign identifier and local snapshot; CRM owns patient lifecycle and demographic updates.
Double-entry general ledger, fiscal invoicing, corporate tax filing, and bank reconciliation	Accounting / FMS	Dental Clinic emits completed clinical procedure facts and copay receipts; FMS owns revenue recognition, corporate tax, and financial ledger accounts.
Bulk procurement, vendor master agreements, and warehouse receiving	Purchasing & Inventory	Dental Clinic tracks chairside point-of-use consumption and material lot numbers; Inventory owns procurement contracts, supplier purchase orders, and central bin locations.
Raw DICOM file storage, PACS server operations, and radiologic image rendering	Medical Imaging PACS	Dental Clinic links lightweight image identifiers and tooth coordinates to clinical charts; the PACS context manages multi-gigabyte radiographic image storage.
Staff payroll, labor contracts, vacation accruals, and regulatory license verifications	Human Capital Management (HCM)	Dental Clinic references clinicians and assistants by license role for operatory scheduling; HCM owns employee contracts and credentialing renewal lifecycles.
Dental insurance claims adjudication and payer remittance clearinghouse	Insurance Clearinghouse / Payer Gateway	Dental Clinic generates structured diagnostic and tooth-coded procedure facts; the external payer gateway adjudicates claims and returns remittance advices.

---

4. Context Mapping & Integration Relationships

The Dental Clinic Bounded Context interacts with surrounding enterprise domains and external service providers through explicit DDD integration patterns:

flowchart LR
    CRM["CRM / Patient Master"] -->|Customer-Supplier<br/>Upstream to Downstream| DENTAL["Dental Clinic Context"]
    DENTAL -->|Customer-Supplier<br/>Upstream to Downstream| FMS["Accounting / FMS"]
    DENTAL -->|Customer-Supplier<br/>Upstream to Downstream| SCM["Inventory / SCM"]
    PACS["Imaging PACS"] -->|Anti-Corruption Layer<br/>Conformist Translation| DENTAL
    DENTAL <-->|Open-Host Service (OHS)<br/>Published Language (PL)| LAB["External Dental Lab"]
    DENTAL -->|Customer-Supplier<br/>Recall Dispatch| CRM

Integration Relationship Details

Integrating Context	Relationship Type	Interaction Pattern	Business Purpose
CRM / Patient Master	Upstream (CRM) to Downstream (Dental)	Customer-Supplier	Dental Clinic consumes verified patient identity, emergency contacts, and insurance carrier policies.
Accounting / FMS	Upstream (Dental) to Downstream (FMS)	Customer-Supplier	Dental Clinic publishes DentalProcedureCompleted and DentalCopayCollected events for ledger journalization and invoicing.
Inventory / SCM	Upstream (Dental) to Downstream (Inventory)	Customer-Supplier	Dental Clinic publishes DentalMaterialLotConsumed and DentalAnesthesiaAdministered events for stock decrement and reorder triggers.
Imaging PACS	Upstream (PACS) to Downstream (Dental)	Anti-Corruption Layer (ACL)	Translates heavy DICOM studies into tooth-anchored radiographic image metadata and viewer URLs.
External Dental Lab	Bidirectional	Open-Host Service (OHS) / Published Language (PL)	Standardized digital lab prescription contracts, shade protocols, scan file attachments, and status callback webhooks.
CRM / Recare Service	Upstream (Dental) to Downstream (CRM)	Customer-Supplier	Dental Clinic publishes DentalRecallScheduled events for automated patient hygiene and periodontal maintenance reminders.

---

5. Anti-Corruption Layer (ACL) Specifications

To safeguard the Dental Clinic domain model against foreign schemas and technical standards, explicit Anti-Corruption Layers translate external inputs:

1. Patient Master Identity ACL

The Dental Clinic context must never bind its clinical aggregates to volatile CRM schemas. The Patient Identity ACL maps external CRM patient records into a localized DentalPatientSnapshot:

• Extracts: ExternalPatientId, LegalName, DateOfBirth, BiologicalSex, PrimaryPhone, InsurancePolicyNumber.
• Enforces dental domain invariants: Computes baseline age to validate whether pediatric deciduous tooth charts or permanent adult tooth charts should be loaded by default.

2. Diagnostic Imaging & DICOM ACL

Radiographic modalities (Cone Beam CT, Panoramic Orthopantomograms, Bitewing X-rays, Periapical radiographs) originate from external DICOM PACS servers. The Imaging ACL insulates the dental chart:

• Maps external DICOM Series Instance UIDs (0020,000E) and SOP Instance UIDs into domain-friendly RadiographicStudy value objects.
• Associates DICOM image coordinates with specific tooth entities (e.g., binding a periapical radiograph specifically to Tooth 16 and Tooth 17).
• Strips heavy binary pixel data, retaining only signed streaming URLs, acquisition date, radiographic modality, and exposure radiation dose metrics.

3. Dental Laboratory Published Language (OHS / PL)

Interactions with commercial dental laboratories require a strictly versioned published language:

• Outbound Lab Slip Contract: Conveys PrescriptionId, PatientAnonymizedRef, TargetToothNumber, RestorationType, MaterialSubstrate, ShadeDesignation, ScanAttachmentManifest, and RequestedDeliveryTimestamp.
• Inbound Milestone Webhook: Ingests status updates (ImpressionReceived, DesignApproved, MillingInProgress, TryInDispatched, FinalRestorationDelivered) and maps them into internal DentalLabOrder aggregate state transitions.