Stream: fhir/infrastructure-wg
Topic: Replaces Extensions
Grahame Grieve (Aug 04 2018 at 06:01):
I see that we now have:
- http://build.fhir.org/extension-diagnosticreport-replaces.html 0..1 Reference(DiagnosticReport)
- http://build.fhir.org/extension-observation-replaces.html 0..* Reference(Observation)
- http://build.fhir.org/extension-replaces.html 0..* canonical(%conformance)
- http://build.fhir.org/extension-request-replaces.html 0..* Reference(Resource)
- http://build.fhir.org/extension-task-replaces.html 0..* Reference(Task)
Grahame Grieve (Aug 04 2018 at 06:01):
seems to me that we should have just one of these
Lloyd McKenzie (Aug 04 2018 at 06:10):
There's tooling reasons why it's useful to have Request.replaces and definition-replaces as distinct
Lloyd McKenzie (Aug 04 2018 at 06:10):
But agree that the rest should collapse
Eric Haas (Aug 04 2018 at 19:24):
can we collapse event and request into one gerneral extension? ( I don;t care which one)
Lloyd McKenzie (Aug 04 2018 at 20:23):
Not with how the workflow tools currently work
Grahame Grieve (Aug 04 2018 at 21:20):
which is the definition one?
Lloyd McKenzie (Aug 04 2018 at 22:38):
Looks like we haven't defined one...
Eric Haas (Aug 05 2018 at 07:04):
so do we need to have both an event replace and request replace or just just use one for both?
Lloyd McKenzie (Aug 05 2018 at 15:24):
We could have a shared one I guess, but it shouldn't be prefixed with 'event' or 'request'.
Lloyd McKenzie (Aug 05 2018 at 15:26):
Ideally it should have a distinct prefix that will let me figure out what workflow patterns it's associated with.
Eric Haas (Aug 05 2018 at 15:39):
i've used one from the other for other extensions before. nobody has complained about the name yet
Lloyd McKenzie (Aug 05 2018 at 15:42):
That's because most people don't notice extensions at all... If it says "event" or "request", then it's extremely confusing if you start using it for other things. Also, it'll break the workflow reporting (though there are other things broken there, such that we might not have noticed this particular issue).
Eric Haas (Aug 05 2018 at 15:48):
i don't think we need two extensions- can we just the under general extensions.
Lloyd McKenzie (Aug 05 2018 at 15:52):
Perhaps we can create a generic "workflow" package that covers extensions that aren't specific to event/definition or request
Eric Haas (Aug 05 2018 at 15:55):
"That's because most people don't notice extensions at all..." GF#16525 would fix that.
Eric Haas (Aug 05 2018 at 16:07):
if the name "workflow' needed for some technical reason other than searhing? by being in core id prefer no prefix or some other moniker like 'core' than having three names. i'm often borrowing extensions from other resources, so for example a service request may have an extension from procedure. Embedding context in the extension name is turning out is to not be useful. it is just a name to me.
Grahame Grieve (Aug 05 2018 at 21:28):
I don't like 16525. But I agree that people seem to be ignoring that set of tabs
Lloyd McKenzie (Aug 05 2018 at 23:45):
I think there's middle ground on 16525 that would direct more people to that tab. My need is to know what the set of workflow extensions are and be able to disambiguate them from the others and to know which workflow pattern elements each extension is for.
Eric Haas (Aug 06 2018 at 01:14):
So @Lloyd McKenzie the extension name is used to search which why we need procedure-blah, observation-blah1, event-blah2, and request-blah3. And should not be crossing boundaries to use other extensions? I would prefer if the extension names were not so tightly bound to the context.
Lloyd McKenzie (Aug 06 2018 at 01:27):
We use context to maintain like things together - that's pretty important now and will be more important as we get more. We are also using names so that we know what extensions are for and can link them to workflow alignment validation
Eric Haas (Aug 06 2018 at 01:33):
As discussed above it is causing problems with sharing the extensions across contexts because you get a resources to extension prefix mismatch which may cause confusionl.
Eric Haas (Aug 06 2018 at 01:34):
right now is set up so need to duplicate an existing extension just to match the context to the extension name...
Lloyd McKenzie (Aug 06 2018 at 01:58):
When we design extensions, we should have a sense of where the extension could potentially be used. The issue comes when we initially design the extension to be too narrow - or if the specification evolves such that the scope should be larger
Eric Haas (Aug 06 2018 at 23:30):
I think your response doesn't reflect reality or my experience. I really think this naming convention of prefixing them with the resource or model name paints the extension into a corner. I think if we need to sort them then use a tag or extension and remove the context from the name.
Lloyd McKenzie (Aug 06 2018 at 23:37):
The names need to be unique and fully qualify what they're for. The prefix is a mechanism of qualifying, but qualifying is going to be necessary regardless.
Eric Haas (Aug 06 2018 at 23:42):
Well an editors choices are:
- Back the out of a corner changes the name and add more context - lots more work usually across wgs
- Just duplicating the extension for each context - way easier than the first choice.
-
adding context and ignoring the prefix. - easiest of all and my personal favorite
None of these is satisfactory.
Brian Postlethwaite (Aug 07 2018 at 05:44):
In applying the tracker GF#12974 I discover that this extension is actually owned by FHIR infrastructure, but we as PA have voted and were about to change it.
No issue there?
It was proposing to move it from a generally defined extension (that only applies to Patient) into the patient extensions (and thus the name gets the prefix inline with the other patient extensions)
Brian Postlethwaite (Aug 07 2018 at 05:45):
oh, and there is also a CDA-birthplace defined in the spec too.
Lloyd McKenzie (Aug 07 2018 at 05:52):
No issue from me...
Grahame Grieve (Aug 07 2018 at 20:52):
@Lloyd McKenzie what's your middle ground on GF#16525?
Grahame Grieve (Aug 07 2018 at 20:52):
and I don't think we have time to add an extension categorization to sort them in the rendering
Lloyd McKenzie (Aug 07 2018 at 21:03):
Middle ground is a bolded "See also" link under the UML/table view/etcl rendering tabs (perhaps right above or below the schematron links) for each that jumps to the extensions portion of the profiles & extensions tab
Grahame Grieve (Aug 07 2018 at 21:05):
for each what?
Lloyd McKenzie (Aug 07 2018 at 21:40):
Resource
Last updated: Apr 12 2022 at 19:14 UTC
