Stream: implementers
Topic: Proposal for a new type ConceptReference
Grahame Grieve (Sep 13 2019 at 07:50):
A small group of us spent some time last night looking at some design patterns in the resources. Our analysis of one of the patterns that we didn't like lead to a proposal for a new data type:
https://wiki.hl7.org/Proposal_for_ConceptReference
Using this type, this:
MedicationRequest - medication[x] : CodeableConcept | Reference(Medication) [1..1] // Medication to be taken - reasonCode : CodeableConcept [0..*] // Reason or indication for ordering or not ordering the medication - reasonReference : Reference(Condition | Observation) [0..*] // Condition or observation that supports why the prescription is being written
would become this:
MedicationRequest - medication : ConceptReference(Medication) [1..1] // Medication (code or details) to be taken - reason : ConceptReference(Condition | Observation) [0..*] // Condition or observation (instance or concept) for ordering or not ordering the medication
@Lloyd McKenzie @Claude Nanjo
Grahame Grieve (Sep 13 2019 at 07:51):
comments welcome
Jose Costa Teixeira (Sep 13 2019 at 10:39):
1. This seems a good step.
2. CodeableReference sounds better to me (not being a native English speaker nor from the germanic languages side, I don't really have a say in the order of the words) - but to me this seems not a reference to an existing concept , rather a specification of something which may or not exist as a reference.
Jose Costa Teixeira (Sep 13 2019 at 10:40):
Use Case :
Patient goes to GP and says "I am taking a drug called Sucralfate". Sucralfate is not sold in the GP's country
Physician creates a medication usage in their GUI.
1. What they do is to type "Sucralfate". That is the information they start with - the text.
2. Presumably that concept exists in a terminology (the list of drugs that are known) - then the system sees it as a code and populates the resource (and updates the GUI) accordingly.
3. That drug may or not exist in the system as a Medication resource, but the information that the physician wanted to enter is already there.
Jose Costa Teixeira (Sep 13 2019 at 10:42):
from what I understand the options, it seems that option 3 is the one that best matches the intent here - not forcing inheritance from either datatype.
Lloyd McKenzie (Sep 13 2019 at 11:08):
+1 for CodeableReference. ConceptReference sounds like you're pointing to a concept. CodeableReference sounds like a regular reference that you can sometimes use a code for. The latter is what we're actually doing.
Lloyd McKenzie (Sep 13 2019 at 11:09):
@Michelle (Moseman) Miller @Melva Peters @Paul Knapp This would likely impact your models - thoughts?
Patrick Werner (Sep 13 2019 at 12:48):
+1 for CodeableReference. I really like the idea of this data type.
Lloyd McKenzie (Sep 13 2019 at 13:07):
Also @Eric Haas
Josh Mandel (Sep 13 2019 at 13:39):
I think this change is an incremental improvement and I could certainly get behind it. (I will note that it is also one step in the direction of just making choice types look the way @nicola (RIO/SS) prefers. i.e., we could solve this more generally, rather than doing something special for the particular choice type of "reference or a codeable concept," to solve the cardinality problem. I suspect you've already considered and rejected this, and if so, it might be good to include that in the write-up).
Jason Walonoski (Sep 13 2019 at 13:40):
FWIW, I prefer the first proposal from Grahame's link (not the alternates) with the name CodeableReference.
Grahame Grieve (Sep 13 2019 at 13:47):
I suspect you've already considered and rejected this
It was too late about R1 for this, really. And it's normative now. And I haven't seen any ground swell for doing json like that anywhere else
Mark Kramer (Sep 13 2019 at 13:53):
From the outset, it isn’t clear that concepts and resource references are exchangable alternatives. A concept is an abstract idea or general notion, but a resource is a concrete instance of a single real-world entity. My (least) favorite example is body site (as a code) and BodyStructure (as a resource) which has Patient 1..1. It isn’t only the level of detail that is changing – it is a change from a concept to an instance.
Grahame Grieve (Sep 13 2019 at 14:11):
they are not generally exchangable, but we have many places where we have agreed that you can do one or the other
Alexander Kiel (Sep 13 2019 at 14:27):
they are not generally exchangable, but we have many places where we have agreed that you can do one or the other
But what is the disadvantage to just use the polymorphic data element as right now? If both CodeableConcept and Reference are different things, a polymorphic data element does express exactly that. You can either specify a CodeableConcept or a Reference.
Grahame Grieve (Sep 13 2019 at 14:28):
well, the way we get reasonCode / reasonReference
Lloyd McKenzie (Sep 13 2019 at 15:48):
The biggest challenge is that it makes ordered lists where you have a choice problematic. For example, ServiceRequest.location (which indicates the 'preferred' location for the service), if you want to point to a mix of specific clinics and general concepts like "at home", you need to be able to indicate whether "at home" is more or less preferred than "Clinic A" and "Clinic B"
nicola (RIO/SS) (Sep 13 2019 at 16:16):
With imaginary Concept Resource - Coding becomes Reference :)
Grahame Grieve (Sep 13 2019 at 16:25):
yeah well, it's still imaginary
Pascal Pfiffner (Sep 13 2019 at 18:07):
Is the idea that there would be invariants on these, i.e. you can not have reference if you have the codings/concept?
Eric Haas (Sep 13 2019 at 18:09):
Personally, from modeling perspective, I like the verbose
elementCode
element Reference
This proposal hides the fact thats is really a choice of datatypes. how do you profile only codes or only refs..
Also from a process perspective: How is a new pattern going to be imposed on the resources if the decisions to change existing resource ultimately lay with the WG. we may wind up with three ways to do the same thing.
Lloyd McKenzie (Sep 13 2019 at 18:16):
Main thing it solves is ordered lists where you need both types
Lloyd McKenzie (Sep 13 2019 at 18:17):
We haven't talked about invariants, but my leaning is that there should be one
Michelle (Moseman) Miller (Sep 13 2019 at 18:31):
Honestly, I don't have a strong opinion -- I think either way works in the sense that the proposal doesn't remove any capabilities, but it does cause work for implementers when uplifting to the next version due to it being a non-compatible change without much ROI (when you don't need the ordered lists).
Grahame Grieve (Sep 14 2019 at 10:34):
don't have to use it where there isn't a list... but can. I updated the proposal to say that it's a binary choice.
Alexander Kiel (Sep 14 2019 at 14:31):
I would always favor composability of simple building blocks over the creation of special case constructs. What is the disadvantage of using a cardinality-many BackboneElement with a single polymorphic element inside it?
Grahame Grieve (Sep 14 2019 at 14:33):
What is the disadvantage of using a cardinality-many BackboneElement with a single polymorphic element inside it?
well, actually, from my point of view, that would be a special case construct
Lloyd McKenzie (Sep 14 2019 at 15:17):
Two advantages
- it makes clear that you're actually talking about one thing (a reason, a performer, etc.) and that you can have different types rather than two things that happen to be coincidentally start with the same name
- it allows you to have an ordered collection of those things without requiring a repeating 'grouper' element
That said, it would only solve this special case. There may be other (though perhaps not as common) situations where there's a repeating element that needs multiple types
Grahame Grieve (Sep 14 2019 at 15:18):
instantiates[x]
Lloyd McKenzie (Sep 14 2019 at 15:19):
Yup, that's another one. And this wouldn't solve that one.
Simone Heckmann (Sep 16 2019 at 18:48):
I like the idea! I have often felt, that the concept of logical references should extend to using codings instead of identifiers.
However, using Coding instead of Identifiers as a logical reference would correspond with the last alternative that is mentioned on the proposal... having a new datatype that exists next to Reference rather than inheriting from it...
Eric Haas (Sep 16 2019 at 22:55):
How does one profile only on or the other type os it an invariant?
Grahame Grieve (Sep 16 2019 at 23:21):
we can define profiles for either to be used when profiling
Jose Costa Teixeira (Sep 23 2019 at 15:43):
Do we make a list of candidates for using this new type? or it's @Grahame Grieve 's magic?
Grahame Grieve (Sep 23 2019 at 17:41):
no, it's up to the committee, I can't do this one as magic
Paul Knapp (Sep 26 2019 at 00:16):
Discussed in ITS but not FM yet. Yes it would change the model but if ConceptReference(list of resources) includes both a CodeableConcept and a Reference(list of resources) then it works and simplifies the appearance of the base models.
Rob Hausam (Sep 26 2019 at 01:21):
One bit of uneasiness I have with this is that ConceptReference sounds too much like it's a reference to a concept.
Kevin Mayfield (Sep 26 2019 at 08:14):
+1 on @Simone Heckmann comment
Lloyd McKenzie (Sep 28 2019 at 00:41):
CodeableReference is clearer
Michael Lawley (Sep 28 2019 at 13:53):
What does this do to search? If I want to find all the orders for a given medication identified by a code, for example?
Lloyd McKenzie (Sep 28 2019 at 15:41):
We'd retain the same search capabilities, though the path defining the search parameters would change a bit
Jay Lyle (Oct 17 2019 at 20:18):
Two comments (already on the wiki page): naming option pros and cons, and a need to address overlap between CodeableConcept.text and Reference.display.
Last updated: Apr 12 2022 at 19:14 UTC
