-
Notifications
You must be signed in to change notification settings - Fork 24
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
Conversation
WalkthroughThe 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 Changes
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
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
src/main/java/com/wipro/fhir/data/mongo/amrit_resource/AMRIT_ResourceMongo.java
Show resolved
Hide resolved
There was a problem hiding this 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:
- Validation constraints to ensure data integrity
- Documentation for better understanding
- 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:
- Consider adding field validations using Bean Validation annotations (e.g.,
@NotNull
,@Size
)- Implement proper sanitization for string fields like
healthId
,phoneNo
- 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 theequals
/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
andabdmFacilityId
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
orDate
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
andDisplay
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 needequals()
andhashCode()
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:
- Add field-level validation annotations (e.g.,
@NotNull
for required fields)- Consider adding MongoDB indexes for frequently queried fields
- 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 commentThe class appears to be a MongoDB document but lacks necessary annotations. Consider the following improvements:
- Remove the inline comment "give common name"
- Add
@Document
annotation- 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 documentationThe new ABDM facility fields should follow proper encapsulation and documentation practices:
- Use private access modifier
- Add field-level validation
- 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 validationThe new methods should:
- Follow consistent indentation
- Include JavaDoc documentation
- 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 generatedtoString()
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 +@Settersrc/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:
@NotNull
for mandatory fields@Size
or custom validators for string fields- 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:
Create proper request/response DTOs:
FacilityRequest
for POST endpoint inputFacilityResponse
for standardized API responsesFacilityDTO
for service layer data transferImplement a global error handling mechanism:
- Use
@ControllerAdvice
for consistent error responses- Define specific error codes and messages
- Create custom exceptions for different error scenarios
Add input validation:
- Use Bean Validation (
@Valid
) for request DTOs- Implement custom validators if needed
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
toBigInteger
forid
,beneficiaryRegID
, andvisitCode
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
toBigInteger
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 onsrc/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 valueThe update method looks correct but could benefit from:
- Input validation for abdmFacilityId (e.g., @NotNull, @SiZe constraints)
- 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:
- Removing the hardcoded value
- Getting the description from the appointment data model
- 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/getServicessrc/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:
- Remove the space after the equals sign
- 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=sbxsrc/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:
- Grouping related properties under clear section headers
- Adding descriptive comments for each section
- 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 scenariosThe 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 changesThe 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 securityConsider implementing the following security improvements:
- Clear sensitive data from the map after use
- Use a secure string handling mechanism for credentials
- 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 parametersbeneficiaryID
in the patient demographic datagenderID
in the patient demographic datasrc/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:
- Adding JSDoc documentation explaining the purpose and format of this field
- 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:
- Use more specific exceptions instead of generic
FHIRException
- Add input validation for the JSON request
- 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:
- Add rate limiting for OTP generation to prevent abuse
- Implement audit logging for compliance tracking
- 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:
- Extracts status determination into a separate method
- Makes the priority order (specialist > doctor > nurse) more explicit
- Reduces code duplication in status mapping
- 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
andgenerateConditionResource_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:
- Extract common code into a helper method
- Create constants for observation codes
- 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:
- Add input validation
- Use StringBuilder instead of StringBuffer (thread safety not needed here)
- 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 validationWhile 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 constantThe constant
ACCEPTED = 202
is no longer used as the code now usesHttpStatus.ACCEPTED.value()
. Consider removing this unused field.
Line range hint
134-148
: Consider refactoring error handling patternsThe error handling logic is duplicated across multiple methods. Consider:
- Creating a centralized error handling utility
- Extracting common JSON parsing logic
- 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 dataThe code logs API requests and responses which might contain sensitive healthcare information. Consider:
- Implementing proper log masking for sensitive data
- Adding debug level logging for detailed information
- 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 deprecatedJsonParser
constructorThe
JsonParser
default constructor is deprecated in recent versions of Gson. It is recommended to useJsonParser.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 callingcontains
methodThe
types
variable is derived fromasJsonObject.get("types").toString()
, which will not benull
but could be the string"null"
. The null checknull != 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 isnull
in the JSON.
67-71
: Simplify JSON parsing by using Gson'sfromJson
methodManually 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 exceptionWhen 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-lineif-else
blocks with bracesFor better readability and to avoid potential bugs during future modifications, it's recommended to use braces
{}
even for single-lineif
orelse
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 potentialJsonSyntaxException
when parsing the request objectParsing 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 efficientFetching 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 lineThere is an unnecessary empty line that can be removed for cleaner code.
Remove the empty line at line 79.
58-59
: Avoid unnecessary initialization ofJsonObject
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 formatsEnsure 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 ComparisonWhen comparing
BigInteger
with zero, it's more efficient to useBigInteger.ZERO.compareTo(resultSet.getId())
instead ofresultSet.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 ifccList
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 SpecificallyCatching 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 ResponseThe method
searchPatientProfileFromMongo
might return null if none of the conditions are met, which can lead toNullPointerException
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
📒 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
viaBenHealthIDMappingRepo.updateFacilityIdForVisit()
- Properly configured with MongoDB infrastructure based on environment properties
- The
BigInteger
type forvisitCode
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:
- The repository method is called only in
CommonServiceImpl.fetchTempResourceFromMongo
- The
ResourceRequestHandler
class has both fields declared asBigInteger
: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:
- Ensure all database schemas can handle the larger number type
- Verify that all related services and repositories handle these fields consistently
- 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:
- That all necessary Lombok dependencies are properly configured in the build file
- 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:
- Lombok is correctly configured in pom.xml with version 1.16.18
- The annotation processor path is properly set up in the build configuration
- @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:
- All existing getter/setter methods have been removed to avoid duplication
- 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:
- The database column type for
beneficiaryID
supports the full range of BigInteger - 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:
- The entity
TRG_PatientResourceData
usesBigInteger
forbeneficiaryID
field - The
ResourceRequestHandler
class also usesBigInteger
forbeneficiaryID
- The service layer correctly handles the BigInteger type in method calls
- 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:
- The database columns can handle the larger number ranges
- 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:
-
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);
-
The pattern of BigInteger usage is consistent across multiple data models (DiagnosticReport, Appointment, MedicationRequest, etc.), indicating this is an established pattern in the codebase.
-
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:
- The model is used only in
ObservationResource
for data transformation, not directly for persistence - Similar
BigInteger
changes have been consistently applied across multiple resource models in the same package - Spring JPA is configured with MySQL dialect and the application doesn't use explicit type converters
- 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:
- All resource models (Vitals, Lab, Encounter, etc.) use BigInteger for these fields
- Repository methods and stored procedures have been updated to handle BigInteger parameters
- 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
:
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:
- Update the parameter types in callAppointmentSP method call
- Update any internal processing of these IDs
- 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:
- Is this intentional?
- Are there any compatibility issues to consider?
- 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:
- Is this intentional and aligned with ABDM's API versioning strategy?
- Are there any breaking changes between v1 and v0.5?
- 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:
- The v0.5 version is consistently used across all environments (test, dev, example) for gateway authentication and care context APIs
- Other ABDM APIs (health ID, registration, etc.) consistently use v1/v2 versions
- 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:
- This file is properly added to
.gitignore
- Sensitive values use consistent placeholder format
- 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:
- Is contained within the
APIChannelImpl
class - Gets sent as part of the standard authentication request
- 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
usesBigInteger
for its parameters in thecallFamilyMemberHistorySP
method - No
Long
type usages were found in theFamilyMemberHistoryResource
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:
- All stored procedure calls in the repository consistently use
BigInteger
for bothbeneficiaryRegID
andvisitCode
parameters - The repository's CrudRepository extension properly uses
BigInteger
as the ID type - 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:
ResourceRequestHandler
class hasbeneficiaryRegID
andvisitCode
fields declared asBigInteger
callAllergySP
method expectsBigInteger
parameters- 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 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
:
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:
src/main/java/com/wipro/fhir/data/mongo/care_context/SaveFacilityIdForVisit.java
Show resolved
Hide resolved
src/main/java/com/wipro/fhir/data/mongo/care_context/SaveFacilityIdForVisit.java
Show resolved
Hide resolved
@@ -41,11 +45,11 @@ public class TempCollection { | |||
|
|||
@Expose | |||
@Field(value = "BeneficiaryRegID") | |||
private Long beneficiaryRegID; | |||
private BigInteger beneficiaryRegID; |
There was a problem hiding this comment.
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
: UsesLong beneficiaryRegID
CreateHealthIDWithMobileOTP.java
: UsesLong
in request params and JSON processingBenHealthIDMapping.java
: UsesLong beneficiaryRegID
NDHM_TRG_VisitData.java
: UsesLong visitCode
T_PatientIssue.java
: UsesLong visitCode
CommonServiceImpl.java
: UsesLong 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:
- Existing data in MongoDB will be properly migrated
- Any queries or aggregations using these fields are updated
- 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; |
There was a problem hiding this comment.
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
usesBigInteger
forbeneficiaryRegID
andvisitCode
- 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)
inHealthIDService
still expectLong
parameters - No type conversion logic found between
Long
andBigInteger
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:
- All related repositories and services handle BigInteger correctly
- Any existing queries or comparisons are updated
- 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
src/main/java/com/wipro/fhir/service/common/CommonServiceImpl.java
Outdated
Show resolved
Hide resolved
cc.setCareContextLinkedDate(resData[1] != null ? resData[1].toString() : null); | ||
} | ||
|
||
logger.info("********data to be saved in mongo :" , cc); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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>
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks ok
📋 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
ℹ️ 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
abdmFacilityId
and updated endpoints to versionv0.5
.FacilityService
interface for fetching registered facilities and saving facility IDs.FacilityServiceImpl
class to handle facility-related operations.Bug Fixes
Refactor
Long
toBigInteger
across multiple classes and repositories to accommodate larger values.Documentation