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

• New Features

  • Added Elasticsearch integration for data indexing and search capabilities.
  • Added Care Context linking APIs for ABDM V3 integration.
  • Introduced health check endpoint (/health) with MySQL and Redis status monitoring.
  • Added version information endpoint (/version) displaying build and git details.
  • Enabled async request processing support.

• Improvements

  • Enhanced CORS configuration with extended header support.
  • Refactored bundle creation for multiple document types (OP Consult, Prescription, Diagnostic Report, Wellness, Immunization, Discharge Summary).

• Dependencies

  • Updated HAPI FHIR from 6.10.0 to 8.4.0.
  • Upgraded Jackson libraries to 2.15.2.
  • Added Elasticsearch client 8.11.0.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR introduces Elasticsearch integration for ABHA data syncing, implements ABDM V3 M2 care context linking APIs, refactors bundle creation from resource_gateway to bundle_creation architecture, adds health and version check endpoints, upgrades core dependencies (Jackson, HAPI FHIR, Elasticsearch clients), and updates CORS and datasource configurations.

Changes

Cohort / File(s)	Summary
Dependency & Build Configuration .factorypath, pom.xml	Updated Lombok version, added Elasticsearch/ECS logging dependencies, upgraded Jackson (2.14.2→2.15.2), HAPI FHIR (6.10.0→8.4.0), and added git-commit-id plugin for git.properties generation.
Environment & Application Configuration src/main/environment/common_ci.properties, src/main/environment/common_docker.properties, src/main/environment/common_example.properties, src/main/resources/application.properties	Added ABDM V3 M2 endpoints, HIP system URL, Elasticsearch connection settings (host/port/credentials/index), disabled Tomcat pool config, enabled HikariCP with detailed pool/timeout/validation settings, and extended Elasticsearch client properties.
Elasticsearch Configuration & Integration src/main/java/com/wipro/fhir/config/ElasticsearchConfig.java, src/main/java/com/wipro/fhir/service/elasticsearch/AbhaElasticsearchSyncService.java	Added ElasticsearchConfig with RestClient, transport, and async executor beans; created AbhaElasticsearchSyncService with retry logic, timeout handling, and document existence checks for ABHA data sync.
Health & Version Endpoints src/main/java/com/wipro/fhir/controller/health/HealthController.java, src/main/java/com/wipro/fhir/service/health/HealthService.java, src/main/java/com/wipro/fhir/controller/version/VersionController.java	Added HealthController returning health status (UP/DEGRADED/DOWN) with per-component MySQL/Redis checks and HealthService with concurrent execution; added VersionController exposing git properties (buildTimestamp, version, branch, commitHash).
Care Context Linking 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/*	Introduced care context linking for ABDM V3 M2 with two endpoints (generateCareContextToken, linkCareContext), service handling token generation with Mongo caching, HI type discovery, and ABDM API integration; added DTOs (AddCareContextRequest, GenerateCareContextTokenRequest, LinkCareContextRequest, CareContexts, PatientCareContext).
MongoDB Care Context Models src/main/java/com/wipro/fhir/data/mongo/care_context/GenerateTokenAbdmResponses.java, src/main/java/com/wipro/fhir/repo/mongo/generateToken_response/GenerateTokenAbdmResponsesRepo.java	Added GenerateTokenAbdmResponses document model with id/abhaAddress/requestId/response/createdDate fields; created repository with findByAbhaAddress and findByRequestId query methods.
Bundle Creation Refactoring src/main/java/com/wipro/fhir/service/bundle_creation/*, 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_gateway/DiagnosticReportRecord.java, src/main/java/com/wipro/fhir/service/resource_gateway/DiagnosticReportRecordImpl.java	Migrated from resource_gateway to bundle_creation; added new interfaces (OPConsultResourceBundle, PrescriptionResourceBundle, DiagnosticRecordResourceBundle, ImmunizationRecordResourceBundle, DischargeSummaryResourceBundle, WellnessRecordResourceBundle) and implementations with FHIR bundle serialization, Mongo persistence, and national health ID mapping.
Resource Model Data Classes 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 models mapping database result sets to POJO fields with constructor-based initialization, null handling, and list-conversion helpers for Immunization, MedicalHistory, Organization, and Practitioner resources.
Resource Model 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, src/main/java/com/wipro/fhir/service/resource_model/EncounterResource.java, src/main/java/com/wipro/fhir/service/resource_model/ObservationResource.java, src/main/java/com/wipro/fhir/service/resource_model/MedicationRequestResource.java, src/main/java/com/wipro/fhir/service/resource_model/DiagnosticReportResource.java, src/main/java/com/wipro/fhir/service/resource_model/PatientResource.java	Added/refactored resource generators: ImmunizationResource, MedicalHistoryResource with database queries and FHIR mapping; updated OrganizationResource and PractitionerResource to use dynamic data models instead of hardcoded values; removed Encounter parameter from ObservationResource.getObservationVitals; cleaned up imports; added indexing to MedicationRequest and null guards for condition lists.
Repository Enhancements src/main/java/com/wipro/fhir/repo/common/PatientEligibleForResourceCreationRepo.java, src/main/java/com/wipro/fhir/repo/v3/careContext/CareContextRepo.java	Added stored-procedure mappings (callMedicalHistorySp, callImmunizationSP, callOrganizationSp, callPractitionerSP) to PatientEligibleForResourceCreationRepo; created CareContextRepo with COUNT(*) queries (hasPhyVitals, hasPrescribedDrugs, hasLabtestsDone, hasVaccineDetails) for HI type discovery.
Service Integration & Orchestration src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.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	Updated CommonServiceImpl to use new bundle_creation services with conditional processing based on visit category and CareContextRepo checks, replacing old resource_gateway logic; injected AbhaElasticsearchSyncService into HealthIDServiceImpl for post-mapping sync; added getLinkToken method to NDHM service interface and implementation; added response logging to LinkCareContext service.
Application Startup & CORS Configuration src/main/java/com/wipro/fhir/FhirApiApplication.java, src/main/java/com/wipro/fhir/config/CorsConfig.java	Added @EnableAsync to FhirApiApplication; expanded CORS allowed methods (added PATCH) and headers (added Accept, Jwttoken, serverAuthorization variants).
HTTP Filtering & Interception src/main/java/com/wipro/fhir/utils/JwtUserIdValidationFilter.java, src/main/java/com/wipro/fhir/utils/http/HTTPRequestInterceptor.java	Updated filter with explicit OPTIONS preflight handling, origin validation blocking (403), CORS header assignment, and path skipping for /version and /health endpoints; enhanced interceptor with configurable per-origin CORS handling and isOriginAllowed helper instead of wildcard.
Controller Refactoring 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/service/bundle_creation/BundleValidator.java	Updated ResourceRequestGateway and Test controller to invoke bundle_creation services instead of resource_gateway; added @CrossOrigin to verifyMobileForAuth endpoint; added BundleValidator utility with FHIR validation chain setup.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant CareContextController as CareContextLinkingController
    participant CareContextService as CareContextLinkingService
    participant NDHMService as Common_NDHMService
    participant ABDMAPI as ABDM API
    participant Mongo as MongoDB
    participant Repo as Repo

    Client->>CareContextController: POST /careContext/generateCareContextToken
    CareContextController->>CareContextService: generateTokenForCareContext(request)
    CareContextService->>Mongo: Check existing token (last 3 months)
    Mongo-->>CareContextService: GenerateTokenAbdmResponses or null
    alt Token exists and valid
        CareContextService-->>CareContextController: Return cached LinkToken
    else Generate new token
        CareContextService->>NDHMService: Prepare ABDM headers
        CareContextService->>ABDMAPI: POST to generateTokenForLinkCareContext
        ABDMAPI-->>CareContextService: HTTP 202 with requestId
        CareContextService->>Mongo: Fetch response by requestId
        Mongo-->>CareContextService: LinkToken response
        CareContextService-->>CareContextController: Return LinkToken
    end
    CareContextController-->>Client: OutputResponse with token

Loading

sequenceDiagram
    participant Client
    participant CareContextController as CareContextLinkingController
    participant CareContextService as CareContextLinkingService
    participant RepoLayer as PatientEligibleForResourceCreationRepo
    participant ABDMAPI as ABDM API
    participant Mongo as MongoDB

    Client->>CareContextController: POST /careContext/linkCareContext
    CareContextController->>CareContextService: linkCareContext(request)
    CareContextService->>Mongo: Fetch LinkToken from stored response
    Mongo-->>CareContextService: Token retrieved
    CareContextService->>RepoLayer: findHiTypes(visitCode, visitCategory)
    RepoLayer->>RepoLayer: COUNT checks (labs, drugs, vitals, vaccines)
    RepoLayer-->>CareContextService: Available HI types array
    CareContextService->>CareContextService: Build PatientCareContext list
    CareContextService->>ABDMAPI: POST to linkCareContext with X-LINK-TOKEN
    ABDMAPI-->>CareContextService: Success or error response
    CareContextService-->>CareContextController: Response message or FHIRException
    CareContextController-->>Client: OutputResponse

Loading

sequenceDiagram
    participant HealthIDService as HealthIDServiceImpl
    participant NDHMService as Common_NDHMServiceImpl
    participant BenHealthIDMapping as Repo (BenHealthIDMapping)
    participant EsService as AbhaElasticsearchSyncService
    participant EsClient as ElasticsearchClient

    HealthIDService->>NDHMService: mapHealthIDToBeneficiary(request)
    NDHMService->>BenHealthIDMapping: Save health ID mapping
    BenHealthIDMapping-->>NDHMService: Success
    NDHMService->>HealthIDService: Mapping complete
    HealthIDService->>EsService: updateAbhaInElasticsearch(benRegId, healthId, ...)
    EsService->>EsClient: checkDocumentExists(documentId)
    EsClient-->>EsService: Document exists?
    alt Document found
        EsService->>EsClient: UpdateRequest with doc(...)
        EsClient-->>EsService: Success
    else Document not found
        EsService->>EsService: Retry up to 3 times with 5s delay
        EsService->>EsClient: UpdateRequest (retry)
        EsClient-->>EsService: Success or timeout
    end
    EsService-->>HealthIDService: Sync complete (errors logged)

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Possibly related PRs

• M2 FHIR bundles creation #123: Makes overlapping code-level changes including bundle_creation interfaces/implementations, repository stored-procedure methods, Elasticsearch and ABDM configuration, and updates to shared services like CommonServiceImpl.

Suggested reviewers

• 5Amogh

Poem

🐰 Bundles hop to new homes, care contexts link with grace,
Elasticsearch searches beneficiaries across the place,
Health checks bounce and versions bloom so bright,
This FHIR refactor leaps with all its might! ✨

✨ 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 release-3.6.1

[coderabbitai]

Actionable comments posted: 20

Note

Due to the large number of review comments, Critical, Major 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/service/resource_model/MedicationRequestResource.java (1)

62-62: ⚠️ Potential issue | 🟠 Major

Thread-safety risk: instance field medicationRequest in singleton @Service.

The medicationRequest field at line 62 is an instance variable that gets reassigned in generateMedicationRequestResource (line 96). Since @Service beans are singletons by default in Spring, concurrent requests could cause race conditions where one thread's medication request is overwritten by another.

Consider making this a local variable inside the method instead:

🔧 Proposed fix

-	MedicationRequest medicationRequest;

And inside generateMedicationRequestResource, change line 96 to:

MedicationRequest medicationRequest = new MedicationRequest();

🤖 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/MedicationRequestResource.java`
at line 62, The instance field medicationRequest in the singleton Service class
MedicationRequestResource is not thread-safe because
generateMedicationRequestResource reassigns it; change medicationRequest to be a
local variable within generateMedicationRequestResource (remove the class-level
field or stop using it elsewhere) so the method uses a local MedicationRequest
variable (e.g., declare MedicationRequest medicationRequest = new
MedicationRequest() inside generateMedicationRequestResource) to avoid shared
mutable state and race conditions.

src/main/java/com/wipro/fhir/utils/JwtUserIdValidationFilter.java (1)

40-51: ⚠️ Potential issue | 🟡 Minor

Remove duplicate logging statements.

Lines 42-43 and 48-51 log the same information twice:

        logger.debug("Incoming Origin: {}", origin);
-       logger.debug("Allowed Origins Configured: {}", allowedOrigins);
-
        String method = request.getMethod();
        String uri = request.getRequestURI();

-       logger.debug("Incoming Origin: {}", origin);
        logger.debug("Request Method: {}", method);
        logger.debug("Request URI: {}", uri);
        logger.debug("Allowed Origins Configured: {}", allowedOrigins);

🤖 Prompt for AI Agents

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

In `@src/main/java/com/wipro/fhir/utils/JwtUserIdValidationFilter.java` around
lines 40 - 51, The JwtUserIdValidationFilter contains duplicate logger.debug
calls for the same values (origin and allowedOrigins) — remove the repeated
logging so each value is logged only once; specifically, keep a single grouped
debug block that logs origin, method, uri, and allowedOrigins (using the
existing variables origin, method, uri, allowedOrigins with logger.debug) and
delete the duplicate logger.debug lines to avoid redundant logs.

🟡 Minor comments (12)

src/main/java/com/wipro/fhir/utils/JwtUserIdValidationFilter.java-53-92 (1)

53-92: ⚠️ Potential issue | 🟡 Minor

Redundant origin validation creates dead code.

The origin validation logic is duplicated:

1. Lines 53-71 already block unauthorized origins with sendError(403) and return
2. Lines 76-92 re-check isOriginAllowed(origin) but the else branch (lines 85-91) is unreachable because unauthorized origins were already blocked

The else branch at lines 85-91 is dead code. Simplify:

        // After lines 53-71, we know origin is either null or allowed
        
        if (origin != null && isOriginAllowed(origin)) {
            addCorsHeaders(response, origin);
            logger.info("Origin Validated | Origin: {} | Method: {} | URI: {}", origin, method, uri);

            if ("OPTIONS".equalsIgnoreCase(method)) {
                response.setStatus(HttpServletResponse.SC_OK);
                return;
            }
-       } else {
-           logger.warn("Origin [{}] is NOT allowed. CORS headers NOT added.", origin);
-
-           if ("OPTIONS".equalsIgnoreCase(method)) {
-               response.sendError(HttpServletResponse.SC_FORBIDDEN, "Origin not allowed for OPTIONS request");
-               return;
-           }
        }
+       // If origin is null, no CORS headers needed - proceed to JWT validation

🤖 Prompt for AI Agents

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

In `@src/main/java/com/wipro/fhir/utils/JwtUserIdValidationFilter.java` around
lines 53 - 92, In JwtUserIdValidationFilter, remove the duplicate origin check
by eliminating the unreachable else branch that re-checks
isOriginAllowed(origin); instead, after the initial OPTIONS and non-OPTIONS
validation blocks (which already sendError+return for disallowed origins),
perform a single allowed-origin path: if origin != null and
isOriginAllowed(origin) then call addCorsHeaders(response, origin), log via
logger.info(...), and if method is OPTIONS set SC_OK and return; otherwise
proceed normally; ensure any logging for disallowed origins remains in the first
validation and remove the later logger.warn(...) and sendError(...) dead-code
block; reference variables/methods: method, origin, uri, isOriginAllowed(...),
addCorsHeaders(...), logger.

src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java-238-284 (1)

238-284: ⚠️ Potential issue | 🟡 Minor

Fix typos in log messages: "proceesed" → "processed".

Multiple log statements have "proceesed" instead of "processed" (lines 238, 248, 257, 266, 276, 284).

✏️ Proposed fix

-				logger.info(" The value of opConsult proceesed: " + processed);
+				logger.info(" The value of opConsult processed: " + processed);
 ...
-				logger.info(" The value of diagReport proceesed: " + processed);
+				logger.info(" The value of diagReport processed: " + processed);
 ...
-				logger.info(" The value of presp proceesed: " + processed);
+				logger.info(" The value of presp processed: " + processed);
 ...
-				logger.info(" The value of wellness proceesed: " + processed);
+				logger.info(" The value of wellness processed: " + processed);
 ...
-				logger.info(" The value of immunization proceesed: " + processed);
+				logger.info(" The value of immunization processed: " + processed);
 ...
-				logger.info(" The value of dischargeSummary proceesed: " + processed);
+				logger.info(" The value of dischargeSummary processed: " + processed);

🤖 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/common/CommonServiceImpl.java` around
lines 238 - 284, In CommonServiceImpl update the logger messages that misspell
"processed" (search for logger.info calls around the processed variable and
bundle handlers: opConsult, diagReport, presp, wellness, immunization,
dischargeSummary) — replace "proceesed" with "processed" in each logger.info
invocation so the log strings read e.g. "The value of opConsult processed: " +
processed, and similarly for diagReport, presp, wellness, immunization, and
dischargeSummary.

pom.xml-226-279 (1)

226-279: ⚠️ Potential issue | 🟡 Minor

Verify HAPI FHIR 8.4.0 compatibility with your codebase.

This is a significant upgrade from version 6.10.0 spanning multiple major versions with documented breaking changes, including Java version bump (JDK 17 required—already met by your configuration), package namespace migration (javax→jakarta in version 7.0.0), and database schema updates.

However, review and complete the jakarta migration: The codebase partially uses jakarta packages (e.g., jakarta.servlet in HTTPRequestInterceptor.java) but retains javax.ws.rs.core.MediaType imports in HttpUtils.java, HTTPRequestInterceptor.java, and PatientDataGatewayController.java. Replace these with Spring's org.springframework.http.MediaType for consistency with Spring Boot 3.2.2 before upgrading to HAPI FHIR 8.4.0.

Also ensure all FHIR-related code (bundle creation, validation, etc.) is compatible with 8.4.0, and if this is a server deployment, plan for database schema migrations using the hapi-fhir-cli migrate-database command.

🤖 Prompt for AI Agents

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

In `@pom.xml` around lines 226 - 279, The project mixes javax and jakarta/spring
imports after bumping HAPI FHIR to 8.4.0; update any javax.ws.rs.core.MediaType
usages to Spring's org.springframework.http.MediaType in HttpUtils.java,
HTTPRequestInterceptor.java, and PatientDataGatewayController.java to align with
Spring Boot 3.2.2 and jakarta migration, then scan for other javax.* usages and
replace with jakarta.* or Spring equivalents as appropriate; after code changes,
run the test suite and review FHIR-related code paths (bundle creation,
validation) for HAPI 8.x API changes and, if deploying a server, run
hapi-fhir-cli migrate-database to update DB schema.

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

51-51: ⚠️ Potential issue | 🟡 Minor

Resource ID prefix doesn't match resource type.

The ID is set as "MedicationRequest-{index}/{uuid}" but the resource being created is a MedicationStatement. This is misleading and could cause confusion when debugging or parsing FHIR bundles.

🐛 Proposed fix

-			ms.setId("MedicationRequest-" + index + "/" + commonService.getUUID()); 
+			ms.setId("MedicationStatement-" + index + "/" + commonService.getUUID()); 

🤖 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`
at line 51, The ID prefix for the created FHIR resource is incorrect: update the
ms.setId call in MedicalHistoryResource (the method constructing the
MedicationStatement instance, where ms.setId("MedicationRequest-" + index + "/"
+ commonService.getUUID()) is used) to use the correct resource type prefix
("MedicationStatement-") so the ID matches the actual resource; ensure the rest
of the formatting (index and UUID from commonService.getUUID()) remains
unchanged and scan for any other places in the class that set IDs with the
"MedicationRequest-" prefix to correct them similarly.

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

57-64: ⚠️ Potential issue | 🟡 Minor

Invalid SNOMED coding with blank code.

Setting setCode(" ") (a single space) is not a valid SNOMED CT code. If the actual SNOMED code is unavailable, it's better to omit the coding entirely and use only the text, or use a data-absent-reason extension.

🐛 Proposed fix - use text-only CodeableConcept

 			CodeableConcept medCC = new CodeableConcept();
-			medCC.addCoding(new Coding()
-					.setSystem("http://snomed.info/sct")
-					.setCode(" ")
-					.setDisplay(med.getCurrentMedication())); // scts code so kept only the name
-
+			// SNOMED code not available - 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 CodeableConcept uses a Coding with
setSystem("http://snomed.info/sct") and setCode(" ") which produces an invalid
SNOMED code; update the creation of medCC (and the anonymous Coding) to avoid
emitting a blank code — either remove the Coding entirely and only set
medCC.setText(med.getCurrentMedication()), or if you must keep a Coding, do not
call setCode with a blank string (leave code unset or null) and optionally add a
DataAbsentReason extension to the MedicationStatement (or the CodeableConcept)
to indicate the code is not available; adjust the code around medCC, new
Coding(), setSystem(...), setCode(...), setDisplay(...), and
ms.setMedication(...) accordingly.

src/main/java/com/wipro/fhir/service/resource_model/PractitionerResource.java-60-65 (1)

60-65: ⚠️ Potential issue | 🟡 Minor

Missing null check after getPractitioner() call.

Unlike OrganizationResource.getOrganizationResource() which validates that orgData != null before proceeding, this method passes the result of getPractitioner() directly to generatePractitionerResource(). If getPractitioner() returns null, this will cause a NullPointerException on Line 65.

🐛 Proposed fix

-		PractitionerDataModel practitionerData = practitionerDataModel.getPractitioner(rsObj.get(0));
-		return generatePractitionerResource(practitionerData);
+		PractitionerDataModel practitionerData = practitionerDataModel.getPractitioner(rsObj.get(0));
+		if (practitionerData == null) {
+			throw new FHIRException("Practitioner data not found");
+		}
+		return generatePractitionerResource(practitionerData);

🤖 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/PractitionerResource.java`
around lines 60 - 65, The code calls practitionerDataModel.getPractitioner(...)
and passes its result straight into generatePractitionerResource(...) without
guarding for null, which can cause an NPE; after calling PractitionerDataModel
practitionerData = practitionerDataModel.getPractitioner(rsObj.get(0)) add a
null check (similar to OrganizationResource.getOrganizationResource()) and throw
a FHIRException with a clear message (e.g., "invalid practitioner data" or
"practitioner not found") or handle accordingly before calling
generatePractitionerResource(practitionerData).

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

17-19: ⚠️ Potential issue | 🟡 Minor

Missing @CrossOrigin annotation.

Per project conventions, all controllers use the @CrossOrigin annotation without parameters for consistency. This controller is missing the annotation. Based on learnings: "all controllers... use the CrossOrigin annotation without parameters to maintain consistency across the codebase."

💡 Suggested fix

+import org.springframework.web.bind.annotation.CrossOrigin;
+
+@CrossOrigin
 `@RestController`
 `@RequestMapping`(value = "/careContext", headers = "Authorization")
 public class CareContextLinkingController {

🤖 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 17 - 19, The CareContextLinkingController class is missing the
`@CrossOrigin` annotation; add `@CrossOrigin` directly above the class declaration
(above `@RestController/`@RequestMapping) on CareContextLinkingController so the
controller uses the project-standard CORS annotation without parameters,
ensuring the class-level annotation is applied to the existing RestController
and RequestMapping declarations.

src/main/java/com/wipro/fhir/data/resource_model/PractitionerDataModel.java-14-16 (1)

14-16: ⚠️ Potential issue | 🟡 Minor

serialVersionUID declared but Serializable not implemented.

The serialVersionUID field is only meaningful when the class implements Serializable. Either remove it or add implements Serializable to the class declaration.

Proposed fix

 `@Data`
 `@Component`
-public class PractitionerDataModel {
-	
-	private static final long serialVersionUID = 1L;
+public class PractitionerDataModel implements java.io.Serializable {
+	
+	private static final long serialVersionUID = 1L;

🤖 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/resource_model/PractitionerDataModel.java`
around lines 14 - 16, The class PractitionerDataModel declares a
serialVersionUID but does not implement Serializable; update the class
declaration for PractitionerDataModel to implement java.io.Serializable (so
serialVersionUID is meaningful) or remove the private static final long
serialVersionUID field—modify the class declaration (PractitionerDataModel)
accordingly and ensure imports include java.io.Serializable if you choose to
implement it.

src/main/java/com/wipro/fhir/service/bundle_creation/ImmunizationRecordResourceBundleImpl.java-189-195 (1)

189-195: ⚠️ Potential issue | 🟡 Minor

Duplicate setCustodian call.

composition.setCustodian(...) is called unconditionally on line 190, then conditionally on lines 193-195. The conditional block is redundant since the same value is set.

Proposed fix - remove duplicate

 	composition.addAuthor(new Reference(practitioner.getIdElement().getValue()));
-	composition.setCustodian(new Reference(organization.getIdElement().getValue()));
 	composition.setTitle("Immunization Record");
 
     if (organization != null) {
         composition.setCustodian(new Reference(organization.getIdElement().getValue()));
     }

Or, if organization can be null, guard the unconditional call instead:

 	composition.addAuthor(new Reference(practitioner.getIdElement().getValue()));
+    if (organization != null) {
+        composition.setCustodian(new Reference(organization.getIdElement().getValue()));
+    }
 	composition.setTitle("Immunization Record");
-
-    if (organization != null) {
-        composition.setCustodian(new Reference(organization.getIdElement().getValue()));
-    }

🤖 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/ImmunizationRecordResourceBundleImpl.java`
around lines 189 - 195, composition.setCustodian(...) is being called twice:
once unconditionally and once again inside an if (organization != null) block;
remove the redundancy by either deleting the conditional block or, if
organization may be null, guard the initial call so composition.setCustodian(new
Reference(organization.getIdElement().getValue())) is only invoked when
organization != null (refer to composition, organization, and setCustodian to
locate the lines).

src/main/java/com/wipro/fhir/service/bundle_creation/DiagnosticRecordResourceBundleImpl.java-83-84 (1)

83-84: ⚠️ Potential issue | 🟡 Minor

TODO placeholder in exception message.

The exception message "TODO - exception - later will implement" is a placeholder that should be replaced with a meaningful error message before production use.

Proposed fix

 		} else
-			throw new FHIRException("TODO - exception - later will implement");
+			throw new FHIRException("Failed to create Diagnostic Report bundle - Mongo document is 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/DiagnosticRecordResourceBundleImpl.java`
around lines 83 - 84, Replace the placeholder exception message in
DiagnosticRecordResourceBundleImpl where it currently throws new
FHIRException("TODO - exception - later will implement") with a clear, specific
message describing the failure condition (include any relevant context such as
the operation being attempted, input identifiers, or state variables available
at that point); update the throw site in DiagnosticRecordResourceBundleImpl (the
branch that currently throws the placeholder) to construct the FHIRException
with that descriptive message and, if available, include the underlying cause or
details (e.g., invalid input id, missing resource, or processing step) to aid
debugging.

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

102-102: ⚠️ Potential issue | 🟡 Minor

Security Coding has swapped code and display values.

The Coding constructor signature is (system, code, display). Here "restricted" is used as the code and "R" as the display, but in ImmunizationRecordResourceBundleImpl and DiagnosticRecordResourceBundleImpl, the values are ("...", "R", "restricted"). This appears to be swapped.

Proposed 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/PrescriptionResourceBundleImpl.java`
at line 102, The meta.addSecurity Coding in PrescriptionResourceBundleImpl is
using swapped code and display values; update the Coding constructor call in the
meta.addSecurity invocation (the new Coding(...) expression) to match the same
ordering used in ImmunizationRecordResourceBundleImpl and
DiagnosticRecordResourceBundleImpl by passing "R" as the code and "restricted"
as the display (i.e., use system, "R", "restricted") so the constructor
signature (system, code, display) is respected.

src/main/java/com/wipro/fhir/service/bundle_creation/DiagnosticRecordResourceBundleImpl.java-129-130 (1)

129-130: ⚠️ Potential issue | 🟡 Minor

Remove unused encounter parameter or implement its usage.

The encounter parameter passed to getDiagnosticReport is never used in the generateDiagnosticReportResource method. Either remove this unused parameter from both the caller and method signature, or implement its intended usage in the DiagnosticReport generation logic.

🤖 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/DiagnosticRecordResourceBundleImpl.java`
around lines 129 - 130, The call to
diagnosticReportResource.getDiagnosticReport(patient, new Encounter(),
resourceRequestHandler, observationMap) passes an Encounter that isn’t used;
either remove the unused encounter parameter from the call site in
DiagnosticRecordResourceBundleImpl and from the getDiagnosticReport method
signature (and from generateDiagnosticReportResource implementation), or update
generateDiagnosticReportResource (and getDiagnosticReport) to actually consume
the Encounter (e.g., use it when building DiagnosticReport resources or to
derive encounter-related references/fields) so the parameter is meaningful;
adjust all callers of getDiagnosticReport (and any related tests) to match the
chosen approach and ensure resourceRequestHandler and observationMap usage
remains intact.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 552e2be0-181c-4120-994e-79d6fc28cef8

📥 Commits

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

📒 Files selected for processing (70)

• .factorypath
• E:/uat_new/wildfly-30.0.0.Final/wildfly-30.0.0.Final/Logs/fhir-api.log.json
• 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/controller/version/VersionController.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/health/HealthService.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/v3/abha/CreateAbhaV3ServiceImpl.java
• src/main/java/com/wipro/fhir/service/resource_gateway/OPConsultRecordBundle.java
• src/main/java/com/wipro/fhir/service/resource_gateway/DiagnosticReportRecord.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_gateway/DiagnosticReportRecordImpl.java
• src/main/java/com/wipro/fhir/service/resource_gateway/OPConsultRecordBundleImpl.java

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify Lombok version consistency between .factorypath and pom.xml
echo "Checking Lombok version in pom.xml:"
rg -n "lombok" pom.xml -A2 -B2 | head -20

echo ""
echo "Checking .factorypath Lombok entry:"
cat .factorypath

Repository: PSMRI/FHIR-API

Length of output: 1775

---

🏁 Script executed:

#!/bin/bash
# Verify Lombok version in pom.xml and .factorypath
echo "=== Checking pom.xml for Lombok version ==="
if [ -f pom.xml ]; then
    rg -n "lombok" pom.xml -A 3 -B 1
else
    echo "pom.xml not found"
fi

echo ""
echo "=== Checking .factorypath for Lombok version ==="
if [ -f .factorypath ]; then
    cat .factorypath
else
    echo ".factorypath not found"
fi

Repository: PSMRI/FHIR-API

Length of output: 1205

---

Update .factorypath Lombok version to match pom.xml.

pom.xml declares Lombok 1.18.36 (line 30: <org.projectlombok.version>1.18.36</org.projectlombok.version>), but .factorypath specifies 1.18.30. Update the .factorypath entry to lombok-1.18.36.jar to prevent annotation processor version mismatches during compilation.

🤖 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 an older Lombok
JAR (lombok-1.18.30.jar) which mismatches the pom.xml's
org.projectlombok.version (1.18.36); update the factorypathentry element's id
attribute to use lombok-1.18.36.jar so the VARJAR id matches the pom version
(look for the factorypathentry line containing kind="VARJAR" and
id="...lombok-1.18.30/...").

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Avoid concrete Elasticsearch credentials and enabled-by-default in example config.

Line 127–129 ships real-looking defaults, and Line 132 enables ES by default. In sample configs, this increases accidental insecure rollout risk.

Suggested change

-elasticsearch.username=elastic
-elasticsearch.password=piramalES
+elasticsearch.username=<Enter Elasticsearch username>
+elasticsearch.password=<Enter Elasticsearch password>
@@
-elasticsearch.enabled=true
+elasticsearch.enabled=false

📝 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

	elasticsearch.username=elastic
	elasticsearch.password=piramalES
	elasticsearch.index.beneficiary=beneficiary_index
	# Enable/Disable ES (for gradual rollout)
	elasticsearch.enabled=true
	elasticsearch.username=<Enter Elasticsearch username>
	elasticsearch.password=<Enter Elasticsearch password>
	elasticsearch.index.beneficiary=beneficiary_index
	# Enable/Disable ES (for gradual rollout)
	elasticsearch.enabled=false

🤖 Prompt for AI Agents

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

In `@src/main/environment/common_example.properties` around lines 127 - 132, The
example properties expose concrete Elasticsearch credentials and enable
Elasticsearch by default; replace the hardcoded values for
elasticsearch.username, elasticsearch.password and any real-looking index names
(e.g., elasticsearch.index.beneficiary) with generic placeholders (like
${ELASTICSEARCH_USERNAME} / ${ELASTICSEARCH_PASSWORD} or <username>/<password>)
and update elasticsearch.enabled to false (or comment it) so ES is disabled by
default in the example; ensure keys remain the same (elasticsearch.username,
elasticsearch.password, elasticsearch.index.beneficiary, elasticsearch.enabled)
but contain placeholder values and a disabled default to prevent accidental
insecure rollouts.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

In Spring MVC CORS (WebMvcConfigurer), does allowedHeaders("*") allow all custom request headers (including different header-name casing) during preflight checks?

💡 Result:

Yes, in Spring MVC CORS configuration via WebMvcConfigurer, setting allowedHeaders("*") allows all custom request headers during preflight checks, regardless of header name casing.

Citations:

• 1: https://docs.spring.vmware.com/spring-framework/reference/web/webmvc-cors.html
• 2: https://docs.spring.io/spring-framework/reference/web/webmvc-cors.html
• 3: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/cors/CorsConfiguration.html
• 4: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/cors/DefaultCorsProcessor.html
• 5: https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/web/cors/DefaultCorsProcessor.java
• 6: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Access-Control-Allow-Headers
• 7: https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/web/cors/CorsConfiguration.java

---

🏁 Script executed:

# First, find the CorsConfig.java file and examine its content
fd CorsConfig.java

Repository: PSMRI/FHIR-API

Length of output: 109

---

🏁 Script executed:

# Check the size and content of CorsConfig.java
if [ -f "src/main/java/com/wipro/fhir/config/CorsConfig.java" ]; then
  wc -l "src/main/java/com/wipro/fhir/config/CorsConfig.java"
  echo "---"
  cat -n "src/main/java/com/wipro/fhir/config/CorsConfig.java"
fi

Repository: PSMRI/FHIR-API

Length of output: 1521

---

🏁 Script executed:

# Also check if there are other CORS-related configurations in the codebase
rg -i "corsconfig|@crossorigin|allowedheaders" --type java -l

Repository: PSMRI/FHIR-API

Length of output: 185

---

Replace hardcoded header list with wildcard to support custom headers required by FHIR integrations.

Lines 23–24 restrict allowed headers to a predefined list, which prevents custom headers and requires code changes when integrations add new headers. FHIR APIs commonly need flexible header support for various healthcare standards and vendor-specific integrations.

Suggested change

-                .allowedHeaders("Authorization", "Content-Type", "Accept", "Jwttoken",
-                        "serverAuthorization", "ServerAuthorization", "serverauthorization", "Serverauthorization")
+                .allowedHeaders("*")

📝 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

	.allowedHeaders("Authorization", "Content-Type", "Accept", "Jwttoken",
	"serverAuthorization", "ServerAuthorization", "serverauthorization", "Serverauthorization")
	.allowedHeaders("*")

🤖 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/CorsConfig.java` around lines 23 - 24, In
CorsConfig update the CORS configuration that currently calls
allowedHeaders("Authorization", "Content-Type", "Accept", "Jwttoken",
"serverAuthorization", "ServerAuthorization", "serverauthorization",
"Serverauthorization") to allow all/custom headers by replacing the hardcoded
header list with a wildcard (e.g., allowedHeaders("*")) so FHIR integrations can
send custom headers; locate this change in the CorsConfig class where
allowedHeaders(...) is invoked and remove the duplicated specific header
entries.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n "src/main/java/com/wipro/fhir/service/bundle_creation/DischargeSummaryResourceBundleImpl.java" | sed -n '130,150p'

Repository: PSMRI/FHIR-API

Length of output: 1171

---

🌐 Web query:

HAPI FHIR Coding constructor parameter order code display

💡 Result:

The HAPI FHIR Coding class provides a convenience constructor that takes three String parameters in the following order: system, code, display. This is documented across multiple FHIR versions in the official HAPI FHIR Javadocs: - For FHIR R4: public Coding(String theSystem, String theCode, String theDisplay) - Convenience constructor. Parameters: theSystem (code system), theCode (code), theDisplay (human readable display). - For DSTU3: Similar constructor shown in source code: public Coding(String theSystem, String theCode, String theDisplay), which internally calls setSystem(theSystem), setCode(theCode), setDisplay(theDisplay). There is also a no-arg constructor public Coding, but the parameterized one matching "code display" in the query is system first, then code, then display. Usage example: Coding coding = new Coding("http://terminology.hl7.org/CodeSystem/v3-ParticipationType", "RCM", "recorder"); Official sources confirm this order consistently. No other constructors taking just code and display were found; system is required for the 3-parameter version.

Citations:

• 1: https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/Coding.html
• 2: https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-structures-dstu3/undefined/src-html/org/hl7/fhir/dstu3/model/Coding.html
• 3: https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-structures-hl7org-dstu2/org/hl7/fhir/dstu2/model/Coding.html

---

🌐 Web query:

HL7 v3-Confidentiality CodeSystem R restricted code display

💡 Result:

The HL7 v3 Confidentiality CodeSystem (OID: 2.16.840.1.113883.5.25, URL: http://terminology.hl7.org/CodeSystem/v3-Confidentiality) includes the code "R" with display name "restricted". This code indicates privacy metadata for highly sensitive, potentially stigmatizing information requiring a restricted level of protection, less protective than "V" (very restricted) but subsuming lower levels like N, M, L, U. It is active and used in Act.confidentialityCode and Role.confidentialityCode.

Citations:

• 1: https://terminology.hl7.org/en/CodeSystem-v3-Confidentiality.html
• 2: https://terminology.hl7.org/CodeSystem-v3-Confidentiality.html
• 3: https://terminology.hl7.org/4.0.0/CodeSystem-v3-Confidentiality.html
• 4: https://terminology.hl7.org/1.0.0/CodeSystem-v3-Confidentiality.html

---

Fix the v3-Confidentiality code/display order in the Meta security coding.

The code currently passes "restricted" as the code and "R" as the display parameter, but the v3-Confidentiality CodeSystem defines "R" as the code with "restricted" as its display. This inverts the semantic meaning in the serialized bundle metadata.

💡 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/DischargeSummaryResourceBundleImpl.java`
around lines 136 - 141, The Meta security Coding is using the wrong code/display
order: when building the Meta for dischargeSummaryBundle you call
meta.addSecurity(new
Coding("http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "restricted",
"R")), which inverts code and display; change the Coding arguments to use "R" as
the code and "restricted" as the display (i.e., construct the Coding with system
"http://terminology.hl7.org/CodeSystem/v3-Confidentiality", code "R", display
"restricted") before calling dischargeSummaryBundle.setMeta(meta).

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Diagnosis data is being emitted as “Physical examination”.

conditionListDiagnosis is passed into the physicalExam slot and then serialized with the physical-exam section title/code. If this section is supposed to be diagnosis, the semantics are wrong; if it is supposed to be physical exam, the wrong resource set is being used.

Also applies to: 188-189, 343-352

🤖 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 159 - 161, The diagnosis list (conditionListDiagnosis) is being
assigned/serialized into the physical exam section — fix by separating the two
concerns: keep conditionListDiagnosis = conditionResource.getCondition(patient,
resourceRequestHandler, "diagnosis") and ensure it is passed into the diagnosis
section/slot (not physicalExam), and create or fetch a distinct physical exam
list (e.g., conditionListPhysicalExam = conditionResource.getCondition(patient,
resourceRequestHandler, "physical-exam") or call the appropriate method) to pass
into the physicalExam slot; update the serialization/section title and code
usage so the diagnosis section uses the diagnosis title/code and the physical
exam section uses the physical-exam title/code (check occurrences around
conditionListDiagnosis usage and the physicalExam variable at lines noted and
also in the block at 343-352) so each section receives the correct resource set.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Thread-safety risk: instance field encounter in singleton @Service.

Similar to MedicationRequestResource, the encounter field is an instance variable reassigned in generateEncounterResource (line 80). Concurrent requests to this singleton bean could cause data corruption.

🔧 Proposed fix

-	private Encounter encounter;

And change line 80 to declare it locally:

Encounter encounter = new Encounter();

🤖 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 instance field `encounter` in the EncounterResource service
introduces a thread-safety risk because it's reassigned in
generateEncounterResource; remove the class-level field declaration `private
Encounter encounter;` from the EncounterResource class and change the usage
inside generateEncounterResource to create a local variable (e.g. declare
`Encounter encounter = new Encounter();`) so each request gets its own instance.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

# First, locate the file and verify it exists
find . -type f -name "CareContextLinkingServiceImpl.java" 2>/dev/null | head -20

Repository: PSMRI/FHIR-API

Length of output: 146

---

🏁 Script executed:

# Read the file to examine RestTemplate usage and timeout configuration
wc -l ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java

Repository: PSMRI/FHIR-API

Length of output: 150

---

🏁 Script executed:

# Read the entire file to inspect RestTemplate usage and timeout configuration
cat -n ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java

Repository: PSMRI/FHIR-API

Length of output: 18215

---

🏁 Script executed:

# Search for RestTemplate bean configuration or HttpClient configuration
find . -type f \( -name "*.java" -o -name "*.xml" -o -name "*.properties" \) 2>/dev/null | head -100 | xargs grep -l "RestTemplate" 2>/dev/null | grep -E "(config|bean|spring)" | head -20

Repository: PSMRI/FHIR-API

Length of output: 40

---

🏁 Script executed:

# Look for any RestTemplate bean definitions with timeout configuration
rg -t java "RestTemplate" --max-count=50 | grep -E "(bean|@Bean|ClientHttpRequestFactory|HttpClient|timeout|Timeout)" 2>/dev/null

Repository: PSMRI/FHIR-API

Length of output: 40

---

🏁 Script executed:

# Check if there's a Spring configuration class that defines RestTemplate with timeouts
fd -t f -e java -x rg -l "Bean.*RestTemplate|RestTemplate.*Bean" {} \; 2>/dev/null | head -20

Repository: PSMRI/FHIR-API

Length of output: 40

---

🏁 Script executed:

# Search for any RestTemplate configuration beans across the codebase
rg -t java "@Bean" -A 3 | grep -B 3 "RestTemplate" 2>/dev/null | head -50

Repository: PSMRI/FHIR-API

Length of output: 40

---

🏁 Script executed:

# Look for application.properties or application.yml for HTTP timeout configuration
find . -type f \( -name "application*.properties" -o -name "application*.yml" \) 2>/dev/null

Repository: PSMRI/FHIR-API

Length of output: 101

---

🏁 Script executed:

# Check if there are any HTTP client factory or timeout configurations
rg -t java "ClientHttpRequestFactory|setConnectTimeout|setReadTimeout|HttpComponentsClientHttpRequestFactory|SimpleClientHttpRequestFactory" 2>/dev/null | head -30

Repository: PSMRI/FHIR-API

Length of output: 172

---

🏁 Script executed:

# Read the application.properties file to check for HTTP timeout settings
cat ./src/main/resources/application.properties | grep -i "timeout\|http"

Repository: PSMRI/FHIR-API

Length of output: 462

---

🏁 Script executed:

# Check if there's a RestTemplate configuration or any HTTP client setup in the codebase
rg -t java "new RestTemplate" -B 5 -A 5 | head -100

Repository: PSMRI/FHIR-API

Length of output: 9943

---

🏁 Script executed:

# Check Spring RestTemplate default timeout behavior and verify HttpClient is not used
rg -t java "HttpClient|setRequestFactory|SimpleClientHttpRequestFactory|HttpComponentsClientHttpRequestFactory" | head -20

Repository: PSMRI/FHIR-API

Length of output: 2254

---

🏁 Script executed:

# Verify the exact lines 143-145 and 290-292 to confirm they use the bare RestTemplate
sed -n '143,145p' ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java
echo "---"
sed -n '290,292p' ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java

Repository: PSMRI/FHIR-API

Length of output: 493

---

Configure timeouts on the RestTemplate instances making external ABDM calls.

Both methods allocate a bare RestTemplate and call the ABDM API on the request thread without connect/read timeouts. This allows slow upstream responses to block servlet threads indefinitely, risking thread pool exhaustion.

Applies to:

• Lines 87–145: generateTokenForCareContext()
• Lines 195–292: linkCareContext()

🤖 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 87 - 88, The RestTemplate instances in
generateTokenForCareContext() and linkCareContext() are created without
timeouts; update both methods to use a RestTemplate configured with connection
and read (socket) timeouts (e.g., via SimpleClientHttpRequestFactory or
HttpComponentsClientHttpRequestFactory) instead of new RestTemplate(), and
replace the local RestTemplate creation (RestTemplate restTemplate = new
RestTemplate()) with a factory-configured RestTemplate (or share a singleton
bean) so external ABDM calls have bounded connect/read timeouts and do not block
servlet threads indefinitely.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Return a single token field from generateTokenForCareContext().

The cache-hit branch emits "linkToken", while the fresh-token branch emits "X-LINK-TOKEN". The response schema changes depending on whether Mongo had a hit.

💡 Suggested fix

-				            responseMap.put("X-LINK-TOKEN", linkToken);
+				            responseMap.put("linkToken", linkToken);

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, The code returns two different keys for the token
depending on cache hit ("linkToken") vs fresh generation ("X-LINK-TOKEN");
update generateTokenForCareContext() so both branches place the token under the
same response key (e.g., always do responseMap.put("linkToken", token)) and
remove or stop using "X-LINK-TOKEN" as the response map key (if you need to set
an HTTP header too, set response.setHeader("X-LINK-TOKEN", token) but keep the
response payload key consistent). Update the places using linkExists,
generatedToken/ token variables, and the fresh-token branch (the block that
currently sets "X-LINK-TOKEN") to use the unified "linkToken" field.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

find . -name "CareContextLinkingServiceImpl.java" -type f

Repository: PSMRI/FHIR-API

Length of output: 146

---

🏁 Script executed:

find . -name "*CareContext*" -type f | head -20

Repository: PSMRI/FHIR-API

Length of output: 1701

---

🏁 Script executed:

sed -n '110,125p' ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java

Repository: PSMRI/FHIR-API

Length of output: 859

---

🏁 Script executed:

wc -l ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java

Repository: PSMRI/FHIR-API

Length of output: 150

---

🏁 Script executed:

rg "abdmFacilityId" ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java -B 3 -A 3

Repository: PSMRI/FHIR-API

Length of output: 821

---

🏁 Script executed:

cat -n ./src/main/java/com/wipro/fhir/controller/v3/careContext/CareContextLinkingController.java | grep -A 20 -B 5 "abdmFacilityId\|careContext"

Repository: PSMRI/FHIR-API

Length of output: 2865

---

🏁 Script executed:

sed -n '1,130p' ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java | head -60

Repository: PSMRI/FHIR-API

Length of output: 2492

---

🏁 Script executed:

sed -n '95,140p' ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java

Repository: PSMRI/FHIR-API

Length of output: 2083

---

🏁 Script executed:

rg "LinkCareContextRequest" ./src/main/java/com/wipro/fhir/data/v3/careContext/LinkCareContextRequest.java

Repository: PSMRI/FHIR-API

Length of output: 95

---

🏁 Script executed:

cat ./src/main/java/com/wipro/fhir/data/v3/careContext/LinkCareContextRequest.java

Repository: PSMRI/FHIR-API

Length of output: 297

---

🏁 Script executed:

rg "isEmpty\|isBlank" ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java

Repository: PSMRI/FHIR-API

Length of output: 40

---

🏁 Script executed:

sed -n '60,95p' ./src/main/java/com/wipro/fhir/service/v3/careContext/CareContextLinkingServiceImpl.java

Repository: PSMRI/FHIR-API

Length of output: 1118

---

🏁 Script executed:

rg "LinkCareContextRequest\|abdmFacilityId" ./src/main/java/com/wipro/fhir/service/v3/careContext/ -A 2 -B 2

Repository: PSMRI/FHIR-API

Length of output: 40

---

🏁 Script executed:

cat ./src/main/java/com/wipro/fhir/data/v3/careContext/CareContextLinkTokenRequest.java

Repository: PSMRI/FHIR-API

Length of output: 338

---

🏁 Script executed:

rg "class.*Request" ./src/main/java/com/wipro/fhir/data/v3/careContext/ -A 5

Repository: PSMRI/FHIR-API

Length of output: 2634

---

Use .isEmpty() or .isBlank() for empty string validation—reference comparison allows empty strings through.

The condition "" != careContextLinkRequest.getAbdmFacilityId() uses reference comparison (identity), not value comparison. An empty string deserialized from JSON creates a new object that won't match the string literal "", so it will pass this check and be sent as an empty X-HIP-ID header to the downstream API. Use .isEmpty() or .isBlank() instead, consistent with the getAbhaNumber() validation on line 123.

💡 Suggested fix

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

🤖 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 - 118, The conditional in CareContextLinkingServiceImpl that
checks careContextLinkRequest.getAbdmFacilityId() uses reference comparison (""
!= ...) which can let an empty string through; change the check to mirror the
getAbhaNumber() validation by using a value-based empty/blank test (e.g.,
Objects.nonNull(careContextLinkRequest.getAbdmFacilityId()) &&
!careContextLinkRequest.getAbdmFacilityId().isBlank()) before calling
headers.add("X-HIP-ID", careContextLinkRequest.getAbdmFacilityId()); otherwise
fall back to headers.add("X-HIP-ID", abdmFacilityId).

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Only return a cached token from checkRecordExisits().

If the stored response is older than three months, or the JSON has no LinkToken, this method falls through to return linkResponse;. The caller treats any non-null value as a valid token, so stale/error JSON can short-circuit fresh token generation.

💡 Suggested fix

 	public String checkRecordExisits(String abhaAddress) {
 		GenerateTokenAbdmResponses result = generateTokenAbdmResponsesRepo.findByAbhaAddress(abhaAddress);
-		logger.info("find by abha address result - ", result);
+		logger.info("find by abha address result - {}", result);
 		String linkResponse = null;
 
 		if (result != null && result.getCreatedDate() != null) {
 			Calendar cal = Calendar.getInstance();
 			cal.add(Calendar.MONTH, -3);
@@
 					try {
 						ObjectMapper mapper = new ObjectMapper();
 						JsonNode root = mapper.readTree(linkResponse);
 						JsonNode linkToken = root.path("LinkToken");
 						if (!linkToken.isNull() && !linkToken.isMissingNode()) {
 							return linkToken.asText();
 						}
 					} catch (Exception e) {
-						logger.info("failed abha exists check with exception - ", e.getMessage());
-						return null;
+						logger.info("failed abha exists check with exception - {}", e.getMessage());
 					}
 				}
 			}
 		}
 
-		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 336 - 365, The method checkRecordExisits currently returns
linkResponse even when the cached response is stale (>3 months) or lacks a
LinkToken; change the logic so you only return a cached token when
result.getCreatedDate() is after threeMonthsAgo and the JSON contains a
non-missing LinkToken; specifically, move/replace the assignment of linkResponse
with parsing the stored result.getResponse() first, extract linkToken
(root.path("LinkToken")) and if it's present return linkToken.asText(),
otherwise return null; ensure any parsing exceptions are caught and cause a null
return (do not fall through to return the raw linkResponse).

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 Security Hotspot
7.6% 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