Stream: implementers
Topic: Resource References in Base/Core National IGs
Peter Jordan (Feb 16 2022 at 03:05):
I'm seeking best practices when a national base resource profile contains a reference to another resource that is also profiled in the base IG. For example, should Location.managingOrganization in a NzLocation Profile refer to NzOrganization and/or Organization? I've seen examples of all 3 approaches - sometimes within the same IG - so am wondering which one(s) to follow and the rationale.
Elliot Silver (Feb 16 2022 at 03:15):
There should be some thought applied to it. Do we require that this organization meets the requirements of a NzOrganization, or would any organization do? I’ve encountered this with Practitioner, where for example local Practitioners have a license number, but we might receive records of referencing foreign Practitioners, which won’t have local licence numbers, so we have to allow non-profiled Practitioners for, e.g. Observations.
Lloyd McKenzie (Feb 16 2022 at 03:20):
Another thing that's an option is to declare NzOrganization as 'global' - which means that all references to Organization are automatically treated as NzOrganization
Richard Townley-O'Neill (Feb 16 2022 at 04:44):
In a national base profile I'd like leaving the references to Core, that way you can still say in a conformance statement that instances of PractitionerRole must conform to PractitionerRole-NZ but instances of Organization do not need to conform to Organization-NZ.
Richard Townley-O'Neill (Feb 16 2022 at 04:44):
More flexibility in the conformance statement.
Jens Villadsen (Feb 16 2022 at 06:19):
@Lloyd McKenzie the 'global' flag didnt work in the tooling last time I checked
Grahame Grieve (Feb 16 2022 at 07:52):
it's still on my todo list.
Jens Villadsen (Feb 16 2022 at 07:55):
here's a picture of that list nicely wrapped in a cover :grinning_face_with_smiling_eyes: image.png
Peter Jordan (Feb 17 2022 at 04:34):
Thanks for the helpful responses. I particularly like the option to declare profiles as 'global' and hope that makes it to the top of Grahame's list before too long.
I am aware of the dangers of constraining out elements in national profiles, as that may hinder implementers with requirements that we may not be aware of - for example there was a proposal to remove the suburb element from the NZ Address Profile (as that's not part of the NZ Postal Address standard) until the need for some systems to store holiday home addresses in Australia was surfaced. The obvious trade-off is with being too flexible and permitting use of core resources when NZ-specific ones should be used (e.g. because they contain the required identifiers and vocabulary).
Grahame Grieve (Feb 17 2022 at 04:44):
actually it looks like it's implemented to me. Does someone want to test it out?
Peter Jordan (Feb 17 2022 at 22:54):
Grahame Grieve said:
actually it looks like it's implemented to me. Does someone want to test it out?
@David Hay , @Daniel Thomson , @John Carter - thoughts?
John Carter (Feb 18 2022 at 00:51):
I still prefer the flavour referenced by @Elliot Silver in this thread... in our National IG we provide the option to refer both to an NZ one or to the base/core one. My thinking is that in the National IG I want us to be very prescriptive in defining exactly what the NZ version is supposed to look like (for example an NZaddress DOES have suburb, DOES NOT have state, and the postcode is 4 digits), but still recognise that users have a need to deal with non-NZ instances as well. I think that encourages precision but allows for flexibility in a way that's easy to understand.
Lloyd McKenzie (Feb 18 2022 at 02:11):
You can't have a choice of two types where one is based on the other. It's going to confuse the validator because the instance ends up resolving to both.
John Carter (Feb 22 2022 at 04:25):
@Lloyd McKenzie Here's an example of what I would like to see us do in NZ... are you saying this isn't good practice?: http://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-au-organization.html (see the address element in particular)
Lloyd McKenzie (Feb 22 2022 at 04:55):
Two concerns:
- Listing 'Identifier' plus a bunch of profiles of Identifier doesn't actually accomplish anything. None of the constraints present in the other profiles will ever come into play
- My experience has been that the validator gets unhappy when there are multiple profiles that are valid, though it's possible that's now been addressed.
Richard Townley-O'Neill (Feb 22 2022 at 07:14):
Two concerns:
- Listing 'Identifier' plus a bunch of profiles of Identifier doesn't actually accomplish anything. None of the constraints present in the other profiles will ever come into play
One major intent of AU Base is to provide guidance with minimal restricting. Restriction is to be in profiles derived from AU Base profiles. Listing identifier and a bunch of its profiles supports
- Not restricting what is valid
- Displaying relevant profiles of identifier
- Encouraging profiles of (say Organization) to be derived with unwanted variations of Identifier excluded
Richard Townley-O'Neill (Feb 22 2022 at 07:17):
Two concerns:
- My experience has been that the validator gets unhappy when there are multiple profiles that are valid, though it's possible that's now been addressed.
The validator gives warnings or informations, not errors.
Lloyd McKenzie (Feb 22 2022 at 14:08):
Warnings and information messages can still be confusing to implementers...
Last updated: Apr 12 2022 at 19:14 UTC
