Open richfirely opened 4 months ago
Adding additional information:
Some interesting data is necessary in the final FHIR Resource files, but isn't available via CQL or otherwise. We should add a template for authors to use to push along data from a settings file to the resources that get built.
For example:
Library.publisher = Firely (or NCQA, CMS etc) Library.copyright = copywrite statement. Library.relatedArtifact = url of documentation references (this would be an addendum to existing child library references)
Ideas for this are fhirpath, liquid template or just simply a Library/Measure resource json file that contains the overrides or missing values. This might be best as a post-processor in the packager that is careful not to overwrite import values that should only be defined by the packager or come from the CQL, such as title, parameters, etc.
We will need to consult the Clinical Reasoning IG for specs on this as there are requirements for the different types of publishable artifacts.
Also note that this exists: https://github.com/FirelyTeam/firely-cql-sdk/blob/develop-2.0/Cql/Cql.CqlToElm/CqlToElmOptions.cs
We need to marry Bryn's options with ours, and support his schema. But we should also allow someone to trivially serialize CqlToElmOptions
as json and then read it back as configuration as well, e.g. through standard IConfiguration
service loading from JSON files. The latter approach is more intuitive for .NET developers.
Is your feature request related to a problem? Please describe. In the java engine there is a file that contains the cql options for the elm compiler and other instructions for building fhir libraries. Here is a sample
And this is the schema
This file is published in the IG and I assumed would be used by IG implementers to compile the CQL to their own engine logic.
Describe the solution you'd like It would be a good addition to support these options directly by consuming this same file. This is not to say that we should adopt this file for our config, rather to allow consuming it to help augment our own appsettings.json file. This becomes more important with our own CQL to ELM compilation step. Alternatively, we could provide and option to convert the file to our own format.
Describe alternatives you've considered End users would need to manually copy these settings, or parse the file themselves and set the runtime parameters or appsettings.json file.
Additional context Add any other context or screenshots about the feature request here.