Stream: implementers
Topic: Pattern Development
Grahame Grieve (May 12 2019 at 23:28):
@Claude Nanjo see http://build.fhir.org/request-analysis.html - the task list is driven from the file \source\[name]\[name]-tasks.ini, where [name] is the pattern name e.g. request.
The Ini file has a series of entries
[pattern.path]
Resource=tasks
where
- pattern.path is something like Event.subject - the element in the pattern that the issue is about
- Resource is the name of the resource on which the issue is being raised - e.g. there is no mapping for pattern.path, and there should be
- Tasks is a semi-colon delimited list (no spaces)
Claude Nanjo (May 13 2019 at 04:58):
This looks great. I will review with the group on Tuesday and provide feedback.
Grahame Grieve (May 13 2019 at 19:20):
more, for people's review:
- I added a new page: http://build.fhir.org/patterns.html
- I added a new set of patterns that are much more tight and suitable for code generation
- I use the pattern as a reference target: Communication.recipient
I still have some issues to sort out.
Jean Duteau (May 13 2019 at 19:29):
A couple of questions:
1) do workgroups have the ability to create patterns as they see fit or is it similar governance to resources?
2) will we be able to create patterns in Implementation Guides?
3) can WGs start changing their resources to use the patterns now, i.e. I'm assuming the build tools now support the patterns?
Grahame Grieve (May 13 2019 at 19:34):
1. It should definitely be a lower bar than resources, but it's also a team activity. So I propose that new patterns should be created via MnM
2. Yes, you already can, but they won't quite have the same implication
3. yes as far as I can see, the support is complete.
Jean Duteau (May 13 2019 at 19:34):
by #2, I guess I was asking if I can create a pattern and use it in my resources. Will the igpublisher support that?
Grahame Grieve (May 13 2019 at 19:34):
at the moment, if you use a pattern:
- the table and uml view show the pattern
- the detailed description shows the pattern and expands it
- everything else expands the pattern
Grahame Grieve (May 13 2019 at 19:35):
#2 - no, not at that level. and harder for me. I'll put it on the wishlist
Jean Duteau (May 13 2019 at 19:38):
at the moment, if you use a pattern:
- the table and uml view show the pattern
- the detailed description shows the pattern and expands it
- everything else expands the pattern
that looks good. basically the pattern is used at definition time, but is invisible to the actual definitions and other tools. nice. thank you for your work on that!
Jean Duteau (May 13 2019 at 19:38):
now we just need to start abstracting out the proper patterns and get resources to use them.
Grahame Grieve (May 13 2019 at 19:39):
there's plenty of work to do there. I'm going to write an analysis looking for reference continuity into the patterns page
Lloyd McKenzie (May 13 2019 at 19:49):
I'm not overly thrilled with this. Participant-Contactable and Participant-Living should never be used without also having PractitionerRole as an option. I'm very concerned that designers will somehow feel that these patterns trump applying the 80% rule - and they don't. I also think that 'hiding' the list of available resources behind pattern names does a disservice to readers. It adds a level of indirection to understanding what's going on.
Lloyd McKenzie (May 13 2019 at 19:49):
I understand that these might be the patterns that happen to be easy to create interfaces on, but we should be driven by the combinations of resources that are actually commonly supported.
Grahame Grieve (May 13 2019 at 19:50):
indirection is kind of useful too.
Lloyd McKenzie (May 13 2019 at 19:50):
Also, I'm not terribly clear on who we're creating programmatic interfaces for or what they need.
Jean Duteau (May 13 2019 at 19:50):
Participant-Contactable and Participant-Living should never be used without also having PractitionerRole as an option.
Get rid of the stupid distinction between Practitioner and PractitionerRole. I've already created a GForge tracker item on this because I see this over and over again ("Practitioner should never be an option without having PractitionerRole as an option").
Grahame Grieve (May 13 2019 at 19:51):
but actually this has nothing to do with 80% or any %. The question is: does the pattern override the need for analysis specific to the context
Lloyd McKenzie (May 13 2019 at 19:51):
Indirection is only useful if it's aligned with how people think of the data - and I'm not sure that these are. The names are artifacts of what was easy to create interfaces on.
Lloyd McKenzie (May 13 2019 at 19:52):
The pattern can't override the need for context-specific analysis. That needs to reflect what most systems do. If not, we're throwing away a core tenet of FHIR (for questionable benefit).
Grahame Grieve (May 13 2019 at 19:53):
There's a degree of truth to that. There's 2 reasons to create patterns - so we can use them in design, or so that they can be used in implementations
Grahame Grieve (May 13 2019 at 19:57):
if the pattern is useful in design time, the indirection is useful.
Jean Duteau (May 13 2019 at 20:01):
I also think that 'hiding' the list of available resources behind pattern names does a disservice to readers. It adds a level of indirection to understanding what's going on.
Contrary to this, I feel that the 'hiding' does a better job of further communicating the purpose of a field. Looking at Communication.receiver vs Communication.sender, I can see that a receiver is intended to be a Participant, but sender is different. If sender was converted to Reference(Participant | HealthcareDevice), I suddenly get a better view who/what might be sending Communications.
Committees will be able to look at these common interface patterns and assume that they have been vetted by many committees and users and can start with the classes in those patterns. If they decide that the pattern classes fit their use cases, then the can reference the pattern directly. If not, they can be explicit. Implementers/spec-readers will know, however, that the committee made a conscious choice to deviate from the pattern as opposed to now where we wonder how explicit a committee was being. When I looked at the list of class combos that Grahame spit out, there were some that just caused me to go "huh?". I suspect that many of those slight differences will go away now that committees can see (and potentially adopt) the common interface pattern.
Lloyd McKenzie (May 13 2019 at 20:07):
The vetting by other work groups doesn't matter when a WG is evaluating their own use. Just because Patient or Device is allowed as a participation in some places doesn't mean it will meet the 80% criteria for your domain. We want differences to go away that are there unnecessarily. We don't want differences to go away that are caused by legitimate domain differences. Providing an 'easy' reference makes it much more likely that the appropriate analysis won't happen.
Jean Duteau (May 13 2019 at 20:08):
The vetting by other work groups doesn't matter when a WG is evaluating their own use. Just because Patient or Device is allowed as a participation in some places doesn't mean it will meet the 80% criteria for your domain. We want differences to go away that are there unnecessarily. We don't want differences to go away that are caused by legitimate domain differences. Providing an 'easy' reference makes it much more likely that the appropriate analysis won't happen.
Except that implementers will push back if the appropriate analysis hasn't happen. "Why is Device included in the list of X for this data element?" will always be a question that gets asked of a workgroup and a resource. And the workgroup will need to justify the use of these resources.
Lloyd McKenzie (May 13 2019 at 20:08):
I agree that splitting Practitioner and PractitionerRole is problematic, but I think there's little chance of that being reversed at this stage. And if it's not, its absence from these patterns is going to cause huge problems. The issue is that "what's easy to interface" and "what's useful to combine" are different criteria.
Lloyd McKenzie (May 13 2019 at 20:09):
Implementers aren't doing a great job of pushing back now. And in general implementers don't push back because there's too much stuff, just when there's too little. The methodology is supposed to push back against "too much" - and the patterns approach is going to create problems with that.
Jean Duteau (May 13 2019 at 20:15):
Implementers aren't doing a great job of pushing back now. And in general implementers don't push back because there's too much stuff, just when there's too little. The methodology is supposed to push back against "too much" - and the patterns approach is going to create problems with that.
I don't understand your concern as specific to these interface patterns. When I'm looking for a participant, I go and look at existing resources to see what they have and I start from that. I then add or delete or leave as specified according to my needs. How is that going to be any different with these patterns? They provide a wonderful starting point.
Jean Duteau (May 13 2019 at 20:16):
Indirection is only useful if it's aligned with how people think of the data - and I'm not sure that these are. The names are artifacts of what was easy to create interfaces on.
What Grahame has introduced is basically just syntactic sugar (https://en.wikipedia.org/wiki/Syntactic_sugar)
Lloyd McKenzie (May 13 2019 at 20:23):
The pattern is useless as a starting point if you diverge from the starting point because you then need to replace the pattern with a full enumerated list. And you'll also have people ragging on you about why you didn't use the pattern.
The syntactic sugar is driven by "which classes have resources elements" as opposed to "which resources are commonly used together" - and those are completely different lists. The latter might be useful. The first isn't useful for design - and is likely to lead to poor design choices.
Jean Duteau (May 13 2019 at 20:27):
The pattern is useless as a starting point if you diverge from the starting point because you then need to replace the pattern with a full enumerated list. And you'll also have people ragging on you about why you didn't use the pattern.
a) Just because I need to diverge doesn't make the pattern useless. That argument would apply equally to the Request and Event pattern - why do we have MedicationRequest since I could just use the Request pattern. Because the WG took the pattern and analyzed it and diverged where they felt the need to. This would work the same with these interface patterns except that if I didn't diverge, I can just use the syntactic sugar to represent the list of classes.
b) If a committee can't elaborate on why they didn't use the pattern, then that might be a reason why they should have used it. "Your data element looks like a participant, but you only have Patient and RelatedPerson, are you sure that the other resources in the Participant pattern aren't appropriate?" looks like a totally justified question that I better have an answer to.
Jean Duteau (May 13 2019 at 20:29):
The syntactic sugar is driven by "which classes have resources elements" as opposed to "which resources are commonly used together" - and those are completely different lists. The latter might be useful. The first isn't useful for design - and is likely to lead to poor design choices.
This objection would be to the current content of the patterns and not to the use of the patterns per se. I am actually with you on the content, but Grahame just started with a common set of resources. We need to push back on the patterns to see if they are correct.
Jean Duteau (May 13 2019 at 20:33):
Moving away from the discussion of the patterns that Grahame created, I'd like to explore the use of these interface patterns as a way for a resource creator to delay defining the specific set of resources that would be referenced by a data element. I'm thinking of CatalogEntry and ChargeItemDefinition.
Would it make sense to have metadata around a pattern as to whether it was open or closed? By open, I mean a pattern that a content creator could to add by simply tagging their resource. By closed, to get a new resource added would require a tracker item.
As an example, ChargeItemDefinition.instance would be Reference(ChargeableItem) and ChargeableItem would be an open interface. Then the resources that would be considered to be ChargeableItems would add some tag in their definition to be included in the list.
Lloyd McKenzie (May 13 2019 at 20:45):
The patterns Grahame has defined are not patterns that reflect what WGs have typically done. They are patterns that reflect what resources have common elements that make them amenable to the construction of interfaces. I.e. they were designed on the basis of what might be useful to generate code for, not what constitutes good or appropriate design practice. But the proposal is to push them into design practice. I think that's a mistake.
If in implementation, someone wants to process Patients and Practitioners and RelatedPersons with the same set of code, that's a totally appropriate use for these patterns. But the fact that the resources reflect a particular common set of elements doesn't really have much relevance to appropriateness for use in a given model. And it's not that helpful for a reader either. Someone skimming a resource is going to see "Participant" and that's not going to tell them anything - it's certainly not going to break any pre-conceived mental presumptions they have about what participant might or might not include, nor is it going to encourage them to think about which of the set of allowed resources they're going to want to constrain out - or mandate support for.
John Silva (May 13 2019 at 20:45):
"Implementers aren't doing a great job of pushing back..." -- from my perspective it seems that push-back is sometimes futile since the resources have already got too much momentum to change at this point; your example of Practitioner and PractitionerRole being a prime example. Also for folks who are implementers not modelers, there are real-world concerns of 'getting the job done' that have higher priority. I remember asking the question about why MedicationRequest.category and MedicationAdministration.category have different cardinalities and ended up down a long discussion path that wasn't that fruitful from my perspective as a developer. It seemed to me that the cardinality difference was an error of omission, not a conscious decision of the committee but it took weeks to get to that understanding. Yes, we probably need more input from implementers but it is not 'inexpensive' for implementers to get involved and if their efforts aren't seen as productive, they will 'shy away' from participating.
Lloyd McKenzie (May 13 2019 at 20:54):
1. I think introducing patterns into the design process as something that can be explicitly referenced by designers is a mistake:
- it hides what resources are actually available from both the authors and the readers
- it adds complexity to profiling constraints (and those are complex enough, thanks)
- it encourages adherence to patterns over adherence to the 80% rule and the latter is more important than the former
2. If we were going to introduce patterns into the design process, the patterns should be based on whats commonly implemented together, not what happens to have common attributes. The latter has no place in the design process at all. If such patterns are going to be used, they belong only in the implementation space. (Which also means that it would be fine to add Person into the Living Participant pattern, because you'd only care about the attributes, not where they're used.)
Note: I'm in favor of encouraging greater consistency - and specifically on eliminating as much as possible those errors of omission that create grief. But I'm not in favor of making the modeling neater at the price of no longer reflecting the reality of what systems do. Our objective with the FHIR core spec is not to change what data systems capture and false consistency of resource designs when underlying implementations don't reflect that doesn't help anyone.
Claude Nanjo (May 13 2019 at 21:00):
I completely agree with John Silva. I think it sums up exactly the kinds of problems we are facing as well. Some of the resource divergences from patterns seem fairly arbitrary but come at a cost for implementers. While these do get fixed, it requires tremendous effort and time commitment. In the meantime, we address these inconsistencies in code but now the problem has been pushed to all implementers of FHIR. I would favor two views of FHIR, the resource view and a more consistent (and stable) view based on patterns where all participations, for instance, are addressed in a consistent way.
Grahame Grieve (May 13 2019 at 21:01):
the problem is that there is no consistency in participations in the real world. The risk, then, is that we impose a fantasy consistency that isn't real. And it does seem pretty likely to me...
Grahame Grieve (May 13 2019 at 21:05):
we do not have, at this time, a list of which elements represent 'participations' and I think it's only a meaningful thing to say in a derived ontological view of the world (the RIM). Eventually the discussion will morph into 100s of little issues, or a single large discussion about the importance of not being a heretic. That's what Lloyd's afraid of
Grahame Grieve (May 13 2019 at 21:06):
but the community participation issues @John Silva raises are real too
Grahame Grieve (May 13 2019 at 21:06):
let's just have the 100s of little discussions
Claude Nanjo (May 13 2019 at 21:07):
If you look at performer for instance, there is great variation across resources - naming of attributes, types allowed for choices, attributes that make up the participation in the first place. Yet, they all look roughly the same - give or take a few attributes such as period or required. If the resource wishes to name these things differently, okay. The pattern, on the other hand can be consistent. Often, even the variation in choice types seems odd (sometimes CareTeam is in, sometimes it is out, etc...). I think that there is a lot that could still be done to make the resources more consistent and the patterns useful while still meeting the other requirements of FHIR.
Grahame Grieve (May 13 2019 at 21:21):
ok. analysis for performer:
pasted image
Grahame Grieve (May 13 2019 at 21:22):
first question: - how can a substance or a location be the target of "Indicates who or what is being asked to perform (or not perform) the ction" ? (@Paul Knapp)
Grahame Grieve (May 13 2019 at 21:23):
reposting simpler diagram without crazy outliers:
Grahame Grieve (May 13 2019 at 21:23):
Grahame Grieve (May 13 2019 at 21:30):
- a healthcareService should be able to perform a contract, or be linked to a ChargeItem
- same for an ImagingStudy, Observation, DiagnosticReport and MedicationRequest performer - if a care team and and organization can perform it, why not a healthcare service?
presumably those relate to a process problem
Grahame Grieve (May 13 2019 at 21:35):
- Observation and DiagnosticReport don't allow for a Device to perform them. I presume that's a domain based decision - but it's one I think I'd challenge on domain based reasoning. (actually Observation pulls device off on it's own, but it's effectively a performer)
Grahame Grieve (May 13 2019 at 21:36):
- I don't know what grounds there is for allowing an organization to dispense or do a procedure, but not a careteam or a healthservice
Grahame Grieve (May 13 2019 at 21:37):
- MedicationAdministration and RiskAsessement are limited to trace to an individual not a collective source - a domain decision - but why not allow patients or their carers to make RiskAssessments? (and clinical impressions?)
Grahame Grieve (May 13 2019 at 21:38):
- I don't know why care teams and healthcare services can't agree to consents
Grahame Grieve (May 13 2019 at 21:41):
Seems to me that there's 2 orthogonal patterns:
- Collective / Individual
- +/- device
Lloyd McKenzie (May 13 2019 at 21:47):
HealthCareService (and CareTeam) have both evolved, which is part of the challenge. The former used to talk about "a capacity", but is now being used as a sub-organizational unit. CareTeam is similar, though it's been around for longer so has propagated further.
CareTeam or HealthService doing dispenses doesn't really make sense. I can't imagine a use-case where that would ever be tracked at that granularity in practice. Same is true for RiskAssessments. A Patient or care-giver might complete the questionnaire that serves as input to the assessment. However the determination that you have a 23.7% chance of getting diabetes by age 50 is going to be made by a Device or a Practitioner, never by the patient or caregiver themselves.
Jean Duteau (May 13 2019 at 21:48):
Seems to me that there's 2 orthogonal patterns:
- Collective / Individual
- +/- device
So perhaps just two defined patterns that don't include Device and WGs can add Device if necessary?
Performer (for the Collective)
IndividualPerformer (for the non-collective)
Lloyd McKenzie (May 13 2019 at 21:48):
Consents need to be agreed to be a legal entity. In general, CareTeams and healthcare services aren't. They're "convenience" organizations that can be used to attribute responsibility.
Claude Nanjo (May 13 2019 at 21:50):
Interesting, when trying to make sense of FHIR participations and choices, I came up with this. Device, as Jean points out is a different dimension potentially: pasted imageJohn
Lloyd McKenzie (May 13 2019 at 21:50):
You still need to prune out the ones that don't make sense/would never be supported in a particular use-case. For example, Patients/RelatedPersons aren't allowed to be the "performers" of an immunization. That's a domain choice reflecting practice. We're not going to tell Public Health they need to use the pattern just because it makes for neater modeling.
Jean Duteau (May 13 2019 at 21:51):
You still need to prune out the ones that don't make sense/would never be supported in a particular use-case. For example, Patients/RelatedPersons aren't allowed to be the "performers" of an immunization. That's a domain choice reflecting practice. We're not going to tell Public Health they need to use the pattern just because it makes for neater modeling.
That's a straw-man argument - why do you think we'd be telling Public Health to use the pattern? Obviously they wouldn't use it because it doesn't make sense for their use case.
Paul Knapp (May 13 2019 at 21:55):
I don't know why, or understand why, a location is a choice for performer, I ask others.
Lloyd McKenzie (May 13 2019 at 22:02):
My gut is that 1/2 to 2/3 of the places we'd look at using these patterns, at least one of the resources in the patterns would need to be yanked out or one or two would need to be added. Based on past experience with patterns, I'd also expect that many WGs would feel constrained to use the pattern and wouldn't do the necessary yanking/addition.
Let me ask a different question. If I determine what I need is Patient, Practitioner, PractitionerRole, Organization and Device, how does that impact the utility of the interface pattern from a development perspective? Is it going to have problems because Practitioner and Device are in the mix? In either event, does it matter whether the pattern is declared on the design side?
Grahame Grieve (May 13 2019 at 22:16):
However the determination that you have a 23.7% chance of getting diabetes by age 50 is going to be made by a Device or a Practitioner, never by the patient or caregiver themselves.
Actually, it's made by an algorithm. I don't agree with this for domain reasons. why can't a patient adminster the algorithm? (see openAPS...)
Claude Nanjo (May 13 2019 at 22:17):
I agree with Grahame. Are we too focused on the inpatient use case?
Grahame Grieve (May 13 2019 at 22:17):
CareTeam or HealthService doing dispenses doesn't really make sense
but organizations do? I'm not seeing the differentiation here
Claude Nanjo (May 13 2019 at 22:21):
I think it is okay if the pattern is more general than the individual resource. In some cases, some options won't be relevant or used much - as long as they are not semantically wrong - e.g., a related person will generally not administer a vaccine but they could if they were trained to do so and needed to reach an isolated population.
Claude Nanjo (May 13 2019 at 22:23):
They key is that the pattern is not more narrow than the collection of resources represented by the pattern such that a resource loosens the constraints of the pattern. I have seen that in FHIR where a resource references ANY when the pattern references a specific set of resource types.
Lloyd McKenzie (May 13 2019 at 22:41):
Pharmacies are represented as Organizations. HealthCareService might be used to say "this clinic/hospital has a pharmacy", but the dispense would be indicated as coming from the hospital organization or departmental organization.
Grahame Grieve (May 13 2019 at 23:10):
but a Healthcare Service has and acts on behalf of an organization...
Grahame Grieve (May 13 2019 at 23:14):
so clarifying based on off-thread discussion - I'm not arguing that the reference list in the resources is wrong because they don't conform to the pattern. I used the pattern analysis to discover that I disagreed with the analysis in the resources
Lloyd McKenzie (May 13 2019 at 23:20):
Grahame has clarified off-line that the proposed patterns wouldn't replace the type declarations in the StructureDefinitions, which means that my concern about profiling/validation impact goes away and - depending on publishing decisions - may make my hiding concerns go away as well.
Is there something that these patterns add that the existing Event/Definition/Request patterns don't in terms of being able to examine analyis choices made by WGs? The Event/Definition/Request patterns have the additional benefit that their patterns of references allow different expectations for different types of associations. And they aren't driven by commonality of attributes, they're driven by commonality of usage.
Claude Nanjo (May 13 2019 at 23:28):
That was my understanding as well @Lloyd McKenzie . By patterns, I mean the current three patterns. I was not referring to other patterns but perhaps others were.
Grahame Grieve (May 13 2019 at 23:30):
well, there's 2 different subjects here. one concerns the general utility of the patterns, and the other concerns the particular patterns i chose. I did chose those patterns based on suggested commonality of attributes, and then I did use one of them in a place where it was already used in order to demonstrate what it would look like. Perhaps there are 2 different things at play, but you are way over concerned about the connection
Grahame Grieve (May 14 2019 at 00:02):
GF#22142, GF#22143, GF#22144, GF#22145, GF#22146, GF#22147, GF#22148, GF#22149, GF#22150, GF#22151
Grahame Grieve (May 14 2019 at 00:02):
I do not believe that we have ever asked committees to review the list of resources that do or don't refer to a resource that they define
Claude Nanjo (May 14 2019 at 18:01):
Hi @Grahame Grieve , could we add another column to http://build.fhir.org/request-analysis.html called status with three values: "In backlog", "In progress", "Resolved"? The resolved status is important so we know that a decision was taken and that if there is a divergence from the pattern it is known and expected.
Eric Haas (May 14 2019 at 18:53):
Committees will be able to look at these common interface patterns and assume that they have been vetted by many committees and users and can start with the classes in those patterns.
I won't be making any assumptions that they have been vetted by any one
Eric Haas (May 14 2019 at 18:53):
because I don't believe it has
Grahame Grieve (May 14 2019 at 20:02):
well, the current ones haven't at all. But later that might change. or not
Grahame Grieve (May 14 2019 at 20:02):
@Claude Nanjo don't know where the source for that would be
Claude Nanjo (May 14 2019 at 20:09):
Same ini file?
Grahame Grieve (May 14 2019 at 20:16):
well, there's 2 different ideas here - the status of the task, and the status of the mapping. And the question of who's authority we are talking about when we make any statements in this regard
Claude Nanjo (May 14 2019 at 21:52):
@Grahame Grieve I was referring to the status of the mapping. The status of the task(s) would be handled in GF. There could be multiple tasks targeting a single mapping. As to the authority on the mapping, I am assuming it is the workgroup that owns the resource after collaboration with the FHIR team.
Jean Duteau (May 15 2019 at 05:03):
We had a lengthy discussion on the MnM call today about Patterns. People should come to the next call in two weeks (on the 28th) as I suspect we might talk some more about it. We agreed that there were three types of "patterns":
1) The existing patterns like Event/Request which are large-scale patterns that are intended to shape resources that want to conform to the pattern.
2) Category patterns where a resource agrees to defer who is being referenced by one of its data elements to other resources. The clearest example of these would be CatalogEntry having a reference to a CatalogableItem or a ChargeItemDefinition have a reference to a ChargeableItem. Resources could then declare that they belong to the CatalogableItem category or the ChargeableItem catagory and could be referenced by the parent resources. I called these "open" patterns in previous postings. The benefit of this scheme is that the CatalogEntry or ChargeItemDefinition doesn't have to change every time a new resource wants to be cataloged or have a charge definition.
3) The final pattern type is what Grahame has been posting about. A combination of a pattern that details the data elements (like #1) and also allows resources to talk about sets of resources (like #2). There is still some debate over how these patterns would be referenced. Currently, Grahame has the tooling working so that Communication.recipient is a Reference(Practitioner). There is an argument that this syntactic sugar does not communicate well with implementers. So that might not stick. Instead, what appears to be workable is that a resource data element would be marked as a candidate for a pattern, eg. X.performer should be conformant to the Performer resource pattern. To declare a different set of resources than the pattern would require an override by the resource owner and a clear reason for why the difference exists. These reasons would be visible in the specification.
For both pattern type #1 and #3, we all agreed that better enforcement of the patterns and a more rigorous treatment of differences needed to happen. The mechanics of this governance are still to be worked out, but it does mean that those of us who are creating resource definitions will need to pay closer attention to build warnings and QA issues.
Grahame Grieve (May 15 2019 at 05:09):
the tooling working so that Communication.recipient is a Reference(pattern)
That’s also necessary for pattern type 2, so the question isn’t about the methodology, but about when it should be applied
Jean Duteau (May 15 2019 at 05:12):
the tooling working so that Communication.recipient is a Reference(pattern)
That’s also necessary for pattern type 2, so the question isn’t about the methodology, but about when it should be applied
Yes, that is correct. I forgot to make that point in type 2, i.e. that we need the syntactic sugar for type 2 but don't want it for type 3.
Jean Duteau (May 15 2019 at 05:14):
In all cases, FMG will be the arbiter of a) what resources/elements should conform to a pattern, b) what resources can claim to belong to a category, and c) when a resource data element can claim to use/follow a pattern. NOTE: (c) might be the same as (a), my notes are a bit fuzzy on this distinction.
Lloyd McKenzie (May 15 2019 at 05:17):
I expect the arbiter bit will be a mix of FMG, FHIR-I and MnM. MnM/FHIR-I will propose, FMG will choose to enforce or not (or push back). (FHIR-I is involved just because it owns the workflow project - though I guess that could be transferred to MnM.)
John Silva (May 15 2019 at 10:09):
As an observer of this it seems that having these patterns, formalized or not, is very valuable in getting consistency in the naming and structure of resources developed independently by the different WGs. As an end-user, I don't necessarily know these WG distinctions and I wonder why the same structural item (concept/property) is named differently in one resource vs. the other. I understand the WGs come from their own domain of experience, but to an end user, this domain distinction blurs, because we need to 'get the job done' and consistency helps more than 'domain-specific naming'. Besides, the (clinical) end users of FHIR do NOT see these naming distinctions, the two groups affected most are the modelers or resource developers but those are few, and the implementers, who, if the standard is working well, are the majority of the users of these resources (patterns).
Grahame Grieve (May 15 2019 at 12:26):
consistency helps more than 'domain-specific naming'.
Actually, our feedback is the opposite. Expecially from the CDA world where all the status code and element names are constant, and we have to explain what those things actually mean in CDA templates...
Lloyd McKenzie (May 15 2019 at 14:22):
Our objective is to make FHIR intuitive, particularly to 'simple' implementers - those who might only be worrying about a couple of resources. Having generic names that don't reflect domain conventions significantly increases the learning curve for those people - and loses one of FHIR's key advantages. Systems that are interested in sharing code that works across many resources are comparatively less common and always more sophisticated, so dealing with naming variations is something they can more reasonably handle - especially if there are mappings indicating which elements are equivalent.
Yunwei Wang (May 15 2019 at 15:00):
Give an example, one of my app only deal with Condition resource (patient's problem list). So consistency is not an issue for me. It is more important to be able to communicate with users/physician/provider with FHIR resource.
Jose Costa Teixeira (May 16 2019 at 22:12):
implementers have roadmaps and some may have several teams. So most teams will start with a couple of resources, then they will add the other resources, or another team will do other resources. Lack of consistency usually hurts much later than when we are starting to adopt.
Jose Costa Teixeira (May 16 2019 at 22:13):
Naming is hardly an issue for them. Most painful is when similar things work rather differently.
Lloyd McKenzie (May 16 2019 at 22:40):
If the behavior is different, that'll be driven by domain variations, not forced by FHIR. It certainly sucks when it happens, but the real world is what the real world is. (I continue to cringe at some of the financial models because they don't do things the 'standard' FHIR way. But those from the domain consistently say that they're happy and that the models align with how that space works. It's certainly going to create challenges for those who would prefer that everything worked consistently, but we can't very well tell the whole financial business space to change their business processes to better align with how FHIR would like to see things done. (As much as part of me might privately like to do just that :>)
Grahame Grieve (May 16 2019 at 22:46):
there's a balance here. We can work to reduce unnecessary variation. we can also go too far
Jose Costa Teixeira (May 17 2019 at 00:00):
domain variations is what i mean - different domains model the same real world in different ways. As an SDO (which developers will read to influence their designs), I believe we have a responsibility to keep some orthodoxy. But i certainly agree we shold support the variety of practices out there.
Jose Costa Teixeira (May 17 2019 at 00:03):
I am not unhappy with the "design first, pattern later" approach, just saying that consensus changes, so people should be aware that there will be alignment even after they agree on something.
Jose Costa Teixeira (May 17 2019 at 00:05):
Like most people, I have some times "this is what we agreed and we will never change.... 5...4...3..2...1.. oh wait..."
Jose Costa Teixeira (May 17 2019 at 00:07):
I think that step of aligning to a pattern is key. but should be use-case driven. And there I am not sure the 80/20 rule is the criterion.
Jose Costa Teixeira (May 17 2019 at 00:08):
sure, there are not many implementations that handle device and medication in a common way. and the products that are on the border are very few. So the use case to keep them consistent is not in the 80%.
Jose Costa Teixeira (May 17 2019 at 00:09):
but there is no use case to keep them inconsistent either.
Grahame Grieve (May 21 2019 at 06:46):
ok. so I just committed something more - now, the build tools look to see what patterns a set of targets implement, and state this. for an example, see http://build.fhir.org/allergyintolerance-definitions.html#AllergyIntolerance.asserter. the same information is written into the StructureDefnitions to assist code generators
Lloyd McKenzie (May 21 2019 at 08:08):
And that is advice to implementers (who might want to use the interface), not guidance for designers - correct?
Grahame Grieve (May 21 2019 at 09:43):
yes
Mark Kramer (May 21 2019 at 18:51):
@Grahame Grieve's comment that "there is no consistency in participations in the real world" requires some analysis. Participation in an event is perfectly well-defined, but who or what can participate in what type of event in what role is highly varied. Every participation should have an actor, associated role, an optional time period and optional "onBehalfOf", but when you look across FHIR, you find this high-level pattern is broken right and left. The low level particulars of who/what can participate in what type of event is also broken because you find numerous cases where the choices are incomplete due to errors and oversights. FHIR puts great faith in the wisdom of work groups, but committees suck at design -- no matter if we are talking patterns OR particulars.
Lloyd McKenzie (May 21 2019 at 19:45):
It's not a question of 'should' - it's a question of what systems actually do. If systems don't do it, then it doesn't show up in the FHIR spec - regardless of whether it might be good practice or desirable from a modeling perspective. The places where there are differences because of errors/oversights need to be fixed. The places where there are differences because "most real systems don't currently support that" are legitimate differences.
Mark Kramer (May 21 2019 at 20:20):
"If systems don't do it, then it doesn't show up in the FHIR spec - regardless of whether it might be good practice or desirable from a modeling perspective. " What evidence do you have for that statement @Lloyd McKenzie?
Lloyd McKenzie (May 21 2019 at 20:24):
That's the FHIR design rules. The whole 80% principle is that FHIR tries to adhere to what systems actually support in the real world, not what we wish they did. As a result there will be inconsistencies in resources that are driven by real-world variations in behavior. The benefit of that approach is that when you look at FHIR you'll get a sense of what you can reasonably expect (as opposed to seeing a model of the theoretical which never actually gets met in practice).
Mark Kramer (May 21 2019 at 20:29):
That isn't evidence.
Grahame Grieve (May 21 2019 at 20:30):
The low level particulars of who/what can participate in what type of event is also broken because you find numerous cases where the choices are incomplete due to errors and oversights
That is certainly true. And it's a place where more work is required. I don't think Lloyd's response is quite balanced; what the majority systems do is a big part of the input to the design, but it's not the only input.
It is true that if some pattern isn't being followed, the justification for change in the proposal to the committee isn't "you aren't following the pattern", but "this real world case isn't being considered, and it should be (and, btw, the pattern says)". See the tasks I created above
Participation in an event is perfectly well-defined, but who or what can participate in what type of event in what role is highly varied. Every participation should have an actor, associated role, an optional time period and optional "onBehalfOf"
Maybe, but for example, the time period might be fixed by context for a resource that doesn't represent something that happened over a period of time. Same for role - often fixed by context or element name (though it would be good to have a way to be explicit about that). And OnBehalf of seems very theoretical to me; I don't see it being used in all but a few legal-ish circumstances
Grahame Grieve (May 21 2019 at 20:31):
tasks back above - https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Pattern.20Development/near/165580595
Mark Kramer (May 21 2019 at 20:32):
Grahame, I should have said that the pattern of Participation can omit elements if an element is irrelevant in the context where that pattern is used. But the overriding pattern still holds.
Lloyd McKenzie (May 21 2019 at 20:37):
That isn't evidence.
Not sure what you're looking for. Are you asking for evidence of disuse? The onus is actually the other way around in FHIR. A proponent of having something included in the core specification needs to provide evidence of widespread support (or in limited cases, expected support) for an element to have it included in the specification.
As an example, most systems don't have the ability to capture patients or devices that perform immunizations. It might be theoretically possible that that could happen sometimes, but if most systems don't have the ability to capture that, it's not going to be supported by the resource - and thus Immunization would diverge from the pattern of the "common" participants.
Claude Nanjo (May 21 2019 at 21:32):
@Grahame Grieve you did not reply to my answer to your question about adding another column for the status of a row in http://build.fhir.org/request-analysis.html. If we could add this, it allows the work group to state whether the current state of the row is 'in-progress' or 'resolved'. When resolved, it means all tracker items on the item have been addressed and the deviation (or adherence) to the pattern is known and understood to be correct. It allows us not to relitigate an item that has undergone significant discussion. Another row for comments might also be useful (e.g., summary of decision or gist about open questions).
Grahame Grieve (May 21 2019 at 21:35):
I'm still thinking about where the source for the row lives
Mark Kramer (May 21 2019 at 21:51):
@Lloyd McKenzie I'm not blindly arguing for globally implementing patterns that no system could possibly populate, but since you brought it up as a justification against patterns, I am curious about how well FHIR does in modeling only what the super-majority of EHR systems actually collect. Again, I'm asking what evidence you have that FHIR has actually held to the design principles you enunciated. If not, then your argument against imposed patterns is substantially weakened.
Lloyd McKenzie (May 21 2019 at 22:06):
I'm not sure what evidence you're looking for. The methodology is the methodology. It's certainly been adhered to with varying degrees of success (and some of the challenges we've had with adherence has actually been work groups over adhering to patterns rather than focusing on what's common practice). In any event, the methodology remains the methodology. Implementers can and should raise tracker items when they feel items are included in a resource that aren't widely supported (as well as the reverse). In situations where there's a choice between adhering to a pattern or reflecting what most systems do, the current expectation is that work groups will err towards the latter.
Mark Kramer (May 21 2019 at 22:10):
Round up the top 10 EHRs in use today, and see which ones can populate each element in FHIR, starting with the top 20 resources in FHIR. That kind of evidence.
ksrc murthy (May 21 2019 at 22:10):
Can use hapi fhir in my application and share with clients?
ksrc murthy (May 21 2019 at 22:10):
Please help me.
Josh Mandel (May 21 2019 at 22:11):
You'll want #hapi @ksrc murthy.
Grahame Grieve (May 21 2019 at 22:15):
@Mark Kramer we do what we can do do to that . but the access is never complete and the answer is never simple or binary.
ksrc murthy (May 21 2019 at 22:16):
Yeah, ACN I use hapi fhir
Lloyd McKenzie (May 21 2019 at 22:17):
And EHRs are only one part of the denominator for evaluation.
Mark Kramer (May 21 2019 at 22:23):
Imperfect evidence is better than no evidence at all, and I'll bet $20 (AU or CA) that the bulk of FHIR doesn't literally follow the 80% rule. If that's the case, we should formally acknowledge FHIR needs another design rule, not just "it models what's really out there". I think we are slowly creeping toward that conclusion, anyway.
Lloyd McKenzie (May 21 2019 at 22:27):
I disagree with the premise that divergences from the methodology mean we should change the methodology. An alternative view is that divergences point to a need for better training and governance. The objective behind the methodology stands - it's more important to reflect what systems do in a standard than what we'd like them to do. We want to lower barriers to implementation and also set a common understanding about what's reasonable to expect in other systems.
Grahame Grieve (May 21 2019 at 22:44):
divergences from the methodology mean we should change the methodology
Consistent divergences from the stated methodology mean we should state the methodology more clearly
Michele Mottini (May 21 2019 at 22:48):
(for what is worth at https://fhir.careevolution.com/master.adapter1.webclient/fhir you can see which resources our data model maps to / from - with mapped elements for each one - we are not an EHR but we aggregate data from a lot of different EHRs and other data sources like payer systems)
Michele Mottini (May 21 2019 at 22:49):
(all and only US - based)
Jose Costa Teixeira (Jun 01 2019 at 07:02):
divergences from the methodology mean we should change the methodology
Consistent divergences from the stated methodology mean we should state the methodology more clearly
and we should monitor why those divergences appear. I think we need outer feedback loops to see if what we are doing is breaking on the edges - very often it does.
Jose Costa Teixeira (Jun 01 2019 at 07:05):
To me, it seems that there are a few mechanisms that push towards tunnel vision ("we are going to do this for these systems because those are the systems we know of today / we are in a hurry / we don't yet see the big issue") but later it is very hard to broaden, because a decision has been made and "well, why should we reopen things that were voted already?"
(these quotes are meant to be representations, not actual citations)
John Silva (Jun 01 2019 at 12:21):
@Jose Costa Teixeira - thanks for pointing this out. It sometimes feels like us 'late comers' to the FHIR world have real use cases and real systems that we are dealing with but because the decisions have already been made it's almost impossible to change now. It seems like there are reasons that decisions had to be made back 4-5 yrs ago based on the 80% principal but the 'contributor world' was relatively small back then that there were most likely very few use cases that were used to make the decisions and now that many more (companies, individuals, new start-ups, government entities) are getting 'into the game' that there may be a need to revisit some of the "80% decisions" made previously.
Jose Costa Teixeira (Jun 01 2019 at 14:40):
Indeed sometimes we see this. It is not bad to iterate and that is one success of FHIR IMO : we populated the key areas and we managed the scope quite well, now we see that some decisions were made when we had less insight or we did not know what the next person was working on. But now we know and it feels hard to swim upstream and revisit some decisions. I look forward for some methodology aspects to help collaborate faster. And I think these patterns will help.
Grahame Grieve (Jun 01 2019 at 22:47):
we revisit them on a regular basis, but that doesn't make it an easy process. OTOH, some people's obvious is other people's 'what?"
Lloyd McKenzie (Jun 01 2019 at 23:47):
With FHIR, I believe we've had a deeper degree of implementation and a longer period of review and broader degree of review than we've had with any previous specification before we moved it to "normative". The reality is that we have to lock things down at some point - the cost of change becomes too high and the potential instability becomes a barrier to adoption. That does mean that those who are late to the party may find that there are some things they might wish were different have limited ability to affect change. However, the way FHIR is designed, it should be exceptionally rare that there's a use-case that simply cannot be implemented because of the normative decisions. The worst that should happen is that the locked-in solution is sub-optimal for a particular space and requires an unpleasant work-around.
The other thing to consider is that there's a lot of FHIR that isn't locked down yet - and this is definitely the time to review and propose changes before things get locked down further.
Jose Costa Teixeira (Jun 05 2019 at 15:56):
Suggesting the "Product" pattern gets some attention then: Medication and Devices have been aligning with each other but not compete yet and not so easy.
They are the same - both have definitions (one is called Knowledge). Both are prt of catalogs. Both can be ordered, or be stated, or be traced, or be supplied...
Jose Costa Teixeira (Jun 05 2019 at 15:57):
The longer we wait , the more likely we will have
a) genuine and valid divergences in models (hard to resolve)
b) tendency for "my baby" vs "not invented here"
Lloyd McKenzie (Jun 05 2019 at 17:46):
We could take up a "product" pattern on the workflow calls. (Given that other work is sort of stalled at the moment, that would be a useful thing.)
Grahame Grieve (Jun 07 2019 at 04:36):
there's no reason not to draft one now... it's the right time to do speculative work like that
Last updated: Apr 12 2022 at 19:14 UTC
