Stream: implementers
Topic: Forge: How to point to a base profile
Brian Reinhold (Dec 07 2017 at 17:46):
I have made a base profile in Forge which is local on my system. I want to 'inherit' from that profile but I cannot figure out what Forge wants me to enter in the
<baseDefinition value="?" />
element. I tried
<baseDefinition value="PhdBaseObservation" />
since the base profile is in the same directory as all my other profiles but Forge says it cannot find it. Is Forge expecting me to upload this profile to the FHIR site? That would not be good; especially in a pre-mature state!
Anyone know how to do this? Thanks!
Grahame Grieve (Dec 07 2017 at 20:59):
needs to be a full URL - a reference to a canonical URL
Rob Eastwood (Dec 08 2017 at 03:04):
Unless I am misunderstanding your query, we have done this in Forge with the menu option "New > New Derived Profile". An 'open conformance resource' dialogue then displays where the 'base' profile needs to be found somewhere on your accessible file system. Then the profile will open in Forge, ready for your constraints etc. To confirm this, go to the properties tab and scroll down to the 'base definition' entry and the URL of the base profile will have been auto-entered. And as Grahame states - by inspecting the xml, the baseDefinition value is the full url.
Michel Rutten (Dec 08 2017 at 09:25):
Hi @Brian Reinhold, as Grahame explains, the baseDefinition property should contain the canonical url (i.e. value of StructureDefinition.url) of the desired base profile.
@Rob Eastwood Correct! However Brian's question is not about creating a new derived profile, but about re-basing an existing profile. The Forge UI does not provide a command for this. But as I explained to Brian, you can manually hack the base url, then re-open in Forge to update the constraints wrt the new base.
Michel Rutten (Dec 08 2017 at 09:26):
Note that references to conformance resources are almost always based on the canonical url, not on file name.
Brian Reinhold (Dec 08 2017 at 09:56):
@Rob Eastwood you may have given me a way to find out what I need to know. If I look at the 'canonical url' before I try to modify it, the value is
http://hl7.org/fhir/StructureDefinition/Observation which is great. That exists. However, my base structure definition is ONLY on my computer. No one wants my garbage on the public FHIR site. So I have no idea how to define this URL such that it points to a file in a directory on my local computer system. Maybe by starting from scratch as you suggest I will find that magic address.....
And yes, doing so reveals this URL
http://pchalliance.org/phdfhir/StructureDefinition/PhdBaseObservation
which is just the fake URL I put in creating my base profile. So now I know the magic URL. However, I hope Forge doesn't try and look for the base definition at that location because it does not exist!
But Forge likes it! It does not try to go to that non-existent site. Thus it works and I didn't even have to do any hand-editing after the fact. The merge appears to have been done perfectly. A quick scan of the derived profile also shows it only has the new stuff in the difference fields so it worked perfectly!
I must add one extra step. You need to make some fake edit to complete the merge. Add a space, check that the 'star' gets indicated that you have made edits, delete it, and then save it. Otherwise the merge does not get done since your file is not saved. After manually saving you will get the merged file with only the difference from your base profile.
Michel Rutten (Dec 08 2017 at 10:39):
Hi @Brian Reinhold, excellent! I'm happy it works.
Concerning canonical urls: please consider these as "uri" (identifier, not locator). How a system resolves a profile by the canonical url identifier depends on the implementation. Forge scans a directory on local disk. A FHIR server will typically perform a database lookup. Or it might even reach out to another server.
As for you final comment, indeed Forge doesn't enable the save button until you actually made a change. Because Forge is not aware of the manually updated base, you have to simulate a change. In theory, Forge could detect that the recalculated diff has changed wrt the original. I'll think about it.
Brian Reinhold (Dec 08 2017 at 10:44):
@Michel Rutten The problem I had yesterday is that I did not know what that identifier should be. But by creating the new derived profile I found out and it was the identifier I had made up for the base profile. I did not know that would be ok. Then as far as the saving goes, I just wanted others following what I did to make the extra step. It may be obvious in hind sight considering one is working outside of Forge that it would be necessary but i skipped that step at first and wondered why nothing happened. Ah yes....
Michel Rutten (Dec 08 2017 at 10:54):
Thank you for clarifying, I'll keep this in mind.
Brian Reinhold (Dec 08 2017 at 11:51):
Some bad news. One profile does not work correctly. The other 4 do. When I first did it and saved it, the saved profile looked good. All the common elements were removed. However, on reloading, one component element from the base profile does not get merged in correctly. It loses the cardinality in the element. I do not know why. In the other profiles this particular component element gets added fine.
Michel Rutten (Dec 08 2017 at 12:47):
Hi @Brian Reinhold, you could try to create a new derived profile from the same base profile (for testing/debugging purposes) and manually recreate the constraints on the specific element you're concerned about. Save the test profile and re-open in Forge and see if you can reproduce/explain the behavior.
Last updated: Apr 12 2022 at 19:14 UTC
