Stream: implementers
Topic: Implementation guide - Profiles from spreadsheet
Sadiq Saleh (Feb 02 2017 at 19:56):
Hi,
I am using trying to build an implementation guide with several profiles built using the profile template spreadsheet. I noted that the profiles generated have a "Profile " added before the name attribute of the resulting StructureDefinition and that the description attribute is not populated.
I also noted that unlike when extensions are build as part of the build process, extensions in the IG do not get assigned the name extension-abc as they do with the build.
Are these differences intentional?
Sadiq
Eric Haas (Feb 02 2017 at 21:58):
Ill take a stab at the last question. If you want an extension to be named
http://hl7.org/fhir/StructureDefinition/extension-o instead of
http://hl7.org/fhir/StructureDefinition/observation-bodyPosition
you can add the 'extension-' prefix in the metadata table in the row with the label "extension.uri"
If you mean the title doesn't say "Extension: The body position during the observation"
but instead something like " D.4.1 StructureDefinition-bservation-bodyPosition" that depends on how you customize the template used for extensions. They are using the same templates for Profiles and Extensions by default.
Sadiq Saleh (Feb 03 2017 at 14:30):
Thanks @Eric Haas for the response. I was able to fix both the uri and title on the generated webpages as you described. However I was referring to the names of the generated JSON and xml files. As I had described, during the build process these are renamed to start with Extension-abc.json and profiles to abc.profile.json for example, but in this case they are all made with a common Structuredefinition-abc.json.
Eric Haas (Feb 03 2017 at 20:06):
Yes those are the IG build generated fragments. Since extensions use StructureDefinition they share the same prefix as profiles.
Grahame Grieve (Feb 06 2017 at 06:31):
this is a deliberate difference from the main build
Sadiq Saleh (Feb 06 2017 at 18:37):
Thanks @Grahame Grieve and @Eric Haas , it is something that we will work with for the file names. Is this also the reason for the other observation: that the profiles generated have a "Profile " added before the name attribute of the resulting StructureDefinition and that the description attribute is not populated?
Sadiq Saleh (Feb 07 2017 at 16:17):
Just a follow up for the question about why "Profile " is added by the IG tool in the name attribute of profiles authored using spreadsheets and that the description attribute is not populated?
Any feedback would be much appreciated.
Eric Haas (Feb 07 2017 at 17:00):
OK here is my quick and dirty summary to using the spreadsheet with the IG publisher.
Eric Haas (Feb 07 2017 at 17:01):
Eric Haas (Feb 07 2017 at 17:09):
The above snapshot is all you need for creating a profile. don't need definition, id, etc, the"published-structure becomes the id and url through the IG tooling. Why? well the IG publisher is based on stitching together the fragments created by the publisher into static web pages using Jekyll so the user can customize the content to her liking. That means the description is typically replaced by custom content - for example in my case I create the descriptions in Markdown files that are then rendered into html along side the tool-generated profiles by Jekyll.
Sadiq Saleh (Feb 07 2017 at 17:15):
Thanks for that explanation @Eric Haas
So from what I understand from this is that the IG tool allows me to make descriptions for importing into the Jekyll generated webpages, but these decriptions will not be included into the Json/XML files?
Eric Haas (Feb 07 2017 at 17:19):
Yes these descriptions will not be included into the Json/XML files - they are separate artifacts from the JSON/XML files and the idea of the IG is to combine all these artifacts into a single document.
Sadiq Saleh (Feb 07 2017 at 17:21):
Perfect, thank you!
Sadiq Saleh (Feb 07 2017 at 17:35):
Is there a reason why the code adds a "Profile " tag to the "Published structure" for the name?
Grahame Grieve (Feb 07 2017 at 18:28):
because the old code for spreadsheet to SD conversion did, and the only reason that code still exists is for legacy support. We are trying to get people to stop using spreadsheets for profiles
Sadiq Saleh (Feb 07 2017 at 19:43):
I see. However given the lack of other tools for generating profiles for the STU3 fhir build, does this warrant an update of this code till other alternatives are available?
Grahame Grieve (Feb 08 2017 at 01:55):
don't know. you haven't identified a functional problem here
Sadiq Saleh (Feb 08 2017 at 14:47):
As far as we can see, there are a variety of fields of the StructureDefinition for which there is currently no way to populate except to go in an manually edit the resulting JSON/XML files:
1) Version
2) Description
3) FhirVersion
among others. I am not sure if this constitutes a functional problem, or is a functional problem just something that breaks the build process?
Lloyd McKenzie (Feb 08 2017 at 16:19):
fhirVersion is driven by the version you build against. Description and version are set on the metadata tab
Sadiq Saleh (Feb 08 2017 at 16:55):
As far as I can tell this information is pulled from the spreadsheet when using the publish process but not when using the IG tool.
i.e. I see these fields in JSON files when I build using the publish process, but I don't see any of these three fields populated in the JSON files that result from the IG tool.
Lloyd McKenzie (Feb 08 2017 at 19:06):
Hmm. May need to submit a tooling correction request then - they should be grabbed.
Eric Haas (Feb 08 2017 at 19:19):
Au Contraire the version is defined in the definition file see documentation here: http://wiki.hl7.org/index.php?title=IG_Publisher_Documentation
Lloyd McKenzie (Feb 08 2017 at 20:20):
The version certainly *can* be set in the definition file - that forces the definition of all of the conformance artifacts to the same value. But, if that's not populated, the version *should* come from the source for each artifact, which means it should come from the spreadsheet. (There's a bit of an issue in that the spreadsheet only lets you have one set of metadata for everything defined in the sheet, but you can get around that by splitting things into multiple spreadsheets as need be.)
Grahame Grieve (Feb 09 2017 at 03:49):
so is there some missing code around metadata in the IG publisher? I'm confused about this thread?
Sadiq Saleh (Feb 09 2017 at 14:32):
To summarize...
Currently there are some fields from metadata which are not put into the final StructureDefinition json object (or put incorrectly) for the following attributes:
1) name: "Profile " is added to the name taken from the published structure name, which means it is not computer friendly.
2) version is not set from metadata. Can only be set using the "fixed-business-version" but this makes all resources conform to the same version.
3) the fhirVersion is also left empty
The name and fhirversion attributes are properly populated for the extensions JSON files that are generated, but not the version.
Grahame Grieve (Feb 09 2017 at 19:00):
1) - the name is only populated like that if you don't have a short description on the root element. But from my next commit, you can use the metadata entry 'name' to set the name directly
2) version will be set from the metadata from my next commit
3) fhirVersion will be populated from my next commit
Sadiq Saleh (Feb 09 2017 at 19:15):
Great, thank you @Grahame Grieve
Last updated: Apr 12 2022 at 19:14 UTC
