Stream: implementers
Topic: Profile Inheritance
Charlie Filkins (Jul 13 2020 at 20:26):
I have an OO background, so I'm inclined to see inheritance in places it may not exist. For example, CARINBBPatient "builds on" USCorePatientProfile. That suggests to me that if a representation of a patient instance conforms to the CARINBBPatientProfile it must also conform to the USCorePatient profile. As such, we can include profiles in the Meta.profile collection. Is this true? If so, where is this level of specificity between profiles documented?
Thanks ... Charlie (FHIR Novice)
Jens Villadsen (Jul 13 2020 at 20:28):
it is valid to include both profiles in the meta.profile with the case you mention, yes
Jens Villadsen (Jul 13 2020 at 20:28):
the level of specificity between profiles is documented in your implementation guide
Grahame Grieve (Jul 13 2020 at 20:29):
yes. But note that profiles themselves are not quite class definitions, so other generalizations you might draw from OO may not apply
Jens Villadsen (Jul 13 2020 at 20:29):
where the CARINBBPatientProfile states that it is based on USCorePatientProfile
Charlie Filkins (Jul 13 2020 at 20:30):
Thanks Jens ... I was thinking about general documentation that discusses profile relationships.
Jens Villadsen (Jul 13 2020 at 20:30):
i would say it is closer to interfaces than to inheritance ...
Jens Villadsen (Jul 13 2020 at 20:30):
as your instance can 'conform' or be valid to multiple profiles on equal levels
Jens Villadsen (Jul 13 2020 at 20:31):
(unless we are talking programming languages that allow multiple inheritance like C++ that is)
Charlie Filkins (Jul 13 2020 at 20:33):
It is sounding to me like we're leaning towards OWL resource definitions ... my resource has these properties ... therefore it is an XXX.
Is that about right?
Charlie Filkins (Jul 13 2020 at 20:37):
If one profile build on another, can that new profile change the definition so that the resource no longer conforms to the original profile?
Jens Villadsen (Jul 13 2020 at 20:38):
not necessarily spot on, but yes. While a given resource of may conform to both CARINBBPatientProfile and USCorePatientProfile - it may also conform to other profiles that may be of no interest - eg. SomeExampleCoreGermanPatientProfile, but just because it in a certain state may conform to all three, it does not necessarily make sense to state all three
Jens Villadsen (Jul 13 2020 at 20:42):
Charlie Filkins said:
If one profile build on another, can that new profile change the definition so that the resource no longer conforms to the original profile?
depends on whether your canonical url to your profile in meta.profile is versioned or not in your resource (if im not mistaken, @Grahame Grieve )
Jens Villadsen (Jul 13 2020 at 20:42):
@Charlie Filkins see http://build.fhir.org/datatypes.html#canonical and http://build.fhir.org/resource.html#Meta
Grahame Grieve (Jul 13 2020 at 20:49):
well, assuming that versions match, then no, a new profile cannot change the definition so that the resource no longer conforms to the original profile.
A clearer way to say this is : profiles can only add rules; they cannot unmake any rules already made elsewhere
Jens Villadsen (Jul 13 2020 at 20:54):
there are no technical barriers that guards that step - only common sense
Jens Villadsen (Jul 13 2020 at 20:54):
AFAIK
Grahame Grieve (Jul 13 2020 at 21:45):
the snapshot generator does what it can - what I have figured out how to compute
Charlie Filkins (Jul 14 2020 at 11:23):
Grahame ... Thanks, that is what I understood from my reading ... you can only add to the constraints, not override them.
Grahame Grieve (Jul 14 2020 at 12:12):
yes that's correct.
Last updated: Apr 12 2022 at 19:14 UTC
