-
Notifications
You must be signed in to change notification settings - Fork 9
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
Transformation rule engine implementation #1046
Conversation
…gine implementation
Added dummy definitions from design discussion
…formation-engine-implementation
Fix method names
Updated one of the failing tests
Use double checked locking on ensureRulesloaded
Update more test cases
All tests pass
…/CDCgov/trusted-intermediary into story/1024/transformation-engine
...gov/hhs/cdc/trustedintermediary/etor/ruleengine/transformation/CustomFhirTransformation.java
Dismissed
Show dismissed
Hide dismissed
...in/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/validation/ValidationRuleEngine.java
Outdated
Show resolved
Hide resolved
...gov/hhs/cdc/trustedintermediary/etor/ruleengine/transformation/TransformationRuleEngine.java
Outdated
Show resolved
Hide resolved
shared/src/main/java/gov/hhs/cdc/trustedintermediary/context/ApplicationContext.java
Show resolved
Hide resolved
shared/src/main/java/gov/hhs/cdc/trustedintermediary/context/ApplicationContext.java
Show resolved
Hide resolved
e2e/src/test/groovy/gov/hhs/cdc/trustedintermediary/e2e/DemographicsTest.groovy
Outdated
Show resolved
Hide resolved
.../java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/transformation/TransformationRule.java
Show resolved
Hide resolved
…per class with static methods
Quality Gate failedFailed conditions |
package gov.hhs.cdc.trustedintermediary.etor.orders; | ||
|
||
/** Interface for converting things to orders and things in orders. */ | ||
public interface OrderConverter { |
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.
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.
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.
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 { |
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.
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); |
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.
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?
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.
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); |
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.
Same as the transformation for convertToOmlOrder
@Override | ||
public void transform(FhirResource<?> resource, Map<String, String> args) { | ||
Bundle bundle = (Bundle) resource.getUnderlyingResource(); | ||
HapiOrderConverterHelper.addContactSectionToPatientResource(bundle); |
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.
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 { |
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.
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?
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.
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) { |
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.
Could we make these methods more generic? Like ConvertToOrderType
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.
That's a great idea. As I wrote on a response to Jorge, I think we should refactor this helper in a separate PR
We're bypassing the SonarCloud duplication notice because we are saving refactoring of Rule Engines for a future PR. |
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.
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.
Transformation rule engine implementation
Transformation rule engine implementation
Note: there is code duplication in
ValidationRuleEngine
andTransformationRuleEngine
that we have decided to refactor in a future PRIssue
#1024
Checklist