Stream: conformance
Topic: Basic IG
John Moehrke (Nov 01 2017 at 14:53):
Given that I have a very basic IG need (one resource profiled, client/server with spec for minimal query parameters must support). I would have an ImplementationGuide, StructureDefinition, and two (client/server) CapabilityStatements (desired solution)... What is the proper way for these to be linked together and registered? It seems the CapabilityStatements --> ImplementationGuide --> StructureDefinition... but then how does one register this as a package? I got the impression lately that I should list these two CapabilityStatement resources also in the ImplementationGuide. Is that right?
Lloyd McKenzie (Nov 01 2017 at 15:02):
IG -> CapabilitySTatement & StructureDefinition; CapabilityStatement -> StructureDefinition
John Moehrke (Nov 01 2017 at 15:09):
okay, so in the ImplementationGuide.global ?
John Moehrke (Nov 01 2017 at 15:16):
ImplementationGuide.global is defined as only StructureDefinition... so I am not sure where to put my CapabilityStatement references
Lloyd McKenzie (Nov 01 2017 at 15:24):
ImplementationGuide.package.resource for everything. ImplementationGuide.global is for listing profiles that always apply for systems adhering to that IG. E.g. "All addresses must be US-Core addresses unless otherwise stated"
John Moehrke (Nov 01 2017 at 15:36):
Ill try that. It seemed to me that .package was used for building .pages... and I am not all that interested in pages (at this time). So, I need a .package entry for both StructureDefinition and my CapabilityStatement(s).. and also a .global for my StructureDefinition...
John Moehrke (Nov 01 2017 at 16:05):
for example my IHE PDQm IG is https://simplifier.net/IHEPatientDemographi/IHEPDQm/~xml
Lloyd McKenzie (Nov 01 2017 at 16:36):
Package isn't actually used for building pages, though some publishing mechanisms do use it to build an index or resources.
Lloyd McKenzie (Nov 01 2017 at 16:36):
Usually no need for "global" - that's only needed if you want to establish global defaults
John Moehrke (Nov 01 2017 at 16:44):
well, the element definitions are lacking...
John Moehrke (Nov 01 2017 at 16:44):
I don't need global?
Lloyd McKenzie (Nov 01 2017 at 16:50):
Global is only used if you want to establish a global default.
John Moehrke (Nov 01 2017 at 18:01):
isn't that what the StructureDefinition is that is a part of an IG?
John Moehrke (Nov 01 2017 at 18:05):
im not clear on why or why-not a SD would be a global default . ... I guess I am not clear what a global default is.
Lloyd McKenzie (Nov 01 2017 at 18:46):
If you're defining a constraint on Address and you want the rule to be "any time you see an unconstraint address type, treat it as if this profile was declared", then that's a global default. If you're just defining a profile that says "here's what a blood pressure should look like", there are no global defaults involved.
John Moehrke (Nov 01 2017 at 18:53):
thanks. Not all that much more clear, but clear enough for me to stay away from .global
Michel Rutten (Nov 01 2017 at 19:13):
Basically, using IG.global can save you from repeating the same type profile constraints in all profiles in the IG (could be many). Or you could reference (some of) these profiles from other IG's, without or with different global type profile constraints.
But I'm not sure if any of the (validator) implementations provide support for IG.global...?
As Lloyd suggest, I wouldn't use this unless you have some pressing need. In that case, please report back your use case, as this could help drive actual implementation support.
Lloyd McKenzie (Nov 01 2017 at 19:20):
The Java validator tries in theory - not sure how well it does
John Moehrke (Nov 01 2017 at 20:10):
thanks. I will no use .global
John Moehrke (Nov 01 2017 at 20:12):
It also seems for my use-case that I should not have .page
John Moehrke (Nov 01 2017 at 20:12):
so my basic IG for PDQm is https://simplifier.net/IHEPatientDemographi/IHEPDQm
Last updated: Apr 12 2022 at 19:14 UTC
