Stream: implementers
Topic: Why X not Y Modeling Questions
Virginia Lorenzi (Jan 21 2020 at 19:41):
Patient and MedicationRequest and RelatedPerson and ServiceRequest are of type DomainResource which is of Type Resource. As a result, these resources all end up sharing a common set of fields - those in DomainResource and Resource.
MedicationRequest and SupplyRequest and ServiceRequest all share some fields in common beyond those in DomainResource and Resource. Those common fields are defined in the Request pattern.
Patient and Practitioner and RelatedPerson are not of type Person but all 4 share similar fields that are not in DomainResource or Resource and do not follow an established Pattern.
1) Why is that? Why isn't there either a pattern or a "nested" resource?
2) Why was the pattern approach used for workflow, instead or the nested resource approach - what are the ramifications for each of these approaches for implementers?
3) If you want to follow a pattern, what rules do you need to follow - are there standards and guidelines or official process somewhere or a tool that takes you through it or quality checks to ensure you are doing it right?
4) Are there any other examples of "nested resources" (let me know if that is the wrong term to use) and are there plans to nest in future or no and why.
Thanks in advance for humoring my and my students interest in this matter.
Jose Costa Teixeira (Jan 21 2020 at 19:57):
DomainResource is the "parent class" for all FHIR implementable resources (except for a few infrastructural resources like Bundle)
Jose Costa Teixeira (Jan 21 2020 at 19:58):
so it's easy to see why MedicationRequest and RelatedPerson and ServiceRequest and Observation are of type DomainResource. Because they all do.
Jose Costa Teixeira (Jan 21 2020 at 20:00):
For workflow (and soon for things like Product) we are using patterns - not for imposing a model, but to make sure that the committees' decisions and different perspectives from local consensus do not introduce distortions.
Jose Costa Teixeira (Jan 21 2020 at 20:03):
For example: the notion of "Do not do this" is pretty common across all resources, so it may as well be expressed in a similar manner.
Another example: When fulfilling a request, we may have some events, sub-requests, tasks, etc. And some of these things are pretty consistent in the reality, there is no need for our implementations to diverge.
Jose Costa Teixeira (Jan 21 2020 at 20:04):
This is why we have some patterns - non-binding aspects that groups can use (or not), but ensure that software can be implemented in a consistent way.
Jose Costa Teixeira (Jan 21 2020 at 20:06):
These are just a quick description of what we have (my personal opinion).
There are more discussions on this topic, much more interesting and fundamented in the Methodology stream
Lloyd McKenzie (Jan 21 2020 at 20:49):
We're pretty careful about the use of inheritance in FHIR because we don't want to inherit just because it logically might exist, but rather because it meets the 80% rule. Patterns get mapped to, not inherited from. Many of the Request resources don't exactly mirror the Request pattern - some elements are handled as extensions rather than core. Some are dropped entirely. Some attributes have different constraints. Inheritance doesn't allow for any of that. As well, inheritance doesn't allow for terribly logical ordering of elements sometimes.
Lloyd McKenzie (Jan 21 2020 at 20:49):
Person is not a logical ancestor of Patient, RelatedPerson or Practitioner - it's a completely different resource intended for linking multiple resources together and maintaining shared demographics.
Lloyd McKenzie (Jan 21 2020 at 20:50):
The rules for following a pattern are "please look at the pattern and consider whether alignment makes sense for each element. Even if there isn't full alignment (e.g. name is different due to domain conventions), include a mapping to the pattern where the semantics are equivalent.
Lloyd McKenzie (Jan 21 2020 at 20:51):
We have a bit of inheritance in the data types spec. No other place that I can think of
Virginia Lorenzi (Jan 22 2020 at 04:08):
Thank you!
Last updated: Apr 12 2022 at 19:14 UTC
