FHIR Chat · Canonical Resource version · IG creation

Stream: IG creation

Topic: Canonical Resource version

Grahame Grieve (Sep 14 2020 at 19:15):

@Robert McClure points out that most of the IGs are not displaying the version of the artifact, which should be front and center. The expected way for it to be displayed is that summary, as shown here: https://www.hl7.org/fhir/us/core/ValueSet-birthsex.html

But lots of profile authors like to think they shouldn't show this. E.g. https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-condition.html or https://build.fhir.org/ig/HL7/cqf-recommendations/branches/master/StructureDefinition-cpg-computablevalueset.html

I'm going to make it a requirement before publishing anything in the future: the summary needs to be displayed prominently

Lloyd McKenzie (Sep 14 2020 at 21:25):

Is this something we need to improve the handling of in the templates?

Eric Haas (Sep 14 2020 at 21:29):

I am not aware of summary artifacts for anything but CodeSystem and ValueSet. If they are present it is news to me. I don't think is is failure of the Authors . If they are present then the templates are incomplete.

Grahame Grieve (Sep 14 2020 at 23:11):

yes we definitely need to improve this in the templates

Grahame Grieve (Sep 14 2020 at 23:12):

but Eric might be right :-(

Eric Haas (Sep 15 2020 at 02:19):

We can construct them in the templates without a need for the prebuilt fragments if we have all the info in temp _data.

Lloyd McKenzie (Sep 15 2020 at 02:21):

I have a slight preference for the temp _data approach. Not everyone's going to want this data exposed in a table grid. And different implementation spaces may want to expose different subsets. (E.g. for some, FMM and ballot status will matter, for others not so much.)

Grahame Grieve (Sep 15 2020 at 02:31):

well, I will generate a table summary for all canonical resources as a minimum, but if the template can do something better, then by all means...

Lloyd McKenzie (Sep 15 2020 at 02:50):

Is all the info in the table available in the resource data file?

Grahame Grieve (Sep 15 2020 at 02:55):

not all of it, but the most important part is

Lloyd McKenzie (Sep 15 2020 at 03:14):

If you can add to your todo list to expose all of it at some point, that would give us (and others) the flexibility to experiment with presentation.

Jose Costa Teixeira (Sep 15 2020 at 06:14):

can't this be part of the summary fragment?

Grahame Grieve (Sep 15 2020 at 06:30):

I'm just making a new release (hopefully) and this one will generate a new fragment [type]-[id]-table-summary which will be the table summary for all canonical resources. It has:

• URL
• Version
• Status
• Definition
• Publisher
• Workgroup
• Copyright
• FMM Level
• [some resource specific things]
• references to source

It will be very hard to reproduce the table in the template - a fair bit of work goes into a couple of them

Grahame Grieve (Sep 15 2020 at 06:31):

for all resources but StructureDefinition, this will be the same as the summary fragment. It's a new fragment because I didn't want to break anything existing

Eric Haas (Sep 15 2020 at 15:38):

I think the best place for all this metadata is in the implementation guide resource for each resource, Then that way won't have all these redundant_data and separed data files since everything is neatly packaged in one place. The IG resource then lives in the data folder for access by the templates.

Eric Haas (Sep 15 2020 at 15:57):

then could render tables in liquid:

<table>
    <tr>
  {% for item in  ig.definition.resource[index for conformance resource]  %}
  {# some filter here to exclude stuff like reference, example, groupingID #}
        <td>{{item[0]}}</td>
        <td>{{item[1]}}</td>
    {% endfor %}
    </tr>
</table>

Jose Costa Teixeira (Sep 15 2020 at 16:06):

Not sure I follow, @Eric Haas - you mean adding this into the implementationguide.definition.resource ?

Jose Costa Teixeira (Sep 15 2020 at 16:07):

I am already complaining that the IG contains too much metadata.

Jose Costa Teixeira (Sep 15 2020 at 16:08):

I want to industrialize the production of IGs, allowing contributors (e.g. terminology experts, test data creators, profile creators) to add their own stuff autonomously. I don't feel comfortable with saying "and update the main IG.xml accordingly".

Jose Costa Teixeira (Sep 15 2020 at 16:09):

if everyone must update the ig.xml things will just be harder

Jose Costa Teixeira (Sep 15 2020 at 16:09):

(or did I miss something?)

Eric Haas (Sep 15 2020 at 16:13):

It already contains the name , title and description,,, for each artifact. and can be computationally populated from the resources themselves as is being done already. What I am suggesting would make it more manageable to publish. The IG resource is just a configuration file so it makes sense to catalog all this stuff there IMO. Its the pages part that is a pain.

Last updated: Apr 12 2022 at 19:14 UTC