[ENG-486] add extensions to encounter

[Jacobjeevan]

Proposed Changes

• add extension to encounter

ENG-486

Merge Checklist

• Tests added/fixed
• Update docs in /docs
• Linting Complete
• Any other necessary step

Only PR's with test cases included and passing lint and test pipelines will be reviewed

@ohcnetwork/care-backend-maintainers @ohcnetwork/care-backend-admins

Summary by CodeRabbit

• New Features
  • Added a new extensions field to encounter reports, enabling access to encounter extension data in JSON format.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR refactors field mapping lambdas in encounter context builders for conciseness and consistency, while adding a new public extensions field to expose encounter extensions with JSON-path-like access patterns.

Changes

Encounter Context Field Refinements

Layer / File(s)	Summary
Field mapping refactorings care/emr/reports/context_builder/data_points/encounter.py	EncounterCareTeamContextBuilder.role and BaseEncounterReportContext.end_time mappings are condensed to parenthesized lambdas; EncounterHospitalizationContextBuilder mappings for admit_source, discharge_disposition, and diet_preference now explicitly guard on input presence before translating through display dictionaries, returning empty strings when absent.
Extensions field exposure care/emr/reports/context_builder/data_points/encounter.py	EncounterReportContext gains a new extensions field exposing e.extensions (defaulting to {}) with JSON documentation for accessing extension values.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• ohcnetwork/care#3661: Adds extensions datapoint field exposure to encounter and patient context builders using the same pattern of mapping *.extensions with {} defaults.
• ohcnetwork/care#3662: Introduced the hospitalization display-mapped fields (admit_source, discharge_disposition, diet_preference) that this PR refactors.

Suggested reviewers

• vigneshhari

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description lacks essential details. It provides minimal context about what 'add extension to encounter' means and omits the 'Associated Issue' section linking to ENG-486.	Add a proper 'Associated Issue' section explaining how ENG-486 is addressed, expand the 'Proposed Changes' with specific technical details about the extension implementation, and ensure all checklist items are explicitly verified before merging.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and specifically describes the main change: adding extensions to the encounter resource, which aligns with the code addition of the extensions field in EncounterReportContext.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR adds an extensions field to BaseEncounterReportContext, exposing Encounter.extensions (a JSONField(default=dict)) as a named data point usable in report templates. Several multi-line ternary lambdas are also reformatted to parenthesised form for readability with no logic change.

• The new extensions field correctly maps lambda e: e.extensions or {}, which is safe given the model's default=dict (never None). The or {} is a harmless defensive guard.
• The preview value {"encounter_attender": {"attender_name": "Jane Doe"}} is a truthy dict and will be returned correctly in preview mode.
• No other data points or model definitions are changed.

Confidence Score: 5/5

The change is a small, additive data point on the report context builder with no modifications to models, migrations, or business logic — safe to merge.

The extensions field implementation is correct: the lambda, the or {} fallback, and the preview value all behave as expected. The Jinja2 environment's autoescape=True and SandboxedEnvironment mean extension values rendered in templates are escaped. The lambda reformatting is purely cosmetic. No missing guards, no schema changes, no risk of data loss or incorrect behavior.

No files require special attention.

Important Files Changed

Filename	Overview
care/emr/reports/context_builder/data_points/encounter.py	Adds a new extensions Field to BaseEncounterReportContext that exposes the encounter's JSONField extensions; also reformats several inline ternary lambdas for PEP 8 / Black compliance with no logic change.

_{Reviews (1): Last reviewed commit: "ft: add extensions to encounter" | Re-trigger Greptile}

[coderabbitai]

🧹 Nitpick comments (1)

care/emr/reports/context_builder/data_points/encounter.py (1)

319-328: ⚡ Quick win

Mark extensions with a non-string field type.

This field returns a dict, but Field still defaults its metadata to "string". For a new public JSON field, that mismatch is a pretty avoidable way to confuse schema/UI consumers and any nested-path tooling built on top of Field.type.

♻️ Proposed fix

     extensions = Field(
         display="Encounter Extensions",
         mapping=lambda e: e.extensions or {},
+        field_type="json",
         preview_value={
             "encounter_attender": {
                 "attender_name": "Jane Doe",
             },
         },

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@care/emr/reports/context_builder/data_points/encounter.py` around lines 319 -
328, The Field named extensions is declared with a mapping that returns a dict
but left with the default string type; change its Field type to a non-string
JSON type (e.g. type="json" or FieldType.JSON depending on your Field API) so
the metadata matches the actual dict return value; update the Field call for
extensions (the Field(...) instantiation in this module) to include the
appropriate non-string type and keep the existing mapping/preview/description
as-is.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@care/emr/reports/context_builder/data_points/encounter.py`:
- Around line 319-328: The Field named extensions is declared with a mapping
that returns a dict but left with the default string type; change its Field type
to a non-string JSON type (e.g. type="json" or FieldType.JSON depending on your
Field API) so the metadata matches the actual dict return value; update the
Field call for extensions (the Field(...) instantiation in this module) to
include the appropriate non-string type and keep the existing
mapping/preview/description as-is.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 94b63f3e-f075-495d-ae2f-2176c55e98a5

📥 Commits

Reviewing files that changed from the base of the PR and between ece71a8 and b441065.

📒 Files selected for processing (1)

• care/emr/reports/context_builder/data_points/encounter.py

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.85%. Comparing base (ece71a8) to head (b441065).
⚠️ Report is 1 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #3668      +/-   ##
===========================================
- Coverage    75.85%   75.85%   -0.01%     
===========================================
  Files          479      479              
  Lines        23043    23044       +1     
  Branches      2380     2380              
===========================================
  Hits         17480    17480              
  Misses        4990     4990              
- Partials       573      574       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.