Stream: implementers
Topic: Use of Meta.tag vs Request.intent
Michelle (Moseman) Miller (Jul 16 2018 at 21:39):
Question:
As it pertains to GF#17169, should Meta.tag or Request.intent be used to convey that an order is authoritative vs non-authoritative? This distinction is critical because there can be different business rules around authoritative and non-authoritative orders. For example, an authoritative order will probably have far more required fields than a non-authoritative historical/recorded order. Additionally, there are presumably more restrictions around who can modify authoritative orders (and when).
Using Meta.tag
- 'authoritative' could be considered orthogonal to 'intent' (e.g. non-authoritative order, non-authoritative plan)
- tags can be applied to resources more broadly (e.g. it isn't limited to *Request resources)
- tags can be changed without breaking digital signatures
- tags are not considered a modifier element
- consider changing Meta.tag binding strength to extensible (to enforce consistency of codes used)
- mitigate risk of being overlooked by adding examples and documentation (to both request pattern + resource notes section)
Using Request.intent
- intent is a modifier element
- intent is more visible "face up" when viewing the resource specification, which makes it less likely to be overlooked
Background context:
Using pharmacy as an example...
- In DSTU2, there was a MedicationOrder resource, which was scoped narrowly to “authorizations to dispense” only.
- In STU3, the scope (and name) of MedicationOrder changed to MedicationRequest to accommodate more than just “authorizations to dispense.”
- The Request.intent element was introduced with definition
Indicates the level of authority/intentionality associated with the {{title}} and where the request fits into the workflow chain"
Note that MedicationStatement is NOT equivalent to a non-authoritative prescription/order. The MedicationStatement is intended to represent what the patient said they are actually doing. By contrast, the MedicationRequest is intended to represent what the patient should be doing regardless of whether the request is authoritative (e.g. MedicationRequest can include the non-authoritative representation of an order from an external provider/system OR an over the counter medication.)
Feedback Welcome
Please share your thoughts - including additional pros/cons we may have missed.
Lloyd McKenzie (Jul 16 2018 at 23:37):
Grahame Grieve (Jul 16 2018 at 23:57):
why would we put this in a tag? Do we want this to change without changing the signature? That sounds off to me...
Lloyd McKenzie (Jul 17 2018 at 00:23):
The same record is authoritative on one system and non-authoritative when it's stored on another system. All the other information remains the same and the signature could (and should) remain valid when moving from one to the other. (The same approach is taken with the "actionable" tag - it's actionable when you send it to pharmacy A, but not when you cc it to pharmacy B and C.)
Lloyd McKenzie (Jul 17 2018 at 00:24):
It's also an assertion you can make about pretty much any resource.
Richard Townley-O'Neill (Jul 17 2018 at 02:22):
The point of making the binding of meta.tag extensible is to support shared work-flow. It seems to me that work-flow should be specified in implementation guides rather than in base resources. So this binding should remain example in the FHIR resources, but be extensible in most implementation guides.
Lloyd McKenzie (Jul 17 2018 at 02:48):
The core specification isn't defining what workflows must be used, only standardizing some of the components that can be used in workflows. It wouldn't make sense for different jurisdictions to come up with different tags that convey that a resource is actionable or authoritative. That's also a general requirement that's going to be relevant across a wide variety of jurisdictions and use-cases. If we were to push it into an international-level IG, it would be just as binding as if it were in the core specification.
Grahame Grieve (Jul 17 2018 at 02:50):
we don't need an extensible binding for this, actuall.y
Grahame Grieve (Jul 17 2018 at 02:51):
we can just make rues about particular tags in narrative.
Grahame Grieve (Jul 17 2018 at 02:51):
but on the whole I agree with Richard - we can define tags, and it's for IGs to mandate them
Lloyd McKenzie (Jul 17 2018 at 02:52):
I agree it's for IGs to mandate them. But I think it's reasonable to say that if we standardize the meaning of a tag at the international level, it's inappropriate for a downstream IG to define a different tag for the same purpose - that's what we're trying to avoid.
Lloyd McKenzie (Jul 17 2018 at 02:53):
And the purpose of the extensible binding would be to do that.
Grahame Grieve (Jul 17 2018 at 02:53):
that's not an extensible binding thing. that's something else
John Moehrke (Jul 17 2018 at 12:51):
I don't think the tags are the right place for this functionality. First, I am concerned that tags have historically not been critical to the function of the Resource, they are 'meta'. This use-case seems to indicate that this specific tag is critical to understanding of the Resource.
We also have all kinds of exclusion rules around meta, such as the signature exclusion Grahame mentioned; or the fact that Versioning doesn't happen when meta is changed...
Could this be done with a second Resource that carries the meaning of authority? When it is communicated, it expresses the authority explicitly being conveyed, when it is not present then the original Resource is simply data.
Lloyd McKenzie (Jul 17 2018 at 13:21):
The tag doesn't change the understanding of the resource - a prescription is a prescription is a prescription. Tags do change what you can do with a resource. Security tags affect who can see or change a resource. Other tags can impact workflow. No one has to support a particular tag, but if you've agreed to support a particular tag, paying attention to it is going to be vitally important.
Lloyd McKenzie (Jul 17 2018 at 13:22):
Meaning of authority in some other resource would be super dangerous.
Lloyd McKenzie (Jul 17 2018 at 13:22):
Resources need to stand alone
Jenni Syed (Jul 17 2018 at 13:23):
But not all statements are prescriptions. And the signature worries me: if a doctor didn't intend something as an authorization to dispense, but the tag is flipped, the signature won't detect that. This means another system could receive this as an actual authorization to dispense from that physician.
Lloyd McKenzie (Jul 17 2018 at 13:35):
Flipping tags is problematic no matter what. Flipping a tag from "highly restricted - assigned GP only" to "public test data" would be an equally bad thing. Tags contain stuff that drive data access and workflow - they're pretty important elements. The signature reflects the contents of the prescription as authored. When you pass the data around, whether the recipient is allowed to dispense or not is going to vary. Even if the initial prescription was sent to a pharmacy intended to dispense, that pharmacy might then pass the prescription along to someone else - e.g. a payor or another pharmacy. The pharmacy itself might need to flip the tag to "not actionable" in its local store if it's transferred the prescription elsewhere (whether using FHIR or by fax).
Grahame Grieve (Jul 17 2018 at 21:22):
the problem is that the fact that a resource is authoritative is contextual - it's not a property of the resource itself
Lloyd McKenzie (Jul 17 2018 at 21:32):
Right - and we generally put contextual things in tags. (Similar to how the resource is "restricted" on my system but "normal" on your system.)
John Moehrke (Jul 18 2018 at 02:51):
I don't think these are the same concepts. The fact that the word "authoritative" is used, does not make it a "Security Access Control" concept. It seems that what was described was more of a business layer workflow enabling some action to begin. I might very well be convinced, I am not that much against it... I just don't think that the original thread request is being fully engaged in this discussion.
John Moehrke (Jul 18 2018 at 02:54):
ON the topic of "Is this observation authorized by an authoritative individual", this is not a Access Control decision, this is a fact of Provenance. It might be satisfied by Observation.performer (lightweight provenance), or might need full strength Provenance resource.
I am just thinking that this is closer to Provenance concept of authoritative, than it is to Security Access Control
Grahame Grieve (Jul 18 2018 at 02:54):
tag != security label
John Moehrke (Jul 18 2018 at 02:55):
I am fully willing to accept that, like Provenance, there is a light weight flavor and a full strength Resource.
Lloyd McKenzie (Jul 18 2018 at 03:44):
I'm not suggesting that tags are security labels. But tags and security labels work the same way - outside the signature, live in metadata and define expectations around how the data is going to be used. Security tags around permissions and tags around workflow. Both are important and should not be ignored. Both require negotiation between partners around which ones will be supported and how they'll be used.
Lloyd McKenzie (Jul 18 2018 at 03:45):
My point was that it's not inappropriate to put "very important information" in a tag any more than it's inappropriate to put such information in a security label.
John Moehrke (Jul 19 2018 at 12:48):
and my point is that by definition the Meta.tag the tag can't have an effect on the meaning of the resource..
Meta.tag
Element Id Meta.tag
Definition
Tags applied to this resource. Tags are intended to be used to identify and relate resources to process and workflow, and applications are not required to consider the tags when interpreting the meaning of a resource.
Grahame Grieve (Jul 19 2018 at 12:56):
how does the meaning of the resource change?
John Moehrke (Jul 19 2018 at 13:00):
authorized or not authorized.... that is my understanding of what this vocabulary is saying. (or to pull from the other thead on the same topic "Authorized because my boss said so." --- or something like that)
John Moehrke (Jul 19 2018 at 13:03):
my understanding is that sometimes this tag value will be on the exact same Resource for various intent. It will be used to communicate to the pharmist to go ahead and dispense, where as everyone else will see it without this tag value not present and understand it simply as a statement of facts found in the resource... same resource content, just a different tag value.... that seems to violate the ".. are not required to consider the tags when interpeting the meaning of the resource"
Grahame Grieve (Jul 19 2018 at 13:15):
depends what you think meaning is. the tricky thing here is that meaning is not a property of the resource, but the context it is in
Lloyd McKenzie (Jul 19 2018 at 14:32):
The meaning of "Patient is prescribed 100mg Tylenol BID" is the same whether the copy you have locally is "for reference" or "intended to be dispensed". Exactly the same instance (with the same digital signature) on two different systems could be "for reference" on one system and "intended to be dispensed" on a different system.
Lloyd McKenzie (Jul 19 2018 at 14:32):
The meaning hasn't changed. The workflow expectations have.
Michelle (Moseman) Miller (Jul 19 2018 at 15:18):
I think I still lean towards using Request.intent. The non-authoritative version isn't always a copy from the source of truth -- meaning the authenticity and veracity greatly varies depending on whether it is THE order to be dispensed or just documented hearsay (when it's patient reported).
Michelle (Moseman) Miller (Jul 19 2018 at 15:20):
Here is a specific example illustrating when meaning changes: When an authoritative request is documented, maybe we follow the guidance in the spec (as it exists today) that says: If nothing is specified substitution may be done. However, for a non-authoritative request, I don't think I'd be so bold because nothing specified can mean the patient doesn't recall whether substitution is allowed.
Lloyd McKenzie (Jul 19 2018 at 15:30):
One example of non-authoritative is recorded as patient-hearsay. Another is a record is forwarded from another system as a "FYI". The former will likely differ from the original order. The latter could well be identical - down to the signature. The differentiation needs to handle both.
Lloyd McKenzie (Jul 19 2018 at 15:31):
There's no argument that the business rules you would use for authoritative and non-authoritative would be different. That's the point. Tags on resources can change what business rules apply.
Grahame Grieve (Jul 19 2018 at 20:39):
@Michelle (Moseman) Miller I wonder what you mean 'use Request.intent' since that's just a pattern?
Lloyd McKenzie (Jul 19 2018 at 20:46):
It would be MedicationRequest.intent or ServiceRequest.intent, etc. - same solution for all Request resources. (Which doesn't much help with authoritative vs. not for non-Request resources.)
Melva Peters (Jul 20 2018 at 02:19):
Pharmacy had requested a new value added to Intent - called "reported". That's what started this discussion.
Michelle (Moseman) Miller (Jul 20 2018 at 12:48):
@Grahame Grieve I agree with what Lloyd and Melva clarified -- I meant adding a new code in the intent value set, which is used by MedicationRequest.intent (which is what started all this).
I believe this distinction is a modifier (intent is a modifier whereas tags are not modifiers). It changes how an end user interprets empty elements (e.g. implicit no refills and implicit substitution allowed -- versus -- unknown refills and unknown substitution allowed)
Grahame Grieve (Jul 20 2018 at 12:51):
I'm not sure I follow the domain logic, but if you're right, haven't you answered your own question?
Michelle (Moseman) Miller (Jul 20 2018 at 12:53):
I haven't convinced @Lloyd McKenzie , who advocates for tags, which is why we started this discussion thread...
Lloyd McKenzie (Jul 20 2018 at 14:10):
Nothing in the definition of MedicationRequest implies that the record is authoritative. So by our definition, I don't think that's a modifier. (In fact, based on our new understanding of isModifier, it may be that even Request.intent isn't a modifier as the resource definitions now make clear that requests are proposal, plan or order.
From a signature perspective, I don't see that you'd want to break the signature if you had a non-authoritative copy.
Lloyd McKenzie (Aug 01 2018 at 18:10):
This conversation sort of stalled. From a "modifier" perspective, the copy of a prescription being actionable or not doesn't break the definitions of prescription as defined. Nothing in the definition of MedicationRequest says that it's the record of something actionable (and adding that would be rather problematic for a lot of the uses of the resource). I don't understand Grahame's initial reluctance to put this sort of thing in tag. And it would be good to land this before the ballot if we can...
Jenni Syed (Aug 01 2018 at 18:37):
So far, most of the arguments against this seem to be around forwarding on requests and having them become "statements" in the other system (I would hope there was a way to indicate this intent on the resource). How does one determine whether the system is sending me what use to be a MedicationOrder (indicated authorization to dispense/take) vs a MedicationStatement? If it's not a field changing on the resource, you're assuming the receiver somehow "knows" this based on other setup/config vs. first class in the representation of the resource.
Jenni Syed (Aug 01 2018 at 18:38):
In addition, for systems that will be communicating intent to authorize dispense as well as historical records, I have no way (if using a tag) to confirm that the message was not modified in flight to flip the authorization.
Lloyd McKenzie (Aug 01 2018 at 18:56):
You have no way of knowing "in flight" whether a tag was flipped from "actionable" to "not-actionable" or "restricted" to "test data public access" either. If you're concerned about tags changing inappropriately, it's possible to have signatures that encompass the tags too. Data isn't put in tags because "it's unimportant". It's put in tags because it's information that's expected to change as the data is moved from system to system or based on workflow expectations independently from the "signed" core of the resource.
Lloyd McKenzie (Aug 01 2018 at 19:05):
If we forget about medications for a second, lets look at this with lab orders. If you have a copy of a ServiceRequest on your system, that doesn't necessarily imply that it's an active order intended to be fulfilled. It could be a "FYI" copy of an order someone else wrote and sent to you, or that was included with a referral or CDA document or something like that. There's no "MedicationStatement" equivalent in that space, but the need is the same. We agree that there needs to be an element on the order that tells you whether it's authoritative or not. The question is whether that's an "intent" or a "tag". The rationale for tag is:
- it lets you distinguish authoritative from non-authoritative without losing whether something is a plan/intent/order (or whether it's a placer/filler or reflex order)
- it allows the signature to be retained on the record as it's sent from a system where it's authoritative to one where it won't be
- it allows for systems that can "transfer" custody of orders to be clear about what's happening - i.e. the authoritative copy is no longer the authoritative copy because another system now owns and is making the authoritative updates
- it's consistent with how we flag whether an order is "actionable" or not - that's also done with tags
- the notion of authoritative vs. non-authoritative record is not specific to orders - it holds with events, definitions and even entities (e.g. organizations, devices). The tag solution scales to all of them
The primary rationale against tags is:
- tags are burried and are perceived as unimportant/ignorable information
I don't think that perception is accurate or safe. I agree that if we do go the tag route, we're going to need to make a concerted effort to change that perception.
Michelle (Moseman) Miller (Aug 01 2018 at 19:53):
I think there is a big distinction between using intent (modifier) versus tags (not a modifier). My best example of why I believe it is a modifier is around how you interpret empty elements or "default" values.
- Authoritative orders with empty MedicationRequest.substitution defaults to a meaning of substitution allowed = true per the comment in the spec that says
If nothing is specified substitution may be done
- Non-authoritative "hearsay" with empty MedicationRequest.substitution defaults to a meaning of unknown substitution allowed
John Moehrke (Aug 01 2018 at 19:56):
so it sounds like you are proposing another tag type 'intent' that operates similar to what Lloyd outlines, but also has the meaning of expressing the intent for this copy... I like that far better than Lloyds overloading of the existing tag that clearly indicates it can be ignored. is tis a Resource specific element? or do you see this applying to all Resources and thus would go down where meta is?
John Moehrke (Aug 01 2018 at 20:01):
I would ask that you separate the concept of provenance authority, from the more intent based concept. There is already two ways to carry provenance authority: ( 1 ) Provenance, and ( 2 ) meta.security with the vocabulary http://build.fhir.org/v3/SecurityIntegrityObservationValue/vs.html -- see UNRELIABLE, CLINAST, DEVAST, PATAST, SDMAST, etc...
Lloyd McKenzie (Aug 01 2018 at 21:56):
I think, based on our new definition of modifier, that Request.intent isn't a modifier anymore either. The definitions of MedicationRequest, ServiceRequest, etc. all acknowledge that the resource might be a plan, proposal or order. As such, the value in intent doesn't cause the meaning to violate the expectation of the definitions in the resource.
Lloyd McKenzie (Aug 01 2018 at 21:57):
Having distinct business rules for the value of an element doesn't make it a modifier. You may have very different rules for human patients vs. animal patients - but subject isn't a modifier.
Lloyd McKenzie (Aug 01 2018 at 21:57):
You could have a tag that prohibits editing of a resource by anyone other than the author. That wouldn't be a modifier.
Lloyd McKenzie (Sep 10 2018 at 18:50):
Bringing this back to try to get it landed. @Grahame Grieve, what is the issue with using a tag to distinguish authoritative vs. non-authoritative (given that we already use tag to differentiate "actionable" vs. not)?
Grahame Grieve (Sep 10 2018 at 18:59):
did I say it was?
Lloyd McKenzie (Sep 10 2018 at 19:26):
You weren't thrilled with it. If you've changed your mind - great :)
John Moehrke (Sep 10 2018 at 19:43):
It was me that was not thrilled. My concern is less given where things are going. However I am wondering why we would use a general solution (tags) that exist in all resources to support a functionality needed in some. Why not make that functionality appear where it is needed, and be visible as first-class element in those resource?
Lloyd McKenzie (Sep 10 2018 at 19:45):
Because it is needed in almost all resources. The need to say "this is non-authoritative" applies to all orders, to protocols (i.e. PlanDefinitions), Encounters, Procedures, Immunizations and lots of other events and definitions. It could even apply to something like Group.
Lloyd McKenzie (Sep 10 2018 at 20:09):
That's one of the reasons for the proposed solution. The other is that it works well with signed data that gets moved from an authoritative server to a non-authoritative server, we don't break the signature
John Moehrke (Sep 10 2018 at 20:13):
okay, that is the part that made me less worried...
Jenni Syed (Sep 10 2018 at 22:20):
I'm worried that the part of the request that tells a server how to process the data isn't part of the signature, when (especially for meds) a "statement" from a patient has historically been treated as a separate concept than the actual requests that authorize dispense/carry physician authority. Would need to delve more into the international meds requirements and electronic transfer to understand implications of that.
Grahame Grieve (Sep 10 2018 at 22:21):
well, I share jenni's concern, but I think it goes further for me: whether something is authoritative or not is often not a property of the thing, but of the reference to the thing
Jenni Syed (Sep 10 2018 at 22:23):
I think it can also be that
Jenni Syed (Sep 10 2018 at 22:23):
but when the source of both an authoritative order and a statement can be "born" in the same system for the first time... that's harder to get to a reference.
Jenni Syed (Sep 10 2018 at 22:23):
That came out confusing...
Jenni Syed (Sep 10 2018 at 22:24):
IE, I'm a meds management app that both a patient and a physician can sign into
Jenni Syed (Sep 10 2018 at 22:24):
the store of the data is a single system
Jenni Syed (Sep 10 2018 at 22:24):
That app needs to create, for the first time ever, the record that the patient is taking something w/o prior auth (required or not: eg, illegally or otc) AND the med that the doc authorized
Jenni Syed (Sep 10 2018 at 22:25):
So it needs to create the "thing" to be referenced for both cases?
Jenni Syed (Sep 10 2018 at 22:25):
but then you have to go look somewhere else to find out what that data means?
Jenni Syed (Sep 10 2018 at 22:27):
A lot of what Lloyd talks about assumes the transfer from 2 systems is involved, and that there's a source somewhere with an authoritative authorization
Jenni Syed (Sep 10 2018 at 22:29):
at least, if I'm following that concern around why we want the tag correctly
Jenni Syed (Sep 10 2018 at 22:32):
I also think there's some confusion around what "authoritative" means - technically the patient is authoritative (in most cases) about what they put into their body, but the physician is authoritative in what can legally be dispensed?
Jenni Syed (Sep 10 2018 at 22:33):
well, physician + pharmacist or whatever laws hold true in the country :)
Jenni Syed (Sep 10 2018 at 22:35):
Would really love to see input from some other implementers to see if I'm an oddity here :)
Lloyd McKenzie (Sep 11 2018 at 01:13):
You can choose to sign tags if you want to. There are reasons to sign tags and security labels. But there are reasons not to sign them too. Tags and security labels can often change as data migrates between systems. What's authoritative on system "A" is not authoritative on system "B". If you're concerned about bad actors messing around with security labels or tags, then you'll want a signature on them too, but that's not usually an issue for most systems.
You don't have to look elsewhere to find out what the data means - the tag is in the instance. Authoritative means the official source-of-truth record. And for an order, that never comes from the patient. In terms of a medication statement, then yes the patient's PHR is probably the source of truth.
John Moehrke (Sep 11 2018 at 12:27):
Now I am back confused... are we talking about authoritative in the way Lloyd just described? Because THAT is Provenance. are we talking about this in the way Jenni described? because THAT is workflow. I am not sure what we are talking about. The less clear, the less sure I am that there is a use-case to be worked on that hasn't already a home. If a use-case has a home, we should be careful about creating another alternative home without clear differentiation of why the two homes for that use-case exist.
Lloyd McKenzie (Sep 11 2018 at 13:12):
When you copy a record from one system to another, you can produce a non-authoritative record from an authoritative record. The relationship between them is Provenance. But the derived record still needs to be marked and it has impact on workflow. Provenance is not sufficient for that.
Last updated: Apr 12 2022 at 19:14 UTC
