Stream: committers
Topic: reasonCode inconsistency
Grahame Grieve (Feb 15 2017 at 19:12):
Looking through the resources, I see this:
Grahame Grieve (Feb 15 2017 at 19:12):
reasonCode Request AuditEvent CarePlan DeviceRequest MedicationRequest ProcedureRequest ReferralRequest reasonCodeableConcept Event Communication CommunicationRequest FamilyMemberHistory Procedure reason ChargeItem Encounter ImagingStudy Immunization MedicationDispense MessageHeader Provenance Task reasonGivenCodeableConcept MedicationAdministration. reasonForUseCodeableConcept MedicationStatement
Grahame Grieve (Feb 15 2017 at 19:13):
I think that there's needless variation here. And we're going to hear about it.
Grahame Grieve (Feb 15 2017 at 19:14):
@Melva Peters @John Moehrke @Michelle M Miller @Lloyd McKenzie @Anthony(Tony) Julian can we get some alignment here?
John Moehrke (Feb 15 2017 at 19:40):
There likely is an opportunity for alignment, however it is not obvious. I am expert in AuditEvent, Provenance, and ImagingStudy. I can explain these. (For Provenance and AuditEvent - this element holds the PurposeOfUse. You might call that a 'reason', but it is a specific access scope concept. Note you missed Consent, which has the same PurposeOfUse concept found in AuditEvent and Provenance. Consent also has an action, which is related. For ImagingStudy it is the procedure reason, and is aligned with Procedure, ProcedureRequest; a more clinical 'reason' concept). However I am ignorant of the other Resources. I expect we all are expert in our domain, and thus ignorant of the some other domain.
John Moehrke (Feb 15 2017 at 19:41):
Isn't getting comments from the "Trial Use" implementers what we WANT?
Grahame Grieve (Feb 15 2017 at 19:43):
well, I'd rather fix things before it gets to them
Grahame Grieve (Feb 15 2017 at 19:44):
if both AuditEvent and Provenance have the same binding, why do tnhey have different names?
Grahame Grieve (Feb 15 2017 at 19:45):
and ImagingStudy manages not the use the same name as the resources you indicate it matches
John Moehrke (Feb 15 2017 at 19:46):
if it was only that easy... consensus is a fickle thing...
Grahame Grieve (Feb 15 2017 at 19:50):
I understand. I'm just asking the question
Melva Peters (Feb 15 2017 at 19:52):
For Pharmacy resources, I think that they could be consistent in MedRequest, MedStatement and MedAdmin - can change to be "Reason" as the Backbone with ReasonCodeableConcept and ReasonReference. For MedAdmin.reasonGiven, the binding is slightly different for the reasonReference. For Meddispense - it doesn't have the same binding so wouldn't propose changing. I'll run this by the Pharmacy Co-chairs. Does this help?
Grahame Grieve (Feb 15 2017 at 19:56):
that would be good. I can see why reasonGiven etc. that part makes sense
Anthony(Tony) Julian (Feb 15 2017 at 20:01):
So I see MessageHeader.reason as "Cause of event". In that case, should reason be sibling of MessageHeader.event - or at least change to MessageHeader.eventreason?
Grahame Grieve (Feb 15 2017 at 20:02):
it is a sibling of MessageHeader.event. I don't think that eventReason is a better name than reason
Grahame Grieve (Feb 15 2017 at 20:02):
I possibly prefer reasonCode for it for consistency sake
Grahame Grieve (Feb 15 2017 at 20:02):
but there's not a lot of consistency right now, or prospect of getting it
Lloyd McKenzie (Feb 15 2017 at 20:05):
Workflow just held a call agreeing to change the Event pattern to be reasonCode instead of reasonCodeableConcept. The rationale for the qualifier is that the pattern also has reasonReference. (And it's not reason[x] because both are 0..*).
Anthony(Tony) Julian (Feb 15 2017 at 20:07):
How would we relate MessageHeader.event and MessageHeader.ReasonCode - is there a datatype that consists of 2 codes?
Anthony(Tony) Julian (Feb 15 2017 at 20:08):
I see a couple with 2 numbers
Lloyd McKenzie (Feb 15 2017 at 20:10):
There's no correlation. This isn't like v2 where we have message + event. The event code is equivalent to "ADT_A01". The reason would be something like "why are you asking for this order to be suspended?"
Anthony(Tony) Julian (Feb 15 2017 at 20:13):
I could see MessageHeader.reason-for-event -
Anthony(Tony) Julian (Feb 15 2017 at 20:13):
or MessageHeader.reasoncode-for-event
John Moehrke (Feb 15 2017 at 20:41):
are we thinking we will end up with harmonized valuesets too? I would agree that if we have three different concepts, we should have three different element names and valuesets...
John Moehrke (Feb 15 2017 at 20:41):
I think the security concept of purposeOfUse is a different vector than the clinical reasons. But even in this space (AuditEvent) there is a purposeOfUse at the event level, and a different one at the agent level. As a user's participation in an event may be different than the whole event.
Michelle (Moseman) Miller (Feb 15 2017 at 20:52):
Patient Care resources were aligned with the workflow patterns, but I had logged GF#12814 due to the inconsistencies between Request and Event. Today, GF#12814 was approved (to rename reasonCodeableConceot to reasonCode), so I just committed the corresponding change to rename reasonCodeableConcept to reasonCode for Procedure, FamilyMemberHistory, and Communication. CommunicationRequest already had reasonCode since it followed the Request pattern. Thus, Patient Care resources should all be aligned when the build finishes.
Grahame Grieve (Feb 15 2017 at 21:00):
amazing progress - thanks all
Brian Postlethwaite (Feb 15 2017 at 23:35):
so those at reason can just remain there? no need to just add Code to the end of it (especially where the type isnt a code)
Grahame Grieve (Feb 15 2017 at 23:36):
not when it's not a code, no. otherwise... I'm not sure
Michelle (Moseman) Miller (Feb 15 2017 at 23:44):
@Brian Postlethwaite using Encounter as an example, there are elements for both reason (CodeableConcept) and indication (reference to either Condition | Procedure). Both elements share the same definition of "Reason the encounter takes place". If aligned with the other event resources, reason could be renamed reasonCode and indication could be renamed reasonReference.
Brian Postlethwaite (Feb 15 2017 at 23:48):
Except that issue will go away when the other change I have to apply which removes the inconsistency as indication is changing to a diagnosis backbone element as per tracker 10544
Brian Postlethwaite (Feb 15 2017 at 23:49):
But if the others are all changing to reasonCode, I don't have a strong objection, just weird.
Michelle (Moseman) Miller (Feb 15 2017 at 23:57):
I would only promote the "Code" or "Reference" suffix if the resource supports two elements.
Lloyd McKenzie (Feb 16 2017 at 00:06):
Agree with Michelle. No need to differentiate in the name unless you currently (or reasonably expect to) have multiple "reason" elements. You're moving Condition to a diagnosis backbone element. What happens to Procedure as a reason? I.e. a follow-up encounter after surgery.
Lloyd McKenzie (Feb 16 2017 at 00:07):
If you think there's a decent chance of needing reasonReference, then going to reasonCode now may avoid a subsequent rename. But we'll defend your right to stay with "reason" if you're comfortable that's all you're likely to need.
Last updated: Apr 12 2022 at 19:14 UTC
