Stream: implementers
Topic: Supporting/Related Information
Stephen Royce (Jul 26 2016 at 06:02):
Is there a standard (non-extension-based) mechanism for adding references to supporting information to a clinical resource?
Lloyd McKenzie (Jul 26 2016 at 13:40):
As part of the workflow project, "supportingInformation" is encouraged as a standard element on all "request" resources, though in some cases a work group may decide that it's an extension rather than core and they have the right to decide it's totally irrelevant and exclude it. So far no use-case has arisen for a general "supportingInformation" on event-type resources like procedures or observations, though the workflow pattern suggests they should support "reason" codes and relationships.
Stephen Royce (Jul 27 2016 at 00:37):
Our models currently have a number of supporting information structures, especially our equivalent of Condition and AllergyIntolerance. Both serve as a record of the justification for a clinician reaching the conclusion regarding each. Indeed, we started to find that many models required such, especially attaching images or pathology reports that are not available as structured data, e.g. just a PDF, and so we've ended up adding an implicit relatedInformation item to every model. (Hence my question.) So, basically, you're telling me that if we want to continue that practice, we need to create an extension to support it and put it in all our profiles?
Grahame Grieve (Jul 27 2016 at 00:52):
Sounds like the Linkage reosurce? But yes, for now, it's an extension whatever
Jeffrey Chen (Jul 27 2016 at 00:55):
Not sure I understand correctly. If having document which need to be linked to a clinical resource, you may create DocumentReference for those documents. And inside DocumentReference, you can use content.related to point to the clinical resource. When you want to retrive those documents for the clinial resource, you just do a search for that.
Stephen Royce (Jul 27 2016 at 00:56):
So
Stephen Royce (Jul 27 2016 at 00:57):
1. It's for a _lot_ more than just documents; and
Stephen Royce (Jul 27 2016 at 00:58):
2. Most resources do not contain an element that is a DocumentReference. For example, which element in the AllergyIntolerance resource would I use to point to an "attached" document?
Jeffrey Chen (Jul 27 2016 at 00:58):
imaging test result and pathology reports are the DiagnosticReport resources. What the other types of information do you need?
Stephen Royce (Jul 27 2016 at 00:59):
Who knows? It could be anything. It couild be a scan of some hand-written notes; literally anything.
Stephen Royce (Jul 27 2016 at 01:01):
And again, if I want to link and DiagnosticReport to an AllergyIntolerance resource specifically as supporting information, which element would you suggest I use?
Jeffrey Chen (Jul 27 2016 at 01:01):
You use DocumentReference resource to link the document to AllergyIntolerance resource instead of adding things into AllergyIntolerance. Most of the other resources have content or other elements to allow you to link them back to clinical resources.
Jeffrey Chen (Jul 27 2016 at 01:02):
For DiagnosticReport, you use subject element.
Stephen Royce (Jul 27 2016 at 01:03):
So the subject of the DiagnosticReport is the AllergyIntolerance or vice versa?
Jeffrey Chen (Jul 27 2016 at 01:03):
IMO, yes
Stephen Royce (Jul 27 2016 at 01:05):
So, that might work in that particular case, but what I need is a generic solution with which I can attach any supporting information to any resource.
Stephen Royce (Jul 27 2016 at 01:10):
Also, with the DiagnosticReport solution, that's a bit back-to-front because theDiagnosticReport is telling you that it's about the AllergyIntolerance rather than the AllergyIntolerance telling you that a particular DiagnosticReport is evidence of the conclusion.
Grahame Grieve (Jul 27 2016 at 01:13):
we did have evidence in Allergyintolerance in early models, but there was not consensus about what evidence meant or what was needed, and the discussions made it clear that one of the reasons there was no consensus is because few systems do it. Hence, extensions
Jeffrey Chen (Jul 27 2016 at 01:15):
I think we need to keep in mind that FHIR is not a data storage standard. So, the real linkage is happened in your database side instead of FHIR resources. All of the DocumentReference.content.related, DiagnosticReport.subject and other linkage elments are based on your database design. And your database is the one to provide generic solution for that.
Stephen Royce (Jul 27 2016 at 01:15):
Yeah, so that's probably a bad example because the reaction element would typically cover nearly everything you need in that particular resource. And I'm fine with it having to be an extension. I just thought that there might be a generic solution because most resources could take advantage of being able to attach supporting information.
Stephen Royce (Jul 27 2016 at 01:17):
So the 80% here is not that 80% of implementations already provide supporting information for a given resource; it is, instead, that 80% of resources would benefit from being able to carry supporting information. 
Lloyd McKenzie (Jul 27 2016 at 06:02):
@Grahame Grieve The linkage resource is to link multiple records of the same thing, not to link related records. For Condition, this would be the supporting evidence extension. I'm not sure we have the same for AllergyIntolerance, but we could.
Lloyd McKenzie (Jul 27 2016 at 06:03):
"Supporting information" for requests is different. It doesn't indicate a 'reason' for the request, it just indicates "extra stuff you may need to know in order to execute this request"
Stephen Royce (Jul 27 2016 at 06:26):
Our models have a generic related information concept that carries a code to indicate the nature of the relationship between the source data and the related information. The code set we use for this is from CEN 13606 because that set is _much_ richer than the HL7 v3 x_ActRelationshipExternalReference set That means that the same extension can be used to supply supporting evidence, further reading, more complete data, summarised data or even "extra stuff you may need to know in order to execute this request".
Lloyd McKenzie (Jul 27 2016 at 06:29):
In FHIR, the general pattern is you use a separate extension for each type of relationship. We try to avoid embedding semantics in code-value pairs as much as we can because conformance is trickier with value sets.
Stephen Royce (Jul 27 2016 at 06:31):
Oh right. That makes things harder. It means I have to think of all types of relationships that may exist between data items ahead of time instead of just adding a new code as new types become relevant.
Stephen Royce (Jul 27 2016 at 06:36):
I suppose, though, if there were circumstances where certain types of relationships were not permitted, it could be more challenging to validate, although I would have thought you could just use a constrained value set in such circumstances. Can you have a profile of an extension?
Grahame Grieve (Jul 27 2016 at 07:46):
Lloyd said, general pattern. But where the relationship is not a fixed list, then code/relationship pair becomes preferred. It's not a simple one or the other
Lloyd McKenzie (Jul 27 2016 at 09:05):
@Stephen Royce There's no need to think everything up ahead of time. If you come up with a new relationship, you define a new extension. No different really than defining a new code, other than there's an automatic way for people to look up the definition if they don't recognize it and it's easier to declare whether you support that specific relationship or not.
Stephen Royce (Jul 27 2016 at 22:42):
@Lloyd McKenzie It's much more expensive in the long term to do it like that. Adding a code is cheap, creating a new model every time is expensive. However, the marginal cost of creating an extra one if you're already doing others, while still more expensive than adding a code, is a lot cheaper than creating the first model. That's the reason why you'd want to try to envision all possibilities up front. Other than that there's no real difference.
Stephen Royce (Jul 27 2016 at 22:52):
@Grahame Grieve So where does that leave me? Can I create a generic RelatedInformation extension to be used everywhere as per our current model, or should I leave that to each use case and create extensions as required by the circumstances? I can't imagine us wanting to disallow any relationship type except for extreme edge cases, but maybe I should be thinking from a modelling perspective, what are the most common relationship types and simply create extensions for each and leave the implementers to create the rarer ones as and when they need? On the other hand, there are circumstances where we know the model must be capable of including a particular kind of related information, e.g. attaching a pathology report PDF to the DiagnosticReport instance.
Lloyd McKenzie (Jul 27 2016 at 23:17):
@Stephen Royce But you're not creating a new model. The new model already includes extensions everywhere they're needed. The extension uri is equivalent to the code in your code + value pair. There's no greater effort and no additional imposition on implementers (who will need to map either to their internal model).
Stephen Royce (Jul 27 2016 at 23:21):
My job is to create the extensions and build them into profiles so that implementers don't have to concern themselves with such problems. Consequently, every time a new type of relationship is identified, I would have to create a new StructureDefinition and update every profile where that new extension might be used. This is a big job compared to have a single pre-defined extension one element of which is the type of relationship that is bound to a value set that can be updated over time.
Lloyd McKenzie (Jul 27 2016 at 23:53):
That might be easier for you, but harder for implementers. Because implementers now have to map potentially unknown codes into their internal data store and have to dig through value set definitions to see what's where. With extensions in a structure definition, it's clear. And it's also clear how many times it can appear, whether they must support it, what types it's allowed to reference, etc. Far more explicit. And still just as easy to handle transparently in a generic fashion if they wish.
Stephen Royce (Jul 28 2016 at 00:14):
That wouldn't be problem if the implemter modelled the data in the same generic fashion; however, I acknowledge that many, many don't and often simply for legacy reasons. Having said that, the whole "clear how many times it can appear, whether they must support it, what types it's allowed to reference, etc." would be covered in our by use case-specific scenarios where we would further slice (and dice!) the general profile for the particular circumstance. In this case, though, I can't see that there would be any need to do that in general because it'd be hard to say that a given type was not permissible in a given situation. i.e. an implementation would probably not need to concern themselves with such questions beyond assuming you can have infinitely many and you must support them all. (In my experience, such assumptions are very easy to cater for in an implementation, but maybe people don't see it that way.) Must understand them all, though, is a different thing. If you actually mean that by "must support" then you have a case!
Lloyd McKenzie (Jul 28 2016 at 00:18):
Right. But if you're slicing, then you're updating the FHIR structure definitions that reference the code anyhow - so no delta in work. Going the extension approach forces explicitness in a way that using codes does not - which is to the implementer's benefit.
Stephen Royce (Jul 28 2016 at 00:25):
Well, yes, but we'll have to update all the FHIR structure definitions for each use case anyway, so there's only a marginal cost to me to slice there if I have to.
Stephen Royce (Jul 28 2016 at 00:28):
Nonethelesss, I'm happy to follow your approach; I'm just trying to tease out all the implications. The main thing for me is, in our logical models, should we continue to include a general Related Information concept, or should we simply model only known requirements for particular types of related information? If I am going to use the case-by-case extension approach, then that pretty much forces me into the latter.
Lloyd McKenzie (Jul 28 2016 at 14:41):
Having a general "related information" that isn't typed is fine. But if you want it typed, the types *should* be separate extensions
Stephen Royce (Jul 28 2016 at 23:59):
Can I subclass the each separate extension? 
Lloyd McKenzie (Jul 29 2016 at 02:41):
In theory, yes. An extension is just a profile on the Extension data type. So you could create a generic extension profile and then use that as a base for your extension profiles. But I'm not sure what it would buy you . . .
Stephen Royce (Jul 29 2016 at 05:33):
It might buy me a generic extension with a set of relationship types that's specialised into individual extensions where the relationship type is fixed, i.e. I can eat my cake and have it too!
Lloyd McKenzie (Jul 29 2016 at 14:07):
Not really. The pattern here would be that the extension URL would convey the extension type and you'd just have a valueReference. There wouldn't be a code defining the type of reference other than the URL.
Stephen Royce (Jul 31 2016 at 22:19):
Yeah, so you obviously missed my meaning earlier. I was thinking of a generic extensions with a relationship type element as a code and then each individual extension would fix the value of the relationship type element to a specific code, i.e. it would carry the type in 2 places: the URL _and_ the relationship type element. Anyway, I wasn't really that serious. I already knew what your anser would be.
Lloyd McKenzie (Aug 01 2016 at 01:44):
@Stephen Royce I understood and I was explaining that the general FHIR convention is to use the extension URL as the code and have the extension type as Reference
Lloyd McKenzie (Aug 01 2016 at 01:45):
I.e. you wouldn't have a code + Reference, you'd have an extension URL + reference
Stephen Royce (Aug 01 2016 at 04:49):
I've been looking more closely at the DocumentReference resource because one type of related information that we want to support is other documents. I'm unclear as to the purpose of DocumentReference.context.related; would this be the resource(s) for which the referenced document is related/supporting information or is it something else? If the former, it seems a bit back-to-front to me. You'd have a hanging DocumentReferencein your Bundle that says "Oh, by the way, you know that AllergyIntolerance resource that you think you've finished processing? Actually, I'm further information about that. Gotcha!"
Stephen Royce (Aug 01 2016 at 04:50):
Even worse, it could just be lying around on a server somewhere and you wouldn't even know about it!
Grahame Grieve (Aug 01 2016 at 04:51):
it would be used when your workflow is document centric - starts with the document. In your context, you would rule it's use out
Stephen Royce (Aug 01 2016 at 04:51):
Okay.
Stephen Royce (Aug 03 2016 at 02:27):
@Lloyd McKenzie So what if we want to create a standard extension for related information that implementers can use for types of relationships for which we do not yet have a specific extension?
Lloyd McKenzie (Aug 03 2016 at 02:52):
@Stephen Royce Why would we do that? If the implementer needs something new, they just define their own extension. It's no different than defining their own code - and a lot less overhead to accomplish and easier to manage from a conformance perspective too.
Stephen Royce (Aug 03 2016 at 02:55):
Because then
- a receiver can have a standard mechanism for understanding _all_ related information extensions (they'd have better semantics, at least knowing it's a related information extension instead of any old extension that they have no semantics for); and
- we don't have different implementers creating different extensions for the same thing.
Lloyd McKenzie (Aug 03 2016 at 03:35):
But what understanding is possible other than "source resource has some relationship to target resource" - which is exactly the semantic you've got when source resource contains an extension with type of Reference. And you'd just have implementers creating different codes for the same thing. The impact is the same . . .
Stephen Royce (Aug 03 2016 at 04:17):
The target might not be a resource. The data type of target is likely to number or things, including Reference, but also url and possibly identifier. And besides, Reference does not actually tell you that the target is "related information". Obviously, the information is related because otherwise you wouldn't link to it, but the semantic idea of "related information" is a little more constrained than that. Furthermore, the generic extension could carry a code which does give more semantics that could at least be displayed to a human if not understood by machine.
Grahame Grieve (Aug 03 2016 at 04:21):
I think that this is a more general discussion about FHIR architecture - it comes up in a bumber of different places, and it's not obvious where it fits into the picture
Grahame Grieve (Aug 03 2016 at 04:21):
but it does tend to be a, hmm... theoretical... concern.
Stephen Royce (Aug 03 2016 at 04:53):
Yeah, so I get that it tends towards the theoretical because we're trying to imagine up front how things _might_ get used at some vague date in the future. However, that's kinda my job: to think of stuff now, so that when folks catch up we go "Here's one we created earlier," and that "one" is a reasonbly close model of what they need. (It's very unlikely to be exactly what they need, unfortunately.)
Lloyd McKenzie (Aug 03 2016 at 06:12):
My general attitude is that we already have a generic structure for adding new content. Creating a layer on top of that doesn't seem to buy much other than added complexity. From a practical perspective, how is a system going to deal with a new unknown code in the "relatedThingy" code system that's different from how it would deal with a new unknown extension URL? The only differences I see are as follows: the system or the analysts can look up the definition of the extension definition (they're required to be able to do that if the instance is conformant). But there's no expectation that the meaning of the code will be resolvable. As well, it's straightforward to declare whether a given interface must support the new extension. It's more work to do that with the code. And finally, the ability to send the extension is already built in and requires no extra effort on the part of designers or implementers. I really don't see the plus side of the coded approach beyond "it's what we're used to doing because we had to do it that way in 3".
Paul Knapp (Aug 03 2016 at 06:37):
I think Stephen is proposing to create a single coded extension where his systems would understand the extension and its purpose and the code would convey the value of the relationship. Clearly less work to program for a single extension than a 'code-table's worth' or extensions. Presumably would not require reprogramming on the interface to add codes.
Stephen Royce (Aug 03 2016 at 06:39):
So I hear what you're saying (although this has nothing to do with version 3; the name/value pair pattern, or, in this case, type/link pair, is a very common pattern in software development and was the first thing that every developer here thought of). However, here's some things to think about:
- We can guarantee the meaning of the code because we already have an extensive code set that I don't have a problem data typing as
code (Required); if anyone can think of a use case for a relationship type outside of the set we have, I'd be very surprised (at least, not in the foreseeale future). - I don't want to have to create a separate extension for each code in that code set, though, on the off chance that someone might use it. (There'd be about 50 extensions, I think.)
- You haven't addressed the "how do we stop implementers creating many varieties of extension for the same thing" problem.
- You seem to be assuming that implementers will be quite happy to create (conformant) extensions when they need them. My experience of working with healthcare IT is that most vendors are very small organisations who cannot afford to do much more than the minimum and if the choice comes down to creating a properly conformant extension or not sending the data, they will do the latter. And they'll do so silently so we'll never even find out the requirement ever existed.
Grahame Grieve (Aug 03 2016 at 06:40):
permutating codes or extensions - is there much difference?
Grahame Grieve (Aug 03 2016 at 06:41):
and in fact, what's the difference between defining a set of extensions, and defining an extension with a set of codes?
Stephen Royce (Aug 03 2016 at 06:42):
There wouldn't be if I could have one extension in which the url came from a code set!!! 
Stephen Royce (Aug 03 2016 at 06:43):
Otherwise, there's quite a bit of difference for me between a code set that I already have and creating a StructureDefinition model for each.
Grahame Grieve (Aug 03 2016 at 06:46):
well, it shouldn't be - you can generate them. There's been other uses for StructureDefinition factories, but the functionality for that is currently not in the IG publisher right now. I'll be digging it up next week
Paul Knapp (Aug 03 2016 at 12:08):
The code would resemble if not BE what you would store in your information system, so using a code saves the translation in both directtions.
Stephen Royce (Aug 03 2016 at 23:23):
So we're going with the "generate 50 identical-but-for-the-url extensions just in case someone needs them" approach?
Grahame Grieve (Aug 03 2016 at 23:34):
it's not much different to 'generate 50 codes'
Stephen Royce (Aug 03 2016 at 23:50):
I remain unconvinced of that, but I'll be happy to change my mind if the StructureDefinition factories you mention prove effective.
Stephen Royce (Aug 03 2016 at 23:53):
Another thing: our set of codes has a simple, 2-level hierarchy consisting of 5 or 6 main categories, of which each has a number of sub-types if you want to be more specific; how would we capture that in the extensions?
Richard Townley-O'Neill (Aug 04 2016 at 00:10):
It seems to me that conceptually this can be seen as one model with a code with 50 values. This is useful for understanding the design and guarantees commonality of approach, however implementation in FHIR is easier with 50 similar extensions. Even if 50 extensions is the best implementation approach, it would be nice to have a way of presenting the common underlying design. How can that be done?
Grahame Grieve (Aug 04 2016 at 00:28):
I'll work on this next week once the ballot is published
Paul Knapp (Aug 07 2016 at 12:25):
While it is technically possible to implement a valueset as a series of extensions, this is not the design pattern in FHIR and I don't think you want to introduce that pattern do you?
Grahame Grieve (Aug 07 2016 at 12:40):
there's certainly cases for it. Trading between structure and function
Grahame Grieve (Aug 07 2016 at 12:40):
sorry, structure and terminology
Last updated: Apr 12 2022 at 19:14 UTC
