Stream: cql
Topic: cqf-tooling for custom IG ModelInfo
Matt Sargent (Sep 30 2020 at 16:14):
I recently came across the cqf-tooling repo, and was wondering if there is support for generating ModelInfo from custom FHIR structure definitions. I have been handed some FHIR shorthand as input and generate the structure definitions from the shorthand.
It seems like StructureDefinitionToModelInfo expects to fail when not running for one of the implemented models (https://github.com/cqframework/cqf-tooling/blob/f1c3ed8d9c14dc8c5af37556ff678953e1c33e32/src/main/java/org/opencds/cqf/modelinfo/StructureDefinitionToModelInfo.java#L141), and indeed the program has null pointer exceptions related to class/model info objects when running with a custom model name.
Is the best way around this to implement the ClassInfoBuilder/ModelInfoBuilder classes for the custom structures I have? Alternatively, is there a way to use one of the existing models, but provide my own definitions? Or is this tool not intended for what I am trying to accomplish?
If anyone has any advice or pointers I would greatly appreciate it. Thanks!
Bryn Rhodes (Sep 30 2020 at 20:05):
Hi @Matt Sargent , yes this tool is definitely intended to support what you are trying to do, but it is a bit hard-coded/in-flight right now. You can extend it by imlementing a ClassInfoBuilder/ModelInfoBuilder for your set of structure definitions.
Bryn Rhodes (Sep 30 2020 at 20:06):
We are working right now on that use case, driving a ModelInfo entirely from the structuredefinitions in an IG, and further, using the profile constraints and extensions to inform the classes in the ModelInfo.
Bryn Rhodes (Sep 30 2020 at 20:09):
For example, take a look at this FHIR-based test versus the equivalent US-Core-based test to see how the profiles inform the ModelInfo and simplify the resulting CQL.
Matt Sargent (Sep 30 2020 at 20:31):
Thanks for the response! I will plan on trying to implement ClassInfo/ModelInfo for our definitions.
I have to look over the code a bit more first to try to understand the differences between the available ClassInfo* and ModelInfo* classes before I know which model's patterns to use for our model, but it is useful to know that this is an intended use case for the tooling.
Matt Sargent (Oct 01 2020 at 20:16):
I had a follow up question about should be the expected input when creating a ModelInfo with this tool? Should I be using just the custom structure definitions, or should I be passing in the custom definitions + the FHIR structure definitions?
Likewise, when writing a ClassInfoBuilder should my target be something like the one written for USCore (which seems to list out explicitly what is in USCore) or FHIR (that seems to be looking at the structure definitions themselves so that there is not a need to list out everything).
I wasn't sure if the convention is to try to generate a ModelInfo that just captures custom definitions, or if the goal is to try to generate an uber-ModelInfo that would have base FHIR + the custom definitions. Is the tooling you mentioned for generating ModelInfo from an IG targeting one/both of these use cases?
Bryn Rhodes (Oct 01 2020 at 21:49):
It covers both use cases. In the case of the base FHIR Structure Definitions (which are just the StructureDefinitions published with FHIR), it's creating a complete ModelInfo that doesn't list specifics, it just includes everything that's there.
Bryn Rhodes (Oct 01 2020 at 21:50):
In the case of specific IGs, we list out the profiles there because we don't yet have the code that says "just use the profiles defined in this implementation guide", though that is the next step to be automated.
Bryn Rhodes (Oct 01 2020 at 21:54):
Within the use case of "build a model info for an IG", there are two potential approaches we're considering: 1) Flatten, so that the profiles provide a complete, flattened set of all and only the structures available, or 2) Derive, preserving the profile hierarchy and still allowing access to the base FHIR structures.
Bryn Rhodes (Oct 01 2020 at 21:54):
The tooling supports both approaches, because that's a question we're still trying to answer (and the answer may actually be that both use cases are needed).
Matt Sargent (Oct 02 2020 at 15:03):
Thanks again for the context. I'm glad to know that generating the ModelInfo for an IG is a somewhat open question and that we have multiple options. I mostly wanted to make sure that I wasn't going down a path that was frowned upon/not intended.
Matt Sargent (Oct 09 2020 at 19:28):
Thanks again for answering my initial questions. I was able to work with the tooling this week and generate a ModelInfo based off our IG. Figured I would follow up here with a couple of mistakes I made along the way in case anyone else is interested using this tooling for their own IG before that type of support is added natively.
- The StructureDefinitions for our IG were initally generated with only the differential (no snapshot) included. I had to go circle back around and regenerate the definitions to also include the snapshot so that the ModelInfo had all of the correct elements included. Our definitions are written using FSH and generated with SUSHI, so this was easy enough to accomplish with
sushi -s path/to/our/defs. - It took several runs for me to realize that some errors will log a message, but not halt execution. I was running in an IDE, so switching my logging to a file was helpful for me so errors did not accidentally page out of the internal console in my IDE and go unnoticed.
- I had to modify several StructureDefinitions where slicing was in use. SUSHI defaults to using
patternfor slices rather thanfixedand the ModelInfo generation code was failing to process some slices due to callinggetFixed()returningnullfor the slice definition. Using the(exactly)syntax for SUSHI generated new definitions that got past this issue.
Hopefully someone might stumble across this in the future and find one of these things helpful.
Last updated: Apr 12 2022 at 19:14 UTC
