Stream: implementers
Topic: Dutch FHIR profiles with HAPI
Aliaksei Maiseyeu (Jan 09 2019 at 08:13):
Hello! I want to create FHIR server with support for Dutch FHIR profiles https://simplifier.net/NictizSTU3-Zib2017 . The easiest way is to use Vonk server from Simplifier supplied with required profiles. But the goal is to create server based on HAPI. As I understood I have to create a lot of java classes to use them instead of default DSTU3 classes. Am I right? If yes, is it possible to convert definitions from XML using some tool/plugin?
Jan-Marc Verlinden (Jan 09 2019 at 14:24):
Yes we are also wondering if we need to generate classes for every profile, or does it work out of the box? And would that be by hand?
Michele Mottini (Jan 09 2019 at 14:31):
The standard classes support every profile - no need to create special ones
Jan-Marc Verlinden (Jan 09 2019 at 14:35):
Yes, but what about for instance the Dutch profiles we have to use for MedMij, so the special classes? Any idea?
Michele Mottini (Jan 09 2019 at 14:37):
Just use the standard classes for those resources? what does not work?
Jan-Marc Verlinden (Jan 09 2019 at 14:37):
Those work, but we are looking at for instance the nl-core-patient extended profiles.
Michele Mottini (Jan 09 2019 at 14:41):
Yes - what prevent you to use the standard Patient class for that? For what I see it defines some extensions - that you can set / read using the standard Patient class
Jan-Marc Verlinden (Jan 09 2019 at 14:52):
Because from what I understand this standard profile is extended for the dutch profile, so I assume the class should be extended
Aliaksei Maiseyeu (Jan 09 2019 at 14:53):
According to http://hapifhir.io/doc_extensions.html#_toc_custom_resource_types this documentation, we should create/have additional java classes for additional profiles
Lloyd McKenzie (Jan 09 2019 at 15:16):
Extensions are built into the base model and, so long as the profiles are available, the standard code can dynamically validate against any profiles it's aware of. You'd only need custom code if you wanted to have special helper methods that hid what was an extension vs. what wasn't. It's up to you whether that provides sufficient value for the work.
Jan-Marc Verlinden (Jan 09 2019 at 15:34):
Sorry for my lack of knowledge :-), let me repeat: you state that the Dutch extended profiles do not need the Java classes to extend because they are adapted?
Lloyd McKenzie (Jan 09 2019 at 15:52):
If the Dutch profiles are FHIR compliant - i.e. they didn't tweak the schema but instead use standard mechanisms to extend & constrain (and I believe this to be true, though I haven't actually looked at the profiles), then the standard Java code will be able to handle all of the extensions and, if you have access to the StructureDefinitions, ValueSets and other artifacts from the Dutch implementation guide, you'll be able to validate instances to ensure they're valid against those profiles. @Tom de Jong @René Spronk any further guidance?
Jan-Marc Verlinden (Jan 09 2019 at 15:55):
Great, many thanks!!
Jan-Marc Verlinden (Jan 09 2019 at 16:13):
Maybe the question is indeed for @René Spronk or @Tom de Jong: in Vonk we can actually see the Dutch profile at https://stu3.simplifier.net/NictizSTU3-Zib2017/StructureDefinition/nl-core-patient but for HAPI we do not http://hapi.fhir.org/baseDstu3/StructureDefinition/nl-core-patient . Any idea what happens?
René Spronk (Jan 09 2019 at 16:36):
@Alexander Henket and @Ardon Toonstra are closely involved with the project, maybe they'd know.
In general, AFAIK, registry.fhir.org only contains a subset of the profiles as available on Simplifier.net, that could be the underlying reason if hapi.fhir.org solely uses registry.fhir.org as its souce for profiles. And: there are two 'active' STU3 profiles with the very same canonical URL ( http://fhir.nl/fhir/StructureDefinition/nl-core-patient ) and the same versionId on Simplifier.net, one of which was created/updated a couple of days ago. Perhaps this causes issues - but all of the above is mere speculation, I'll leave further comments to those much more in the know about the creation of profiles and the use of profile registries.
Ardon Toonstra (Jan 09 2019 at 16:54):
The 'Dutch profiles' are HL7 FHIR compliant (we haven't tweaked schema's). The Nictiz STU3 Zib2017 project contains the profiles in use for MedMij. All the StructureDefinitions, ValueSets and other artefacts are downloadable through Simplifier or resolvable through the stu3 API of Simplifier. You can download an entire project as a zip file at the project level or another option is to get everything from this GitHub repo.
@René Spronk There are no two 'active' versions of the profiles anymore. In addition, we are working on restructuring the projects and creating packages for the Dutch profiles. However, this will take some time and will require good communication to all our implementers.
Ardon Toonstra (Jan 09 2019 at 16:56):
Regarding the HAPI implementation, unfortunatly, I am not the right person to give advice. I would expect that you can use all the FHIR profiles created. They are not depended on Vonk, or any particular server.
Alexander Henket (Jan 09 2019 at 16:58):
In addition: I think the Github link that syncs Github stuff into Simplifier, causes the StructureDefinition.meta.versionId to be static unless we update that manually. The only thing we update however is the StructureDefinition.version, which should not be the same for any profile in the retired project NictizSTU3 and the active project NictizSTU3-Zib2017.
Alexander Henket (Jan 09 2019 at 17:00):
Suppose my guess for StructureDefinition.meta.versionId is right: would we need to flag this as an issue for Firely @Ardon Toonstra ? It sort of makes sense that Simplifier does not update content while syncing, but on other hand it also limits the use of SD.meta.versionId and .lastUpdated. We might as well remove that entirely so as to avoid misunderstanding.
Jan-Marc Verlinden (Jan 10 2019 at 07:35):
Hi @Ardon Toonstra and @Alexander Henket . I think now we are getting in more than just 1 discussion.. ;-), so I will only forcus on mine. What we found out is that the same nl-profiles do work in Vonk and they do not in HAPI. We have no clue about versioning in Github or Simplifier and old (or not so old) STU3 or NictizSTU3 or NictizSTU3-Zib2017 versions. We only hope there is one single version that does the trick for both Vonk as well as for HAPI.. :-)
Alexander Henket (Jan 10 2019 at 08:32):
Sure, well we only supply exactly one version which works in Vonk and the Aegis Touchstone environments. If HAPI doesn't work, then this might be because we asked Aegis to tweak a few shortcomings of the STU3 validator. Disable broken invariants and improved sliced validation. These changes have been included in some cases in the official R4 validator that supports STU3 too. I do not know what validator code HAPI carries. My suggestion would be to ask on the conformance stream and include James Agnew in that.
Alexander Henket (Jan 10 2019 at 08:35):
On the other hand I'm not sure what the exact problems are you are running into. In principle you should assume there should be no difference between the tools, but in practice you'll find that each tool has its strongholds and pitfalls
Vadim Peretokin (Jan 10 2019 at 08:47):
@Jan-Marc Verlinden have you uploaded the Dutch profiles to http://hapi.fhir.org/baseDstu3/StructureDefinition ?
Vadim Peretokin (Jan 10 2019 at 08:47):
I don't think hapi.fhir.org by default mirrors Simplifier or registry.fhir.org, so expecting the content to be there as well won't work
Last updated: Apr 12 2022 at 19:14 UTC
