0

Profile packages list their dependencies in the form of packages and their versions, but the dependency graph derived from that information is not always sufficient for configuring a validation context. Better analysis could be done if the dependencies were available at the level of individual resources; this would make it possible to identify conflicts/contradictions and missing resources that cannot be uncovered by package-level analysis (but which might wreak havoc under the hood).

Is there a way to obtain a list of dependencies for some particular validation resource like e.g. a StructureDefinition pulled from a package file?

Validators have to do that internally in the normal course of their work in any case, but I cannot see a way of getting that information out. Can it be done with the HAPI or Firely libraries? If not, is there some other way of getting that information?

DarthGizka
  • 4,347
  • 1
  • 24
  • 36

3 Answers3

2

There's a new IG (http://build.fhir.org/ig/HL7/crmi-ig/) that's proposing an operation that would gather all dependencies. However, it's not fully baked, and to my knowledge, not yet implemented anywhere.

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • Thanks, Lloyd. It may not solve the immediate problem but it seems like a particularly rich vein of ore. Off to mine me some gold now .... ;-) – DarthGizka May 23 '23 at 16:43
1

Validators have to do that internally in the normal course of their work in any case

Yes, indeed "during the normal course of their work", so the .NET validator does this at runtime ("go fetch profile X and validate it") - but there is no static analysis done here. It would always be incomplete, by the way, since extensions can introduce references to profiles not known until you hit an instance with that extension.

Maybe Gino's code generator (https://github.com/microsoft/fhir-codegen) has the information, is does a full load of profiles before it starts running its code generators.

DarthGizka
  • 4,347
  • 1
  • 24
  • 36
Ewout Kramer
  • 984
  • 6
  • 9
  • For the primary use case there is no danger of unspecified extensions occurring. The Germanic profiles in questions are nailed shut, tightly. So tight that it is not possible to create conforming instances in some cases. ;-) Besides, everybody lives in holy terror of the Krankenkassen (mandatory health insurance) and so nobody would dare risk not getting paid by adding anything that is not 100.000000% orthodox. Even if you're 100% right, a court decision in your favour would be years away whereas you'd go bust right this month. – DarthGizka May 23 '23 at 16:35
  • In any case, even a fully static analysis would be of enormous value. First by uncovering the plethora of holes/bugs in the profiles (Simplifier seems to do little or no validation when accepting profile packages for publication), and second for configuring validation contexts with much more surgical precision than merely juggling packages and hoping for the best. – DarthGizka May 23 '23 at 16:40
  • Thank you for the pointer go Gino's code generator. This is extremely interesting, but it will take some time to study this little gold mine. I will report back here if I find something that can help solve the immediate problem that I posed. – DarthGizka May 23 '23 at 16:54
  • It seems that Gino does only package-level dependency analysis and for the rest he seems to rely mostly on snapshots (with deeper analysis for ValueSet and CapabilityStatement). This makes total sense, of course. The snapshot contains all that is needed for modelling the stuff in the target system. What's not needed is the info where it all came from, it's sufficient that it is all there. ;-) So, because of the nature of the project Gino had no need to solve the problem we're discussing here ... In any case the project is well worth studying. – DarthGizka May 23 '23 at 18:37
1

Validators have to do that internally in the normal course of their work in any case

That's not quite something that they do. What they do is resolve specific links as they encounter them based on the data that they are validating. That's not the same thing.

Grahame Grieve
  • 3,538
  • 3
  • 15
  • 17
  • You are right, my statement was rather imprecise, and your point is an important one. One consequence is that intercepting the communication between a validator and its validation support chain will usually catch only a subset of all dependencies; tx is particularly thorny in that regard. – DarthGizka May 24 '23 at 06:59
  • Grahame's objection is also important for another reason: static analysis of *profiles* alone cannot deliver satisfactory results whenever *instances* are allowed to use specialisations, like when the type constraint for a reference specifies only the HL7 base type (e.g. `http://hl7.org/fhir/StructureDefinition/Medication`) and the actual requirements are hidden in comments or other human-only documentation. – DarthGizka May 26 '23 at 09:16
  • 1
    but in spite of that, it's still potentially a useful thing to know. So from the next release, the validator will be able to produce output like this on request: Find Dependencies for http://hl7.org/fhir/us/core/CapabilityStatement/us-core-server|6.0.0 from hl7.fhir.us.core#6.0.0 Depends On http://hl7.org/fhir/us/core/StructureDefinition/us-core-allergyintolerance|6.0.0 from hl7.fhir.us.core#6.0.0 .... – Grahame Grieve May 30 '23 at 04:22
  • Wonderful! :-) Among other things, this can be extremely helpful for vetting packages before publication, especially in ecosystems like electronic prescriptions in Teutonia where the aspiration is to nail everything shut so tight that not even an ant could smuggle in an extension edgewise. – DarthGizka May 30 '23 at 12:29