Stream: conformance
Topic: Derived profile and custom data type
Stefan Lang (Jul 17 2017 at 17:18):
I'm currently creating a derived profile and am a bit stuck at the point of further constraining elements of a contained custom data type.
To be precise: the profile I'm deriving from is https://simplifier.net/BasisprofilDE/patient-de-basis which uses https://simplifier.net/BasisprofilDE/address-de-basis as it's sole type for address.
In my derived profile, I want to add some additional constraints, like must-support, cardinality etc., to certain elements of the address.
At least in Forge, I can't find a possibility to do so, since Forge shows the structure of the FHIR base Address datatype instead of address-de-basis within my derived profile.
So, my question is: how can I achieve this in Forge, or if not possible, how should that be defined in the profile's XML?
Or, third option, is it even possible to constrain custom data types within a derived profile?
Mirjam Baltus (Jul 18 2017 at 08:10):
@Stefan Lang Do you have all the relevant StructureDefinitions in one folder? Forge will try to find referenced profiles in the same folder, or subfolders. If they're found, Forge is able to load the changes you made to the data type and show them. If Forge cannot load the referenced profile, it will default to showing the standard data type fields.
Michel Rutten (Jul 18 2017 at 08:26):
Hi @Stefan Lang, when you open a profile, Forge will try to resolve all referenced external (element type) profiles from the containing file folder (and subfolders). So try to place all the referenced datatype & extension profiles in the same folder.
For now, you have to manually download/import all dependencies. In a future release, we're planning to implement resolving external profiles from Simplifier.
Stefan Lang (Jul 18 2017 at 08:33):
Thanks Mirjam and Michel. I have the profiles and all required extensions in the same folder.
I just subsequently created a new derived profile on patient-de-basis to double check.
Strange enough, on the first try address showed the elements of the base Address type, while on the second try I actually see it as profiled in address-de-basis ...
Stefan Lang (Jul 18 2017 at 08:35):
This is really weird, it seems to work at the moment ...
Stefan Lang (Jul 18 2017 at 08:47):
I also noticed that on the last try, Forge needed much longer to open the new derived profile. So I suspect that for whatever reason it failed to successfully scan the folder at the earlier tries.
Michel Rutten (Jul 18 2017 at 08:48):
Hi @Stefan Lang, note that Forge caches the contents of profile working folders on the first access. Currently this is not always clear in the UI (TODO). Restarting the application (and also closing all open files) will clear all caches and re-scan the actual file folder contents.
Stefan Lang (Jul 18 2017 at 08:58):
Ok, that might be the explanation for the longer time to open.
Well, atm I can't reproduce the problem. Should have done a screenshot to convince myself that it was not me who failed :D
Michel Rutten (Jul 18 2017 at 09:00):
I'm aware that the internal file management currently isn't very clear to the end user. We have plans to completely rewrite the session explorer, in order to improve this. However I haven't had time to work on this yet.
Stefan Lang (Jul 19 2017 at 15:19):
@Mirjam Baltus @Michel Rutten Just got the Forge issue once again.
This is the base profile in Forge:
patient-de-basis-name.png
And this is the derived profile:
patient-de-vsdm-name.png
Note that e.g. the extensions to family are missing in the derived profile.
Stefan Lang (Jul 19 2017 at 15:24):
Same for address, i.e. both custom data types (humanname-de-basis and address-de-basis) are there as the type, but not in the representation.
Mirjam Baltus (Jul 19 2017 at 15:29):
Stefan, do you have specific steps that can reproduce the issue? My tests all seem to work correctly. If so, please send the steps to forge@furore.com so we can investigate and resolve it.
Stefan Lang (Jul 19 2017 at 15:31):
We store all profiles with snapshots from Forge for better representation in Simplifier. Manually removing the snapshot part from the XML solved it.
I'll send you the steps I took by e-mail.
Richard Townley-O'Neill (Jul 20 2017 at 02:06):
We have stopped generating snapshots in Forge and generate them using the IGPublisher.
Michel Rutten (Jul 20 2017 at 08:57):
Hi @Stefan Lang, thank you for the report. Are all referenced profiles available in the working folder? Because missing references may prevent Forge from building a full tree.
FYI I'm currently working on a new release with a number of bug fixes. I'll try to also fix this issue.
Stefan Lang (Jul 20 2017 at 09:17):
@Michel Rutten the working folder is basically a clone of https://github.com/hl7germany/basisprofil-de plus the core extensions we use.
I'd be very happy to see the fix in the next release. It really slows down profiling
Michel Rutten (Jul 20 2017 at 09:24):
Hi @Stefan Lang, Last week I've managed to fix a nasty bug in the development branch regarding faulty element matching. I've tried your example in the latest internal build and it now seems to work correctly.
Here's a screenshot of patient-de-vsdm:
Forge-Develop.PNG
Stefan Lang (Jul 20 2017 at 13:52):
Thanks Michel, I'll give it a try
Last updated: Apr 12 2022 at 19:14 UTC
