Stream: implementers
Topic: detectedIssue
Pete Salisbury (Feb 26 2018 at 17:13):
I work for GP Connect which is an API to provide access to data in GP systems in England. We are considering the use of the detectedIssue resource in the context of the MedicationRequest resource and I want to check that I have the correct understanding of how it should be used.
We are looking to use detectedIssue/date and detectedIssue/detail to record the date and reason a medication in the GP system was discontinued. An example scenario when this would be recorded in the GP system is if a clinician has issued a repeat mediction to a patient they have had on issue dispesed but when they have taken the medication have had a reaction to it. The GP would then stop the medication so no further authorisations were dispensed and record a date and a reason why the medication was stopped.
They may also record an allergy but this would be represented separately and if exported would be in an allergyIntolerance resource.
Is this use case the correct use of the detectedIssue resource?
Lloyd McKenzie (Feb 26 2018 at 17:27):
The DetectedIssue is typically used to represent some sort of manifested contraindication/issue. You can note that you managed the contraindication by discontinuing one of the involved meds/procedures/whatever. However actually stopping the medication (and why) would be handled by changing the MedicationRequest.status to "stopped" and specifying a status reason.
Pete Salisbury (Feb 26 2018 at 17:34):
Thanks for the speedy reply.
In the above we would change the status to stopped as you suggested but are looking for somewhere to put the date it was stopped and the reason. I thought that the detectedIssue may be a good place. If it's not should we just use the note and an end date in dispenseRequest/validityPeriod? If not would we need to extend?
Lloyd McKenzie (Feb 26 2018 at 17:41):
You have MedicationRequest.statusReason. For the date of the change (and who made it), you'd need to look at MedicationRequest.eventHistory. It's not wrong to capture the information in DetectedIssue, it's just that querying DetectedIssue isn't the first place people would expect to find that information. And the MedicationRequest does have standard ways of capturing it.
Pete Salisbury (Feb 26 2018 at 18:53):
We're going to be using STU3 so the statusReason doesn't exist in the version that we are looking to get people to develop against. I suppose that we could add it as an extension but all of the systems suppliers we are dealing with only capture the reason for stopping the medication as a string of text so we wouldn't be able to easily convert it to any type of code.
Grahame Grieve (Feb 26 2018 at 19:59):
that's why it's a CodeableConcept - you can use just .text
Amir Mehrkar (Mar 01 2018 at 12:32):
@Lloyd McKenzie @Grahame Grieve @Pete Salisbury so in a workflow process would the following be appropriate:
GP creates an order for a medicatoin: MedicationRequest.status = active; MedicationRequest.intent = order; authoredOn = date GP creates the order
THEN
GP STOPS the order (new FHIR instance): MedicationRequest.status = stopped; MedicationRequest.intent = order; authoredOn = date GP stops order
My point being, for workflow between primary care and an electronic prescription service in the community, and audit purposes, we need two instances, with status and intent values helping to distinguish the context of the authoredOn date.
Lloyd McKenzie (Mar 01 2018 at 14:30):
MedicationRequest.authoredOn would not change when the order was stopped. Information about when it was stopped ans by whom would be in MedicationRequest.eventHistory.
Lloyd McKenzie (Mar 01 2018 at 14:31):
The eventHistory would convey all relevent status and other events throughout the order's history.
Amir Mehrkar (Mar 01 2018 at 18:35):
Thanks @Lloyd McKenzie so would this be different then, as in the INTEROPen UK FHIR profiling work we have said:
GP creates a plan for the medication: MedicationRequest.status = active; MedicationRequest.intent = plan; authoredOn = Date GP creates the plan
THEN
GP creates an order for that medication (new instance): MedicationRequest.status = active; MedicationRequest.intent = order; authoredOn = Date GP creates the order
Here a "active - plan" goes to an "active - order" and the authoredOn date changes.
Is MedicationRequest.eventHistory involved here too or different this time?
And in the previous example, of "active - order" to "stopped - order", is it wrong to use the authoredOn date to distinguish (instead of eventHistory)
Lloyd McKenzie (Mar 01 2018 at 18:43):
That use would be fine as you have two different MedicationRequests - one a plan and one an order
Lloyd McKenzie (Mar 01 2018 at 18:43):
You don't transition plan to order, you create a new instance
Lloyd McKenzie (Mar 01 2018 at 18:44):
MedicationRequest.intent is immutable
David Hay (Mar 01 2018 at 22:45):
What is it (in the spec) that makes the intent immutable?
Lloyd McKenzie (Mar 01 2018 at 23:20):
Apparently nothing. Added GF#15686
Amir Mehrkar (Mar 06 2018 at 08:26):
Im scratching my head and confused still - sorry if im being stupid @Lloyd McKenzie @David Hay @Pete Salisbury because I dont see how the two use cases Ive mentioned are different as workflow concepts, yet the answers seem different.
1a GP adds a drug to the system (ready to be ordered) MedicationRequest.intent = plan .status = active
1b GP now orders the drug (ie authorises / orders the prescription) MedicationRequest.intent = order .status = active
The authoredOn date distinguishes event 1a and 1b
2a GP orders a drug (this message is sent) MedicationRequest.intent = order .status = active
2b. GP decides to stop that drug (this message is sent) MedicationRequest.intent = order . status = stopped
Why is it wrong for there to be two fhir instances here, with the authoredOn date also distinguishes event 2a and 2b.
(also, suppose we choose NOT to use eventHistory)
Lloyd McKenzie (Mar 06 2018 at 15:35):
1a and 1b represent different things. The first says "I plan for the patient to be on Med X for 6 months". The second says "I have ordered the patient to be on Med X for 3 months". The first statement remains effective and in force when the second is created.
However, if you stop the medication, you want to terminate the statement that's in force. In fact, you probably want to terminate both statements and indicate that both the plan and the order have been revised.
Amir Mehrkar (Apr 10 2018 at 13:33):
@Lloyd McKenzie thanks for your replies. Let me check my understanding:
MedicationRequest.intent eg plan or order, that has status changes must have the status changes managed by the eventHistory element? Is that correct? Thus when an “intent” is created, the authoredOn date never changes, but the intent’s status changes are logged in EventHistory?
If that is correct, assume this is a well understood rule for the use of this resource?
We hadn’t anticipated to use eventHistory to track changes in the Request’s status. And given eventHistory’s 0..* cardinality this would capture all such status changes over time? @Pete Salisbury @Dave Barnet FYI
Lloyd McKenzie (Apr 10 2018 at 13:43):
"Well-understood" is hard to evaluate when writing a spec. It's certainly the intention. If it's not clear, feel free to submit change requests and we can try to improve the language. Not all systems will capture eventHistory. So it's possible you'll have a medication that's on-hold with no indication of who placed it there or why or when - or perhaps only see that as non-computable inofrmation in the comments or narrative. But if systems do support that information computably, then eventHistory would be where that information would be expected.
Amir Mehrkar (Apr 10 2018 at 17:50):
Thank you @Lloyd McKenzie - we may need to review our INTEROPen UK FHIR profiles localisations (named CareConnect) for MedicationRequest given this intended use of the resource and eventHistory. It’s not something we had taken into account during our “curation” calls ie when we profile the resource as a General Parent UK FHIR profile.
There was a proposal to create an extension “DateStopped” - it would seem this might be a “quick fix” and whilst not a breaking chain, seems against intended usage.... would
you advise against this?
@Pete Salisbury @Dave Barnet @Jennifer Ellison in the use case for GPConnect, when “plans” or “orders” change from status “active” to “stopped”, we need to look at this element to be conformant with FHIR usage. What is your advice?
Lloyd McKenzie (Apr 10 2018 at 18:50):
If you're going to go with an extension, I might go with "statusDate" as that would also let you communicate held date if you don't want to capture the full status history.
Lloyd McKenzie (Apr 10 2018 at 18:50):
But it would certainly be better to use eventHistory - even if you only capture the most recent "history" event.
Last updated: Apr 12 2022 at 19:14 UTC
