Merge release 3.6.1 to main

[vanitha1822]

📋 Description

JIRA ID:

Please provide a summary of the change and the motivation behind it. Include relevant context and details.

---

✅ Type of Change

• 🐞 Bug fix (non-breaking change which resolves an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 🔥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 🛠 Refactor (change that is neither a fix nor a new feature)
• ⚙️ Config change (configuration file or build script updates)
• 📚 Documentation (updates to docs or readme)
• 🧪 Tests (adding new or updating existing tests)
• 🎨 UI/UX (changes that affect the user interface)
• 🚀 Performance (improves performance)
• 🧹 Chore (miscellaneous changes that don't modify src or test files)

---

ℹ️ Additional Information

Please describe how the changes were tested, and include any relevant screenshots, logs, or other information that provides additional context.

Summary by CodeRabbit

Release Notes

• New Features

  • Added care context linking with ABDM token generation and verification.
  • Integrated Elasticsearch for beneficiary data indexing and search capabilities.
  • Added support for immunization record creation and wellness record bundles.
  • Added discharge summary documentation support.
  • Enhanced CORS handling with configurable origin policies.

• Chores

  • Updated FHIR and Jackson dependencies to latest versions.
  • Improved database pool and Elasticsearch connection configuration.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR introduces ABDM V3 care context linking APIs, integrates Elasticsearch for beneficiary data synchronization, refactors bundle generation from legacy resource_gateway to new bundle_creation services, upgrades dependencies (Jackson, HAPI FHIR, Elasticsearch), adds multiple resource data models, and expands configuration with Elasticsearch and ABDM endpoint properties.

Changes

Cohort / File(s)	Summary
Configuration & Dependencies .factorypath, pom.xml, src/main/resources/application.properties, src/main/environment/common_*.properties	Updated Lombok JAR reference, bumped module version 3.1.0→3.6.1, added Elasticsearch/ECS logging dependencies, upgraded Jackson (2.14.2→2.15.2) and HAPI FHIR (6.10.0→8.4.0), switched to HikariCP datasource configuration, added Elasticsearch connection/tuning and ABDM V3 endpoint properties.
ABDM V3 Care Context Integration src/main/java/com/wipro/fhir/controller/v3/careContext/CareContextLinkingController.java, src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingService.java, src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java, src/main/java/com/wipro/fhir/data/v3/careContext/*	Added REST controller for care context endpoints, service interface/implementation for token generation and care context linking with ABDM integration, data models (AddCareContextRequest, CareContextLinkTokenRequest, GenerateCareContextTokenRequest, LinkCareContextRequest, PatientCareContext, CareContexts).
Elasticsearch Configuration & ABHA Sync src/main/java/com/wipro/fhir/config/ElasticsearchConfig.java, src/main/java/com/wipro/fhir/service/elasticsearch/AbhaElasticsearchSyncService.java	Added Elasticsearch client configuration with connection pooling, timeouts, and auth; introduced async ABHA data sync service with retry logic and document existence checks.
Bundle Creation Services (Interfaces & Implementations) src/main/java/com/wipro/fhir/service/bundle_creation/OPConsultResourceBundle*.java, src/main/java/com/wipro/fhir/service/bundle_creation/PrescriptionResourceBundle*.java, src/main/java/com/wipro/fhir/service/bundle_creation/DiagnosticRecordResourceBundle*.java, src/main/java/com/wipro/fhir/service/bundle_creation/ImmunizationRecordResourceBundle*.java, src/main/java/com/wipro/fhir/service/bundle_creation/WellnessRecordResourceBundle*.java, src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundle*.java, src/main/java/com/wipro/fhir/service/bundle_creation/BundleValidator.java	Added new bundle creation interfaces and implementations for OP consultation, prescription, diagnostic reports, immunization, wellness, and discharge summary records; includes bundle composition building, FHIR document structure, and MongoDB persistence.
Data Models for Resources src/main/java/com/wipro/fhir/data/resource_model/ImmunizationDataModel.java, src/main/java/com/wipro/fhir/data/resource_model/MedicalHistoryDataModel.java, src/main/java/com/wipro/fhir/data/resource_model/OrganizationDataModel.java, src/main/java/com/wipro/fhir/data/resource_model/PractitionerDataModel.java	Added data model classes for mapping database results to immunization, medical history, organization, and practitioner entities with constructors for object-array conversion and list conversion utilities.
FHIR Resource Services src/main/java/com/wipro/fhir/service/resource_model/ImmunizationResource.java, src/main/java/com/wipro/fhir/service/resource_model/MedicalHistoryResource.java, src/main/java/com/wipro/fhir/service/resource_model/OrganizationResource.java, src/main/java/com/wipro/fhir/service/resource_model/PractitionerResource.java	Added services to dynamically generate FHIR resources (Immunization, MedicationStatement, Organization, Practitioner) from database-fetched data models, replacing hardcoded/dummy resource generation.
Repository Methods src/main/java/com/wipro/fhir/repo/common/PatientEligibleForResourceCreationRepo.java, src/main/java/com/wipro/fhir/repo/v3/careContext/CareContextRepo.java, src/main/java/com/wipro/fhir/repo/mongo/generateToken_response/GenerateTokenAbdmResponsesRepo.java	Added stored-procedure calls for medical history, immunization, organization, and practitioner data; added care context presence checks (vitals, prescriptions, lab tests, vaccines); added MongoDB repository for ABDM token responses.
Service Refactoring src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java, src/main/java/com/wipro/fhir/service/ndhm/Common_NDHMService.java, src/main/java/com/wipro/fhir/service/ndhm/Common_NDHMServiceImpl.java, src/main/java/com/wipro/fhir/service/healthID/HealthIDServiceImpl.java	Migrated bundle dependencies from resource_gateway to bundle_creation, added conditioned bundle processing based on visit category and care context availability, added Elasticsearch sync side effects on health ID mapping, added getLinkToken method for ABDM token retrieval.
Legacy Bundle Removals src/main/java/com/wipro/fhir/service/resource_gateway/OPConsultRecordBundle*.java, src/main/java/com/wipro/fhir/service/resource_gateway/PrescriptionRecordBundle*.java, src/main/java/com/wipro/fhir/service/resource_gateway/DiagnosticReportRecord*.java	Deleted legacy bundle interfaces and implementations; consolidated into new bundle_creation services.
Controller & Endpoint Updates src/main/java/com/wipro/fhir/controller/generateresource/ResourceRequestGateway.java, src/main/java/com/wipro/fhir/controller/test/Test.java, src/main/java/com/wipro/fhir/controller/v3/abha/CreateAbhaV3Controller.java, src/main/java/com/wipro/fhir/controller/health/HealthController.java	Updated controllers to use new bundle_creation services instead of resource_gateway, added @CrossOrigin annotation to ABHA endpoint, added GPL header to HealthController, updated method names and injected service types.
CORS & Security Utilities src/main/java/com/wipro/fhir/config/CorsConfig.java, src/main/java/com/wipro/fhir/utils/JwtUserIdValidationFilter.java, src/main/java/com/wipro/fhir/utils/http/HTTPRequestInterceptor.java	Expanded CORS allowed methods (added PATCH), added multiple serverAuthorization header variants, enhanced JWT filter with explicit OPTIONS handling and origin validation, added origin-aware CORS headers in error handling, implemented configurable allowed-origins matching.
Miscellaneous src/main/java/com/wipro/fhir/FhirApiApplication.java, src/main/java/com/wipro/fhir/data/mongo/care_context/GenerateTokenAbdmResponses.java, src/main/java/com/wipro/fhir/service/resource_model/EncounterResource.java, src/main/java/com/wipro/fhir/service/resource_model/MedicationRequestResource.java, src/main/java/com/wipro/fhir/service/resource_model/ObservationResource.java, src/main/java/com/wipro/fhir/service/v3/abha/CreateAbhaV3ServiceImpl.java, src/main/java/com/wipro/fhir/service/resource_model/DiagnosticReportResource.java, src/main/java/com/wipro/fhir/service/resource_model/PatientResource.java, src/main/java/com/wipro/fhir/service/ndhm/LinkCareContext_NDHMServiceImpl.java	Added @EnableAsync annotation to FhirApiApplication, added MongoDB model for ABDM token responses, removed Appointment parameter from Encounter/Observation resource generation, updated MedicationRequest ID format and added null guards, removed unused BigInteger imports, minor whitespace/formatting adjustments.

Sequence Diagrams

sequenceDiagram
    actor User
    participant Controller as CareContextLinkingController
    participant Service as CareContextLinkingServiceImpl
    participant Repo as GenerateTokenAbdmResponsesRepo
    participant ABDM as ABDM API
    participant Mongo as MongoDB

    User->>Controller: POST /careContext/generateCareContextToken
    Controller->>Service: generateTokenForCareContext(request)
    Service->>Service: Parse CareContextLinkTokenRequest
    Service->>Mongo: Check existing token by ABHA address
    alt Token exists & recent
        Service-->>Controller: Return cached token
    else Token missing
        Service->>ABDM: POST generate-token (with auth headers)
        ABDM-->>Service: Token response
        Service->>Repo: Save/persist token response
        Service->>Mongo: Store token in MongoDB
        Service-->>Controller: Return new token
    end
    Controller-->>User: HTTP 200 + token response JSON

Loading

sequenceDiagram
    participant Service as HealthIDServiceImpl
    participant EsSync as AbhaElasticsearchSyncService
    participant Repo as BenHealthIDMappingRepo
    participant ES as Elasticsearch

    Service->>Service: mapHealthIDToBeneficiary(...)
    Service->>Repo: Save health ID mapping
    Repo-->>Service: Success
    Service->>EsSync: updateAbhaInElasticsearch(benRegId, healthId, ...)
    activate EsSync
    EsSync->>ES: GetRequest to check document
    alt Document exists
        ES-->>EsSync: Document found
        EsSync->>ES: Update document with ABHA fields
        ES-->>EsSync: Update confirmed
    else Document not found
        EsSync->>EsSync: Retry with delay (up to max retries)
        EsSync->>ES: Retry GetRequest
    end
    deactivate EsSync
    EsSync-->>Service: Update complete (async)
    Service-->>Service: Continue processing

Loading

sequenceDiagram
    participant Client as ResourceRequestGateway
    participant Common as CommonServiceImpl
    participant Bundle as OPConsultResourceBundleImpl
    participant Repo as CareContextRepo
    participant Mongo as MongoDB

    Client->>Common: processPatientResourceCreation(...)
    Common->>Repo: hasPhyVitals(visitCode)
    Repo-->>Common: Count result
    alt VisitCategory in [General OPD, General OPD QC]
        Common->>Bundle: processOpConsultRecordBundle(...)
        Bundle->>Bundle: populateOPConsultRecordResourceBundle(...)
        activate Bundle
        Bundle->>Bundle: Fetch Practitioner, Organization, Patient
        Bundle->>Bundle: Build Composition with sections
        Bundle->>Bundle: Assemble FHIR Document Bundle
        Bundle->>Bundle: Serialize to JSON
        deactivate Bundle
        Bundle->>Mongo: Save via commonService.saveResourceToMongo(...)
        Mongo-->>Bundle: Persist successful
        Bundle-->>Common: Return result
    else Visit category not matched
        Common->>Common: Skip OP Consult bundle
    end
    Common-->>Client: Resource processing complete

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• Abdm v3 #128 — Identical ABDM V3 care context linking implementation and bundle service refactoring with matching code-level changes across careContext, bundle_creation, and data models.
• M2 FHIR bundles creation #123 — Parallel refactoring of legacy resource_gateway bundle implementations to new bundle_creation service architecture with shared data model additions and repository methods.

Suggested reviewers

• 5Amogh
• drtechie

---

🐰 Elasticsearch hops into the scene,
Care contexts linked in ABDM's dream,
Bundles refactored, resources pristine,
Data flowing in async stream! ✨

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix-merge-release-3.6.1

📝 Coding Plan

• Generate coding plan for human review comments

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 Security Hotspot
9.0% Duplication on New Code (required ≤ 3%)
C Reliability Rating on New Code (required ≥ A)
E Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[coderabbitai]

Actionable comments posted: 3

Note

Due to the large number of review comments, Critical severity comments were prioritized as inline comments.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

src/main/java/com/wipro/fhir/controller/v3/abha/CreateAbhaV3Controller.java (1)

29-29: ⚠️ Potential issue | 🟠 Major

Potential PII/PHI exposure: logging raw request payloads containing health identifiers.

The request body for ABHA enrollment likely contains sensitive data (Aadhaar numbers, mobile numbers, health IDs). Logging the full request at INFO level could violate compliance requirements (GDPR, local health data regulations) and expose PII in log aggregation systems.

Consider logging only non-sensitive metadata (e.g., request size, masked identifiers) or moving detailed logging to DEBUG level.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/wipro/fhir/controller/v3/abha/CreateAbhaV3Controller.java`
at line 29, The current logger.info call in CreateAbhaV3Controller that
concatenates the raw request ("logger.info(\"Generate OTP for ABHA enrollment
API request \" + request)") can expose PII/PHI; change this to avoid logging the
full payload by either: 1) switching to logger.debug and only logging
non-sensitive metadata (e.g., request size, correlationId), or 2) constructing a
sanitized summary that masks sensitive fields (Aadhaar, mobile, healthId) before
logging (use a maskLike function or explicit field masking), and ensure any
detailed payload logging is gated behind DEBUG. Locate the logger call in
CreateAbhaV3Controller and update it to log masked/metadata-only info (or
debug-level raw payload) instead of the raw request.

pom.xml (1)

86-89: ⚠️ Potential issue | 🟡 Minor

Duplicate logback-ecs-encoder dependency.

logback-ecs-encoder 1.3.2 is declared at lines 56-60 and again at lines 86-89.

🔧 Remove duplicate

-		<dependency>
-			<groupId>co.elastic.logging</groupId>
-			<artifactId>logback-ecs-encoder</artifactId>
-			<version>1.3.2</version>
-		</dependency>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@pom.xml` around lines 86 - 89, The POM contains a duplicate dependency
declaration for co.elastic.logging:logback-ecs-encoder version 1.3.2; remove the
redundant dependency block so the artifactId "logback-ecs-encoder" / groupId
"co.elastic.logging" with version "1.3.2" appears only once in the pom.xml,
ensuring any remaining dependency retains the correct version and scope.

🟠 Major comments (28)

src/main/java/com/wipro/fhir/service/ndhm/LinkCareContext_NDHMServiceImpl.java-122-122 (1)

122-122: ⚠️ Potential issue | 🟠 Major

Avoid logging full OTP API response payload at INFO level.

Line 122 logs responseEntity directly, which can leak sensitive response content into application logs. Log status code/request ID only, and keep payload-level logging off or masked.

Proposed safe logging change

- logger.info("NDHM_FHIR Carecontext generateOTP API response - " + responseEntity);
+ logger.info("NDHM_FHIR Carecontext generateOTP API response status={}, requestId={}",
+         responseEntity.getStatusCodeValue(), obj.getRequestId());

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/ndhm/LinkCareContext_NDHMServiceImpl.java`
at line 122, The current logger.info call in LinkCareContext_NDHMServiceImpl is
logging the full OTP API responseEntity which may contain sensitive data; change
the logging in the method where responseEntity is used (look for the
logger.info("NDHM_FHIR Carecontext generateOTP API response - " +
responseEntity) call) to only log non-sensitive metadata such as
responseEntity.getStatusCode(), a request ID or correlationId if available, and
avoid printing the response body (or mask it) at INFO level; ensure any detailed
payload logging is removed or moved to a secure debug-level log with explicit
masking.

.factorypath-2-2 (1)

2-2: ⚠️ Potential issue | 🟠 Major

Update .factorypath Lombok version to match the build dependency.

Line 2 specifies Lombok 1.18.30, but pom.xml declares 1.18.36 as the project dependency. This version mismatch causes the IDE annotation processor to behave differently from the Maven build, leading to inconsistent code generation and potential missed errors during development.

Update .factorypath to use 1.18.36:

Suggested change

-    <factorypathentry kind="VARJAR" id="M2_REPO/org/projectlombok/lombok/1.18.30/lombok-1.18.30.jar" enabled="true" runInBatchMode="false"/>
+    <factorypathentry kind="VARJAR" id="M2_REPO/org/projectlombok/lombok/1.18.36/lombok-1.18.36.jar" enabled="true" runInBatchMode="false"/>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.factorypath at line 2, The .factorypath entry references Lombok version
1.18.30 which mismatches pom.xml's Lombok 1.18.36; update the factorypathentry
with id containing "org/projectlombok/lombok/1.18.30/lombok-1.18.30.jar" to use
1.18.36 so the IDE annotation processor matches the Maven build (i.e., change
the version segment in that factorypathentry id from 1.18.30 to 1.18.36 and
ensure enabled/runInBatchMode attributes remain unchanged).

src/main/java/com/wipro/fhir/service/bundle_creation/BundleValidator.java-28-46 (1)

28-46: ⚠️ Potential issue | 🟠 Major

Current validator bootstrap is non-operational due to placeholder inputs.

Line 28 loads a blank classpath package and Line 44 validates an empty bundle string; this makes the tool fail by default. Accept package path + bundle JSON (or file path) via args and fail fast with clear usage.

Suggested fail-fast pattern

- npmPackageValidationSupport.loadPackageFromClasspath(" "); // download the package from ABDM and add in resources
+ if (args.length < 2) {
+     throw new IllegalArgumentException("Usage: BundleValidator <npm-package-classpath> <bundle-json>");
+ }
+ npmPackageValidationSupport.loadPackageFromClasspath(args[0]);
@@
- String bundleJson = ""; // add bundle json here
+ String bundleJson = args[1];

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/wipro/fhir/service/bundle_creation/BundleValidator.java`
around lines 28 - 46, The current bootstrap uses placeholder inputs causing
non-operational validation: replace the hardcoded
npmPackageValidationSupport.loadPackageFromClasspath(" ") and empty bundleJson
with real inputs accepted from method arguments or program args, validate them
early, and fail fast with a clear usage message; specifically, update the code
that constructs the ValidationSupportChain (npmPackageValidationSupport,
DefaultProfileValidationSupport, etc.) to call
npmPackageValidationSupport.loadPackageFromClasspath(packagePath) where
packagePath comes from args, and pass a non-empty bundle JSON or file contents
into validator.validateWithResult(bundleJson) (or read from a provided file
path), throwing an informative error and exiting if packagePath or
bundleJson/file is missing or invalid.

src/main/java/com/wipro/fhir/data/v3/careContext/GenerateCareContextTokenRequest.java-12-12 (1)

12-12: ⚠️ Potential issue | 🟠 Major

Make yearOfBirth nullable and validate it explicitly.

Line 12 uses primitive int, so omitted JSON maps to 0 silently. Prefer Integer plus validation constraints to reject missing/invalid input early.

Suggested DTO hardening

 import lombok.Data;
+import jakarta.validation.constraints.Max;
+import jakarta.validation.constraints.Min;
+import jakarta.validation.constraints.NotNull;
 
 `@Data`
 public class GenerateCareContextTokenRequest {
@@
-    private int yearOfBirth;
+    `@NotNull`
+    `@Min`(1900)
+    `@Max`(2100)
+    private Integer yearOfBirth;
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/data/v3/careContext/GenerateCareContextTokenRequest.java`
at line 12, Change the primitive field yearOfBirth in
GenerateCareContextTokenRequest from int to Integer and add explicit validation
annotations (e.g., `@NotNull` and appropriate range checks like `@Min/`@Max) so
omitted or invalid JSON does not default to 0; update the corresponding
getter/setter/constructor usage and any places that instantiate or validate
GenerateCareContextTokenRequest to handle nulls and enforce the new constraints
(use the class name GenerateCareContextTokenRequest and the field yearOfBirth to
locate changes).

src/main/java/com/wipro/fhir/controller/v3/abha/CreateAbhaV3Controller.java-63-64 (1)

63-64: ⚠️ Potential issue | 🟠 Major

Inconsistent CORS configuration: @CrossOrigin without parameters allows all origins.

The global CorsConfig restricts allowed origins via the cors.allowed-origins property, but this endpoint-level @CrossOrigin annotation without parameters defaults to allowing all origins (*). This creates an inconsistency and potentially undermines the security restrictions set globally.

Consider either:

1. Removing @CrossOrigin to rely on the global configuration, or
2. Explicitly specifying the same allowed origins pattern.

Proposed fix to align with global CORS config

-	`@CrossOrigin`
+	`@CrossOrigin`(origins = "${cors.allowed-origins}")
 	`@Operation`(summary = "Verify Auth By ABDM for ABHA enrollment")
 	`@PostMapping`(value = { "/verifyAuthByAbdm" })

Alternatively, if the global config is sufficient:

-	`@CrossOrigin`
 	`@Operation`(summary = "Verify Auth By ABDM for ABHA enrollment")

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/wipro/fhir/controller/v3/abha/CreateAbhaV3Controller.java`
around lines 63 - 64, The endpoint-level `@CrossOrigin` on class
CreateAbhaV3Controller overrides global CORS and currently allows all origins;
either remove the `@CrossOrigin` annotation so the controller uses the global
CorsConfig (cors.allowed-origins) or replace `@CrossOrigin` with an explicit
allowedOrigins value that matches the configured cors.allowed-origins pattern
(or the same property value) to ensure consistent origin restrictions across the
app.

src/main/environment/common_example.properties-128-128 (1)

128-128: ⚠️ Potential issue | 🟠 Major

Replace the sample Elasticsearch password with a placeholder.

Even in an example file, committing a concrete password invites reuse across environments and leaks a secret into source control. If this value was ever real, rotate it.

Suggested fix

-elasticsearch.password=piramalES
+elasticsearch.password=<Enter Elasticsearch password>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/environment/common_example.properties` at line 128, Replace the
hardcoded password value for the property elasticsearch.password with a
non-secret placeholder (e.g., ${ELASTICSEARCH_PASSWORD} or <REPLACE_ME>) so no
real credential is stored in the example file; update any README or env docs to
instruct users to set the actual password via environment/configuration and
ensure any real password previously committed is rotated if it was in use.

src/main/java/com/wipro/fhir/service/healthID/HealthIDServiceImpl.java-228-231 (1)

228-231: ⚠️ Potential issue | 🟠 Major

Guard optional name parts before concatenating.

This path dereferences middleName and lastName unconditionally, but the same class already treats those fields as optional earlier in mapHealthIDToBeneficiary. Profiles missing either field will throw here and skip the insert.

Suggested fix

- healthID.setName(
- 		abhaProfileJson.get("firstName").getAsString() + " "
- 				+ abhaProfileJson.get("middleName").getAsString() + " "
- 				+ abhaProfileJson.get("lastName").getAsString());
+ String fullName = Stream.of("firstName", "middleName", "lastName")
+ 		.map(field -> abhaProfileJson.has(field) ? abhaProfileJson.get(field).getAsString() : "")
+ 		.filter(s -> !s.isEmpty())
+ 		.collect(Collectors.joining(" "));
+ healthID.setName(fullName);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/wipro/fhir/service/healthID/HealthIDServiceImpl.java`
around lines 228 - 231, The code in HealthIDServiceImpl where
healthID.setName(...) concatenates firstName, middleName, and lastName
unconditionally can NPE or throw when middleName/lastName are missing; update
the healthID name construction (in the same method that currently calls
healthID.setName and related to mapHealthIDToBeneficiary) to conditionally
include only present, non-null JSON fields (check
abhaProfileJson.has("middleName")/has("lastName") and that values are not
JsonNull/empty) — build a list of name parts (e.g., firstName plus optional
middleName and lastName) and join with single spaces before calling
healthID.setName so absent parts are skipped and no exception is thrown.

src/main/java/com/wipro/fhir/service/healthID/HealthIDServiceImpl.java-106-113 (1)

106-113: ⚠️ Potential issue | 🟠 Major

Pass the ABHA address, not the ABHA number, into the first ES sync.

Lines 111-112 pass healthIdNumber into both ABHA fields, even though the first slot is the ABHA address. When the health-id row already exists, the later sync path does not correct this, so Elasticsearch keeps the ABHA number in the address field.

Suggested fix

+ String abhaAddress = IntStream.range(0, abhaProfileJson.getAsJsonArray("phrAddress").size())
+ 		.mapToObj(i -> abhaProfileJson.getAsJsonArray("phrAddress").get(i).getAsString())
+ 		.collect(Collectors.joining(", "));
  String createdDate = LocalDateTime.now(ZoneId.of("Asia/Kolkata"))
  		.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.S"));
  abhaEsSyncService.updateAbhaInElasticsearch(
  		health.getBeneficiaryRegID(),
- 		healthIdNumber, // healthID (ABHA address)
+ 		abhaAddress, // healthID (ABHA address)
  		healthIdNumber, // abhaID (ABHA number)
  		createdDate);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/wipro/fhir/service/healthID/HealthIDServiceImpl.java`
around lines 106 - 113, The call to abhaEsSyncService.updateAbhaInElasticsearch
is passing healthIdNumber into both the ABHA address and ABHA number parameters;
change the first argument to the actual ABHA address variable (e.g., abhaAddress
or health.getAbhaAddress()) while keeping health.getBeneficiaryRegID() and
healthIdNumber for the other params so the signature
updateAbhaInElasticsearch(beneficiaryRegId, abhaAddress, abhaNumber,
createdDate) receives the correct address value.

src/main/java/com/wipro/fhir/service/healthID/HealthIDServiceImpl.java-211-218 (1)

211-218: ⚠️ Potential issue | 🟠 Major

Move the duplicate check after setHealthIdNumber() is called, or add a @SerializedName("ABHANumber") annotation to the healthIdNumber field in HealthIDResponse.

Line 215 queries getCountOfHealthIdNumber(healthID.getHealthIdNumber()) before line 217 assigns the ABHA number. Since HealthIDResponse.healthIdNumber has no @SerializedName mapping and InputMapper uses default Gson configuration (no custom FieldNamingPolicy), the JSON field ABHANumber will not deserialize into the Java field healthIdNumber—it remains null. The duplicate check runs with null and will not detect existing records, allowing duplicates to be inserted.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/wipro/fhir/service/healthID/HealthIDServiceImpl.java`
around lines 211 - 218, The duplicate-check uses healthID.getHealthIdNumber()
before ABHANumber is assigned from the JSON, so move the duplicate-check (the
call to healthIDRepo.getCountOfHealthIdNumber(...)) to after
healthID.setHealthIdNumber(abhaProfileJson.get("ABHANumber").getAsString()) in
HealthIDServiceImpl, or alternatively annotate the
HealthIDResponse.healthIdNumber field with `@SerializedName`("ABHANumber") so
InputMapper.gson() populates it on deserialization; update references to
getCountOfHealthIdNumber(...) accordingly so the repository receives the actual
ABHA number.

src/main/java/com/wipro/fhir/config/ElasticsearchConfig.java-50-91 (1)

50-91: ⚠️ Potential issue | 🟠 Major

RestClient resource leak and hardcoded HTTP scheme.

1. Resource leak: The RestClient created at line 83 is not managed by Spring and won't be closed on application shutdown. Consider returning the RestClient as a bean or implementing DisposableBean to close it.

2. Hardcoded scheme: Line 59 hardcodes "http". For production environments requiring TLS, this should be configurable.

🔧 Proposed fix for resource management

+    `@Value`("${elasticsearch.scheme:http}")
+    private String esScheme;
+
     `@Bean`
-    public ElasticsearchClient elasticsearchClient() {
+    public RestClient restClient() {
         BasicCredentialsProvider credentialsProvider = new BasicCredentialsProvider();
         credentialsProvider.setCredentials(
             AuthScope.ANY,
             new UsernamePasswordCredentials(esUsername, esPassword)
         );

         RestClientBuilder builder = RestClient.builder(
-            new HttpHost(esHost, esPort, "http")
+            new HttpHost(esHost, esPort, esScheme)
         );

         // Apply timeout configurations
         builder.setRequestConfigCallback(requestConfigBuilder -> 
             requestConfigBuilder
                 .setConnectTimeout(connectionTimeout)
                 .setSocketTimeout(socketTimeout)
                 .setConnectionRequestTimeout(connectionTimeout)
         );

         // Apply connection pool settings
         builder.setHttpClientConfigCallback(httpClientBuilder -> 
             httpClientBuilder
                 .setDefaultCredentialsProvider(credentialsProvider)
                 .setMaxConnTotal(maxConnections)
                 .setMaxConnPerRoute(maxConnectionsPerRoute)
                 .setDefaultIOReactorConfig(
                     IOReactorConfig.custom()
                         .setSoTimeout(socketTimeout)
                         .build()
                 )
         );

-        RestClient restClient = builder.build();
+        return builder.build();
+    }

+    `@Bean`
+    public ElasticsearchClient elasticsearchClient(RestClient restClient) {
         ElasticsearchTransport transport = new RestClientTransport(
             restClient,
             new JacksonJsonpMapper()
         );

         return new ElasticsearchClient(transport);
     }

By making RestClient a Spring bean, it will be automatically closed when the application context shuts down.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/wipro/fhir/config/ElasticsearchConfig.java` around lines 50
- 91, The elasticsearchClient() method currently creates a RestClient that is
not managed/closed by Spring and hardcodes the "http" scheme; change the
configuration so the RestClient is a Spring-managed bean (e.g., add a `@Bean`
RestClient restClient() that builds the HttpHost using a configurable esScheme
property instead of the hardcoded "http"), then inject that RestClient into
elasticsearchClient() to build the RestClientTransport and ElasticsearchClient
so Spring will close the RestClient on shutdown; alternatively implement
DisposableBean/@PreDestroy in this config class to close the RestClient instance
created in elasticsearchClient(); update references to HttpHost construction
(esHost, esPort, esScheme) and keep RestClientTransport and ElasticsearchClient
creation in elasticsearchClient().

src/main/java/com/wipro/fhir/service/resource_model/MedicalHistoryResource.java-57-64 (1)

57-64: ⚠️ Potential issue | 🟠 Major

Invalid SNOMED code placeholder.

Setting the SNOMED code to a single space " " is semantically invalid. FHIR validators may reject this, and downstream systems expecting valid SNOMED codes will fail. If no SNOMED code is available, omit the Coding entry entirely and rely on the text.

🐛 Proposed fix - only set text when no code available

 			CodeableConcept medCC = new CodeableConcept();
-			medCC.addCoding(new Coding()
-					.setSystem("http://snomed.info/sct")
-					.setCode(" ")
-					.setDisplay(med.getCurrentMedication())); // scts code so kept only the name
-
+			// Only add SNOMED coding if a valid code is available
+			// Currently no SNOMED code mapping exists, so using text only
 			medCC.setText(med.getCurrentMedication());
 			ms.setMedication(medCC);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/resource_model/MedicalHistoryResource.java`
around lines 57 - 64, The current code creates a Coding with a blank SNOMED code
(" ") which is invalid; update the construction in MedicalHistoryResource so
that you only add a Coding to medCC when a valid SNOMED code is present (e.g.,
check med.getSnomedCode() or if med.getCurrentMedication() supplies a code,
ensure it is non-null and not blank after trim), otherwise do not call
medCC.addCoding(...) and only set medCC.setText(med.getCurrentMedication())
before calling ms.setMedication(medCC); reference CodeableConcept medCC, Coding,
med.getCurrentMedication() and ms.setMedication when making the change.

src/main/java/com/wipro/fhir/controller/v3/careContext/CareContextLinkingController.java-29-29 (1)

29-29: ⚠️ Potential issue | 🟠 Major

Avoid logging user-controlled data directly.

Logging the raw request body poses security risks:

1. Log injection: Attackers could inject malicious content that corrupts log files or exploits log viewers
2. PII/PHI exposure: Request may contain sensitive health data (ABHA numbers, patient identifiers) that shouldn't be in logs

Consider logging only a request identifier or sanitized metadata instead.

🛡️ Proposed fix

-		logger.info("Generate token for care context API request " + request);
+		logger.info("Generate token for care context API request received");

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/controller/v3/careContext/CareContextLinkingController.java`
at line 29, The logger.info call in CareContextLinkingController that logs the
raw request ("Generate token for care context API request " + request) exposes
user-controlled/PHI data; change it to avoid printing the request body by
logging a safe request identifier or sanitized metadata instead (e.g.,
correlationId, request.getId(), HTTP method/path, or a masked summary). Update
the logging in the method inside class CareContextLinkingController: remove
concatenation of the full request object and replace with a non-sensitive field
or a generated requestId and ensure any remaining metadata is explicitly
sanitized before logging.

src/main/java/com/wipro/fhir/controller/v3/careContext/CareContextLinkingController.java-47-48 (1)

47-48: ⚠️ Potential issue | 🟠 Major

Same log injection concern applies here.

🛡️ Proposed fix

-		logger.info("link care context API request " + request);
+		logger.info("Link care context API request received");

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/controller/v3/careContext/CareContextLinkingController.java`
around lines 47 - 48, The logger call in CareContextLinkingController.add is
concatenating the raw request into the log ("link care context API request " +
request) which risks log injection and sensitive data exposure; change this to
use parameterized logging or sanitize/omit the request payload instead—update
the add method's logger invocation (refer to CareContextLinkingController.add
and the logger field) to use logger.info with placeholders (or log a safe
summary/id) rather than string concatenation so the raw request is not directly
injected into the log.

src/main/java/com/wipro/fhir/service/resource_model/OrganizationResource.java-78-84 (1)

78-84: ⚠️ Potential issue | 🟠 Major

Externalize the ABDM facility identifier system URL to configuration.

The hardcoded sandbox URL "https://facilitysbx.ndhm.gov.in" (line 81) will cause failures in production deployments. This is inconsistent with the rest of the codebase, which externalizes all ABDM endpoints and system URLs using @Value injection (e.g., hipSystemUrl in PractitionerResource and bundle implementations). Add a @Value-injected property for the facility identifier system URL and define it in the environment-specific property files (common_example.properties, common_docker.properties, common_ci.properties) to support both sandbox and production environments.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/resource_model/OrganizationResource.java`
around lines 78 - 84, The identifier system URL is hardcoded in the
OrganizationResource block that handles orgData.getAbdmFacilityId(); replace the
literal "https://facilitysbx.ndhm.gov.in" with a `@Value-injected` property (e.g.,
abdmFacilitySystemUrl) on the OrganizationResource class, use that property when
creating the Identifier before calling organization.addIdentifier(identifier),
and add the corresponding key/value to the environment property files
(common_example.properties, common_docker.properties, common_ci.properties) with
sandbox and production values so deployments use the configured URL.

src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java-98-99 (1)

98-99: ⚠️ Potential issue | 🟠 Major

Return the link token under one stable field name.

The cached-token path writes linkToken, while the fresh-token path writes X-LINK-TOKEN. That makes the response schema depend on where the token came from, so clients have to branch on cache hit vs. miss.

Also applies to: 152-163

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java`
around lines 98 - 99, In CareContextLinkingServiceImpl, normalize the response
field name so both cache-hit and fresh-token paths put the token under the same
key; update the fresh-token branch that currently writes "X-LINK-TOKEN" to
instead use the stable key "linkToken" (matching the
responseMap.put("linkToken", linkExists") usage) and ensure any headers or map
entries set in the fresh-path (see the block around lines 152-163) are changed
to the same "linkToken" key so clients receive a consistent response schema.

src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java-140-147 (1)

140-147: ⚠️ Potential issue | 🟠 Major

Redact the ABDM request/response logs.

These info logs serialize ABHA numbers/addresses, demographics, and care-context payloads verbatim. That is sensitive health/identity data and should not be written to application logs in full.

Also applies to: 287-295

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java`
around lines 140 - 147, The logs currently print full ABDM request/response
(requestOBJ and responseEntity) which contain sensitive PII/PHI; update the
logging in CareContextLinkingServiceImpl to avoid serializing raw payloads:
either remove the logger.info calls that output requestOBJ/responseEntity or
replace them with sanitized summaries that mask or omit fields from
generateTokenRequest (e.g., ABHA number, address, demographics) and log only
non-sensitive metadata (status code, request id, timestamps). Ensure any
response logging uses restTemplate.exchange result metadata (e.g.,
responseEntity.getStatusCode(), headers) rather than the full body, and apply
the same redaction approach for the other occurrences noted (the similar logging
block around the other exchange call).

src/main/java/com/wipro/fhir/service/elasticsearch/AbhaElasticsearchSyncService.java-84-89 (1)

84-89: ⚠️ Potential issue | 🟠 Major

The missing-document path still drops the sync permanently.

After the last exists == false attempt, the method only logs and returns. Any beneficiary document that appears in Elasticsearch after that window never gets the ABHA fields synced, and retryAfterDelay(...) is currently unused.

Also applies to: 135-145

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/elasticsearch/AbhaElasticsearchSyncService.java`
around lines 84 - 89, The current missing-document branch logs and returns,
causing permanent drop of syncs; update the else branch in
AbhaElasticsearchSyncService (the method containing logger.warn and the
exists==false handling) to schedule a deferred retry instead of returning when
the document is not found: call the existing retryAfterDelay(...) helper
(passing benRegId and any needed context such as attempt/maxRetries or a
Runnable/Task) when you exhaust immediate retries (or even on every not-found if
desired), so the job is requeued for a later attempt; ensure you do not simply
return after the final warn and keep the original retry delay logic
(Thread.sleep) for in-loop retries while using retryAfterDelay to cover
post-maxRetries scheduling.

src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundleImpl.java-176-189 (1)

176-189: ⚠️ Potential issue | 🟠 Major

Include MedicationRequest resources in the bundle.

The composition’s “Medications” section references every MedicationRequest, but this method never adds those resources to Bundle.entry. That leaves dangling references inside the document bundle.

Suggested fix

 			for(MedicationStatement medStatement: medicationStatement) {
 				BundleEntryComponent bundleEntry9 = new BundleEntryComponent();
 				bundleEntry9.setFullUrl(medStatement.getIdElement().getValue());
 				bundleEntry9.setResource(medStatement);
 				
 				bundleEnteries.add(bundleEntry9);
 			}
+
+			for (MedicationRequest mr : medicationRequest) {
+				BundleEntryComponent entryMr = new BundleEntryComponent();
+				entryMr.setFullUrl(mr.getIdElement().getValue());
+				entryMr.setResource(mr);
+				bundleEnteries.add(entryMr);
+			}

Also applies to: 245-259

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundleImpl.java`
around lines 176 - 189, The composition references MedicationRequest resources
but the bundle never includes them; locate the List<MedicationRequest>
medicationRequest (returned from medicationRequestResource.getMedicationRequest)
and add each MedicationRequest as Bundle.entry resources (with fullUrl and
resource) to the document Bundle alongside other entries (e.g., where
diagnosticResourceList and other resources are added) before returning the
bundle; apply the same fix for the later occurrence around the 245-259 block so
all MedicationRequest instances referenced by
populateDischargeSummaryComposition are actually included in Bundle.entry.

src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java-204-233 (1)

204-233: ⚠️ Potential issue | 🟠 Major

Don’t fall through to {} when token lookup or linking fails.

If the stored token lookup misses, or the caught exception has no embedded JSON body, the method reaches Line 333 with an empty responseMap. Callers then get a success-like {} instead of an actionable failure.

Also applies to: 311-330

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java`
around lines 204 - 233, The current token-retrieval block in
CareContextLinkingServiceImpl (handling addCareContextRequest and calling
common_NDHMService.getLinkToken) can exit leaving linkToken null and responseMap
empty, causing callers to receive "{}"; after the existing logic (and similarly
for the 311-330 block) add a definitive failure path: if linkToken is still null
or responseMap is empty, populate responseMap with a clear error entry
(including the raw mongoResponse.getResponse() when available) and/or throw a
FHIRException with a descriptive message so execution does not fall through to a
success return; also update the catch block to include the original response
body or exception stack/details when rethrowing so callers get actionable
failure info.

src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundleImpl.java-188-189 (1)

188-189: ⚠️ Potential issue | 🟠 Major

The “Physical examination” section is populated from diagnoses.

At Lines 188-189, conditionListDiagnosis is passed into the physicalExam slot, so diagnosis conditions will be emitted under the “Physical examination” section instead of their own section.

Also applies to: 293-353

src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundleImpl.java-238-243 (1)

238-243: ⚠️ Potential issue | 🟠 Major

Guard optional family history before dereferencing it.

populateDischargeSummaryComposition(...) already treats family history as optional, but Line 238 calls familyMemberHistory.getId() unconditionally. A patient with no family history will fail bundle generation here.

Suggested fix

-			if(familyMemberHistory.getId() != null) {
+			if (familyMemberHistory != null && familyMemberHistory.getId() != null) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundleImpl.java`
around lines 238 - 243, The code dereferences familyMemberHistory without null
checks; update the logic around bundleEntry8 (in the same flow as
populateDischargeSummaryComposition) to first ensure familyMemberHistory is
non-null and has an id (e.g., familyMemberHistory != null &&
familyMemberHistory.hasId() or familyMemberHistory.getIdElement() != null)
before calling getId()/getIdElement().getValue(), and only create/add
bundleEntry8 to bundleEnteries when those checks pass.

src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java-341-365 (1)

341-365: ⚠️ Potential issue | 🟠 Major

Return null for expired or malformed cached records.

checkRecordExisits(...) only extracts and returns a real token for fresh rows, but Line 364 falls back to result.getResponse() for older or invalid rows. The caller then serializes that raw JSON as if it were the link token.

Suggested fix

-		return linkResponse;
+		return null;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java`
around lines 341 - 365, The method checkRecordExisits (in
CareContextLinkingServiceImpl) currently falls back to returning
result.getResponse() even when the cached row is older than three months or when
the JSON is malformed; change the control flow so that if
result.getCreatedDate() is older than threeMonthsAgo or if parsing the JSON
(ObjectMapper.readTree) does not yield a non-null, non-missing linkToken, the
method returns null instead of returning linkResponse; keep the existing
try/catch and logging around mapper.readTree and ensure only linkToken.asText()
is returned when valid, otherwise return null.

src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java-114-119 (1)

114-119: ⚠️ Potential issue | 🟠 Major

Use content-based emptiness checks for abdmFacilityId.

Line 115 uses != "" against the string, which performs reference equality instead of content comparison. An empty string deserialized from JSON may not be the interned reference literal "", so the condition could evaluate to true and send X-HIP-ID as blank instead of falling back to the configured abdmFacilityId. The codebase already uses the correct pattern on line 122 with .isEmpty().

Use .isEmpty() instead:

-				if (null != careContextLinkRequest.getAbdmFacilityId()
-						&& "" != careContextLinkRequest.getAbdmFacilityId()) {
+				if (careContextLinkRequest.getAbdmFacilityId() != null
+						&& !careContextLinkRequest.getAbdmFacilityId().isEmpty()) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java`
around lines 114 - 119, In CareContextLinkingServiceImpl update the conditional
that checks careContextLinkRequest.getAbdmFacilityId() so it uses a
content-based emptiness check (e.g., .isEmpty() or length()==0) instead of the
reference comparison != ""; specifically modify the block that decides which
value to pass to headers.add("X-HIP-ID", ...) to fall back to abdmFacilityId
when getAbdmFacilityId() is null or empty, mirroring the correct pattern already
used elsewhere in the class.

src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundleImpl.java-136-141 (1)

136-141: ⚠️ Potential issue | 🟠 Major

Fix the confidentiality Coding arguments.

The Coding(system, code, display) constructor parameters are in the wrong order. In the HL7 v3-Confidentiality code system, "R" is the valid code for "restricted"; the current code incorrectly passes "restricted" as the code (which is not a valid code value) and "R" as the display.

-			meta.addSecurity(new Coding("http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "restricted", "R"));
+			meta.addSecurity(new Coding("http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "R", "restricted"));

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundleImpl.java`
around lines 136 - 141, The Confidentiality Coding arguments are passed in the
wrong order in the Meta setup: update the Coding(...) call used when building
Meta (the line constructing new
Coding("http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "restricted",
"R")) to use the correct parameter order so the code is the HL7 code "R" and the
display is "restricted" (i.e., new
Coding("http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "R",
"restricted")), leaving Meta, meta.setVersionId, meta.setLastUpdated and
dischargeSummaryBundle.setMeta unchanged.

src/main/java/com/wipro/fhir/service/bundle_creation/WellnessRecordResourceBundleImpl.java-93-98 (1)

93-98: ⚠️ Potential issue | 🟠 Major

Fix the confidentiality Coding argument order.

The Coding constructor signature is Coding(system, code, display). Currently, code and display are swapped: code="restricted" and display="R" are backwards. The v3-Confidentiality CodeSystem defines "R" as the code (not display), which represents the restricted confidentiality level. Every Wellness document created with the current code advertises an invalid confidentiality code.

Suggested fix

-			meta.addSecurity(new Coding("http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "restricted", "R"));
+			meta.addSecurity(new Coding("http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "R", "restricted"));

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/bundle_creation/WellnessRecordResourceBundleImpl.java`
around lines 93 - 98, The confidentiality Coding arguments are reversed in
WellnessRecordResourceBundleImpl: when creating the Coding passed to
meta.addSecurity(...) you must use the constructor order (system, code, display)
so that code is "R" and display is "restricted"; update the Coding(...) call
used before wellnessBundle.setMeta(meta) to pass
"http://terminology.hl7.org/CodeSystem/v3-Confidentiality" as system, "R" as
code and "restricted" as display so the bundle advertises the correct
v3-Confidentiality code.

src/main/java/com/wipro/fhir/service/elasticsearch/AbhaElasticsearchSyncService.java-115-127 (1)

115-127: ⚠️ Potential issue | 🟠 Major

Catch Elasticsearch exceptions separately from "document not found".

In Elasticsearch Java API Client 8.11.0, esClient.get() returns a GetResponse with found=false when a document doesn't exist—this is NOT an exception. However, server/transport/auth errors throw ElasticsearchException or TransportException.

The current catch-all at line 125 treats both cases identically and returns false, causing the caller (line 68) to misreport auth/transport/index errors as missing documents and unnecessarily retry 3 times (line 85). Only actual "document not found" (where response.found() is false) should map to false; other exceptions should propagate or be handled separately.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/elasticsearch/AbhaElasticsearchSyncService.java`
around lines 115 - 127, The checkDocumentExists method currently swallows all
exceptions and returns false, conflating real "not found" responses with
transport/auth errors; modify checkDocumentExists (the method invoking
esClient.get and reading GetResponse<Object>.found()) to call esClient.get and
if response.found() is false return false, but catch and handle
ElasticsearchException and TransportException separately (log and rethrow or
propagate) instead of returning false, while retaining a broad Exception catch
only for unexpected cases; reference the esClient.get call, GetResponse,
beneficiaryIndex and logger.debug to adjust logging and control flow so only
genuine missing documents map to false.

src/main/java/com/wipro/fhir/service/bundle_creation/OPConsultResourceBundleImpl.java-227-229 (1)

227-229: ⚠️ Potential issue | 🟠 Major

Same FhirContext instantiation issue as in PrescriptionResourceBundleImpl.

Cache or inject FhirContext as a shared singleton to avoid repeated expensive initialization.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/bundle_creation/OPConsultResourceBundleImpl.java`
around lines 227 - 229, The code in OPConsultResourceBundleImpl is creating a
new FhirContext each time (FhirContext.forR4() used with IParser parser =
ctx.newJsonParser()), which is expensive; change this to use a shared singleton
FhirContext instance (either inject a cached FhirContext or expose a static
final field) and obtain the parser from that shared context instead of
instantiating in the method—follow the same singleton/injection approach used in
PrescriptionResourceBundleImpl and replace the local FhirContext.forR4() use
with the shared FhirContext reference (then call sharedCtx.newJsonParser()).

src/main/java/com/wipro/fhir/service/bundle_creation/PrescriptionResourceBundleImpl.java-155-157 (1)

155-157: ⚠️ Potential issue | 🟠 Major

Avoid creating FhirContext per request – it is expensive to instantiate.

FhirContext.forR4() performs class scanning and reflection on initialization, making it very costly. HAPI FHIR documentation recommends using the built-in cached factory method, which maintains a synchronized static cache per FHIR version. The context itself is thread-safe and should be reused.

Replace FhirContext.forR4() with FhirContext.forR4Cached():

🔧 Proposed fix: use built-in cached FhirContext

-	FhirContext ctx = FhirContext.forR4();
+	FhirContext ctx = FhirContext.forR4Cached();
	IParser parser = ctx.newJsonParser();
	serializeBundle = parser.encodeResourceToString(prescriptionBundle);

This is the official recommended approach – forR4Cached() automatically caches the context and returns the same instance on subsequent calls.

Alternative: If you prefer to avoid the local variable entirely, inject FhirContext as a Spring bean:

`@Bean`
public FhirContext fhirContext() {
    return FhirContext.forR4Cached();
}

Then use it directly without creating a new instance each time.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/bundle_creation/PrescriptionResourceBundleImpl.java`
around lines 155 - 157, The code in PrescriptionResourceBundleImpl currently
instantiates a new FhirContext with FhirContext.forR4() (seen where FhirContext
ctx = FhirContext.forR4() and used to create IParser and serializeBundle), which
is expensive; replace that call with FhirContext.forR4Cached() to reuse the
cached, thread-safe context or, alternatively, inject a single FhirContext bean
(constructed with FhirContext.forR4Cached()) and use that instance when creating
the IParser and encoding the prescriptionBundle.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: e03d3ebe-105a-4a5a-a950-d3fde9fbc3d4

📥 Commits

Reviewing files that changed from the base of the PR and between 7dee6de and 7ef6b9a.

📒 Files selected for processing (67)

• .factorypath
• pom.xml
• src/main/environment/common_ci.properties
• src/main/environment/common_docker.properties
• src/main/environment/common_example.properties
• src/main/java/com/wipro/fhir/FhirApiApplication.java
• src/main/java/com/wipro/fhir/config/CorsConfig.java
• src/main/java/com/wipro/fhir/config/ElasticsearchConfig.java
• src/main/java/com/wipro/fhir/controller/generateresource/ResourceRequestGateway.java
• src/main/java/com/wipro/fhir/controller/health/HealthController.java
• src/main/java/com/wipro/fhir/controller/test/Test.java
• src/main/java/com/wipro/fhir/controller/v3/abha/CreateAbhaV3Controller.java
• src/main/java/com/wipro/fhir/controller/v3/careContext/CareContextLinkingController.java
• src/main/java/com/wipro/fhir/data/mongo/care_context/GenerateTokenAbdmResponses.java
• src/main/java/com/wipro/fhir/data/resource_model/ImmunizationDataModel.java
• src/main/java/com/wipro/fhir/data/resource_model/MedicalHistoryDataModel.java
• src/main/java/com/wipro/fhir/data/resource_model/OrganizationDataModel.java
• src/main/java/com/wipro/fhir/data/resource_model/PractitionerDataModel.java
• src/main/java/com/wipro/fhir/data/v3/careContext/AddCareContextRequest.java
• src/main/java/com/wipro/fhir/data/v3/careContext/CareContextLinkTokenRequest.java
• src/main/java/com/wipro/fhir/data/v3/careContext/CareContexts.java
• src/main/java/com/wipro/fhir/data/v3/careContext/GenerateCareContextTokenRequest.java
• src/main/java/com/wipro/fhir/data/v3/careContext/LinkCareContextRequest.java
• src/main/java/com/wipro/fhir/data/v3/careContext/PatientCareContext.java
• src/main/java/com/wipro/fhir/repo/common/PatientEligibleForResourceCreationRepo.java
• src/main/java/com/wipro/fhir/repo/mongo/generateToken_response/GenerateTokenAbdmResponsesRepo.java
• src/main/java/com/wipro/fhir/repo/v3/careContext/CareContextRepo.java
• src/main/java/com/wipro/fhir/service/bundle_creation/BundleValidator.java
• src/main/java/com/wipro/fhir/service/bundle_creation/DiagnosticRecordResourceBundle.java
• src/main/java/com/wipro/fhir/service/bundle_creation/DiagnosticRecordResourceBundleImpl.java
• src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundle.java
• src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundleImpl.java
• src/main/java/com/wipro/fhir/service/bundle_creation/ImmunizationRecordResourceBundle.java
• src/main/java/com/wipro/fhir/service/bundle_creation/ImmunizationRecordResourceBundleImpl.java
• src/main/java/com/wipro/fhir/service/bundle_creation/OPConsultResourceBundle.java
• src/main/java/com/wipro/fhir/service/bundle_creation/OPConsultResourceBundleImpl.java
• src/main/java/com/wipro/fhir/service/bundle_creation/PrescriptionResourceBundle.java
• src/main/java/com/wipro/fhir/service/bundle_creation/PrescriptionResourceBundleImpl.java
• src/main/java/com/wipro/fhir/service/bundle_creation/WellnessRecordResourceBundle.java
• src/main/java/com/wipro/fhir/service/bundle_creation/WellnessRecordResourceBundleImpl.java
• src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java
• src/main/java/com/wipro/fhir/service/elasticsearch/AbhaElasticsearchSyncService.java
• src/main/java/com/wipro/fhir/service/healthID/HealthIDServiceImpl.java
• src/main/java/com/wipro/fhir/service/ndhm/Common_NDHMService.java
• src/main/java/com/wipro/fhir/service/ndhm/Common_NDHMServiceImpl.java
• src/main/java/com/wipro/fhir/service/ndhm/LinkCareContext_NDHMServiceImpl.java
• src/main/java/com/wipro/fhir/service/resource_gateway/DiagnosticReportRecord.java
• src/main/java/com/wipro/fhir/service/resource_gateway/DiagnosticReportRecordImpl.java
• src/main/java/com/wipro/fhir/service/resource_gateway/OPConsultRecordBundle.java
• src/main/java/com/wipro/fhir/service/resource_gateway/OPConsultRecordBundleImpl.java
• src/main/java/com/wipro/fhir/service/resource_gateway/PrescriptionRecordBundle.java
• src/main/java/com/wipro/fhir/service/resource_gateway/PrescriptionRecordBundleImpl.java
• src/main/java/com/wipro/fhir/service/resource_model/DiagnosticReportResource.java
• src/main/java/com/wipro/fhir/service/resource_model/EncounterResource.java
• src/main/java/com/wipro/fhir/service/resource_model/ImmunizationResource.java
• src/main/java/com/wipro/fhir/service/resource_model/MedicalHistoryResource.java
• src/main/java/com/wipro/fhir/service/resource_model/MedicationRequestResource.java
• src/main/java/com/wipro/fhir/service/resource_model/ObservationResource.java
• src/main/java/com/wipro/fhir/service/resource_model/OrganizationResource.java
• src/main/java/com/wipro/fhir/service/resource_model/PatientResource.java
• src/main/java/com/wipro/fhir/service/resource_model/PractitionerResource.java
• src/main/java/com/wipro/fhir/service/v3/abha/CreateAbhaV3ServiceImpl.java
• src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingService.java
• src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java
• src/main/java/com/wipro/fhir/utils/JwtUserIdValidationFilter.java
• src/main/java/com/wipro/fhir/utils/http/HTTPRequestInterceptor.java
• src/main/resources/application.properties

💤 Files with no reviewable changes (9)

• src/main/java/com/wipro/fhir/service/resource_model/DiagnosticReportResource.java
• src/main/java/com/wipro/fhir/service/resource_model/PatientResource.java
• src/main/java/com/wipro/fhir/service/resource_gateway/OPConsultRecordBundleImpl.java
• src/main/java/com/wipro/fhir/service/resource_gateway/PrescriptionRecordBundle.java
• src/main/java/com/wipro/fhir/service/resource_gateway/OPConsultRecordBundle.java
• src/main/java/com/wipro/fhir/service/v3/abha/CreateAbhaV3ServiceImpl.java
• src/main/java/com/wipro/fhir/service/resource_gateway/PrescriptionRecordBundleImpl.java
• src/main/java/com/wipro/fhir/service/resource_gateway/DiagnosticReportRecord.java
• src/main/java/com/wipro/fhir/service/resource_gateway/DiagnosticReportRecordImpl.java

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Inconsistent placeholder syntax will cause runtime failure.

Lines 102-103 use @env.ABDM_HIECM_BASE_URL@ (Maven resource filtering syntax), while all other properties in this file use ${VARIABLE} (Spring property placeholder syntax). This inconsistency will likely result in the literal string @env.ABDM_HIECM_BASE_URL@ being used at runtime instead of the resolved value.

🐛 Proposed fix

 ## ABDM V3 M2 APIs 
-generateTokenForLinkCareContext = `@env.ABDM_HIECM_BASE_URL`@/api/hiecm/v3/token/generate-token
-linkCareContext = `@env.ABDM_HIECM_BASE_URL`@/api/hiecm/hip/v3/link/carecontext
+generateTokenForLinkCareContext = ${ABDM_HIECM_BASE_URL}/api/hiecm/v3/token/generate-token
+linkCareContext = ${ABDM_HIECM_BASE_URL}/api/hiecm/hip/v3/link/carecontext

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	## ABDM V3 M2 APIs
	generateTokenForLinkCareContext = @env.ABDM_HIECM_BASE_URL@/api/hiecm/v3/token/generate-token
	linkCareContext = @env.ABDM_HIECM_BASE_URL@/api/hiecm/hip/v3/link/carecontext
	## ABDM V3 M2 APIs
	generateTokenForLinkCareContext = ${ABDM_HIECM_BASE_URL}/api/hiecm/v3/token/generate-token
	linkCareContext = ${ABDM_HIECM_BASE_URL}/api/hiecm/hip/v3/link/carecontext

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/environment/common_docker.properties` around lines 101 - 103, The
two properties generateTokenForLinkCareContext and linkCareContext use
Maven-style placeholders (`@env.ABDM_HIECM_BASE_URL`@) which will not be resolved
at runtime; update both to use the same Spring-style placeholder used elsewhere
(e.g., replace `@env.ABDM_HIECM_BASE_URL`@ with ${ABDM_HIECM_BASE_URL}) so the
values are resolved consistently at runtime.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

find . -type f -name "WellnessRecordResourceBundleImpl.java" 2>/dev/null

Repository: PSMRI/FHIR-API

Length of output: 150

---

🏁 Script executed:

find . -type f -path "*/bundle_creation/*" -name "*.java" 2>/dev/null | head -20

Repository: PSMRI/FHIR-API

Length of output: 1227

---

🏁 Script executed:

find . -type f -path "*/com/wipro/fhir/utils/exception/*" -name "*.java" 2>/dev/null

Repository: PSMRI/FHIR-API

Length of output: 123

---

🏁 Script executed:

cat -n ./src/main/java/com/wipro/fhir/service/bundle_creation/WellnessRecordResourceBundleImpl.java

Repository: PSMRI/FHIR-API

Length of output: 11310

---

🏁 Script executed:

cat -n ./src/main/java/com/wipro/fhir/service/bundle_creation/DiagnosticRecordResourceBundleImpl.java | head -80

Repository: PSMRI/FHIR-API

Length of output: 3556

---

🏁 Script executed:

cat -n ./src/main/java/com/wipro/fhir/service/bundle_creation/PrescriptionResourceBundleImpl.java | head -80

Repository: PSMRI/FHIR-API

Length of output: 3707

---

🏁 Script executed:

grep -n "throws.*Exception" ./src/main/java/com/wipro/fhir/service/bundle_creation/DiagnosticRecordResourceBundleImpl.java | head -10

Repository: PSMRI/FHIR-API

Length of output: 191

---

🏁 Script executed:

grep -n "throws.*Exception" ./src/main/java/com/wipro/fhir/service/bundle_creation/PrescriptionResourceBundleImpl.java | head -10

Repository: PSMRI/FHIR-API

Length of output: 285

---

🏁 Script executed:

cat -n ./src/main/java/com/wipro/fhir/utils/exception/FHIRException.java

Repository: PSMRI/FHIR-API

Length of output: 1766

---

Use the application FHIRException here, not the HAPI one.

This file imports org.hl7.fhir.exceptions.FHIRException from the HAPI library, while the neighboring bundle builders (DiagnosticRecordResourceBundleImpl and PrescriptionResourceBundleImpl) import and use com.wipro.fhir.utils.exception.FHIRException from the application. This inconsistency breaks the service contract and allows exceptions to bypass application-level error handling. Also, line 64 declares throws FHIRException, Exception while peer implementations declare only throws FHIRException.

Suggested fix

- import org.hl7.fhir.exceptions.FHIRException;
+ import com.wipro.fhir.utils.exception.FHIRException;

And update method signatures:

- public int processWellnessRecordBundle(ResourceRequestHandler resourceRequestHandler, PatientEligibleForResourceCreation p) throws FHIRException, Exception {
+ public int processWellnessRecordBundle(ResourceRequestHandler resourceRequestHandler, PatientEligibleForResourceCreation p) throws FHIRException {

- public String populateWellnessRecordResourceBundle(ResourceRequestHandler resourceRequestHandler, PatientEligibleForResourceCreation p) throws FHIRException {
+ public String populateWellnessRecordResourceBundle(ResourceRequestHandler resourceRequestHandler, PatientEligibleForResourceCreation p) throws FHIRException {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/wipro/fhir/service/bundle_creation/WellnessRecordResourceBundleImpl.java`
at line 8, Replace the HAPI FHIRException import with the application exception
and update the method signature to match peers: change the import from
org.hl7.fhir.exceptions.FHIRException to
com.wipro.fhir.utils.exception.FHIRException at the top of
WellnessRecordResourceBundleImpl and remove the broad "throws Exception" from
the resource-building method declaration (the method that currently declares
"throws FHIRException, Exception" in WellnessRecordResourceBundleImpl) so it
only throws the application FHIRException like
DiagnosticRecordResourceBundleImpl and PrescriptionResourceBundleImpl; ensure
all local references and catch/throw sites in that class use the application
FHIRException type.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Thread-safety issue: mutable instance field in singleton service.

The encounter field is an instance variable in this @Service (singleton-scoped) class. When generateEncounterResource is called concurrently by multiple threads, they will overwrite each other's encounter reference, causing data corruption.

Convert encounter to a local variable within the method.

🔒 Proposed fix

-	private Encounter encounter;
-
 	public Encounter getEncounterResource(Patient patient, ResourceRequestHandler resourceRequestHandler, 

And in generateEncounterResource:

 	private Encounter generateEncounterResource(Patient patient, List<EncounterDataModel> encounterList, 
 			List<Condition> conditionListChiefComplaints,
 			List<Condition> conditionListDiagnosis) {
-		encounter = new Encounter();
+		Encounter encounter = new Encounter();

 		encounter.setId("Encounter/" + commonService.getUUID());
         // ... rest of method unchanged ...
 		return encounter;
 	}

Also applies to: 80-80

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/wipro/fhir/service/resource_model/EncounterResource.java`
at line 63, The class currently holds a mutable instance field "encounter" (and
another mutable field declared around line 80) in a singleton-scoped `@Service`,
which is not thread-safe; remove these instance fields and instead declare and
initialize them as local variables inside generateEncounterResource (and any
other methods that use them), update all references in generateEncounterResource
from the class fields to the new local variables (e.g., use a local Encounter
encounter = ... inside generateEncounterResource), and delete the class-level
declarations to prevent shared mutable state.