FHIR Chat · Multiple IGs on local FHIR server · IG creation

Stream: IG creation

Topic: Multiple IGs on local FHIR server

Travis Stenerson (Apr 06 2018 at 14:24):

I am creating a large number of profiles spread across a number of implementation guides. I would like to share profiles and extensions between these guides where there is crossover. However, I do not have an actual FHIR server at the canonincal URL for these profiles yet. I have however used the nifty HAPI CLI tool to set up a local FHIR server (which of course is at localhost:some_port) that I would like to use to enable these inter-IG dependencies.

Does anyone have guidance on this? When I list an IG in the dependencies list of the IG-build file, I presume it uses the canonincal URL to try and find those resources? Can I point it to localhost and still use the fake canonical URL for all the resources?

Any help or direction to what to read would be appreciated.

Lloyd McKenzie (Apr 06 2018 at 14:34):

To share materials between IGs, you don't need a FHIR Server. But you do need to define your IGs such that there's a strict hierarchy of dependencies. I.e. You can have IG B depend on IG A and IG C depend on IG B, but you can't have a situation where two IGs depend on each other. You then declare the IG dependencies and make sure that the ig.pack files are available when building the dependent guides. (Having a FHIR server won't help you with this.)

Travis Stenerson (Apr 06 2018 at 14:54):

Really. Ok that's useful. I just noticed that source attribute below. Should the 'source' attribute below point to the output folder of the parent IG? Or to the resources folder?
Also, should the 'name' attribute be the 'id' of the parent IG, or the 'name' of the parent-IG.
Should I put anything in the 'location' field?

   "dependencyList": [  // optional
     // a list of other implementation guides that this guide depends on
     // e.g. uses profiles, value sets, code systems etc
     // zero or more of this object:
     {
        "name" : "[name of the IG, for logging, and Jekyll variable name for location]",
        "location" : "[http address where the IG lives]",
        "source" : "[folder to get the definitions from if running ahead of publication at location (relative)]"
     }
   ]

Lloyd McKenzie (Apr 06 2018 at 15:10):

I don't think the name matters other than for rendering - though it needs to be Jekyll friendly (so no spaces or funky characters). The location should be the canonical URL for the IG.

Travis Stenerson (Apr 06 2018 at 16:21):

Thanks Lloyd I'll try it out.

Grahame Grieve (Apr 06 2018 at 19:29):

source is for when the guide (or the right version of the guide) can't be found at the canonical URL

Travis Stenerson (Apr 09 2018 at 21:37):

Having some trouble with this. If I want a profile to appear in IG-A, and also in IG-B. This is what I'm doing:

Build IG-A like normal, defining the differential, running the IG publisher.

Next I go into IG-B's build file and add:

    "dependencyList": [{
                "name": "IGA",
         "location": "fakecanonical/IGA",
         "source": "C:/path/to/other_ig/ImplementationGuides/IG-A/output"
          }]

Then I add an entry in the resources list of IG-B's build file. (Does it need a source attribute? what goes in source here?):

        "StructureDefinition/shared-profile": {
               "base": "StructureDefinition-shared-profile.html"
        }

Then I add a "dependency" attribute to IG-B's ImplementationGuide resource (type is 'reference' or 'inclusion'?):

    "dependency": [{"type": "reference", "uri": "fakecanonical/IGA" }]

Then I add n entry into IG-B's IG resource at package.resource:

                {"example": false,  "sourceReference": { "reference": "StructureDefinition/shared-profile" } }

Putting the resource in package.resource throws an error "Unable to find source file". Removing the entry from package.resource leaves the profile out of the IG. What am I doing incorrectly?

Eric Haas (Apr 09 2018 at 22:07):

all you need to do is add toIG-B ig.json source parameter. Don't add a separate SD entry. You can then reference the profile in IG-B See for example this https://healthedata1.github.io/IG-Sampler/StructureDefinition-template-profile-on-profile2.html where I build a profile on top of another or here https://healthedata1.github.io/IG-Sampler/StructureDefinition-template-basic2.html where I reference a profile from a another IG.

Lloyd McKenzie (Apr 09 2018 at 22:16):

IG-B shouldn't need to reference the shared profile. If it points to IG-A, then you have access to all the profiles in IG-A. There's no way to publish a profile in two IGs at the same time. You publish in one and then depend on that one.

Travis Stenerson (Apr 09 2018 at 22:20):

So from IG-B, I can only reference a profile in IG-A? Like if I have profile "DataElementX" that is common to both IG-A and IG-B, do I need to make two versions of "DataElementX" even if they are otherwise identical? I can't have it sit in both IG's?

Travis Stenerson (Apr 09 2018 at 22:25):

What I'm actually hoping for is that in the list of profiles for both IG-A and IG-B, the shared profiles appear. But if this isn't possible, I guess I can just make IG specific versions that inherit from a parent version.

Eric Haas (Apr 09 2018 at 22:26):

WE assume one IG to be the granddaddy - that is where the common profile would go so it could be used in both.

Eric Haas (Apr 09 2018 at 22:27):

you can alway compose a list to include all the profiles you want, but it Is not a generated fragment.

Travis Stenerson (Apr 09 2018 at 22:28):

A generated fragment, does that mean a resource that has the narrative and html files generated?

Lloyd McKenzie (Apr 09 2018 at 22:33):

A profile needs to be "owned" by only one IG. Other IGs can depend on that parent IG and reference the profile - but they can't republish it. If it's the same content, why would you want to publish it twice? Do you not want to make the parent IG available to everyone?

Travis Stenerson (Apr 09 2018 at 22:39):

I do, but I wanted the child IG's to list all the data elements that might appear in that module, and the parent IG to hold elements that appear in many different modules. But I might have to rethink this.

So one could not make an IG by borrowing a bunch of profiles from other pre-existing IGs? Like if I wanted to say that my CDS system requires smoking status, and instead of making a new profile I intend to use the US-Core Smoking Status profile, can I not add that profile to my implementation guide?

Lloyd McKenzie (Apr 09 2018 at 22:43):

That's not how things are designed to work, no. And because there can be default constaints that get inheriated from an IG, the behavior might be different if you included them in different IGs - which would be confusing at best. The expectation is that there's one authoritative place where you can find the profile. You can then reference it wherever you like.

Grahame Grieve (Apr 10 2018 at 07:27):

hah - this is the 'reference by inclusion' that we voted out of the latest version of the IG because who would want to do that? well, Travis wants to....

Lloyd McKenzie (Apr 10 2018 at 13:46):

I don't think he wants to "include" the whole IG - he wants to include specific artifacts from it. @Travis Stenerson, can you confirm?

Travis Stenerson (Apr 10 2018 at 14:27):

I want to include specific structure definitions in more than one IG.

Quick description of the use case. I'm building data models for multiple guidelines in oncology. And it appears that one IG per guideline would be the easiest manner to describe the data in the guideline. And many data elements occur in multiple guidelines. For instance, I have an observation for "Microsatellite instability" that occurs in prostate cancer and colon cancer. Or 'Medication Requests for Bone Metastases' - it occurs very often across guidelines.

I was hoping to have a 'general-oncology' IG, that the guideline-specific IG's could 'borrow' profiles from so as to share common profiles across guidelines. That was to try and make only one copy of bone-mets-med-request, and the prostate cancer IG could say "I use this profile too.".

But this might not be possible. Whats the best course of action here?

Grahame Grieve (Apr 10 2018 at 21:53):

this was what it was intended for. I don't know what the best course of action is. It relates to the other thread with Eric, I think

Eric Haas (Apr 11 2018 at 01:31):

My use case is more of using the same ig-pub infrastructure across several unrelated IGs. What Travis is describing I get done by setting up dependencies - namely uscore. I don't really have a need similar to what is described above.

Travis Stenerson (Apr 11 2018 at 15:23):

I will probably just build IG specific profiles and when I find a shared profile, abstract it up to the general IG and have the domain specific profiles inherit/derived from the abstract version.

Though the ability to share code systems and valuesets between IGs would also be nice.
Does that IG-ValueSet and IG-CodeSystem ownership follow the same pattern or can I have free floating ValueSets/CodeSystems that are used in multiple IGs?

Grahame Grieve (Apr 11 2018 at 15:24):

no all work the same. In general, canonical URLs work against you publishing by inclusion rather than by reference. The intent is to only publish something once.

Last updated: Apr 12 2022 at 19:14 UTC