Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMM-871 Abdm Facility fetch services changes #46

Merged
merged 6 commits into from
Nov 27, 2024

Conversation

helenKaryamsetty
Copy link
Member

@helenKaryamsetty helenKaryamsetty commented Sep 19, 2024

📋 Description

JIRA ID: AMM-871

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

    • Introduced new configuration properties for API endpoints, including abdmFacilityId and updated endpoints to version v0.5.
    • Added new methods in the FacilityService interface for fetching registered facilities and saving facility IDs.
    • Implemented a new FacilityServiceImpl class to handle facility-related operations.
  • Bug Fixes

    • Enhanced error handling and logging in various service methods to improve traceability and prevent potential issues.
  • Refactor

    • Updated data types from Long to BigInteger across multiple classes and repositories to accommodate larger values.
    • Streamlined code by integrating Lombok for automatic method generation, reducing boilerplate.
  • Documentation

    • Updated method signatures and added comments to clarify changes related to new data types and configurations.

Copy link
Contributor

coderabbitai bot commented Sep 19, 2024

Walkthrough

The changes in this pull request primarily involve updates to various properties files and Java classes within the application. Key modifications include the introduction of new configuration properties related to the ABDM facility, updates to API endpoint versions from v1 to v0.5, and the addition of new methods and fields in several service and repository classes. The data types for multiple identifiers have been changed from Long to BigInteger across various models and repositories to enhance data handling capabilities. Additionally, several classes have been added or modified to improve functionality related to facility management and care context operations.

Changes

File Change Summary
src/main/environment/common_ci.properties Updated API endpoints to v0.5, added abdmFacilityId, and introduced getAbdmFacilityServicies.
src/main/environment/common_dev.properties Updated API endpoints to v0.5, added abdmFacilityId, and introduced getAbdmFacilityServicies.
src/main/environment/common_example.properties Updated API endpoints to v0.5, added abdmFacilityId, and introduced getAbdmFacilityServicies.
src/main/environment/common_test.properties Updated API endpoints to v0.5, added abdmFacilityId, and introduced getAbdmFacilityServicies.
src/main/java/com/wipro/fhir/config/BlockingHttpMethodInterceptor.java Class removed.
src/main/java/com/wipro/fhir/controller/carecontext/CareContextController.java Updated generateOTP method to include abdmFacilityId and abdmFacilityName in request body.
src/main/java/com/wipro/fhir/controller/facility/FacilityController.java Added FacilityController class with methods to manage ABDM facilities.
src/main/java/com/wipro/fhir/data/e_aushdhi/T_PatientIssue.java Changed benRegID type from Long to BigInteger, added @Data annotation.
src/main/java/com/wipro/fhir/data/mongo/amrit_resource/AMRIT_ResourceMongo.java Changed multiple field types from Long to BigInteger, added @Data annotation.
src/main/java/com/wipro/fhir/data/mongo/amrit_resource/TempCollection.java Changed beneficiaryRegID and visitCode from Long to BigInteger, added @Data annotation.
src/main/java/com/wipro/fhir/data/mongo/care_context/CareContexts.java Added fields careContextLinkedDate and abdmFacilityId with corresponding getters/setters.
src/main/java/com/wipro/fhir/data/mongo/care_context/GenerateOTPForCareContextAndValidate.java Added fields abdmFacilityName and abdmFacilityId with corresponding getters/setters.
src/main/java/com/wipro/fhir/data/mongo/care_context/PatientCareContexts.java Modified field types and removed unused fields, added @Data annotation.
src/main/java/com/wipro/fhir/data/mongo/care_context/SaveFacilityIdForVisit.java Added SaveFacilityIdForVisit class with facilityId and visitCode fields.
src/main/java/com/wipro/fhir/data/patient/PatientDemographic.java Changed beneficiaryRegID and beneficiaryID from Long to BigInteger.
src/main/java/com/wipro/fhir/data/patient_data_handler/TRG_PatientResourceData.java Changed benRegId and beneficiaryID from Long to BigInteger, added @Data annotation.
src/main/java/com/wipro/fhir/data/request_handler/PatientEligibleForResourceCreation.java Changed multiple fields from Long to BigInteger.
src/main/java/com/wipro/fhir/data/request_handler/ResourceRequestHandler.java Changed multiple fields from Long to BigInteger.
src/main/java/com/wipro/fhir/data/resource_model/AllergyIntoleranceDataModel.java Changed id, beneficiaryRegID, and visitCode from Long to BigInteger.
src/main/java/com/wipro/fhir/data/resource_model/AppointmentDataModel.java Changed id, beneficiaryRegID, and visitCode from Long to BigInteger.
src/main/java/com/wipro/fhir/data/resource_model/ConditionDiagnosisDataModel.java Changed id, beneficiaryRegID, and visitCode from Long to BigInteger.
src/main/java/com/wipro/fhir/data/resource_model/DiagnosticReportDataModel.java Changed id, beneficiaryRegID, and visitCode from Long to BigInteger.
src/main/java/com/wipro/fhir/data/resource_model/EncounterDataModel.java Changed id, beneficiaryRegID, and visitCode from Long to BigInteger.
src/main/java/com/wipro/fhir/data/resource_model/FamilyMemberHistoryDataModel.java Changed id, beneficiaryRegID, and visitCode from Long to BigInteger.
src/main/java/com/wipro/fhir/data/resource_model/LabTestAndComponentModel.java Changed id, beneficiaryRegID, and visitCode from Long to BigInteger.
src/main/java/com/wipro/fhir/data/resource_model/MedicationRequestDataModel.java Changed id, beneficiaryRegID, and visitCode from Long to BigInteger.
src/main/java/com/wipro/fhir/data/resource_model/VitalsAnthropometryModel.java Changed beneficiaryRegID and visitCode from Long to BigInteger.
src/main/java/com/wipro/fhir/repo/common/PatientEligibleForResourceCreationRepo.java Changed method parameters from Long to BigInteger.
src/main/java/com/wipro/fhir/repo/healthID/BenHealthIDMappingRepo.java Changed method parameter from Long to BigInteger, added new methods.
src/main/java/com/wipro/fhir/repo/mongo/amrit_resource/TempCollectionRepo.java Changed method parameters from Long to BigInteger.
src/main/java/com/wipro/fhir/repo/patient_data_handler/TRG_PatientResourceData_Repo.java Changed method parameter from Long to BigInteger.
src/main/java/com/wipro/fhir/service/api_channel/APIChannelImpl.java Updated userDetails map type from Map<String, String> to Map<String, Object>.
src/main/java/com/wipro/fhir/service/care_context/CareContextServiceImpl.java Added field abdmFacilityId for configuration injection.
src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java Added fields for MongoTemplate and BenHealthIDMappingRepo.
src/main/java/com/wipro/fhir/service/facility/FacilityService.java Added FacilityService interface with new methods.
src/main/java/com/wipro/fhir/service/facility/FacilityServiceImpl.java Implemented FacilityService interface with methods to fetch and save facilities.
src/main/java/com/wipro/fhir/service/ndhm/LinkCareContext_NDHMServiceImpl.java Renamed clientID to abdmFacilityId and updated logic.
src/main/java/com/wipro/fhir/service/resource_model/AllergyIntoleranceResource.java Minor formatting change in method call.
src/main/java/com/wipro/fhir/service/resource_model/AppointmentResource.java Added import for BigInteger.
src/main/java/com/wipro/fhir/service/resource_model/ConditionResource.java Added import for BigInteger.
src/main/java/com/wipro/fhir/service/resource_model/DiagnosticReportResource.java Added import for BigInteger.
src/main/java/com/wipro/fhir/service/resource_model/EncounterResource.java Added import for BigInteger.
src/main/java/com/wipro/fhir/service/resource_model/FamilyMemberHistoryResource.java Added import for BigInteger.
src/main/java/com/wipro/fhir/service/resource_model/MedicationRequestResource.java Added import for BigInteger.
src/main/java/com/wipro/fhir/service/resource_model/ObservationResource.java Added import for BigInteger.
src/main/java/com/wipro/fhir/service/resource_model/PatientResource.java Added import for BigInteger.

Poem

In the fields where data hops,
BigInteger now takes the stops.
With facilities bright and new,
Our API dances, fresh as dew.
From v1 to v0.5, we leap,
In code we trust, our changes deep! 🐇✨


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 5e6f9c8 and 4d37ef2.

📒 Files selected for processing (1)
  • src/main/environment/common_ci.properties (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/main/environment/common_ci.properties

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@drtechie drtechie changed the title ANM- 871 Abdm Facility fetch services changes AMM-871 Abdm Facility fetch services changes Sep 23, 2024
Copy link

sonarqubecloud bot commented Oct 8, 2024

Quality Gate Failed Quality Gate failed

Failed conditions
3 Security Hotspots

See analysis details on SonarCloud

@helenKaryamsetty helenKaryamsetty marked this pull request as ready for review October 8, 2024 08:00
@drtechie
Copy link
Member

drtechie commented Nov 4, 2024

@coderabbitai full review

Copy link
Contributor

coderabbitai bot commented Nov 4, 2024

✅ Actions performed

Full review triggered.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indents are all over the place @helenKaryamsetty

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 42

🧹 Outside diff range and nitpick comments (75)
src/main/java/com/wipro/fhir/data/mongo/care_context/SaveFacilityIdForVisit.java (1)

9-12: Add field validation, documentation, and MongoDB mapping.

The fields should have:

  1. Validation constraints to ensure data integrity
  2. Documentation for better understanding
  3. Proper MongoDB field mapping

Apply these improvements:

-	String facilityId;
-	BigInteger visitCode;
+	@Field("facility_id")
+	@NotNull(message = "Facility ID cannot be null")
+	@Size(min = 1, max = 100, message = "Facility ID must be between 1 and 100 characters")
+	private String facilityId;
+
+	@Field("visit_code")
+	@NotNull(message = "Visit code cannot be null")
+	private BigInteger visitCode;

Add these imports:

import org.springframework.data.mongodb.core.mapping.Field;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Size;

Also, consider adding Javadoc comments to describe the purpose of each field:

/**
 * The unique identifier of the ABDM facility.
 */
private String facilityId;

/**
 * The unique code representing the visit/encounter.
 */
private BigInteger visitCode;
src/main/java/com/wipro/fhir/service/facility/FacilityService.java (3)

7-7: Consider adding pagination and filtering parameters.

The method fetchRegisteredFacilities() might return a large dataset. Consider adding parameters for pagination and filtering to improve performance and usability.

-String fetchRegisteredFacilities() throws FHIRException;
+String fetchRegisteredFacilities(int page, int size, Map<String, String> filters) throws FHIRException;

5-11: Consider adding interface documentation.

Adding Javadoc comments would improve code documentation and help other developers understand the purpose and usage of these methods.

+/**
+ * Service interface for managing ABDM facility operations.
+ */
 public interface FacilityService {
+    /**
+     * Fetches all registered facilities from ABDM.
+     *
+     * @return JSON string containing registered facilities
+     * @throws FHIRException if there's an error during facility fetch
+     */
     String fetchRegisteredFacilities() throws FHIRException;

+    /**
+     * Saves or updates ABDM facility ID.
+     *
+     * @param reqObj JSON string containing facility details
+     * @return JSON string containing operation result
+     * @throws FHIRException if there's an error during save operation
+     */
     String saveAbdmFacilityId(String reqObj) throws FHIRException;
 }

1-11: Consider implementing proper error handling with specific exceptions.

The interface currently uses a generic FHIRException. Consider creating specific exceptions for different error scenarios to improve error handling.

Example implementation:

public class FacilityNotFoundException extends FHIRException {
    public FacilityNotFoundException(String message) {
        super(message);
    }
}

public class InvalidFacilityDataException extends FHIRException {
    public InvalidFacilityDataException(String message) {
        super(message);
    }
}

public interface FacilityService {
    String fetchRegisteredFacilities() throws FacilityNotFoundException, FHIRException;
    String saveAbdmFacilityId(String reqObj) throws InvalidFacilityDataException, FHIRException;
}
src/main/java/com/wipro/fhir/data/request_handler/ResourceRequestHandler.java (1)

Line range hint 40-65: Consider adding input validation and security measures.

Since this class handles sensitive patient data and FHIR resources:

  1. Consider adding field validations using Bean Validation annotations (e.g., @NotNull, @Size)
  2. Implement proper sanitization for string fields like healthId, phoneNo
  3. Consider adding audit logging for tracking data access and modifications

Example validation additions:

 @Data
 public class ResourceRequestHandler {
-    private String healthId;
+    @NotNull(message = "Health ID cannot be null")
+    @Pattern(regexp = "^[0-9]{14}$", message = "Invalid Health ID format")
+    private String healthId;

-    private String phoneNo;
+    @Pattern(regexp = "^[0-9]{10}$", message = "Invalid phone number format")
+    private String phoneNo;
src/main/java/com/wipro/fhir/data/mongo/amrit_resource/TempCollection.java (2)

38-38: LGTM! Consider using more specific Lombok annotations.

While @Data is convenient, for MongoDB document models, you might want to consider using a more specific combination of annotations like @Getter, @Setter, and @ToString if you need to customize the equals/hashCode implementation for better performance with large documents.


Line range hint 63-63: Remove duplicate semicolon.

There's a duplicate semicolon at the end of the createDate field declaration.

-	private Date createDate;;
+	private Date createDate;
src/main/java/com/wipro/fhir/data/mongo/care_context/CareContexts.java (4)

34-38: Add JavaDoc documentation for new fields.

The new fields careContextLinkedDate and abdmFacilityId should be documented with JavaDoc comments explaining their purpose, format, and any constraints.

Add documentation like this:

+/**
+ * The date when the care context was linked to ABDM
+ * Format: ISO-8601 date string
+ */
@Expose
private String careContextLinkedDate;

+/**
+ * Unique identifier for the ABDM facility
+ */
@Expose
private String abdmFacilityId;

34-35: Consider using proper date type instead of String for careContextLinkedDate.

Using String for dates can lead to formatting inconsistencies and validation issues. Consider using LocalDateTime or Date with appropriate serialization annotations.

Example implementation:

+import java.time.LocalDateTime;
+import com.google.gson.annotations.JsonAdapter;
+import your.package.LocalDateTimeAdapter;

-private String careContextLinkedDate;
+@JsonAdapter(LocalDateTimeAdapter.class)
+private LocalDateTime careContextLinkedDate;

-public void setCareContextLinkedDate(String careContextLinkedDate) {
-    this.careContextLinkedDate = careContextLinkedDate;
+public void setCareContextLinkedDate(LocalDateTime careContextLinkedDate) {
+    this.careContextLinkedDate = careContextLinkedDate;
}

Also applies to: 60-62


Line range hint 29-31: Fix inconsistent field naming conventions.

The existing fields ReferenceNumber and Display don't follow Java naming conventions (should be camelCase). While the new fields follow proper conventions, this inconsistency makes the code harder to maintain.

Apply this change:

-private String ReferenceNumber;
-private String Display;
+private String referenceNumber;
+private String display;

Remember to update corresponding getters and setters as well.


68-70: Add input validation for abdmFacilityId.

The setter for abdmFacilityId should validate the input to ensure data integrity.

Example implementation:

 public void setAbdmFacilityId(String abdmFacilityId) {
+    if (abdmFacilityId == null || abdmFacilityId.trim().isEmpty()) {
+        throw new IllegalArgumentException("ABDM Facility ID cannot be null or empty");
+    }
     this.abdmFacilityId = abdmFacilityId;
 }
src/main/java/com/wipro/fhir/data/mongo/amrit_resource/AMRIT_ResourceMongo.java (2)

24-24: Consider using more specific Lombok annotations.

While @Data is convenient, it generates all possible boilerplate code which might be more than needed. Consider using a more specific combination like @Getter @Setter @ToString if you don't need equals() and hashCode() methods, or @Value if immutability is desired for this MongoDB document.

Also applies to: 33-33, 36-36


Line range hint 37-70: Consider adding validation, indexing, and versioning.

As this class handles sensitive healthcare data and FHIR resources:

  1. Add field-level validation annotations (e.g., @NotNull for required fields)
  2. Consider adding MongoDB indexes for frequently queried fields
  3. Implement versioning for tracking changes to resources (e.g., using @Version)

Example improvements:

@Document(collection = "AMRIT_Resource")
@CompoundIndex(def = "{'beneficiaryRegID': 1, 'visitCode': 1}", name = "ben_visit_idx")
public class AMRIT_ResourceMongo {
    @Version
    private Long version;
    
    @NotNull(message = "BeneficiaryRegID is required")
    private BigInteger beneficiaryRegID;
    
    @Indexed
    @NotNull(message = "NationalHealthID is required")
    private String nationalHealthID;
    // ... other fields
}
src/main/java/com/wipro/fhir/data/mongo/care_context/GenerateOTPForCareContextAndValidate.java (3)

Line range hint 1-28: Add proper annotations and remove TODO comment

The class appears to be a MongoDB document but lacks necessary annotations. Consider the following improvements:

  1. Remove the inline comment "give common name"
  2. Add @Document annotation
  3. Add field-level validations using annotations like @NotNull for required fields
+ import org.springframework.data.mongodb.core.mapping.Document;
+ import javax.validation.constraints.NotNull;
+
+ @Document(collection = "generateOTPForCareContext")
  public class GenerateOTPForCareContextAndValidate {
-   //give common name
    @NotNull(message = "Authentication mode cannot be null")
    String authenticationMode;

29-30: Improve field declarations with proper access modifiers and documentation

The new ABDM facility fields should follow proper encapsulation and documentation practices:

  1. Use private access modifier
  2. Add field-level validation
  3. Include JavaDoc documentation explaining the purpose of these fields
-	String abdmFacilityName;
-	String abdmFacilityId;
+	/** Name of the ABDM facility */
+	@NotNull(message = "ABDM facility name cannot be null")
+	private String abdmFacilityName;
+
+	/** Unique identifier for the ABDM facility */
+	@NotNull(message = "ABDM facility ID cannot be null")
+	private String abdmFacilityId;

49-60: Enhance getter/setter methods with documentation and validation

The new methods should:

  1. Follow consistent indentation
  2. Include JavaDoc documentation
  3. Add validation in setters
+	/**
+	 * Gets the name of the ABDM facility
+	 * @return the facility name
+	 */
	public String getAbdmFacilityName() {
		return abdmFacilityName;
	}

+	/**
+	 * Sets the name of the ABDM facility
+	 * @param abdmFacilityName the facility name to set
+	 * @throws IllegalArgumentException if abdmFacilityName is null or empty
+	 */
	public void setAbdmFacilityName(String abdmFacilityName) {
+		if (abdmFacilityName == null || abdmFacilityName.trim().isEmpty()) {
+			throw new IllegalArgumentException("ABDM facility name cannot be null or empty");
+		}
		this.abdmFacilityName = abdmFacilityName;
	}

+	/**
+	 * Gets the ID of the ABDM facility
+	 * @return the facility ID
+	 */
	public String getAbdmFacilityId() {
		return abdmFacilityId;
	}

+	/**
+	 * Sets the ID of the ABDM facility
+	 * @param abdmFacilityId the facility ID to set
+	 * @throws IllegalArgumentException if abdmFacilityId is null or empty
+	 */
	public void setAbdmFacilityId(String abdmFacilityId) {
+		if (abdmFacilityId == null || abdmFacilityId.trim().isEmpty()) {
+			throw new IllegalArgumentException("ABDM facility ID cannot be null or empty");
+		}
		this.abdmFacilityId = abdmFacilityId;
	}
src/main/java/com/wipro/fhir/data/request_handler/PatientEligibleForResourceCreation.java (1)

39-39: Consider using more specific Lombok annotations instead of @DaTa.

For JPA entities, using @Data can sometimes lead to performance issues due to the generated toString() method potentially triggering lazy loading. Consider using a more specific combination of Lombok annotations:

-@Data
+@Getter
+@Setter
+@EqualsAndHashCode(onlyExplicitlyIncluded = true)

This combination provides better control over the generated methods while avoiding potential JPA-related issues.

src/main/java/com/wipro/fhir/data/mongo/care_context/PatientCareContexts.java (1)

32-35: Consider using more specific Lombok annotations.

While @DaTa is convenient, it generates more code than might be needed (toString, equals, hashCode, etc.). Consider using a more specific combination like @Getter @Setter, unless you need the full functionality of @DaTa.

-import lombok.Data;
+import lombok.Getter;
+import lombok.Setter;

 @Document(collection = "PatientCareContexts")
-@Data
+@Getter
+@Setter
src/main/java/com/wipro/fhir/data/patient_data_handler/TRG_PatientResourceData.java (1)

Line range hint 51-74: Consider adding validation constraints.

The entity fields lack validation constraints. Consider adding:

  1. @NotNull for mandatory fields
  2. @Size or custom validators for string fields
  3. Documentation comments explaining the business purpose of each field

Example enhancement:

 @Expose
 @Column(name = "BenRegId")
+@NotNull(message = "Beneficiary registration ID is required")
+// Unique identifier for beneficiary registration
 private BigInteger benRegId;
src/main/java/com/wipro/fhir/controller/facility/FacilityController.java (2)

12-13: Remove unused import and consolidate CORS configuration.

The RequestParam import is not used in the code. Also, the @CrossOrigin annotation is duplicated at both class and method levels.

Apply this diff:

-import org.springframework.web.bind.annotation.RequestParam;

Consider consolidating CORS configuration at the class level only, unless specific methods need different CORS settings.

Also applies to: 23-25


1-78: Consider implementing these architectural improvements:

  1. Create proper request/response DTOs:

    • FacilityRequest for POST endpoint input
    • FacilityResponse for standardized API responses
    • FacilityDTO for service layer data transfer
  2. Implement a global error handling mechanism:

    • Use @ControllerAdvice for consistent error responses
    • Define specific error codes and messages
    • Create custom exceptions for different error scenarios
  3. Add input validation:

    • Use Bean Validation (@Valid) for request DTOs
    • Implement custom validators if needed
  4. Consider API versioning:

    • Add version to URL path (e.g., /v1/facility)
    • Use appropriate versioning strategy (URL, header, or content negotiation)

Would you like me to provide example implementations for any of these improvements?

src/main/java/com/wipro/fhir/data/resource_model/AppointmentDataModel.java (1)

45-47: Good choice upgrading to BigInteger for healthcare identifiers!

The transition from Long to BigInteger for id, beneficiaryRegID, and visitCode is a positive architectural decision. This change:

  • Ensures compatibility with large healthcare identifier ranges
  • Prevents potential overflow issues
  • Aligns with FHIR best practices for handling medical record identifiers

Consider documenting the maximum expected sizes for these identifiers in the class-level documentation to help future maintainers understand the rationale for using BigInteger.

src/main/java/com/wipro/fhir/data/resource_model/AllergyIntoleranceDataModel.java (1)

47-49: LGTM! Consider adding validation annotations.

The migration from Long to BigInteger for identifiers is a good choice for healthcare systems. This change improves the system's ability to handle large identifier values without overflow risks.

Consider adding validation annotations to ensure these critical identifiers are never null:

+import javax.validation.constraints.NotNull;

 @Data
 @Component
 public class AllergyIntoleranceDataModel implements Serializable {
+    @NotNull(message = "ID cannot be null")
     private BigInteger id;
+    @NotNull(message = "Beneficiary registration ID cannot be null")
     private BigInteger beneficiaryRegID;
+    @NotNull(message = "Visit code cannot be null")
     private BigInteger visitCode;
src/main/java/com/wipro/fhir/data/e_aushdhi/T_PatientIssue.java (1)

44-44: Consider implications of Lombok @DaTa on JPA entity.

While @DaTa simplifies boilerplate, be aware that it generates equals/hashCode methods which could impact JPA entity behavior. Consider using more specific Lombok annotations:

  • @Getter/@Setter for basic accessors
  • @tostring(exclude = {"large_fields"}) to prevent performance issues
  • @EqualsAndHashCode(of = "patientIssueID") for proper entity identity
-@Data
+@Getter
+@Setter
+@ToString
+@EqualsAndHashCode(of = "patientIssueID")
src/main/java/com/wipro/fhir/data/resource_model/VitalsAnthropometryModel.java (1)

Line range hint 64-90: Consider refactoring repetitive null checks.

The constructor contains numerous repetitive null checks. Consider using a utility method to make the code more maintainable and reduce duplication.

Consider creating a utility method:

private <T> T safeGet(Object value, Class<T> type) {
    return value != null ? type.cast(value) : null;
}

// For BigInteger conversion specifically:
private BigInteger toBigInteger(Object value) {
    return value != null ? BigInteger.valueOf((long) value) : null;
}

Then use it in the constructor:

this.beneficiaryRegID = toBigInteger(objArr[0]);
this.providerServiceMapID = safeGet(objArr[1], Integer.class);
this.visitCode = toBigInteger(objArr[2]);
this.Temperature = safeGet(objArr[3], BigDecimal.class);
// ... and so on
src/main/java/com/wipro/fhir/repo/healthID/BenHealthIDMappingRepo.java (2)

71-72: Consider using a DTO projection instead of Object[]

While the query is functional, using Object[] makes the code less type-safe and harder to maintain. Consider creating a dedicated DTO or interface-based projection for better type safety and clarity.

Example improvement:

interface FacilityLinkDetails {
    String getAbdmFacilityID();
    LocalDateTime getCarecontextLinkDate();
}

@Query(value = "SELECT AbdmFacilityID, CarecontextLinkDate FROM db_iemr.t_benvisitdetail WHERE VisitCode = :visitCode", nativeQuery = true)
FacilityLinkDetails getAbdmFacilityAndlinkedDate(@Param("visitCode") BigInteger visitCode);

74-77: Add parameter validation and document return value

The update method looks correct but could benefit from:

  1. Input validation for abdmFacilityId (e.g., @NotNull, @SiZe constraints)
  2. Javadoc explaining the return value meaning (number of affected rows)

Example improvement:

/**
 * Updates the ABDM Facility ID for a given visit.
 *
 * @param visitCode The visit code to update
 * @param abdmFacilityId The new ABDM facility ID
 * @return The number of rows affected (should be 1 if successful, 0 if no matching visit found)
 */
@Transactional
@Modifying
@Query(value = "UPDATE db_iemr.t_benvisitdetail SET AbdmFacilityID = :abdmFacilityId WHERE VisitCode = :visitCode", nativeQuery = true)
Integer updateFacilityIdForVisit(@Param("visitCode") BigInteger visitCode, @Param("abdmFacilityId") @NotNull @Size(max=50) String abdmFacilityId);
src/main/java/com/wipro/fhir/service/resource_model/AppointmentResource.java (3)

Line range hint 71-72: Consider adding parameter validation.

The callAppointmentSP method directly passes beneficiaryRegID and visitCode to the repository without validation.

Consider adding null checks and validation before making the repository call:

 public Appointment getAppointmentResource(ResourceRequestHandler resourceRequestHandler,
     Practitioner practitioner) {
+    if (resourceRequestHandler == null) {
+        throw new IllegalArgumentException("ResourceRequestHandler cannot be null");
+    }
+    if (resourceRequestHandler.getBeneficiaryRegID() == null) {
+        throw new IllegalArgumentException("BeneficiaryRegID cannot be null");
+    }
+    if (resourceRequestHandler.getVisitCode() == null) {
+        throw new IllegalArgumentException("VisitCode cannot be null");
+    }
     List<Object[]> rsObjList = patientEligibleForResourceCreationRepo

Line range hint 89-116: Consider using an enum for appointment status mapping.

The status mapping in the switch statement could be more maintainable using an enum.

Consider creating an enum for appointment status:

public enum AppointmentStatusMapping {
    A(AppointmentStatus.ARRIVED),
    C(AppointmentStatus.CANCELLED),
    D(AppointmentStatus.FULFILLED),
    N(AppointmentStatus.BOOKED);

    private final AppointmentStatus fhirStatus;

    AppointmentStatusMapping(AppointmentStatus fhirStatus) {
        this.fhirStatus = fhirStatus;
    }

    public static AppointmentStatus getFhirStatus(String status) {
        try {
            return valueOf(status).fhirStatus;
        } catch (IllegalArgumentException e) {
            return AppointmentStatus.PROPOSED;
        }
    }
}

Then simplify the switch statement:

-        switch (status) {
-        case "A":
-            appointment.setStatus(AppointmentStatus.ARRIVED);
-            break;
-        case "C":
-            appointment.setStatus(AppointmentStatus.CANCELLED);
-            break;
-        case "D":
-            appointment.setStatus(AppointmentStatus.FULFILLED);
-            break;
-        case "N":
-            appointment.setStatus(AppointmentStatus.BOOKED);
-            break;
-        default:
-            appointment.setStatus(AppointmentStatus.PROPOSED);
-        }
+        appointment.setStatus(AppointmentStatusMapping.getFhirStatus(status));

Line range hint 118-118: Remove hardcoded description.

The description "Pirama Test Desc" appears to be a test value that shouldn't be in production code.

Consider:

  1. Removing the hardcoded value
  2. Getting the description from the appointment data model
  3. Or removing the description setting if it's not needed
-        appointment.setDescription("Pirama Test Desc");
+        if (appointmentList.size() > 0 && appointmentList.get(0).getDescription() != null) {
+            appointment.setDescription(appointmentList.get(0).getDescription());
+        }
src/main/environment/common_ci.properties (2)

39-41: Fix spacing in property assignment.

There's an extra space after the equals sign in the abdmFacilityId property. This is inconsistent with other properties in the file.

-abdmFacilityId= @env.ABDM_FACILITY_ID@
+[email protected]_FACILITY_ID@

84-87: Add section comments for better organization.

Consider adding descriptive comments to group related properties and document their purpose, similar to the existing "##ABHA Card API" section. This would improve maintainability and help other developers understand the configuration better.

+## ABDM Facility Configuration
 [email protected]_FACILITY_ID@
 
+## ABDM Gateway API Endpoints
 [email protected]_BASE_URL@/gateway/v0.5/sessions
...
+## ABDM Facility Services API
 [email protected]_BASE_URL@/gateway/v0.5/bridges/getServices
src/main/environment/common_example.properties (2)

40-41: Improve property documentation and format.

The new ABDM Facility ID property needs better documentation and consistent formatting:

  1. Remove the space after the equals sign
  2. Add a comment describing the expected format/length of the ID
 ##Default ABDM Facility ID
-abdmFacilityId= <Enter ABDM Facility ID>
+# Format: Numeric ID assigned by ABDM (e.g., 12345678)
+abdmFacilityId=<Enter ABDM Facility ID>

86-87: Maintain consistent section spacing.

Remove extra empty lines to maintain consistent spacing between sections throughout the file.

 getAbdmFacilityServicies= https://dev.abdm.gov.in/devservice/v1/bridges/getServices
-
-
+
 abhaMode=sbx
src/main/environment/common_dev.properties (3)

40-41: Add validation instructions for ABDM Facility ID.

The placeholder format should be more descriptive and include validation requirements for the ABDM Facility ID.

-abdmFacilityId= <Enter ABDM Facility ID>
+# ABDM Facility ID (required)
+# Format: Valid ABDM-issued facility identifier
+# Example: FACILITYID123456
+abdmFacilityId=

60-62: Consider parameterizing the environment URL.

The endpoints are hardcoded to the dev environment. Consider extracting the base URL to a configurable property for easier environment switching.

+# ABDM Gateway base URL
+abdm.gateway.baseUrl=https://dev.abdm.gov.in/gateway
-generateOTPForCareContext=https://dev.abdm.gov.in/gateway/v0.5/users/auth/init
-addCareContext = https://dev.abdm.gov.in/gateway/v0.5/links/link/add-contexts
-validateOTPForCareContext=https://dev.abdm.gov.in/gateway/v0.5/users/auth/confirm
+generateOTPForCareContext=${abdm.gateway.baseUrl}/v0.5/users/auth/init
+addCareContext=${abdm.gateway.baseUrl}/v0.5/links/link/add-contexts
+validateOTPForCareContext=${abdm.gateway.baseUrl}/v0.5/users/auth/confirm

84-87: Improve properties file organization.

Consider:

  1. Grouping related properties under clear section headers
  2. Adding descriptive comments for each section
  3. Removing extra blank lines
+# ABDM Facility Configuration
+# ------------------------
 ##ABDM Facility services
 getAbdmFacilityServicies= https://dev.abdm.gov.in/devservice/v1/bridges/getServices
-
-
src/main/environment/common_test.properties (2)

40-41: Add documentation for ABDM Facility ID requirements.

The new configuration property lacks documentation about the expected format, validation rules, and where to obtain this ID. This information is crucial for proper configuration across different environments.

Consider adding comments like:

##Default ABDM Facility ID
+ # Format: Valid ABDM Facility ID (e.g., IN0410000183)
+ # Required: Yes
+ # Source: ABDM Facility Registry
abdmFacilityId=<Enter ABDM Facility ID>

86-87: Remove extra empty lines.

Multiple consecutive empty lines can be reduced to one for better readability.

getAbdmFacilityServices=https://dev.abdm.gov.in/devservice/v0.5/bridges/getServices

-

abhaMode=sbx
src/main/java/com/wipro/fhir/service/api_channel/APIChannelImpl.java (3)

Line range hint 89-116: Add proper error handling for logout scenarios

The addition of doLogout flag requires proper error handling for logout failures. Currently, the method doesn't distinguish between login and logout responses.

 if (response != null && response.getStatusCodeValue() == 200) {
     responseBody = response.getBody();
+    if (responseBody == null) {
+        throw new FHIRException("Authentication response body is null");
+    }
     UserAuthAPIResponse psr = (InputMapper.gson().fromJson(responseBody, UserAuthAPIResponse.class));
-    if (psr != null) {
-        if (psr.getData().getIsAuthenticated() && psr.getData().getStatus().equalsIgnoreCase("Active"))
-            authKey = psr.getData().getKey();
+    if (psr == null || psr.getData() == null) {
+        throw new FHIRException("Invalid authentication response format");
+    }
+    if (userDetails.get("doLogout") == Boolean.TRUE) {
+        if (!psr.getData().getStatus().equalsIgnoreCase("Logged Out")) {
+            throw new FHIRException("Logout operation failed");
+        }
+        return null;
+    }
+    if (psr.getData().getIsAuthenticated() && psr.getData().getStatus().equalsIgnoreCase("Active")) {
+        authKey = psr.getData().getKey();
     }
 }

Line range hint 89-116: Add method documentation for the authentication changes

The method lacks documentation about the new logout functionality and its return values.

+/**
+ * Authenticates user or performs logout operation based on the provided credentials
+ * @return Authentication key if login successful, null if logout successful
+ * @throws FHIRException if authentication fails or response is invalid
+ */
 @Override
 public String userAuthentication() throws FHIRException {

89-95: Review credential handling security

Consider implementing the following security improvements:

  1. Clear sensitive data from the map after use
  2. Use a secure string handling mechanism for credentials
  3. Add request rate limiting to prevent brute force attacks
src/main/java/com/wipro/fhir/service/resource_model/DiagnosticReportResource.java (1)

24-24: Remove unused import.

The BigInteger import is not used in this class. While this import might have been added in preparation for future changes, it should be removed until actually needed.

-import java.math.BigInteger;
src/main/java/com/wipro/fhir/controller/carecontext/CareContextController.java (3)

Line range hint 102-111: Empty try block needs implementation.

The saveCareContextToMongo method contains an empty try block, which suggests incomplete implementation. This could lead to silent failures as exceptions are caught but the main functionality is missing.

Would you like me to help implement this method based on the method name and parameters?


Line range hint 56-58: Sensitive data exposure in logs.

The current logging statements include the full request and response objects, which may contain sensitive health information (PHI). Consider masking sensitive fields before logging.

Apply this pattern for safer logging:

-logger.info("NDHM_FHIR Generate Mobile OTP for care context API request" + request);
+logger.info("NDHM_FHIR Generate Mobile OTP for care context API request received");
+logger.debug("Request details: {}", maskSensitiveData(request));

Also applies to: 71-71, 84-86


Line range hint 55-71: Consider extracting common response handling.

The response creation and error handling pattern is duplicated across all methods. Consider extracting this into a common handler using Spring's @ControllerAdvice or a utility method.

Example refactor:

@ControllerAdvice
public class CareContextExceptionHandler {
    @ExceptionHandler(FHIRException.class)
    public ResponseEntity<OutputResponse> handleFHIRException(FHIRException ex) {
        OutputResponse response = new OutputResponse();
        response.setError(5000, ex.getMessage());
        logger.error(ex.getMessage());
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(response);
    }
}

Also applies to: 84-86, 102-111

src/main/java/com/wipro/fhir/service/resource_model/PatientResource.java (1)

Line range hint 24-200: Consider updating numeric ID fields to BigInteger.

Based on the codebase changes mentioned in the summary, consider updating the following potential fields to use BigInteger:

  • beneficiaryRegID in method parameters
  • beneficiaryID in the patient demographic data
  • genderID in the patient demographic data
src/main/java/com/wipro/fhir/service/care_context/CareContextServiceImpl.java (3)

27-27: Add validation and documentation for the new facility ID field.

The newly added abdmFacilityId field is currently not utilized in any methods. Consider:

  1. Adding JSDoc documentation explaining the purpose and format of this field
  2. Adding validation to ensure the injected value is not null or empty during application startup
+/** ABDM Facility ID used for care context operations. Format: String UUID */
 @Value("${abdmFacilityId}")
+@javax.validation.constraints.NotBlank(message = "ABDM Facility ID must not be blank")
 private String abdmFacilityId;

Also applies to: 49-51


Line range hint 89-106: Enhance error handling and logging for better traceability.

Consider the following improvements for the updateHealthIDWithVisit method:

  1. Use more specific exceptions instead of generic FHIRException
  2. Add input validation for the JSON request
  3. Enhance logging with structured log messages including correlation IDs

Example improvement:

private void validateRequest(JsonObject request) throws InvalidRequestException {
    String[] requiredFields = {"healthID", "healthIdNumber", "visitCode"};
    for (String field : requiredFields) {
        if (!request.has(field)) {
            logger.error("Missing required field: {}", field);
            throw new InvalidRequestException("Missing required field: " + field);
        }
    }
}

Line range hint 58-69: Add security measures for OTP and health data handling.

Consider implementing the following security measures:

  1. Add rate limiting for OTP generation to prevent abuse
  2. Implement audit logging for compliance tracking
  3. Add input sanitization for health IDs

Example implementation:

@RateLimiter(name = "otpRateLimiter")
public String generateOTPForCareContext(String request) throws FHIRException {
    try {
        auditLogger.log(AuditEvent.OTP_GENERATION, request);
        sanitizeHealthID(request);
        return linkCareContext_NDHMService.generateOTPForCareContext(request);
    } catch (Exception e) {
        auditLogger.logError(AuditEvent.OTP_GENERATION_FAILED, e);
        throw new FHIRException(e.getMessage());
    }
}
src/main/java/com/wipro/fhir/service/resource_model/FamilyMemberHistoryResource.java (1)

24-24: Remove unused import.

The BigInteger import appears to be unused in this class. While this import might be intended for future use, it's currently not utilized in any of the class methods or fields.

-import java.math.BigInteger;
src/main/java/com/wipro/fhir/repo/common/PatientEligibleForResourceCreationRepo.java (1)

54-117: Consider enhancing SP documentation.

The code has basic comments identifying resource types, but could benefit from more detailed documentation about:

  • Expected parameter ranges
  • Return value formats
  • Error handling behavior

Add Javadoc comments for each SP call method, for example:

/**
 * Calls the FHIR_R_AllergyIntolerance stored procedure to retrieve allergy information.
 * 
 * @param beneficiaryRegID_IN The beneficiary registration ID
 * @param visitCode_IN The visit code
 * @return List of Object arrays containing allergy data in the order:
 *         [allergyCode, allergyType, category, criticality, ...]
 * @throws SQLException if database access error occurs
 */
List<Object[]> callAllergySP(@Param("beneficiaryRegID_IN") BigInteger beneficiaryRegID_IN,
        @Param("visitCode_IN") BigInteger visitCode_IN);
src/main/java/com/wipro/fhir/service/resource_model/EncounterResource.java (1)

Line range hint 108-143: Consider refactoring the encounter status determination logic.

The current implementation uses nested if-else conditions and a switch statement, making it harder to maintain and understand. Consider extracting this logic into a separate method and using a more declarative approach.

Here's a suggested refactoring:

- // use nurse, doctor, specialist and pharma etc flag for annotation
- Integer nurseFlag = encounterList.get(0).getNurseFlag();
- Integer docFlag = encounterList.get(0).getDocFlag();
- Integer specialistFlag = encounterList.get(0).getSpecialistFlag();
-
- String status = "";
- if (specialistFlag != null && specialistFlag != 0) {
-   if (specialistFlag == 1)
-     status = "P";
-   else if (specialistFlag == 3 || specialistFlag == 2)
-     status = "IP";
-   else if (specialistFlag == 9)
-     status = "F";
- } else if (docFlag != null && docFlag != 0) {
-   if (docFlag == 1)
-     status = "P";
-   else if (docFlag == 2 || docFlag == 3)
-     status = "IP";
-   else if (docFlag == 9)
-     status = "F";
- } else if (nurseFlag != null && nurseFlag != 0) {
-   if (nurseFlag == 1)
-     status = "P";
-   else if (nurseFlag == 2 || nurseFlag == 3 || nurseFlag == 9)
-     status = "IP";
- }
- switch (status) {
- case "P":
-   encounter.setStatus(EncounterStatus.PLANNED);
-   break;
- case "IP":
-   encounter.setStatus(EncounterStatus.INPROGRESS);
-   break;
- case "F":
-   encounter.setStatus(EncounterStatus.FINISHED);
-   break;
- default:
-   encounter.setStatus(EncounterStatus.UNKNOWN);
- }
+ encounter.setStatus(determineEncounterStatus(encounterList.get(0)));

+ private EncounterStatus determineEncounterStatus(EncounterDataModel encounter) {
+     Integer specialistFlag = encounter.getSpecialistFlag();
+     Integer docFlag = encounter.getDocFlag();
+     Integer nurseFlag = encounter.getNurseFlag();
+
+     // Check specialist status first
+     if (specialistFlag != null && specialistFlag != 0) {
+         return mapFlagToStatus(specialistFlag);
+     }
+     
+     // Then check doctor status
+     if (docFlag != null && docFlag != 0) {
+         return mapFlagToStatus(docFlag);
+     }
+     
+     // Finally check nurse status
+     if (nurseFlag != null && nurseFlag != 0) {
+         return nurseFlag == 1 ? EncounterStatus.PLANNED : EncounterStatus.INPROGRESS;
+     }
+     
+     return EncounterStatus.UNKNOWN;
+ }
+
+ private EncounterStatus mapFlagToStatus(int flag) {
+     switch (flag) {
+         case 1: return EncounterStatus.PLANNED;
+         case 2:
+         case 3: return EncounterStatus.INPROGRESS;
+         case 9: return EncounterStatus.FINISHED;
+         default: return EncounterStatus.UNKNOWN;
+     }
+ }

This refactoring:

  1. Extracts status determination into a separate method
  2. Makes the priority order (specialist > doctor > nurse) more explicit
  3. Reduces code duplication in status mapping
  4. Improves maintainability and testability
src/main/java/com/wipro/fhir/service/resource_model/ConditionResource.java (2)

Line range hint 152-211: Consider refactoring duplicate code in condition generation methods.

The methods generateConditionResource_ChiefComplaints and generateConditionResource_EncounterDiagnosis share significant code duplication. Consider extracting common logic into a private helper method.

Here's a suggested refactor:

private Condition createBaseCondition(Patient patient, Date createdDate) {
    Condition condition = new Condition();
    condition.setId("Condition/" + commonService.getUUID());
    condition.setRecordedDate(new Time(createdDate.getTime()));
    
    // Set clinical status
    CodeableConcept ccClinicalStatus = new CodeableConcept();
    Coding cClinicalStatus = new Coding();
    cClinicalStatus.setSystem("http://terminology.hl7.org/CodeSystem/condition-clinical");
    cClinicalStatus.setCode("active");
    cClinicalStatus.setDisplay("Active");
    ccClinicalStatus.addCoding(cClinicalStatus);
    condition.setClinicalStatus(ccClinicalStatus);
    
    // Set patient reference
    condition.setSubject(new Reference(patient.getIdElement().getValue()));
    
    return condition;
}

private void setCategory(Condition condition, String code, String display) {
    CodeableConcept ccCategory = new CodeableConcept();
    Coding cCategory = new Coding();
    cCategory.setSystem("http://terminology.hl7.org/CodeSystem/condition-category");
    cCategory.setCode(code);
    cCategory.setDisplay(display);
    ccCategory.addCoding(cCategory);
    ccCategory.setText(display);
    List<CodeableConcept> ccCategoryList = new ArrayList<>();
    ccCategoryList.add(ccCategory);
    condition.setCategory(ccCategoryList);
}

Also applies to: 213-272


Line range hint 1-272: Consider extracting FHIR terminology system URLs into constants.

The code contains several hardcoded FHIR terminology system URLs. These should be extracted into constants for better maintainability and to avoid typos.

Add these constants at the class level:

private static final String SNOMED_SYSTEM = "http://snomed.info/sct";
private static final String CONDITION_CLINICAL_SYSTEM = "http://terminology.hl7.org/CodeSystem/condition-clinical";
private static final String CONDITION_CATEGORY_SYSTEM = "http://terminology.hl7.org/CodeSystem/condition-category";
src/main/java/com/wipro/fhir/service/resource_model/ObservationResource.java (2)

Line range hint 142-277: Consider refactoring vital signs mapping for better maintainability.

The vital signs mapping in generateObservationResourceVitals contains repetitive code blocks. Consider these improvements:

  1. Extract common code into a helper method
  2. Create constants for observation codes
  3. Add null checks and error handling

Here's a suggested refactor for one vital sign (others would follow the same pattern):

+ private static final class VitalSignConfig {
+     final String code;
+     final String unit;
+     VitalSignConfig(String code, String unit) {
+         this.code = code;
+         this.unit = unit;
+     }
+ }

+ private static final Map<String, VitalSignConfig> VITAL_CONFIGS = Map.of(
+     "temperature", new VitalSignConfig("Body temperature", "[degF]"),
+     "pulseRate", new VitalSignConfig("Pulse Rate", "/ min")
+     // ... other vital signs
+ );

+ private Observation createVitalSignObservation(
+     VitalsAnthropometryModel vital,
+     String vitalKey,
+     Object value) {
+     
+     if (value == null) {
+         return null;
+     }
+     
+     VitalSignConfig config = VITAL_CONFIGS.get(vitalKey);
+     Observation observation = getObservationTemp(new Observation(), vital);
+     
+     CodeableConcept ccVital = new CodeableConcept();
+     ccVital.setText(config.code);
+     observation.setCode(ccVital);
+     
+     StringType st = new StringType();
+     st.setId("valueString");
+     st.setValue(value + " " + config.unit);
+     observation.setValue(st);
+     
+     return observation;
+ }

  private List<Observation> generateObservationResourceVitals(Patient patient,
      List<VitalsAnthropometryModel> vitalsAndAnthroList) {
      List<Observation> observationList = new ArrayList<>();
      if (vitalsAndAnthroList.isEmpty()) {
          return observationList;
      }
      
      VitalsAnthropometryModel vital = vitalsAndAnthroList.get(0);
      if (vital == null) {
          return observationList;
      }
      
-     if (vital.getTemperature() != null) {
-         observation = new Observation();
-         observation = getObservationTemp(observation, vital);
-         
-         ccVital = new CodeableConcept();
-         ccVital.setText("Body temperature");
-         observation.setCode(ccVital);
-         
-         StringType st = new StringType();
-         st.setId("valueString");
-         st.setValue(vital.getTemperature() + " [degF]");
-         
-         observation.setValue(st);
-         observationList.add(observation);
-     }
+     Observation tempObs = createVitalSignObservation(
+         vital, "temperature", vital.getTemperature());
+     if (tempObs != null) {
+         observationList.add(tempObs);
+     }
      // ... similar refactoring for other vital signs

Line range hint 279-351: Enhance error handling and performance in lab results processing.

The generateObservationResourceLabComponent method could benefit from improved error handling and performance optimizations:

  1. Add input validation
  2. Use StringBuilder instead of StringBuffer (thread safety not needed here)
  3. Add null checks for critical objects

Here's a suggested improvement:

  private Map<Integer, List<Observation>> generateObservationResourceLabComponent(
      Patient patient, List<LabTestAndComponentModel> observationList) {
+     if (patient == null || observationList == null) {
+         throw new IllegalArgumentException("Patient and observation list must not be null");
+     }
      
      Map<Integer, List<Observation>> resourceMapTestWise = new HashMap<>();
      
      for (LabTestAndComponentModel o : observationList) {
+         if (o == null) {
+             continue;
+         }
          
-         sb = new StringBuffer();
+         StringBuilder sb = new StringBuilder();
          
          observation = new Observation();
          String UUID = commonService.getUUID();
          observation.setId("Observation/" + UUID);
          // ... rest of the method
          
-         if (o.getTestResultValue() != null)
-             sb.append(o.getTestResultValue());
-         if (o.getTestResultUnit() != null)
-             sb.append(" ").append(o.getTestResultUnit());
+         String resultValue = o.getTestResultValue();
+         String resultUnit = o.getTestResultUnit();
+         
+         if (resultValue != null) {
+             sb.append(resultValue);
+             if (resultUnit != null) {
+                 sb.append(' ').append(resultUnit);
+             }
+         }
src/main/java/com/wipro/fhir/service/ndhm/LinkCareContext_NDHMServiceImpl.java (4)

88-92: Consider adding empty string validation

While null checks are implemented, consider validating for empty strings to ensure robust input handling.

-if(null != genOTP.getAbdmFacilityId() && null != genOTP.getAbdmFacilityName()) {
+if(StringUtils.isNotBlank(genOTP.getAbdmFacilityId()) && StringUtils.isNotBlank(genOTP.getAbdmFacilityName())) {

Line range hint 71-71: Remove unused ACCEPTED constant

The constant ACCEPTED = 202 is no longer used as the code now uses HttpStatus.ACCEPTED.value(). Consider removing this unused field.


Line range hint 134-148: Consider refactoring error handling patterns

The error handling logic is duplicated across multiple methods. Consider:

  1. Creating a centralized error handling utility
  2. Extracting common JSON parsing logic
  3. Adding comprehensive error type handling

Example utility method:

private String extractNDHMErrorMessage(JsonObject response) {
    try {
        if (response.has("Error") && response.getAsJsonObject("Error").has("Message")) {
            return "NDHM_FHIR " + response.getAsJsonObject("Error").get("Message").getAsString();
        }
        return "Unknown NDHM error";
    } catch (Exception e) {
        return "Error parsing NDHM response: " + e.getMessage();
    }
}

Also applies to: 191-205, 264-279


Sensitive data exposure in logs - OTP, tokens and health IDs are being logged

The code logs sensitive authentication and healthcare data that could be exploited if logs are compromised:

  • OTP values and verification responses
  • Authentication tokens (NDHM_AUTH_TOKEN, NDHM_OTP_TOKEN, etc.)
  • Health ID numbers and patient identifiers
  • Full API request/response payloads containing PII

Recommendations:

  • Mask/redact sensitive values before logging using a custom logging filter
  • Only log metadata and correlation IDs at INFO level
  • Move detailed request/response logging to DEBUG level
  • Follow healthcare data protection regulations for logging practices
🔗 Analysis chain

Line range hint 1-324: Review logging of sensitive healthcare data

The code logs API requests and responses which might contain sensitive healthcare information. Consider:

  1. Implementing proper log masking for sensitive data
  2. Adding debug level logging for detailed information
  3. Ensuring compliance with healthcare data protection regulations
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for potential sensitive data logging
rg -i "logger\.(info|debug|warn|error).*getHealthID|getHealthIdNumber|OTP|Token|AccessToken" .

Length of output: 80197

src/main/java/com/wipro/fhir/service/facility/FacilityServiceImpl.java (10)

60-61: Avoid using deprecated JsonParser constructor

The JsonParser default constructor is deprecated in recent versions of Gson. It is recommended to use JsonParser.parseString() for parsing JSON strings.

Apply this diff to update the JSON parsing:

-JsonObject jsnOBJ = new JsonObject();
-JsonParser jsnParser = new JsonParser();
-JsonElement jsnElmnt = jsnParser.parse(responseStrLogin);
-jsnOBJ = jsnElmnt.getAsJsonObject();
+JsonObject jsnOBJ = JsonParser.parseString(responseStrLogin).getAsJsonObject();

67-68: Null check unnecessary before calling contains method

The types variable is derived from asJsonObject.get("types").toString(), which will not be null but could be the string "null". The null check null != types is unnecessary, but you should check if the value is not "null".

Apply this diff to adjust the condition:

-if(null != types && types.contains("HIP")) {
+if(!"null".equals(types) && types.contains("HIP")) {

Alternatively, ensure that you're handling the case where types may not be present or is null in the JSON.


67-71: Simplify JSON parsing by using Gson's fromJson method

Manually parsing JSON can be error-prone. Consider using Gson's fromJson method to map the JSON array to a list of objects.

Example:

Type facilityListType = new TypeToken<List<Facility>>(){}.getType();
List<Facility> facilities = new Gson().fromJson(jsonElement.getAsJsonArray(), facilityListType);

Ensure that you have a Facility class that represents the structure of the facility data.


81-81: Include the original exception when throwing a new exception

When rethrowing an exception, it's a good practice to include the original exception as the cause to preserve the stack trace.

Apply this diff:

-throw new FHIRException("NDHM_FHIR Error while accessing ABDM API" + e.getMessage());
+throw new FHIRException("NDHM_FHIR Error while accessing ABDM API: " + e.getMessage(), e);

95-98: Enclose single-line if-else blocks with braces

For better readability and to avoid potential bugs during future modifications, it's recommended to use braces {} even for single-line if or else blocks.

Apply this diff:

 if(response > 0 ) {
     res = "ABDM Facility ID updated successfully";
-} else
+} else {
     res = "FHIR Error while updating ABDM Facility ID";
+}

90-90: Handle potential JsonSyntaxException when parsing the request object

Parsing JSON from a string can throw a JsonSyntaxException if the input is not well-formed. Consider handling this exception to provide a clearer error message.

Example:

try {
    SaveFacilityIdForVisit requestObj = InputMapper.gson().fromJson(reqObj, SaveFacilityIdForVisit.class);
    // existing code...
} catch (JsonSyntaxException e) {
    throw new FHIRException("Invalid JSON input: " + e.getMessage(), e);
}

54-55: Confirm that the NDHM authentication token retrieval is secure and efficient

Fetching the NDHM authentication token should be done securely. Ensure that generateSession_NDHM.getNDHMAuthToken() handles token caching and renewal to avoid unnecessary authentication calls.

Consider reviewing the authentication flow to optimize performance and maintain security.


79-79: Remove unnecessary empty line

There is an unnecessary empty line that can be removed for cleaner code.

Remove the empty line at line 79.


58-59: Avoid unnecessary initialization of JsonObject

You are initializing jsnOBJ before assigning it, which is redundant.

Apply this diff to remove the unnecessary initialization:

-JsonObject jsnOBJ = new JsonObject();
 JsonParser jsnParser = new JsonParser();
 JsonElement jsnElmnt = jsnParser.parse(responseStrLogin);
-jsnOBJ = jsnElmnt.getAsJsonObject();
+JsonObject jsnOBJ = jsnElmnt.getAsJsonObject();

83-83: Consistent exception message formats

Ensure that exception messages are consistent and provide meaningful information. Currently, different methods have slightly varying exception message formats.

For example, standardize on a format like:

throw new FHIRException("Error in saveAbdmFacilityId: " + e.getMessage(), e);
src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java (4)

221-221: Inefficient Use of BigInteger Comparison

When comparing BigInteger with zero, it's more efficient to use BigInteger.ZERO.compareTo(resultSet.getId()) instead of resultSet.getId().compareTo(BigInteger.ZERO).

Apply this diff for a more efficient comparison:

-if (resultSet != null && resultSet.getId().compareTo(BigInteger.ZERO) > 0)
+if (resultSet != null && BigInteger.ZERO.compareTo(resultSet.getId()) < 0)

356-359: Avoid Mutating Shared Collection

ccList is fetched and modified directly, which could lead to concurrency issues if ccList is accessed by multiple threads.

Consider creating a new list when modifying:

+List<CareContexts> newCcList = new ArrayList<>(ccList);
+newCcList.add(cc);
+pcc.setCareContextsList(newCcList);

Line range hint 402-405: Handle Exceptions More Specifically

Catching a generic Exception can obscure the true source of errors. It's better to catch specific exceptions.

Refactor to catch specific exceptions:

-} catch (Exception e) {
+} catch (FHIRException e) {
    logger.error(e.getMessage());
}

Line range hint 577-577: Possible Null Return Without Response

The method searchPatientProfileFromMongo might return null if none of the conditions are met, which can lead to NullPointerException in the calling methods.

Ensure the method always returns a Page object.

// At the end of the method
+return Page.empty();
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 5e63d20 and a985f42.

📒 Files selected for processing (46)
  • src/main/environment/common_ci.properties (3 hunks)
  • src/main/environment/common_dev.properties (3 hunks)
  • src/main/environment/common_example.properties (3 hunks)
  • src/main/environment/common_test.properties (3 hunks)
  • src/main/java/com/wipro/fhir/config/BlockingHttpMethodInterceptor.java (0 hunks)
  • src/main/java/com/wipro/fhir/controller/carecontext/CareContextController.java (1 hunks)
  • src/main/java/com/wipro/fhir/controller/facility/FacilityController.java (1 hunks)
  • src/main/java/com/wipro/fhir/data/e_aushdhi/T_PatientIssue.java (3 hunks)
  • src/main/java/com/wipro/fhir/data/mongo/amrit_resource/AMRIT_ResourceMongo.java (3 hunks)
  • src/main/java/com/wipro/fhir/data/mongo/amrit_resource/TempCollection.java (3 hunks)
  • src/main/java/com/wipro/fhir/data/mongo/care_context/CareContexts.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/mongo/care_context/GenerateOTPForCareContextAndValidate.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/mongo/care_context/PatientCareContexts.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/mongo/care_context/SaveFacilityIdForVisit.java (1 hunks)
  • src/main/java/com/wipro/fhir/data/patient/PatientDemographic.java (3 hunks)
  • src/main/java/com/wipro/fhir/data/patient_data_handler/TRG_PatientResourceData.java (3 hunks)
  • src/main/java/com/wipro/fhir/data/request_handler/PatientEligibleForResourceCreation.java (3 hunks)
  • src/main/java/com/wipro/fhir/data/request_handler/ResourceRequestHandler.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/resource_model/AllergyIntoleranceDataModel.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/resource_model/AppointmentDataModel.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/resource_model/ConditionDiagnosisDataModel.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/resource_model/DiagnosticReportDataModel.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/resource_model/EncounterDataModel.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/resource_model/FamilyMemberHistoryDataModel.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/resource_model/LabTestAndComponentModel.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/resource_model/MedicationRequestDataModel.java (2 hunks)
  • src/main/java/com/wipro/fhir/data/resource_model/VitalsAnthropometryModel.java (2 hunks)
  • src/main/java/com/wipro/fhir/repo/common/PatientEligibleForResourceCreationRepo.java (3 hunks)
  • src/main/java/com/wipro/fhir/repo/healthID/BenHealthIDMappingRepo.java (2 hunks)
  • src/main/java/com/wipro/fhir/repo/mongo/amrit_resource/TempCollectionRepo.java (2 hunks)
  • src/main/java/com/wipro/fhir/repo/patient_data_handler/TRG_PatientResourceData_Repo.java (2 hunks)
  • src/main/java/com/wipro/fhir/service/api_channel/APIChannelImpl.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/care_context/CareContextServiceImpl.java (3 hunks)
  • src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java (8 hunks)
  • src/main/java/com/wipro/fhir/service/facility/FacilityService.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/facility/FacilityServiceImpl.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/ndhm/LinkCareContext_NDHMServiceImpl.java (2 hunks)
  • src/main/java/com/wipro/fhir/service/resource_model/AllergyIntoleranceResource.java (2 hunks)
  • src/main/java/com/wipro/fhir/service/resource_model/AppointmentResource.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/resource_model/ConditionResource.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/resource_model/DiagnosticReportResource.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/resource_model/EncounterResource.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/resource_model/FamilyMemberHistoryResource.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/resource_model/MedicationRequestResource.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/resource_model/ObservationResource.java (1 hunks)
  • src/main/java/com/wipro/fhir/service/resource_model/PatientResource.java (1 hunks)
💤 Files with no reviewable changes (1)
  • src/main/java/com/wipro/fhir/config/BlockingHttpMethodInterceptor.java
🔇 Additional comments (54)
src/main/java/com/wipro/fhir/data/mongo/care_context/SaveFacilityIdForVisit.java (1)

1-13: Verify integration with related components.

Let's verify how this class is integrated with other components mentioned in the AI summary.

✅ Verification successful

Integration verified - class is properly integrated with database layer

The SaveFacilityIdForVisit class is correctly integrated within the codebase:

  • Used in FacilityServiceImpl.saveAbdmFacilityId() to process facility ID updates
  • Maps to database table t_benvisitdetail via BenHealthIDMappingRepo.updateFacilityIdForVisit()
  • Properly configured with MongoDB infrastructure based on environment properties
  • The BigInteger type for visitCode matches the database schema usage
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the integration of SaveFacilityIdForVisit with related components

# Test 1: Check for references to this class in controllers
echo "Checking controller usage..."
rg -l "SaveFacilityIdForVisit" --type java --glob "*Controller.java"

# Test 2: Check for related MongoDB repositories
echo "Checking for related repositories..."
rg -l "SaveFacilityIdForVisit" --type java --glob "*Repository.java"

# Test 3: Check for service layer usage
echo "Checking service layer usage..."
rg -l "SaveFacilityIdForVisit" --type java --glob "*Service.java"

Length of output: 575


Script:

#!/bin/bash
# Let's try a broader search to find any usage of this class

# Search for any file containing SaveFacilityIdForVisit
echo "Searching for any usage of SaveFacilityIdForVisit..."
rg -l "SaveFacilityIdForVisit"

# Get some context around the usage
echo -e "\nSearching with context..."
rg -C 3 "SaveFacilityIdForVisit"

# Check if there are any MongoDB related configurations
echo -e "\nChecking MongoDB configurations..."
fd -e java -e xml -e properties -e yml | xargs rg -l "mongo"

Length of output: 6936


Script:

#!/bin/bash
# Let's examine the FacilityServiceImpl usage in more detail

echo "Examining FacilityServiceImpl implementation..."
rg -C 10 "saveAbdmFacilityId" src/main/java/com/wipro/fhir/service/facility/FacilityServiceImpl.java

# Check for any MongoDB repository that might be handling this data
echo -e "\nChecking for facility related MongoDB repositories..."
rg -C 3 "facility" src/main/java/com/wipro/fhir/repo/mongo/

# Check application properties for MongoDB configuration
echo -e "\nChecking MongoDB configuration in properties..."
rg -C 3 "mongo" src/main/environment/common_*.properties

Length of output: 5461


Script:

#!/bin/bash
# Let's check the BenHealthIDMappingRepo implementation since it's used in the service

echo "Examining BenHealthIDMappingRepo..."
rg -C 5 "updateFacilityIdForVisit" 

# Let's also check for any test cases
echo -e "\nChecking for related test cases..."
fd -e java -e groovy | xargs rg -l "SaveFacilityIdForVisit|updateFacilityIdForVisit" --glob "*Test*"

Length of output: 2775

src/main/java/com/wipro/fhir/repo/mongo/amrit_resource/TempCollectionRepo.java (2)

24-24: LGTM!

Clean addition of the BigInteger import.


36-36: Verify all callers of this repository method.

The change from Long to BigInteger is appropriate for handling larger numerical values, and MongoDB supports BigInteger natively. However, this is a breaking change that requires updates to all calling code.

Let's verify the callers have been updated:

✅ Verification successful

The previous results show the method is called in CommonServiceImpl.java, but we need to verify the parameter types at the call site to ensure they match the BigInteger signature. This will help us confirm if the change is properly propagated to all callers.


We need to verify the return types of these getter methods to ensure they match the BigInteger parameters required by the repository method.


The change is properly propagated and type-safe

The verification shows that:

  1. The repository method is called only in CommonServiceImpl.fetchTempResourceFromMongo
  2. The ResourceRequestHandler class has both fields declared as BigInteger:
    • private BigInteger beneficiaryRegID;
    • private BigInteger visitCode;

This confirms that the types align correctly throughout the call chain, from the repository interface to the actual usage.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Find all usages of findByBeneficiaryRegIDAndVisitCode to ensure they use BigInteger

# Search for method calls
echo "Searching for method calls..."
rg -p "findByBeneficiaryRegIDAndVisitCode\(" --type java

# Search for potential Long declarations of these parameters
echo -e "\nChecking for potential Long declarations of these parameters..."
rg -p "(?i)(beneficiaryRegID|visitCode).*:\s*Long" --type java

Length of output: 688


Script:

#!/bin/bash
# Let's check the actual usage context in CommonServiceImpl.java
echo "Checking the context of the method call in CommonServiceImpl.java..."
rg -p -B 5 -A 5 "findByBeneficiaryRegIDAndVisitCode" src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java

# Let's also check the parameter types in the calling method
echo -e "\nChecking parameter declarations in CommonServiceImpl.java..."
ast-grep --pattern 'BigInteger $var'

Length of output: 835


Script:

#!/bin/bash
# Let's check the ResourceRequestHandler class to verify the types of getBeneficiaryRegID and getVisitCode
echo "Checking ResourceRequestHandler class..."
rg -p "class ResourceRequestHandler" -A 20 --type java

# Also check the getter method implementations
echo -e "\nChecking getter methods in ResourceRequestHandler..."
ast-grep --pattern 'getBeneficiaryRegID() {
  $$$
}'

ast-grep --pattern 'getVisitCode() {
  $$$
}'

Length of output: 953

src/main/java/com/wipro/fhir/data/request_handler/ResourceRequestHandler.java (3)

24-25: LGTM: Import statements are properly organized.

The new imports for BigInteger and Lombok's @Data annotation are correctly placed and necessary for the changes made in this class.

Also applies to: 30-31


43-46: Verify the impact of BigInteger migration across the application.

The change from Long to BigInteger for ID fields is appropriate for handling larger values. However, this change requires careful verification:

  1. Ensure all database schemas can handle the larger number type
  2. Verify that all related services and repositories handle these fields consistently
  3. Check for any potential serialization/deserialization impacts
#!/bin/bash
# Search for potential inconsistencies in ID field types
echo "Checking for inconsistent ID field types..."
# Look for Long type usage in related files
rg -t java "private\s+Long\s+(beneficiaryID|visitCode|beneficiaryRegID)\s*;" 

# Look for related repository and service classes
echo "Checking related components..."
rg -t java "beneficiaryID|visitCode|beneficiaryRegID" -l

40-40: Verify Lombok @DaTa usage and its implications.

The addition of @Data annotation is a good improvement that reduces boilerplate code. However, please verify:

  1. That all necessary Lombok dependencies are properly configured in the build file
  2. That your IDE has Lombok plugin installed for proper development experience
✅ Verification successful

Let me generate another script to check for Lombok configuration since the previous output seems unrelated.


Lombok is properly configured and widely used in the project

The verification shows that:

  1. Lombok is correctly configured in pom.xml with version 1.16.18
  2. The annotation processor path is properly set up in the build configuration
  3. @DaTa annotation is consistently used across multiple model classes in the project

The addition of @DaTa to ResourceRequestHandler.java aligns with the project's established patterns.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if Lombok is properly configured in the project
# Look for Lombok dependency in build files
echo "Checking for Lombok dependency..."
find . -name "pom.xml" -o -name "build.gradle" | xargs grep -l "lombok"

Length of output: 3390


Script:

#!/bin/bash
# Check Lombok configuration in build files
echo "Checking pom.xml for Lombok dependency..."
find . -name "pom.xml" -exec cat {} \; | grep -A 2 -B 2 "lombok"

# Check for other Lombok usage
echo -e "\nChecking for other Lombok annotations usage..."
rg "@(Data|Getter|Setter|Builder|NoArgsConstructor|AllArgsConstructor|RequiredArgsConstructor|Value|ToString|EqualsAndHashCode)" -t java

Length of output: 10005

src/main/java/com/wipro/fhir/data/mongo/amrit_resource/TempCollection.java (1)

24-24: LGTM! Import statements are correctly added.

The new imports for BigInteger and Lombok's @Data annotation are necessary and properly organized.

Also applies to: 35-35

src/main/java/com/wipro/fhir/data/mongo/care_context/GenerateOTPForCareContextAndValidate.java (1)

Line range hint 1-60: Verify MongoDB query performance impact

Since this is a MongoDB document, we should verify if any queries will be performed using the new ABDM facility fields and whether they need to be indexed.

src/main/java/com/wipro/fhir/data/request_handler/PatientEligibleForResourceCreation.java (1)

24-24: LGTM! Required imports added correctly.

The new imports for BigInteger and Lombok's @Data annotation are properly organized and align with the changes made to the class.

Also applies to: 33-33

src/main/java/com/wipro/fhir/data/mongo/care_context/PatientCareContexts.java (1)

79-85: Verify data migration strategy for careContextsList field change.

The field type change from String to ArrayList is a good improvement, but ensure you have a migration strategy for existing MongoDB documents.

Run this script to check for existing documents that might need migration:

src/main/java/com/wipro/fhir/data/patient_data_handler/TRG_PatientResourceData.java (2)

24-24: LGTM: Required imports added correctly.

The imports for BigInteger and Lombok's @Data annotation are properly added.

Also applies to: 33-33


40-40: Verify removal of existing getter/setter methods.

The addition of Lombok's @Data annotation is good for reducing boilerplate code. However, ensure that:

  1. All existing getter/setter methods have been removed to avoid duplication
  2. No custom implementations of these methods were lost in the process
✅ Verification successful

@DaTa annotation is correctly applied without any conflicting getter/setter methods

Looking at the complete file content, there are no manually implemented getter/setter methods in the class. The class is a clean entity class with only field declarations and annotations. The @Data annotation from Lombok will generate all the necessary getter/setter methods without any duplication or conflicts.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining getter/setter methods that might conflict with Lombok
ast-grep --pattern 'class TRG_PatientResourceData {
  $$$
  public $_ get$_() {
    $$$
  }
  $$$
}'

ast-grep --pattern 'class TRG_PatientResourceData {
  $$$
  public void set$_($_) {
    $$$
  }
  $$$
}'

Length of output: 209


Script:

#!/bin/bash
# Let's try a different approach using ripgrep to find the class and its contents
rg -U "class TRG_PatientResourceData\s*\{.*?\}" -A 100 --multiline

Length of output: 68


Script:

#!/bin/bash
# Let's try to find the file first and then examine its contents
fd TRG_PatientResourceData.java --exec cat {}

Length of output: 2211

src/main/java/com/wipro/fhir/repo/patient_data_handler/TRG_PatientResourceData_Repo.java (2)

24-24: LGTM: Required import for BigInteger.

The import is correctly placed and necessary for the parameter type change.


47-47: Verify database column type compatibility with BigInteger.

The change from Long to BigInteger is part of a broader standardization effort. While the change is logically sound, we should verify:

  1. The database column type for beneficiaryID supports the full range of BigInteger
  2. All calling code has been updated to handle BigInteger

Let's verify the database schema and usage:

✅ Verification successful

Let me gather more information about the database schema and usage patterns.


Let me check one more crucial piece - the entity class and the actual caller's type usage.


Let me check one final detail about the ResourceRequestHandler class to complete our verification.


The BigInteger type change is correctly implemented and compatible with the database.

The verification shows:

  1. The entity TRG_PatientResourceData uses BigInteger for beneficiaryID field
  2. The ResourceRequestHandler class also uses BigInteger for beneficiaryID
  3. The service layer correctly handles the BigInteger type in method calls
  4. The database table is in the db_identity schema, which typically uses large number types
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify database column type and usage of beneficiaryID

# Check database column type in repository queries
rg -g '*.java' -B 2 -A 2 'beneficiaryID.*(?i)(bigint|numeric|decimal|number)'

# Find all references to getByBenIdLatestRecord to ensure they're updated
ast-grep --pattern 'getByBenIdLatestRecord($_)'

Length of output: 934


Script:

#!/bin/bash
# Check for table definitions or entity mappings
rg -g '*.java' -B 3 -A 3 '@Table.*TRG_PatientResourceData|@Entity.*TRG_PatientResourceData'

# Look for JPA/Hibernate column definitions for benId
rg -g '*.java' -B 2 -A 2 '@Column.*benId|@Column.*beneficiaryId'

# Find all usages of this repository class
rg -g '*.java' 'TRG_PatientResourceData_Repo'

# Look for service layer implementations using this method
ast-grep --pattern 'getByBenIdLatestRecord'

Length of output: 1122


Script:

#!/bin/bash
# Check the entity class definition
rg -g '*.java' -B 5 -A 5 'class TRG_PatientResourceData'

# Check the resourceRequestHandler's type in the service
rg -g '*.java' -B 3 -A 3 'resourceRequestHandler.*getBeneficiaryID'

# Look for the parameter type in the calling method
ast-grep --pattern 'resourceRequestHandler = $_'

Length of output: 5094


Script:

#!/bin/bash
# Check ResourceRequestHandler class definition
rg -g '*.java' -B 3 -A 3 'class ResourceRequestHandler'

# Look for beneficiaryID field type in ResourceRequestHandler
rg -g '*.java' -B 1 -A 1 'private.*beneficiaryID|setBeneficiaryID|getBeneficiaryID'

Length of output: 12303

src/main/java/com/wipro/fhir/data/resource_model/ConditionDiagnosisDataModel.java (2)

45-47: LGTM! Type change from Long to BigInteger is appropriate.

The change from Long to BigInteger for ID fields is a good practice, especially in healthcare systems where you might need to handle very large numbers. This aligns with the broader changes across the codebase.


59-61: Verify the impact of BigInteger changes on database queries.

Since this is a data model class likely used with JPA/Hibernate, ensure that:

  1. The database columns can handle the larger number ranges
  2. Any native queries are updated to handle BigInteger

Let's check for any potential SQL queries that might need updates:

✅ Verification successful

No issues found with BigInteger changes in database queries

Based on the search results:

  1. The native queries using these fields already handle BigInteger correctly, as evidenced by the query in BenHealthIDMappingRepo:

    @Query(nativeQuery = true, value = " SELECT HealthID FROM t_benvisitdetail t WHERE t.VisitCode = :visitCode")
    public List<String> getLinkedHealthIDForVisit(@Param("visitCode") BigInteger visitCode);
  2. The pattern of BigInteger usage is consistent across multiple data models (DiagnosticReport, Appointment, MedicationRequest, etc.), indicating this is an established pattern in the codebase.

  3. No problematic SQL type mappings were found in the @column annotations that would conflict with BigInteger fields.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for SQL queries referencing these fields
rg -t java "SELECT.*(?:id|beneficiaryRegID|visitCode).*FROM.*condition" 

# Look for repository methods using these fields
ast-grep --pattern 'interface $_ extends JpaRepository<$_, $_> {
  $$$
  @Query($$$)
  $$$
}'

Length of output: 169


Script:

#!/bin/bash
# Let's try a broader search for SQL queries and repository methods

# Search for any SQL queries in the codebase
rg -t java "@Query\(.*SELECT.*\)" -A 2

# Search for repository interfaces that might use these fields
rg -t java "interface.*Repository.*extends.*JpaRepository"

# Search for any references to these specific field names
rg -t java "(?:id|beneficiaryRegID|visitCode)\s*=\s*(?:BigInteger|Long)"

# Look for entity mappings
rg -t java "@Column.*(?:id|beneficiary_reg_id|visit_code)"

Length of output: 15118

src/main/java/com/wipro/fhir/data/resource_model/EncounterDataModel.java (1)

43-45: LGTM! Verify related components for BigInteger compatibility.

The change from Long to BigInteger for identifier fields is a good improvement for handling larger values. This aligns with similar changes across other models mentioned in the summary.

Let's verify that related repositories and services are updated to handle BigInteger:

✅ Verification successful

Let's verify the actual type usage in these files to ensure compatibility.


Type changes are properly synchronized across the codebase

The verification shows that the related components have been properly updated to use BigInteger:

  • Repository layer is consistently using BigInteger for beneficiaryRegID and visitCode parameters
  • TempCollectionRepo is using BigInteger in its method signature
  • PatientEligibleForResourceCreationRepo has all stored procedure calls using BigInteger
  • Service layer shows commented out old Long type usage, indicating the migration has been done
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for repository interfaces and services that might need updates
# Look for method signatures still using Long type for these fields

# Description: Find repository interfaces that might need updates
echo "Checking repository interfaces..."
rg -t java "interface.*Repository|interface.*Repo" -l | xargs rg -l "beneficiaryRegID|visitCode"

# Description: Find service interfaces and implementations that might need updates
echo "Checking service layer..."
rg -t java "interface.*Service|class.*ServiceImpl" -l | xargs rg -l "beneficiaryRegID|visitCode"

Length of output: 715


Script:

#!/bin/bash
# Check type usage in repository and service files
echo "=== Repository Layer Type Usage ==="
rg -A 1 -B 1 "beneficiaryRegID|visitCode" src/main/java/com/wipro/fhir/repo/common/PatientEligibleForResourceCreationRepo.java src/main/java/com/wipro/fhir/repo/mongo/amrit_resource/TempCollectionRepo.java src/main/java/com/wipro/fhir/repo/healthID/BenHealthIDMappingRepo.java

echo -e "\n=== Service Layer Type Usage ==="
rg -A 1 -B 1 "beneficiaryRegID|visitCode" src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java src/main/java/com/wipro/fhir/service/care_context/CareContextServiceImpl.java

Length of output: 16331

src/main/java/com/wipro/fhir/controller/facility/FacilityController.java (1)

29-32: LGTM! Proper dependency injection and logging setup.

The service autowiring and logger initialization follow best practices.

src/main/java/com/wipro/fhir/data/resource_model/AppointmentDataModel.java (1)

45-47: Verify BigInteger compatibility across the application

The type change from Long to BigInteger requires verification of dependent components.

Also applies to: 63-65

src/main/java/com/wipro/fhir/data/resource_model/AllergyIntoleranceDataModel.java (1)

Line range hint 47-66: Verify consistent BigInteger usage across the codebase.

Let's ensure this type change is consistently applied across related components.

✅ Verification successful

Let me try a different search strategy to verify the BigInteger usage.


Based on the search results, I can now provide a final response:

BigInteger usage is consistent across the codebase

The type conversion pattern BigInteger.valueOf((long) objArr[n]) is consistently used across multiple data models in the codebase for id, beneficiaryRegID, and visitCode fields, including:

  • AllergyIntoleranceDataModel
  • EncounterDataModel
  • DiagnosticReportDataModel
  • ConditionDiagnosisDataModel
  • LabTestAndComponentModel
  • FamilyMemberHistoryDataModel
  • AppointmentDataModel
  • MedicationRequestDataModel

The type usage is uniform and follows the same pattern across all related components, indicating proper type consistency.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for inconsistent type usage that might cause runtime issues

# Test 1: Look for potential type mismatches in repository queries
echo "Checking repository queries for type consistency..."
rg -t java "beneficiaryRegID|visitCode" --glob "**/*Repository.java" -A 2 -B 2

# Test 2: Check service layer for proper type handling
echo "Checking service layer implementation..."
rg -t java "AllergyIntoleranceDataModel" --glob "**/*Service.java" -A 2 -B 2

# Test 3: Look for any remaining Long type usage for these fields
echo "Checking for remaining Long type usage..."
ast-grep --pattern 'Long $field = $value' --lang java

Length of output: 659


Script:

#!/bin/bash
# Search for all files that reference AllergyIntoleranceDataModel
echo "Files referencing AllergyIntoleranceDataModel:"
rg -l "AllergyIntoleranceDataModel"

# Check for any BigInteger to Long conversions or vice versa
echo -e "\nChecking type conversions:"
rg "Long\.valueOf|BigInteger\.valueOf" -A 2 -B 2

# Look for repository interfaces/implementations
echo -e "\nChecking repository layer:"
fd -e java ".*Repository.*"

# Check entity mappings
echo -e "\nChecking entity mappings:"
rg "@Entity|@Table" -A 5 "AllergyIntoleranceDataModel.java"

Length of output: 9889

src/main/java/com/wipro/fhir/data/patient/PatientDemographic.java (1)

Line range hint 65-84: LGTM! Constructor signature properly updated.

The constructor signature has been correctly updated to match the new field types, maintaining proper initialization of all fields.

src/main/java/com/wipro/fhir/data/e_aushdhi/T_PatientIssue.java (1)

25-25: LGTM: Required imports added for new functionality.

The addition of BigInteger and Lombok imports supports the new changes.

Also applies to: 36-36

src/main/java/com/wipro/fhir/data/resource_model/DiagnosticReportDataModel.java (1)

45-47: Approve data type changes for better numerical range support.

The migration from Long to BigInteger for IDs and codes is a good change as it:

  • Prevents potential overflow issues with large healthcare identifiers
  • Aligns with FHIR's requirement for handling large numerical values
  • Maintains data integrity for healthcare records
src/main/java/com/wipro/fhir/data/resource_model/LabTestAndComponentModel.java (1)

45-47: LGTM! Verify database and serialization compatibility.

The change from Long to BigInteger for ID fields is appropriate for handling larger numeric ranges in healthcare systems. This aligns with the changes being made across the codebase.

Let's verify if there are any JPA/Hibernate mappings or JSON serialization configurations that need to be updated:

✅ Verification successful

BigInteger changes are consistent and safe to proceed

The verification shows that:

  1. The model is used only in ObservationResource for data transformation, not directly for persistence
  2. Similar BigInteger changes have been consistently applied across multiple resource models in the same package
  3. Spring JPA is configured with MySQL dialect and the application doesn't use explicit type converters
  4. No JPA/Hibernate annotations are present in the model, indicating it's a pure data transfer object

The change from Long to BigInteger is part of a broader, consistent change across the codebase and doesn't require additional database or serialization configurations since:

  • The class is a non-persistent model used for data transformation
  • Spring's default JSON serialization (configured in application.properties) can handle BigInteger
  • Similar changes have been successfully applied to other resource models
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for JPA/Hibernate mapping files and JSON configurations
echo "Checking for related configuration files..."
fd -e xml -e yaml -e properties | xargs rg -l "LabTestAndComponentModel|hibernate|jackson"

# Check for potential serialization annotations
rg -A 2 "@JsonSerialize|@JsonDeserialize" 

Length of output: 459


Script:

#!/bin/bash
# Let's check the content of application.properties and entity mappings
echo "=== Checking application.properties ==="
cat src/main/resources/application.properties

# Check for JPA/Hibernate annotations in the model
echo -e "\n=== Checking JPA/Hibernate annotations in LabTestAndComponentModel ==="
rg -A 3 "@Entity|@Table|@Column" src/main/java/com/wipro/fhir/data/resource_model/LabTestAndComponentModel.java

# Check for any references to this model in repository/service layers
echo -e "\n=== Checking repository/service layer usage ==="
rg "LabTestAndComponentModel" --type java

# Check if there are similar BigInteger changes in related files
echo -e "\n=== Checking similar BigInteger changes ==="
rg "private (Long|BigInteger) (id|.*ID|.*Code)" --type java

Length of output: 10816

src/main/java/com/wipro/fhir/data/resource_model/MedicationRequestDataModel.java (1)

44-46: LGTM! Appropriate use of BigInteger for healthcare identifiers.

The change from Long to BigInteger is a good choice for healthcare system identifiers, as it prevents potential overflow issues and aligns with healthcare data volume requirements.

Let's verify the consistency of this change across related components:

✅ Verification successful

Let me check the type usage in the related files to ensure consistency.


✅ Type consistency verified across all related models

The change from Long to BigInteger for beneficiaryRegID and visitCode is consistent across all related data models in the codebase. All models use BigInteger for these fields and properly handle the type conversion in their constructors using BigInteger.valueOf((long) objArr[]).

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if other related files are using consistent types for these fields
echo "Checking related entity definitions..."
rg -l "beneficiaryRegID|visitCode" | grep -i "entity\|model\|repository"

echo "Checking for any remaining Long type usage for these fields..."
ast-grep --pattern 'private Long beneficiaryRegID;'
ast-grep --pattern 'private Long visitCode;'

Length of output: 1111


Script:

#!/bin/bash
# Check type usage for beneficiaryRegID and visitCode in related models
for file in $(rg -l "beneficiaryRegID|visitCode" | grep "Model.java"); do
  echo "=== $file ==="
  rg -A 1 "beneficiaryRegID|visitCode" "$file"
done

Length of output: 6027

src/main/java/com/wipro/fhir/data/resource_model/VitalsAnthropometryModel.java (1)

42-44: Verify serialization compatibility after type change.

The change from Long to BigInteger for identifiers is appropriate for handling larger values. However, we should ensure this change doesn't affect existing data persistence and API compatibility.

✅ Verification successful

Type changes from Long to BigInteger are consistent across the codebase

The change from Long to BigInteger for beneficiaryRegID and visitCode is part of a consistent pattern across multiple model classes in the codebase. The search results show that:

  1. All resource models (Vitals, Lab, Encounter, etc.) use BigInteger for these fields
  2. Repository methods and stored procedures have been updated to handle BigInteger parameters
  3. The change aligns with the broader standardization effort for large number handling
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any custom serializers/deserializers that might need updates
rg -g '*.java' -A 5 'implements.*Serializer.*|extends.*Serializer.*|@JsonSerializer|@JsonDeserializer'

# Check for any JPA/Hibernate mappings that might need updates
rg -g '*.java' -A 5 '@Entity.*beneficiaryRegID|@Entity.*visitCode'

Length of output: 173


Script:

#!/bin/bash
# Let's check for any repository-wide usage of these fields and their types
rg -g '*.java' -B 2 -A 2 'beneficiaryRegID|visitCode'

# Check for any JPA/Hibernate entity annotations in the specific file
rg -g 'VitalsAnthropometryModel.java' '@Entity|@Table'

# Check for any JSON annotations in the model
rg -g 'VitalsAnthropometryModel.java' '@JsonProperty|@JsonSerialize|@JsonDeserialize'

# Look for similar BigInteger type changes in other files
rg -g '*.java' 'private BigInteger (beneficiaryRegID|visitCode)'

Length of output: 48226

src/main/java/com/wipro/fhir/repo/healthID/BenHealthIDMappingRepo.java (1)

24-24: LGTM: Required import for BigInteger type

The addition of BigInteger import is necessary for the parameter type changes.

src/main/java/com/wipro/fhir/service/resource_model/AppointmentResource.java (1)

24-24: ⚠️ Potential issue

Verify the necessity of BigInteger import.

While the BigInteger import has been added, it's not being used in this class. According to the AI summary, this is part of a larger change to update identifier types from Long to BigInteger.

Let's verify the parameter types in ResourceRequestHandler:

If ResourceRequestHandler has been updated to use BigInteger, the following changes are needed in this class:

  1. Update the parameter types in callAppointmentSP method call
  2. Update any internal processing of these IDs
  3. If no BigInteger usage is planned, remove the unused import
✅ Verification successful

BigInteger import is correctly added and required

The import of java.math.BigInteger is necessary as the class interacts with ResourceRequestHandler where both beneficiaryRegID and visitCode are defined as BigInteger. The import is being used indirectly through the getter methods getBeneficiaryRegID() and getVisitCode() which return BigInteger values.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check the parameter types in ResourceRequestHandler
# Expected: Should find beneficiaryRegID and visitCode declared as BigInteger

ast-grep --pattern 'class ResourceRequestHandler {
  $$$
  private $type beneficiaryRegID;
  $$$
}'

ast-grep --pattern 'class ResourceRequestHandler {
  $$$
  private $type visitCode;
  $$$
}'

Length of output: 196


Script:

#!/bin/bash
# Let's try a different approach to find ResourceRequestHandler and its usage
# First, find the file containing ResourceRequestHandler
fd "ResourceRequestHandler.java"

# Then let's check for any BigInteger usage in AppointmentResource.java
rg "BigInteger" "src/main/java/com/wipro/fhir/service/resource_model/AppointmentResource.java" -A 5

# Also check for method signatures in AppointmentResource.java that might use these IDs
rg "callAppointmentSP" "src/main/java/com/wipro/fhir/service/resource_model/AppointmentResource.java" -A 5

Length of output: 741


Script:

#!/bin/bash
# Let's check the ResourceRequestHandler file to see the types of beneficiaryRegID and visitCode
rg "beneficiaryRegID|visitCode" "src/main/java/com/wipro/fhir/data/request_handler/ResourceRequestHandler.java" -B 1 -A 1

# Also check if there are any BigInteger usages in ResourceRequestHandler
rg "BigInteger" "src/main/java/com/wipro/fhir/data/request_handler/ResourceRequestHandler.java" -A 2

# Check the callAppointmentSP method signature to see parameter types
rg -B 1 -A 1 "callAppointmentSP.*\(" "src/main/java/com/wipro/fhir/service/resource_model/AppointmentResource.java"

Length of output: 876

src/main/environment/common_ci.properties (1)

43-43: Verify API version downgrade from v1 to v0.5.

The change from v1 to v0.5 for multiple ABDM gateway endpoints is unusual as it appears to be a version downgrade. Please verify:

  1. Is this intentional?
  2. Are there any compatibility issues to consider?
  3. Is this a temporary change or permanent solution?

Also applies to: 60-62

✅ Verification successful

API version changes appear to be consistent and intentional

The version changes are consistent across all environment property files (dev, test, ci, example) and follow a clear pattern:

  • All session and user authentication endpoints use v0.5 (/gateway/v0.5/sessions, /gateway/v0.5/users/auth/*)
  • Health ID registration endpoints remain on v1 (/api/v1/registration/*)
  • SMS notification endpoint remains on v1 (/gateway/v1/patients/sms/notify2)

This suggests an intentional API versioning strategy where different service groups use different versions, rather than a downgrade. The changes appear to be part of a permanent solution as they are consistently implemented across all environment configurations.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining v1 endpoints that might need updating
echo "Searching for potentially inconsistent ABDM gateway API versions..."
rg -i "gateway/v1" --type properties

Length of output: 216


Script:

#!/bin/bash
# Search for any ABDM gateway API versions in all files
echo "Searching for ABDM gateway API versions..."
rg -i "gateway/v[0-9]" -A 2 -B 2

# Also search for any properties files to ensure we're not missing anything
echo -e "\nListing all properties files:"
fd -e properties

Length of output: 6281

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

43-43: Verify API version downgrade from v1 to v0.5.

The change from v1 to v0.5 for multiple ABDM endpoints is unusual as it appears to be a version downgrade. Please verify:

  1. Is this intentional and aligned with ABDM's API versioning strategy?
  2. Are there any breaking changes between v1 and v0.5?
  3. Have all dependent systems been notified of this change?

Also applies to: 60-62

✅ Verification successful

Let me check the content of these property files to better understand the API version changes.


API version changes appear to be consistent with ABDM's gateway versioning

After analyzing the property files, I can see that:

  1. The v0.5 version is consistently used across all environments (test, dev, example) for gateway authentication and care context APIs
  2. Other ABDM APIs (health ID, registration, etc.) consistently use v1/v2 versions
  3. This pattern suggests an intentional versioning strategy by ABDM where gateway APIs use v0.5 while other services use v1/v2

The version differences appear to be by design:

  • Gateway APIs (v0.5): sessions, user auth, care context
  • Health ID APIs (v1): registration, OTP, card generation
  • Registration APIs (v2): specific mobile OTP flows
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining v1 references that might need updating
echo "Searching for v1 ABDM gateway endpoints that might need updating..."
rg -l "abdm.gov.in/gateway/v1" --type properties

echo "Searching for potential version references in Java code..."
rg -l "abdm.gov.in/gateway/v[0-9]" --type java

Length of output: 538


Script:

#!/bin/bash
# Check the content of identified property files
echo "Content of common_test.properties:"
cat src/main/environment/common_test.properties

echo -e "\nContent of common_example.properties:"
cat src/main/environment/common_example.properties

echo -e "\nContent of common_dev.properties:"
cat src/main/environment/common_dev.properties

Length of output: 13021

src/main/environment/common_dev.properties (2)

84-85: Review version inconsistency in facility services endpoint.

The new facility services endpoint uses v1 and a different base path (devservice) while other ABDM endpoints use v0.5 and gateway. Please verify if this is intentional.

✅ Verification successful

Let's search for other ABDM endpoints to verify if there's indeed an inconsistency in versioning and base paths.


Version and path differences are consistent with ABDM service patterns

After analyzing all ABDM endpoints, the versioning and base path differences are actually consistent with ABDM's service architecture:

  • Gateway services use /gateway/v0.5/ path (e.g., sessions, care context)
  • Health ID services use /api/v1/ or /api/v2/ path (e.g., registration, auth)
  • Notification service uses /gateway/v1/ path
  • Facility service uses /devservice/v1/ path

The different base path and version for the facility service appears to be intentional as it follows ABDM's pattern of using distinct paths for different service categories.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any documentation about the devservice endpoints
rg -g "*.md" -g "*.txt" -i "devservice|facility.*service"

# Look for other endpoints using the devservice path
rg "devservice" --type-add 'props:*.properties' -t props

Length of output: 722


Script:

#!/bin/bash
# Check for other ABDM endpoints to verify versioning pattern
rg "abdm\.gov\.in" --type-add 'props:*.properties' -t props -i

Length of output: 7845


43-43: Verify API version downgrade from v1 to v0.5.

The NDHM user authentication endpoint version has been downgraded from v1 to v0.5. Please confirm if this is an intentional change and ensure it's documented in the migration guide.

src/main/environment/common_test.properties (2)

Line range hint 1-87: Review security practices for configuration management.

The properties file contains sensitive configuration. Please ensure:

  1. This file is properly added to .gitignore
  2. Sensitive values use consistent placeholder format
  3. Consider using environment variables or a secure configuration management system
#!/bin/bash
# Check if file is properly gitignored
grep -l "common_test.properties" .gitignore

# Check for potential credential leaks
rg -i "password|secret|key|token" src/main/environment/common_test.properties

43-43: Verify API version downgrade from v1 to v0.5.

The change from v1 to v0.5 for multiple endpoints is unusual as it appears to be a version downgrade:

  • ndhmuserAuthenticate
  • generateOTPForCareContext
  • addCareContext
  • validateOTPForCareContext

Please confirm if this is intentional and document the reason for the version change.

Also applies to: 60-62

src/main/java/com/wipro/fhir/service/api_channel/APIChannelImpl.java (1)

89-95: Verify the impact on existing authentication flows

The addition of the logout flag might affect existing clients that depend on this authentication service.

✅ Verification successful

The doLogout flag addition is safe and won't impact existing authentication flows

The doLogout flag is only being added as part of the authentication request payload and is not modifying any existing authentication logic. The implementation shows it's a simple key-value addition to the request parameters that:

  1. Is contained within the APIChannelImpl class
  2. Gets sent as part of the standard authentication request
  3. Doesn't modify the core authentication flow or session handling

The flag appears to be a server-side configuration rather than a client-impacting change, making it backward compatible with existing clients.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for direct calls to userAuthentication method
rg -l "userAuthentication\(\)" --type java

# Search for potential JWT or session handling code that might be affected
rg -l "(?i)(jwt|token|session|auth.*key)" --type java

Length of output: 2794


Script:

#!/bin/bash
# Let's examine the userAuthentication method implementation and its usage
ast-grep --pattern 'userAuthentication($$$)' 

# Also check how doLogout flag is used in authentication flows
rg -A 5 "doLogout" --type java

Length of output: 678


Script:

#!/bin/bash
# Let's check the full implementation of APIChannelImpl to understand the authentication flow
rg -A 20 "class APIChannelImpl" --type java

# Also check for any existing logout related functionality
rg -B 5 -A 10 "logout|signout" --type java -i

Length of output: 3735

src/main/java/com/wipro/fhir/service/resource_model/PatientResource.java (1)

24-24: Verify the necessity of BigInteger import.

The BigInteger import appears to be unused in the current implementation. This might indicate incomplete refactoring from Long to BigInteger types.

Let's verify the planned usage and related changes:

src/main/java/com/wipro/fhir/service/care_context/CareContextServiceImpl.java (1)

107-107: LGTM!

The added blank line improves code readability.

src/main/java/com/wipro/fhir/service/resource_model/FamilyMemberHistoryResource.java (1)

24-24: Verify complete migration to BigInteger.

Based on the AI summary, there's a broader initiative to migrate from Long to BigInteger across the codebase. However, this class still appears to use primitive types. Please verify if this class should also be updated to use BigInteger for consistency, particularly in its interaction with PatientEligibleForResourceCreationRepo.

✅ Verification successful

Let me generate additional scripts to check for any remaining Long usages in the FamilyMemberHistoryResource class and its related models.


Based on the results from both script executions, I can now provide a final response:

Migration to BigInteger appears complete and consistent

The verification shows that:

  • The repository interface PatientEligibleForResourceCreationRepo uses BigInteger for its parameters in the callFamilyMemberHistorySP method
  • No Long type usages were found in the FamilyMemberHistoryResource class or related files
  • The import of BigInteger is justified as it's used through the repository interface
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if PatientEligibleForResourceCreationRepo methods use BigInteger
# and if there are any remaining Long usages that should be migrated

# Check the repository interface for BigInteger usage
echo "Checking repository interface for BigInteger usage:"
rg -A 5 "callFamilyMemberHistorySP" 

# Look for any remaining Long usages in related files
echo -e "\nChecking for remaining Long usages in related files:"
rg "Long" --type java -g "*FamilyMemberHistory*.java" -g "*PatientEligible*.java"

Length of output: 2044


Script:

#!/bin/bash
# Check for Long usage in FamilyMemberHistoryResource.java
echo "Checking FamilyMemberHistoryResource.java for primitive type usage:"
rg -A 2 "private.*Long|Long.*\(" src/main/java/com/wipro/fhir/service/resource_model/FamilyMemberHistoryResource.java

# Check the data model class for Long usage
echo -e "\nChecking FamilyMemberHistoryDataModel for primitive type usage:"
ast-grep --pattern 'class FamilyMemberHistoryDataModel {
  $$$
}'

# Check method parameters and return types
echo -e "\nChecking method signatures in FamilyMemberHistoryResource:"
ast-grep --pattern 'class FamilyMemberHistoryResource {
  $$$
  $_ $_($$$) {
    $$$
  }
}'

Length of output: 702

src/main/java/com/wipro/fhir/repo/common/PatientEligibleForResourceCreationRepo.java (2)

54-117: Verify stored procedure compatibility with BigInteger.

While the parameter type changes are consistent, we need to ensure that the stored procedures in db_iemr database can handle BigInteger parameters correctly.

Let's check the stored procedure definitions:

#!/bin/bash
# Search for stored procedure definitions
fd -e sql | xargs grep -l "PROCEDURE.*FHIR_R_"

# Specific procedures to look for:
procedures=(
  "FHIR_R_AllergyIntolerance"
  "FHIR_R_Diagnosis"
  "FHIR_R_ChiefComplaints"
  "FHIR_R_FamilyMemberHistory"
  "FHIR_R_Appointment"
  "FHIR_R_Encounter"
  "FHIR_R_DiagnosticReportLab"
  "FHIR_R_Vitals_Anthropometry"
  "FHIR_R_MedicationStatement"
  "FHIR_R_PatientDemographic"
)

for proc in "${procedures[@]}"; do
  echo "Searching for $proc:"
  rg "PROCEDURE.*$proc"
done

24-24: LGTM! Verify ID range requirements.

The change from Long to BigInteger is appropriate for handling larger ID values. This is consistent with the broader changes across the codebase.

Let's verify the ID ranges in the database to confirm this change is necessary:

Also applies to: 44-44

✅ Verification successful

The previous search didn't yield SQL files, so let's examine the repository interface and related files to understand the context of this BigInteger change and verify its consistency across the codebase.


Change to BigInteger is consistent and well-implemented

The verification shows that:

  1. All stored procedure calls in the repository consistently use BigInteger for both beneficiaryRegID and visitCode parameters
  2. The repository's CrudRepository extension properly uses BigInteger as the ID type
  3. This is the only repository in the codebase making this change, suggesting it's a targeted modification for this specific use case

The change is properly implemented and maintains consistency across all method signatures within the file.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any SQL schema files that might show the column definitions
fd -e sql | xargs grep -l "beneficiaryRegID\|visitCode"

Length of output: 1931


Script:

#!/bin/bash
# Let's search for stored procedure calls and their parameter types
rg -A 5 "@Procedure|@Query" src/main/java/com/wipro/fhir/repo/common/PatientEligibleForResourceCreationRepo.java

# Also search for similar BigInteger changes in related files
rg "CrudRepository.*BigInteger" --type java

Length of output: 4462

src/main/java/com/wipro/fhir/service/resource_model/MedicationRequestResource.java (3)

Line range hint 85-86: Review type conversion in model mapping.

Ensure that getMedicationRequestList method in MedicationRequestDataModel properly handles type conversion between database types and BigInteger.

#!/bin/bash
# Description: Check type handling in model mapping

# Search for getMedicationRequestList method implementation
ast-grep --pattern 'getMedicationRequestList($params) {
  $$$
}'

Line range hint 82-83: Verify type compatibility with stored procedure.

The SP call might need updates to handle BigInteger parameters if getBeneficiaryRegID() and getVisitCode() have been changed to return BigInteger in ResourceRequestHandler.

#!/bin/bash
# Description: Check ResourceRequestHandler method signatures

# Search for ResourceRequestHandler class definition and its getter methods
ast-grep --pattern 'class ResourceRequestHandler {
  $$$
  $return getBeneficiaryRegID() {
    $$$
  }
  $$$
}'

24-24: Verify unused import and related type changes.

The addition of BigInteger import appears to be in preparation for type changes, but it's currently unused in this file. This suggests incomplete refactoring, especially considering the related changes in MedicationRequestDataModel.

src/main/java/com/wipro/fhir/service/resource_model/AllergyIntoleranceResource.java (2)

24-24: LGTM!

The addition of BigInteger import aligns with the codebase-wide transition from Long to BigInteger for ID fields.


69-69: Verify return types of getter methods for parameter compatibility.

While the formatting change looks good, please ensure that getBeneficiaryRegID() and getVisitCode() return BigInteger to match the updated callAllergySP method signature.

Let's verify the return types:

✅ Verification successful

No type mismatch issues - parameters are compatible

The verification shows that:

  1. ResourceRequestHandler class has beneficiaryRegID and visitCode fields declared as BigInteger
  2. callAllergySP method expects BigInteger parameters
  3. The getter methods will return BigInteger as per the field types

Therefore, the method call is type-safe and no changes are needed.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for the getter method declarations in ResourceRequestHandler
ast-grep --pattern 'getBeneficiaryRegID() {
  $$$
}'

ast-grep --pattern 'getVisitCode() {
  $$$
}'

Length of output: 102


Script:

#!/bin/bash
# Let's try a broader search for these methods using ripgrep
rg "getBeneficiaryRegID|getVisitCode" -A 2

# Also search for the class definition to understand the context
rg "class.*ResourceRequestHandler"

Length of output: 15571


Script:

#!/bin/bash
# Let's check the ResourceRequestHandler class implementation
cat src/main/java/com/wipro/fhir/data/request_handler/ResourceRequestHandler.java

# Also check the callAllergySP method signature
rg "callAllergySP.*\(" -A 2

Length of output: 2633

src/main/java/com/wipro/fhir/service/resource_model/EncounterResource.java (1)

24-24: Verify the necessity of BigInteger import.

The BigInteger import appears to be unused in this file. If this is part of the broader change from Long to BigInteger types, there might be missing updates to the method signatures or field types that interact with the repository layer.

Let's verify the related changes:

src/main/java/com/wipro/fhir/service/resource_model/ConditionResource.java (1)

24-24: Verify if the BigInteger import is necessary.

The BigInteger import appears to be unused in this file. This might be related to the broader changes in the codebase transitioning from Long to BigInteger, but no fields or methods in this class currently use this type.

✅ Verification successful

The BigInteger import is correctly added and necessary

The import is required as this class interacts with ResourceRequestHandler which uses BigInteger for the beneficiaryID field. The getBeneficiaryRegID() method is called multiple times in this class, which returns a BigInteger value.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for BigInteger usage in this file
rg "BigInteger" "src/main/java/com/wipro/fhir/service/resource_model/ConditionResource.java"

# Check if there are any method parameters or return types using BigInteger in related repository
ast-grep --pattern 'interface PatientEligibleForResourceCreationRepo {
  $$$
  $_(BigInteger $_, $_) {
    $$$
  }
  $$$
}'

Length of output: 245


Script:

#!/bin/bash
# Search for any method parameters or return types using BigInteger in this file
ast-grep --pattern '(method_declaration | constructor_declaration) {
  $$$
  BigInteger
  $$$
}'

# Search for any variable declarations using BigInteger
ast-grep --pattern 'variable_declaration_list {
  $$$
  BigInteger
  $$$
}'

# Search for any field declarations using BigInteger
ast-grep --pattern 'field_declaration {
  $$$
  BigInteger
  $$$
}'

# Let's also check if there are any method calls that might require BigInteger
rg -A 2 "\.setBeneficiaryId|\.getBeneficiaryId|\.setVisitCode|\.getVisitCode" "src/main/java/com/wipro/fhir/service/resource_model/ConditionResource.java"

Length of output: 1064


Script:

#!/bin/bash
# Let's check the ResourceRequestHandler class to see if it uses BigInteger
rg -A 2 "class ResourceRequestHandler" 

# Also check the return types of getBeneficiaryRegID and getVisitCode methods
ast-grep --pattern 'class ResourceRequestHandler {
  $$$
  $_ getBeneficiaryRegID() {
    $$$
  }
  $$$
}'

ast-grep --pattern 'class ResourceRequestHandler {
  $$$
  $_ getVisitCode() {
    $$$
  }
  $$$
}'

Length of output: 573

src/main/java/com/wipro/fhir/service/resource_model/ObservationResource.java (1)

24-24: Verify if BigInteger import is needed in this class.

The BigInteger import appears to be unused in this class. While this might be preparation for future changes as part of the Long to BigInteger migration, currently no methods or variables in this class utilize BigInteger.

Let's verify the intended usage:

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

58-59: LGTM: Property injection for ABDM facility ID

The addition of abdmFacilityId property with Spring's @value annotation is well-structured and follows the naming conventions.

src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java (5)

189-189: Typographical Error in Log Message

There is a typo in the log message: "recevied" should be "received".

[typo_fix]
Apply this diff to correct the typo:

-logger.info("*****Fetch beneficiary Id response recevied :", rsObjList);
+logger.info("*****Fetch beneficiary Id response received :", rsObjList);

Line range hint 471-478: Potential Inefficient Loop in getMongoNDHMResponse

Polling the MongoDB in a loop with Thread.sleep(5000) might not be efficient.

[performance_issue]
Consider implementing a more efficient waiting mechanism or using MongoDB change streams for real-time data fetching.


345-346: ⚠️ Potential issue

Potential Null Pointer Exception When Setting Care Context Data

resData[0] and resData[1] are accessed without null checks. If these elements are null, calling toString() will throw a NullPointerException.

Modify the code to handle potential null values:

-cc.setAbdmFacilityId(resData[0] != null ? resData[0].toString() : null );
-cc.setCareContextLinkedDate(resData[1] != null ? resData[1].toString() : null);
+cc.setAbdmFacilityId(resData[0] != null ? resData[0].toString() : "Unknown");
+cc.setCareContextLinkedDate(resData[1] != null ? resData[1].toString() : "Unknown");

Likely invalid or redundant comment.


387-387: ⚠️ Potential issue

Null Check Before Sending SMS

Before sending the advertisement SMS, there should be a null check for pDemo.getPreferredPhoneNo() to avoid potential NullPointerException.

Ensure a null check is in place:

-if (pDemo.getPreferredPhoneNo() != null)
+if (pDemo.getPreferredPhoneNo() != null && !pDemo.getPreferredPhoneNo().isEmpty())
    sendAbdmAdvSMS(pDemo.getPreferredPhoneNo());
else
    throw new FHIRException("Advertisement SMS could not be sent as beneficiary phone number not found");

Likely invalid or redundant comment.


Line range hint 601-606: Hardcoded Accept-Language Header

In sendAbdmAdvSMS, the abhaMode is set to "sbx" if it doesn't match "abdm" or "sbx". This might cause issues in production environments.

Please verify that the abhaMode is correctly set according to the environment.

Run the following script to check all occurrences of abhaMode assignments:

@@ -41,11 +45,11 @@ public class TempCollection {

@Expose
@Field(value = "BeneficiaryRegID")
private Long beneficiaryRegID;
private BigInteger beneficiaryRegID;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Type inconsistencies found - Migration and code updates required

Several files still use Long type for beneficiaryRegID and visitCode which need to be updated for consistency with the BigInteger conversion:

  • PatientDemographicDetails.java: Uses Long beneficiaryRegID
  • CreateHealthIDWithMobileOTP.java: Uses Long in request params and JSON processing
  • BenHealthIDMapping.java: Uses Long beneficiaryRegID
  • NDHM_TRG_VisitData.java: Uses Long visitCode
  • T_PatientIssue.java: Uses Long visitCode
  • CommonServiceImpl.java: Uses Long visitCode in JSON processing

The repository layer (TempCollectionRepo.java) is already updated to use BigInteger, but the inconsistency with other components could cause type conversion issues.

🔗 Analysis chain

Verify data migration strategy for Long to BigInteger conversion.

The type changes from Long to BigInteger for beneficiaryRegID and visitCode are appropriate for handling larger values. However, please ensure that:

  1. Existing data in MongoDB will be properly migrated
  2. Any queries or aggregations using these fields are updated
  3. Related services and repositories handle this type change consistently

Let's verify the consistency of this change across the codebase:

Also applies to: 52-52

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any remaining Long usages of beneficiaryRegID and visitCode
# that might need to be updated for consistency

echo "Checking for potential inconsistencies in type usage..."

# Search for beneficiaryRegID usage with Long type
rg -t java "Long.*beneficiaryRegID|beneficiaryRegID.*Long" -g "!target/*"

# Search for visitCode usage with Long type
rg -t java "Long.*visitCode|visitCode.*Long" -g "!target/*"

# Search for MongoDB queries using these fields
rg -t java "find.*beneficiaryRegID|find.*visitCode" -g "!target/*"

Length of output: 1776

@@ -39,19 +43,19 @@ public class AMRIT_ResourceMongo {

@Expose
@Field(value = "BeneficiaryRegID")
private Long beneficiaryRegID;
private BigInteger beneficiaryRegID;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codebase verification

Inconsistent type usage detected between Long and BigInteger

The verification reveals several inconsistencies that need to be addressed:

  • TempCollectionRepo uses BigInteger for beneficiaryRegID and visitCode
  • Multiple classes still use Long for the same fields:
    • PatientDemographicDetails: beneficiaryRegID, beneficiaryID
    • BenHealthIDMapping: beneficiaryRegID, beneficiaryID
    • T_PatientIssue: visitCode, beneficiaryID
    • NDHM_TRG_VisitData: visitCode
  • Service layer methods like getBenHealthID(Long benRegID) in HealthIDService still expect Long parameters
  • No type conversion logic found between Long and BigInteger except for a single Redis-related usage

The type change needs to be consistently applied across all related classes and layers to prevent runtime type mismatches.

🔗 Analysis chain

Verify BigInteger type changes across the codebase.

The change from Long to BigInteger for ID fields is significant. While this allows for larger values, we should ensure:

  1. All related repositories and services handle BigInteger correctly
  2. Any existing queries or comparisons are updated
  3. Performance impact is considered as BigInteger operations are more expensive

Also applies to: 50-50, 58-58


Let me gather more information about the repository methods and service layer to better understand the impact.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for potential inconsistencies in ID field types

# Look for Long type usage in related files
echo "Checking for potential missed Long to BigInteger conversions..."
rg -t java "private\s+Long\s+(beneficiaryRegID|beneficiaryID|visitCode)" src/

# Check repository methods that might need updates
echo "Checking repository methods that might need updates..."
ast-grep --pattern 'interface $_Repository {
  $$$
  findBy$_(Long $_) {
    $$$
  }
  $$$
}'

Length of output: 1114


Script:

#!/bin/bash
# Check repository interfaces and service methods for Long parameters
echo "Checking repository interfaces for Long parameters..."
rg -t java "findBy\w+\(\s*Long\s+" src/

echo "Checking service methods with Long parameters..."
rg -t java "public\s+\w+\s+\w+\(\s*Long\s+" src/

# Check for BigInteger usage in repository and service layers
echo "Checking BigInteger usage..."
rg -t java "findBy\w+\(\s*BigInteger\s+" src/
rg -t java "public\s+\w+\s+\w+\(\s*BigInteger\s+" src/

# Check for potential type conversion or comparison
echo "Checking for Long/BigInteger comparisons or conversions..."
rg -t java "(Long\.valueOf|\.longValue\(\)|\.toBigInteger\(\))" src/

Length of output: 2784

cc.setCareContextLinkedDate(resData[1] != null ? resData[1].toString() : null);
}

logger.info("********data to be saved in mongo :" , cc);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Incorrect Logging Syntax

Similar to the previous issue, the logging statement uses a comma instead of a placeholder, which may lead to improper logging.

Apply this diff to fix the logger statement:

-logger.info("********data to be saved in mongo :" ,  cc);
+logger.info("********data to be saved in mongo : {}", cc);
📝 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
logger.info("********data to be saved in mongo :" , cc);
logger.info("********data to be saved in mongo : {}", cc);

…nServiceImpl.java

Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
3 Security Hotspots

See analysis details on SonarQube Cloud

Copy link
Member

@ravishanigarapu ravishanigarapu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks ok

@ravishanigarapu ravishanigarapu merged commit a53760b into PSMRI:develop Nov 27, 2024
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants