DeveloperCare plansCare planArchitecture
Architecture Documentation
Core architectural concepts and data models for the clinical documentation system.
Documents
| Document | Description |
|---|---|
| LHR Concept | What LHR means, industry context, and Kulcare's approach |
| LHR Components Audit | What's implemented vs planned for comprehensive LHR |
| LHR Presentation Strategy | How to present LHR in the UI, role-based views |
| Clinical Data Hierarchy | Core relationships: LHR, Episode of Care, Encounter |
| Multi-Practitioner Encounter Types | EncounterDocument model for practitioner-specific documentation |
Standard Healthcare Terminology
Kulcare uses industry-standard terminology where possible:
| Kulcare Term | FHIR Standard | Description |
|---|---|---|
| LHR | N/A (computed view) | Patient's complete health story - application concept |
| Episode of Care | EpisodeOfCare | Treatment program container |
| Encounter | Encounter | Single visit/session |
| Problem | Condition | Patient condition/diagnosis |
| Prescription | MedicationRequest | Medication order |
| Care Plan | CarePlan | Treatment plan |
| Vital Signs | Observation | Clinical measurements |
See LHR Concept for complete terminology mapping.
Key Concepts
Clinical Data Hierarchy
The system is built around three levels:
- Longitudinal Health Record (LHR) - Computed aggregate view of patient's complete health story
- Episode of Care - Container for related encounters in a treatment program (PLANNED)
- Encounter - Single visit/session where documentation is created
Data Flow
Encounter (atomic)
|
+-- Creates: Vitals, Medications, Notes, Assessments
v
Episode of Care (if linked)
|
+-- Aggregates: Session count, Goal progress
v
Longitudinal Health Record (computed)
|
+-- Aggregates: All data across encounters
+-- Computes: Health score, trends, alertsRelated Documentation
- Current State - What's implemented today
- Future State - What's planned