SubEncounter & SubEncounterLink

Overview

The SubEncounter and SubEncounterLink resources enable fine-grained temporal and organizational subdivision of patient encounters within a hospital stay. While every patient interaction is tracked via a standard FHIR Encounter, SubEncounters provide additional granularity for specialized reporting, analytics, and resource filtering.

Purpose

SubEncounters allow you to:

• Segment hospital stays into distinct phases (e.g., pre-op, surgery, recovery, ward stay)
• Filter clinical resources by specific temporal contexts for targeted reporting
• Link FHIR resources (Observations, Procedures, etc.) to precise care phases
• Support specialized queries without modifying the core Encounter structure

Relationship to Encounter

SubEncounters are supplementary to standard FHIR Encounters:

• Every patient interaction must have a standard Encounter
• SubEncounters are optional and used only when temporal subdivision is needed
• One Encounter can have zero, one, or multiple SubEncounters
• SubEncounters cannot be nested (no sub-sub-encounters)

---

Use Case Example

Consider a patient admitted for elective surgery:

Scenario: A patient is admitted at 08:00 for knee surgery and discharged at 18:00.

1. Encounter: Covers the entire hospital stay (08:00 - 18:00)
2. SubEncounter 1: Pre-operative preparation (08:00 - 10:00)
   • Vital signs, consent forms, pre-op checklists
3. SubEncounter 2: Surgical procedure (10:00 - 13:00)
   • Anesthesia records, surgical notes, intra-op observations
4. SubEncounter 3: Recovery room (13:00 - 15:00)
   • Post-anesthesia monitoring, pain assessments
5. SubEncounter 4: Ward stay (15:00 - 18:00)
   • Post-op care, discharge planning

Reporting Benefit: Querying "all vital signs during surgery" becomes straightforward by filtering resources linked to SubEncounter 2, without manually specifying time ranges.

---

SubEncounter Resource

Structure Definition

The SubEncounter resource represents a temporal subdivision of a parent Encounter.

Core Elements

Element	Cardinality	Type	Description
encounter	1..1	Reference(Encounter)	The parent Encounter this SubEncounter belongs to
status	1..1	code	Lifecycle status: planned, in-progress, finished, entered-in-error
type	0..1	CodeableConcept	Classification of the SubEncounter (e.g., "surgery", "recovery")
period	0..1	Period	Time interval covered by this SubEncounter
comment	0..1	string	Optional free-text comment

Status Values

The status field follows a simple lifecycle model:

Status	Description	When to Use
planned	SubEncounter is scheduled but not started	Pre-operative phase scheduled for tomorrow
in-progress	SubEncounter is currently active	Patient is currently in surgery
finished	SubEncounter has been completed	Patient has left the recovery room
entered-in-error	SubEncounter was created by mistake	Duplicate entry or incorrect phase assignment

Example: SubEncounter for Surgical Phase

{
  "resourceType": "SubEncounter",
  "id": "subenc-surgery-12345",
  "encounter": {
    "reference": "Encounter/hosp-stay-12345"
  },
  "status": "finished",
  "type": {
    "coding": [
      {
        "system": "http://mona.icu/CodeSystem/subencounter-type",
        "code": "surgery",
        "display": "Surgical Procedure"
      }
    ]
  },
  "period": {
    "start": "2026-03-17T10:00:00+01:00",
    "end": "2026-03-17T13:00:00+01:00"
  },
  "comment": "Knee arthroscopy completed without complications"
}

---

SubEncounterLink Resource

Purpose

The SubEncounterLink resource creates explicit, versionable associations between a SubEncounter and clinical resources (Observations, Procedures, DiagnosticReports, MedicationAdministrations).

Why SubEncounterLink?

While FHIR resources typically reference their parent Encounter, they don't natively support SubEncounter references. SubEncounterLink provides:

• Explicit linking without modifying core FHIR resources
• Versioning of associations (links can be activated/deactivated)
• Provenance tracking via the source field
• Semantic relationships via relationshipType

Structure Definition

Core Elements

Element	Cardinality	Type	Description
subEncounter	1..1	Reference(SubEncounter)	The SubEncounter being linked
target	1..1	Reference	The linked resource (Observation, Procedure, DiagnosticReport, MedicationAdministration)
status	1..1	code	Link status: active, inactive, entered-in-error
relationshipType	0..1	CodeableConcept	Semantic meaning of the link
source	0..1	CodeableConcept	How the link was created
comment	0..1	string	Optional free-text comment

Relationship Types

The relationshipType field describes the semantic relationship between the SubEncounter and the target resource:

Code	Description	Example Use Case
belongs-to	Resource belongs to this SubEncounter	Blood pressure measurement taken during pre-op
performed-in	Activity performed during this SubEncounter	Surgical procedure executed in operating room phase
documented-in	Documentation created during this SubEncounter	Surgical report written during surgery
reviewed-in	Resource reviewed during this SubEncounter	Pre-op lab results reviewed before surgery
relevant-for	Resource is contextually relevant	Previous surgery notes relevant for current procedure
primary	Primary association with this SubEncounter	Main anesthesia record for surgery
secondary	Secondary association	Additional monitoring during surgery

Source Types

The source field tracks link provenance:

Code	Description
manual	Manually created by a clinician or administrator
rule	Created by automated business rules
import	Created during data import from external system
etl	Created during ETL (Extract-Transform-Load) process
derived	Derived from other data or calculations
ai	Created by AI/ML algorithms

Example: Linking Vital Signs to Surgery SubEncounter

{
  "resourceType": "SubEncounterLink",
  "id": "link-vitals-surgery",
  "subEncounter": {
    "reference": "SubEncounter/subenc-surgery-12345"
  },
  "target": {
    "reference": "Observation/vitals-hr-intraop-001"
  },
  "status": "active",
  "relationshipType": {
    "coding": [
      {
        "system": "http://mona.icu/CodeSystem/subencounter-relationship",
        "code": "performed-in",
        "display": "Performed In"
      }
    ]
  },
  "source": {
    "coding": [
      {
        "system": "http://mona.icu/CodeSystem/subencounter-link-source",
        "code": "rule",
        "display": "Automated Rule"
      }
    ]
  },
  "comment": "Intra-operative heart rate monitoring automatically linked to surgical phase"
}

---

Architecture Overview

The following diagram illustrates how SubEncounters and SubEncounterLinks integrate with standard FHIR resources:

Key Points:

• All clinical resources (Observations, Procedures) reference the main Encounter
• SubEncounters reference the parent Encounter
• SubEncounterLinks connect SubEncounters to clinical resources
• Links are independent resources, allowing version control and deactivation

---

Search Parameters

SubEncounter Search Parameters

Parameter	Type	Description	Example
encounter	reference	Find SubEncounters by parent Encounter	GET /SubEncounter?encounter=Encounter/123
status	token	Filter by lifecycle status	GET /SubEncounter?status=in-progress
type	token	Filter by SubEncounter type	GET /SubEncounter?type=surgery

SubEncounterLink Search Parameters

Parameter	Type	Description	Example
subencounter	reference	Find links by SubEncounter	GET /SubEncounterLink?subencounter=SubEncounter/456
target	reference	Find links by target resource	GET /SubEncounterLink?target=Observation/789
status	token	Filter by link status	GET /SubEncounterLink?status=active
relationship-type	token	Filter by relationship type	GET /SubEncounterLink?relationship-type=performed-in
source	token	Filter by link source	GET /SubEncounterLink?source=rule

---

Workflow Example

Creating a Surgical SubEncounter with Linked Resources

Steps:

1. Create Encounter for the hospital stay
2. Create SubEncounter for the surgical phase
3. Create clinical resources (Observations, Procedures) referencing the main Encounter
4. Create SubEncounterLinks to associate resources with the specific SubEncounter
5. Update SubEncounter status as the phase progresses

---

Best Practices

When to Use SubEncounters

✅ Use SubEncounters for:

• Multi-phase hospital stays requiring granular reporting
• Surgical cases with distinct pre-op, intra-op, post-op phases
• Complex encounters where time-based resource filtering is critical
• Scenarios requiring specialized analytics on care phase performance

❌ Don't use SubEncounters for:

• Simple outpatient visits with no distinct phases
• Cases where temporal filtering can be achieved via timestamp queries
• Encounters with minimal resource segmentation needs

Link Management

• Prefer automated linking (source: rule or source: etl) to reduce manual overhead
• Use relationshipType consistently to enable semantic queries
• Mark links as inactive rather than deleting them to preserve audit trails
• Document source logic for rule-based links to ensure reproducibility

Status Lifecycle

• Transition SubEncounters to finished promptly to ensure accurate reporting
• Use entered-in-error for corrections, but document reasons in comment
• Keep SubEncounterLinks active only for current, valid associations

---

Implementation Considerations

Performance

• SubEncounterLinks create additional relationships—index subEncounter and target fields for query performance
• For high-volume encounters (e.g., ICU stays), consider bulk linking strategies via ETL processes

Data Integrity

• Enforce referential integrity: SubEncounters must reference valid Encounters
• Validate status and relationshipType codes via invariants
• Audit link creation/modification to track provenance

Future Extensions

The SubEncounter model is designed for extensibility:

• Additional relationship types can be defined as use cases emerge
• Custom CodeSystems can further classify SubEncounter types
• Integration with clinical pathways and care plans is possible via future link types

---

Summary

SubEncounter and SubEncounterLink provide a flexible, standards-aligned approach to subdividing hospital encounters for specialized reporting and analytics. By supplementing—not replacing—standard FHIR Encounters, these custom resources enable fine-grained resource filtering while maintaining full compatibility with existing FHIR workflows.

For questions or use case discussions, consult your FHIR implementation team or reference the FHIR Specification for foundational concepts.