Stream: IG creation
Topic: IGs within an IG
Jose Costa Teixeira (Apr 15 2020 at 11:49):
For a first step towards aggregating IGs:
How would an IG look like inside an IG?
Grahame Grieve (Apr 15 2020 at 12:13):
sounds like a very bad idea to me
David Pyke (Apr 15 2020 at 12:15):
In my mind, IGs should be inherited only. Having "sub-IGs" seems like a good way to confuse an issue.
Jose Costa Teixeira (Apr 15 2020 at 12:19):
So, IHE Pharmacy Technical Framework will have N profiles
Jose Costa Teixeira (Apr 15 2020 at 12:19):
assuming each profile is an IG, it would be good to group those IGs in a also-governed framework.
Jose Costa Teixeira (Apr 15 2020 at 12:20):
how would this be handled then?
David Pyke (Apr 15 2020 at 12:21):
YOu can work it like Da Vinci who has a core (EHEX) that defines the basics and subsidiary (PDEX/CDEX).
Grahame Grieve (Apr 15 2020 at 12:21):
anyway it wanted? or perhaps you should be more specific...
Jose Costa Teixeira (Apr 15 2020 at 12:22):
So assuming the Pharmacy Techniocal Framework will have IGs that depend on each other, we can simply publish those IGs separately, and just publish a landing page as the Technical Framework.
David Pyke (Apr 15 2020 at 12:22):
That sounds good
Grahame Grieve (Apr 15 2020 at 12:23):
yes that's what I'd do. Though I'd build it automatically from the package-list.json files
Jose Costa Teixeira (Apr 15 2020 at 12:24):
And we could make that landing page:
a) custom HTML or whatever
b) an implementationGuide that keeps the look-and-feel of the template and says "this TechFramework v2021 consists of the current IGs: 1. Presc 2. Admin 3. Dispense 4....
Jose Costa Teixeira (Apr 15 2020 at 12:25):
I think option b) makes sense for consistency and ease of publication
Jose Costa Teixeira (Apr 15 2020 at 12:26):
within that we can have,
b1) ImplementationGuide just for the look and feel, everything is manually created markdown/xhtml
b2) an implementationGuide that points at the other IGs and just renders them as pointer pages
Grahame Grieve (Apr 15 2020 at 12:27):
(b) - build it from the package.json files
Jose Costa Teixeira (Apr 15 2020 at 12:27):
where can I see how that works?
Jose Costa Teixeira (Apr 15 2020 at 12:28):
or is that a new thing to do ? (sounds like a nice challenge)
Grahame Grieve (Apr 15 2020 at 12:30):
I haven't built a page like that before. All the history.html pages are automatically build from the package-list.json files, so it would be a question of starting from that and building a cross-IG landing page that kept itself up to date
Giorgio Cangioli (Apr 15 2020 at 12:32):
not clear why to split into the b1 and b2 cases....I can imagine that in general both are needed, manually created pages and pointers to the other IGs
(including likely extracted text from the other IGs)
Jose Costa Teixeira (Apr 15 2020 at 12:36):
b1: every time I need to add a child IG, I edit an html/md page where I put the IG name, version etc. and i publish the parent IG
b2: I just add the reference to child IG in my parent_ig.xml, and the publisher does the rest
Jose Costa Teixeira (Apr 15 2020 at 12:36):
b1 is available now. b2 would require a layout for IGs I guess
Jose Costa Teixeira (Apr 15 2020 at 12:36):
Grahame Grieve said:
I haven't built a page like that before. All the history.html pages are automatically build from the package-list.json files, so it would be a question of starting from that and building a cross-IG landing page that kept itself up to date
I'll investigate that.
Grahame Grieve (Apr 15 2020 at 12:37):
b2 - I wouldn't do it by ig.xml. Some kind of json file that defines the group in the publication processing stage
Jose Costa Teixeira (Apr 15 2020 at 12:45):
perhaps that ties into another old thought - why not a List for that json file?
Jose Costa Teixeira (Apr 15 2020 at 12:45):
I think it would be more solid and convenient if the ig.xml could point to a List, and then the publisher+template would do the rest, after a possible preprocessing
Grahame Grieve (Apr 15 2020 at 12:46):
I wouldn't find it more convenient
Jose Costa Teixeira (Apr 15 2020 at 12:48):
what is not more convenient?
1 Using List instead of a custom json file? or
2 changing the IG to support List?
Jose Costa Teixeira (Apr 15 2020 at 12:49):
(I understand 2 could require considerable efffort)
Grahame Grieve (Apr 15 2020 at 12:49):
using list.
Grahame Grieve (Apr 15 2020 at 12:51):
the IG publisher has 2 modes. The first mode that everyone is familiar with, when generating an instance of an ig
Grahame Grieve (Apr 15 2020 at 12:52):
and the second mode, that I use, which is where it actually publishes the IG, and maintains a web site of a set of IGs that cross-link each other and maintain a coherent version history
Grahame Grieve (Apr 15 2020 at 12:52):
and also generate redirects
Grahame Grieve (Apr 15 2020 at 12:53):
the second mode is entirely driven by package-list.json files and web config files
Jose Costa Teixeira (Apr 15 2020 at 13:15):
is this second mode something that you think could be used for groups like IHE?
Jose Costa Teixeira (Apr 15 2020 at 13:17):
if so, and since there is no urgency, we can learn about it, try it, and document a how-to (presuming one does not exist yet)
Grahame Grieve (Apr 15 2020 at 13:22):
sure IHE should use the second mode
John Moehrke (Apr 15 2020 at 13:58):
the second mode is the fhir.org ig registry? we are in there manually today, but would be in there automatically as we move to using the IG publisher and have some place to put our publications
John Moehrke (Apr 15 2020 at 14:00):
There is still a governance step between an editor using the IG publisher; and the commmittee getting thru their standards governance to an artifact that is published for public comment, trial implementation, and final text. The governance is important, not a problem.
Jens Villadsen (Apr 15 2020 at 15:33):
@Irene Zuschlag @Ole Vilstrup this discussion is also og relevance to you
Frank Oemig (Apr 15 2020 at 18:11):
Beside IGs it is important for IHE to have profile hierarchies. This is missing in the past. For example, we have similar message structures for ADT, but no common requirements.
Right now we have the chance to correct that. Therefore, some kind of core seems reasonable. Overarching IGs should crossmap then...
Grahame Grieve (Apr 15 2020 at 20:05):
yes the second step auto-populates the FHIR registry json file as part of it's process. And yes, there is governance around publication
Last updated: Apr 12 2022 at 19:14 UTC
