Stream: IG creation
Topic: Referencing external profiles/extensions
Jean Duteau (Apr 01 2019 at 16:11):
I had a question arise why teaching about profiles, implementation guides, and registries. Can an HL7-balloted/published Implementation Guide reference profiles and extensions that were defined outside of HL7, i.e. on simplifier.net?
Lloyd McKenzie (Apr 01 2019 at 16:41):
Only if the IG imports the dependent IG. As to whether it's appropriate to have a balloted/standard IG that depends on non-balloted/standard content, that's a good question. Probably something for FMG, SGB and/or TSC. You can choose where you want to start the conversation.
Grahame Grieve (Apr 02 2019 at 19:03):
what does hl7 balloted mean? If that includes affiliates, then the answer is yes.
What does defined outside HL7? Simplifier is both a tool and a publishing location. Right now HL7 ballots cannot be developed in Simplifier for technical reasons, but I expect that will be resolved. If content is not published through HL7 then Lloyd's question applies.
-
Grahame Grieve (Apr 02 2019 at 19:03):
if the HL7 published material is not going through ballot then the rules will be different too
Jean Duteau (Apr 02 2019 at 19:49):
The question was basically if I was balloting an IG through HL7 but was referencing a profile that was defined external to HL7 and not balloted at HL7, would that be allowed?
Lloyd McKenzie (Apr 02 2019 at 19:55):
We point to things that aren't balloted now - SNOMED, LOINC, various RFCs. On the other hand, all of those have pretty strong governance frameworks around change. I suspect the answer to the question would be related to the robustness of the governance framework around the external material. However, it's a policy question. The technical answer is that so long as we can find the NPM package for the imported IG, the tooling should work.
Jean Duteau (Apr 02 2019 at 19:56):
i'm more interested in pointing to profiles/extensions so I wouldn't expect there to be an IG or an NPM package
Lloyd McKenzie (Apr 02 2019 at 19:57):
Profiles and extensions can't be referenced unless they're defined in an IG.
Lloyd McKenzie (Apr 02 2019 at 19:57):
The IG is the packaging mechanism that allows them to be accessed/distributed/managed.
Jean Duteau (Apr 02 2019 at 19:57):
Profiles and extensions can't be referenced unless they're defined in an IG.
hmm, why?
Lloyd McKenzie (Apr 02 2019 at 19:58):
Managability. How can you handle dependencies if you have to reference each individual artifact? How is versioning handled? It'd be a mess.
Martijn Harthoorn (Apr 04 2019 at 09:58):
In order to have a 'stable' IG, you will at least have to make sure that you refer to a very specific version of profile or extension.
In Simplifier the best way to make that happen is to reference a package in your project, package or IG. In most cases profiles don't live in isolation anyway.
Martijn Harthoorn (Apr 04 2019 at 10:00):
There is an essential difference between a package and an IG. A HL7 FHIR (balloted) IG is published as a package and contains the used profiles.
But in and of itself - a package does not need to be an IG.
Martijn Harthoorn (Apr 04 2019 at 10:01):
The idea of packages is just to make distribution of sets of conformance resources easy.
Michel Rutten (Apr 04 2019 at 11:34):
A package is a container for a related set of resources, distribution mechanism for targeting machines.
An ImplementationGuide provides documentation targeting developers, i.e. humans.
Lloyd McKenzie (Apr 04 2019 at 14:45):
The ImplementationGuide serves as the manifest for the package and for pointing to other packages. It's possible to have an ImplementationGuide that has minimal/no documentation if you really want to.
Vadim Peretokin (Apr 05 2019 at 09:21):
@LLyod @Lloyd McKenzie when did the definition of an ImplementationGuide change? It existed before packages did.
Grahame Grieve (Apr 05 2019 at 12:20):
we changed it in R4
Michel Rutten (Apr 05 2019 at 13:55):
It's possible to have an ImplementationGuide that has minimal/no documentation if you really want to.
Of course, and you can also publish a package containing only documentation pages.
However I'd prefer a clear separation of concerns.
Lloyd McKenzie (Apr 05 2019 at 14:11):
I don't think we've ever said you can publish a stand-alone 'package'. You can pass around a Bundle of resources, but that's not really the same as "publishing".
Michel Rutten (Apr 05 2019 at 14:18):
Nictiz is publishing stand-alone packages with standardized models for the Netherlands:
https://simplifier.net/NictizSTU3-Zib2017
Is this not a valid approach?
Lloyd McKenzie (Apr 05 2019 at 14:35):
And the reason for those not being considered implementation guides is?
Lloyd McKenzie (Apr 05 2019 at 14:36):
You can't reference a standard package or have a dependency on it or expose metadata such as what version of FHIR it supports in a FHIR-readable way or see any of the metadata that would allow it to be searchable/discoverable without an ImplementationGuide resource.
Michel Rutten (Apr 05 2019 at 15:24):
Actually, Nictiz has published an accompanying IG to a Wiki page (not based on FHIR IG resource):
https://zibs.nl/wiki/ZIB_Hoofdpagina
I assumed that the use of packages and IG resource are both optional in FHIR. The current discussion seems to suggest that these concepts will be intimately tied together, and you really can't use them separately. I'd prefer a loose coupling, to allow different approaches.
Michel Rutten (Apr 05 2019 at 15:26):
(notwithstanding that they are related concepts and using them in combination provides benefits)
Lloyd McKenzie (Apr 05 2019 at 15:36):
The only reason we have the package.json is to support the NPM package distribution. If you want to use NPM for other stuff, you can. But if you're using it with FHIR IGs, then (my opinion) everything involved needs to be a FHIR IG.
Last updated: Apr 12 2022 at 19:14 UTC
