-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
FI-2460: Support for HL7 validator wrapper #488
Conversation
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 seems to be working well for me, but I expect your FHIR core PR will need to get in before we could use this in production. We should see what @arscan thinks as well. I think the next steps are something like the following:
- Make a subclass of the g10 suite, change its id, and have one use the current validator and one use the new validator so that we'll be able to support both during a transition period. I'm not sure whether we'll want the "real" g10 suite to use the new validator to ensure it gets broad testing or the current one to minimize any potential disruption. I guess this would need two version of the configuration checker as well.
- Update the US Core and SMART App Launch test suites to use the new validator so that we'll be ready to completely cut over and remove the current validator from this repo.
case (us_core_version_requirement[:us_core_version]) | ||
when G10Options::US_CORE_3 | ||
igs('hl7.fhir.us.core#3.1.1') | ||
us_core_message_filters = USCoreTestKit::USCoreV311::USCoreTestSuite::VALIDATION_MESSAGE_FILTERS |
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 don't understand why this assignment was changed.
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.
It just felt strange to have the igs
line in the middle of the case
when the result of that case is assigning to a separate variable. I'm probably going to revert this anyway because I suspect there's a better way to define the IG for each option.
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.
Having the igs
lines there wouldn't interfere with the original assignment style.
How will the "two suites" approach look from a user perspective? Will we show the two suites on the start page and the user has to pick one? |
We'll want to discuss that with @arscan |
* FI-2532: add feature flag to switch between inferno validator and hl7 validator wrapper * standardize name * default hl7 validator to false and comment out its services
6364702
to
e05dab1
Compare
This PR enables support for the the g10-test-kit to use the original Inferno validator wrapper or the HL7 validator wrapper, toggled by the env var
USE_HL7_RESOURCE_VALIDATOR
. From the user perspective, there should be no visible change. If I've done this right then it should be plug & play.Summary of changes:
validator
block in test suite to a conditional that selectsvalidator
orfhir_resource_validator
based on a new env varUSE_HL7_RESOURCE_VALIDATOR
. Addigs
setting to this block if using the HL7 validator.cli_context
block to specify validator settings:txServer nil
disables use of a TX server. Aligns withDISABLE_TX
env var in the inferno validatordisplayWarnings true
sets any "display issue" messages to be warnings instead of errors. Aligns withDISPLAY_ISSUES_ARE_WARNINGS
env var in the inferno validatordisableDefaultResourceFetcher true
disables fetching and validating against any unknown profiles found in a resource. (This is now a default in inferno-core, not yet released though. No harm in keeping this setting here temporarily or forever)New error messages that need to be ignored -- there are two messages that occur per usage of a mime type (CapabilityStatement, DocumentReference, some uses of DiagnosticReport)
![image (12)](https://private-user-images.githubusercontent.com/13512036/310959914-9875510d-08c1-45b9-a814-eb26f2069956.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkwMDkxNDcsIm5iZiI6MTczOTAwODg0NywicGF0aCI6Ii8xMzUxMjAzNi8zMTA5NTk5MTQtOTg3NTUxMGQtMDhjMS00NWI5LWE4MTQtZWIyNmYyMDY5OTU2LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA4VDEwMDA0N1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTk1ODgyODlkOWRmZDliNWQ2ZTQwMDkxMmFlNTllMzc4MDY3ODY0NzU4ZDIxNzE3NGI1YjM0NjI2NjVkYmNhZjImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.3YacEvFeaT_HuwdAiSqL7hYGdnbhp9AXYqpNNfN0O7M)