Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Transformation rule engine implementation #1046

Merged
merged 181 commits into from
May 9, 2024

Conversation

basiliskus
Copy link
Contributor

@basiliskus basiliskus commented Apr 26, 2024

Transformation rule engine implementation

Transformation rule engine implementation

Note: there is code duplication in ValidationRuleEngine and TransformationRuleEngine that we have decided to refactor in a future PR

Issue

#1024

Checklist

  • I have added tests to cover my changes
  • I have added logging where useful (with appropriate log level)
  • I have added JavaDocs where required
  • I have updated the documentation accordingly

@basiliskus basiliskus changed the base branch from main to story/1024/transformation-engine April 26, 2024 22:01
Copy link

sonarqubecloud bot commented May 8, 2024

Quality Gate Failed Quality Gate failed

Failed conditions
7.5% Duplication on New Code (required ≤ 3%)

See analysis details on SonarCloud

@basiliskus basiliskus marked this pull request as ready for review May 8, 2024 19:14
package gov.hhs.cdc.trustedintermediary.etor.orders;

/** Interface for converting things to orders and things in orders. */
public interface OrderConverter {
Copy link
Contributor

@jorg3lopez jorg3lopez May 8, 2024

Choose a reason for hiding this comment

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

All three methods from this interface belong to the general flow of the code. Are we going to create a section in the Transformation Engine that will be for our default transformations and a section for custom ones? I'm thinking on a way of separating the default behavior with the custom one. I also see that the custom transformations will go under the transformations/custom folder. Maybe these can live in a system default folder: transformation/system-default folder.

Copy link
Contributor Author

@basiliskus basiliskus May 9, 2024

Choose a reason for hiding this comment

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

This PR replaces the transformation in OrderConverter and ResultConverter. There's no distinction between default or custom behavior. Is there a benefit to have them separated? If we want, we could add a "default" flag in the json file in a future PR. We could discuss this in eng. block

package gov.hhs.cdc.trustedintermediary.etor.results;

/** Interface for converting things to results and things in results. */
public interface ResultConverter {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment as the one for OrderConverter

@Override
public void transform(FhirResource<?> resource, Map<String, String> args) {
Bundle bundle = (Bundle) resource.getUnderlyingResource();
HapiOrderConverterHelper.convertToOmlOrder(bundle);
Copy link
Contributor

@jorg3lopez jorg3lopez May 8, 2024

Choose a reason for hiding this comment

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

I was thinking that the logic was going to be part of the transformation object. But instead, it calls a helper class that has the logic there. What would be the difference if we have the logic in here, so if we need to change the logic, we go toconvertToOmlOrder.java instead of the helper class, and the helper class can be a wrapper that calls all the transformation objects?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could have the logic here. The idea of having the helper is to have functions that could be used by multiple transformations. I don't think we have that right now but I'd propose to leave this refactoring to a separate PR

@Override
public void transform(FhirResource<?> resource, Map<String, String> args) {
Bundle bundle = (Bundle) resource.getUnderlyingResource();
HapiMessageConverterHelper.addEtorTagToBundle(bundle);
Copy link
Contributor

Choose a reason for hiding this comment

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

Same as the transformation for convertToOmlOrder

@Override
public void transform(FhirResource<?> resource, Map<String, String> args) {
Bundle bundle = (Bundle) resource.getUnderlyingResource();
HapiOrderConverterHelper.addContactSectionToPatientResource(bundle);
Copy link
Contributor

Choose a reason for hiding this comment

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

Same as the transformation for convertToOmlOrder

import org.hl7.fhir.r4.model.Patient;

/** Helper class with transformation methods that take an order Bundle and modifies it */
public class HapiOrderConverterHelper {
Copy link
Contributor

Choose a reason for hiding this comment

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

Check the comments for the transformation objects. Thoughts on having the transformation logic as part of each object and having this class be a wrapper that couples with all the transformation objects?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed that we need refactoring and move logic between helper and transformations. As mentioned above, I propose to do it in a separate PR

new Coding(
"http://terminology.hl7.org/CodeSystem/v3-RoleCode", "MTH", "mother"));

public static void convertToOmlOrder(Bundle order) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we make these methods more generic? Like ConvertToOrderType

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a great idea. As I wrote on a response to Jorge, I think we should refactor this helper in a separate PR

@luis-pabon-tf
Copy link
Contributor

We're bypassing the SonarCloud duplication notice because we are saving refactoring of Rule Engines for a future PR.

Copy link
Contributor

@luis-pabon-tf luis-pabon-tf left a comment

Choose a reason for hiding this comment

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

This is a very thoroughly worked on PR, with good coverage and tested functionality. Code refactoring is needed, but due to the size of the PR it will be better off done separately.

@halprin halprin merged commit 04693bf into main May 9, 2024
15 of 16 checks passed
@halprin halprin deleted the story/1024/transformation-engine-implementation branch May 9, 2024 17:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants