Stream: conformance
Topic: Simplifier - Git Worklow FHIR Validation
Kevin Mayfield (May 11 2021 at 15:07):
@Ward Weistra is it possible to add multiple directories using this parameter
PATH_TO_CONFORMANCE_RESOURCES: StructureDefinition
Have tried using coma's.
Kevin Mayfield (May 11 2021 at 15:08):
Alexander Zautke (May 11 2021 at 16:53):
Different paths should be separated by whitespace, will add this to the documentation, thanks!
An example can be found here: https://github.com/medizininformatik-initiative/kerndatensatzmodul-person/actions/runs/788553754/workflow
Alexander Zautke (May 11 2021 at 16:56):
Also with the current version, example validation won't work, it's still a work in progress. Let me know if you need anything else in your pipeline.
Kevin Mayfield (May 12 2021 at 04:53):
That worked fine.
Have also tried using java validation. Ran into this issue.
Screenshot-2021-05-12-at-05.53.30.png
Kevin Mayfield (May 12 2021 at 04:59):
Not sure if my package json is correct but the package is on simplifier and when using the fhirvalidator directly I would specify like
-ig https://packages.simplifier.net/${packageName}/-/${packageName}-${version}.tgz
Extract from package.json:
"dependencies": {
"UK.Core.r4.v2": "2.0.8",
"hl7.fhir.r4.core": "4.0.1"
}
Do we need to publish the UK.Core.r4.v2 differently?
Alexander Zautke (May 12 2021 at 08:09):
Looks like the same issue reported here to me: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Error.20loading.20package.20in.20java.20validator
Alexander Zautke (May 12 2021 at 08:10):
@Ward Weistra Any thoughts?
Alexander Zautke (May 12 2021 at 08:10):
Can you try to use "uk.core.r4.v2"?
Kevin Mayfield (May 12 2021 at 08:26):
Looking great so far
Kevin Mayfield (May 12 2021 at 08:51):
Had issues around the use of subdirectories in java validation.
It worked but the use of subdirectories meant it failed to pick up conformance directories in other folders.
Ward Weistra (May 12 2021 at 09:54):
@Kevin Mayfield Can you explicitly confirm that the Java validator failed when you specified UK.Core.r4.v2
as a dependency, but succeeded when specifying it as uk.core.r4.v2
?
This is the confirmation I'm trying to give Grahame in this conversation.
And thanks for jumping on the pipeline so quickly! :muscle:
Kevin Mayfield (May 12 2021 at 10:04):
Yes that is correct, java validation worked with uk.core.r4.v2
but not UK.Core.r4.v2
Grahame Grieve (May 13 2021 at 23:03):
ok I think this is fixed next release (not the one happening now)
Kevin Mayfield (May 14 2021 at 07:56):
We may want to look at how we validate at a pre packaged state (i.e. the package in git form).
Our structure (at present) subdivides the resources by type
image.png
Kevin Mayfield (May 14 2021 at 07:58):
Also our examples don't specify the profiles they conform to. We've started using the CapabilityStatement (kind=requirements) to state the default profile to be used.
Kevin Mayfield (May 14 2021 at 07:59):
e.g. https://github.com/NHSDigital/NHSDigitial-FHIR-ImplementationGuide/blob/master/CapabilityStatement/api.xml
or simplifier version
https://simplifier.net/guide/NHSDigital/CapabilityStatement
Grahame Grieve (May 14 2021 at 20:53):
We may want to look at how we validate at a pre packaged state
I'm not clear quite you're saying there, about who might do what?
Kevin Mayfield (May 16 2021 at 16:55):
What I'm wanting to do is validate commited resources against the very latest files on git and/or simplifier.
Kevin Mayfield (May 16 2021 at 16:57):
Thinking about itt, not sure how that would be done.
Do I need a package generated on every change in simpifier/git - a dev/test package?
Kevin Mayfield (May 16 2021 at 16:59):
What I'm doing at the moment is using a modified HAPI FHIR Validator to test the package but I have to create one for each test. I'm looking at simplifier git workflow to move the testing to an earlier stage.
Alexander Zautke (May 16 2021 at 19:12):
I think the Firely.Terminal pipeline is missing two feature at the moment to enable the described behaviour:
- Validate all conformance resources together (in the Java validator). Currently, with your folder structure, it would validate each folder individually, meaning that you e.g. wouldn't have access to your ValueSets when validating the StructureDefinitions.
- Validate the resource against the latest definition of your profiles without annotating them with meta.profile
Alexander Zautke (May 16 2021 at 19:14):
The .NET part of the pipeline already validates all conformance resources in a single context, but it's missing a few extra validation rules that are part of the Java validator.
Alexander Zautke (May 17 2021 at 15:15):
Kevin Mayfield said:
Had issues around the use of subdirectories in java validation.
It worked but the use of subdirectories meant it failed to pick up conformance directories in other folders.
@Kevin Mayfield Could you try out version v0.2.0-alpha2 of the Firely.Terminal Pipeline? This version includes the latest version of the validator, so the issue regarding the capitalization of the package should be fixed. Additionally, all subfolders are now included in the validation context.
Kevin Mayfield (May 18 2021 at 05:00):
Thanks. Testing at the moment, will let you know of any issues.
Ward Weistra (May 18 2021 at 16:13):
@Kevin Mayfield @Alexander ZautkeRegarding "Validate examples against a profile without specifying it in meta.profile":
We will work on allowing you to explicitly configure in your Quality Control rules what (group of) example(s) to validate against what resource.
I believe matching this just based on the baseResource of an example against the one or more profiles on that type will be too course (if I understand the idea correctly). E.g., there will potentially be loads of profiles and examples based on the Observation resource. We will need some other way to, e.g., based on FHIRPath, specify which one to validate against which.
The Quality Control rules will allow us to do that (e.g., if Observation.Code = '1234' validate against BloodPressure profile). I believe at some point FHIR servers will also need this kind of similar configuration to specify where each incoming Observation-based FHIR instance needs to go/to be validated against.
Kevin Mayfield (May 18 2021 at 19:34):
Would be OK with just specifying default profile for a resource type for time being.
Last updated: Apr 12 2022 at 19:14 UTC