Stream: IPS
Topic: Breaking Change To IPS Resources in R5
Peter Jordan (Apr 25 2021 at 00:06):
I'm wondering if the Primary IPS Editors - @Rob Hausam, @Giorgio Cangioli & @François Macary - or contributors have collective or individual views on a major breaking change to one of the required resources in the R4 version of the IPS Implementation Guide?
The renaming of the MedicationStatement Resource to MedicationUsage, and the related constraining of its scope**, may represent a major barrier for implementers wishing to move to R5; particularly if international uptake of the R4 version of the IPS IG reaches the targets set by the GDHP/ONC Project (i.e. 10 countries by the end of 2021 and a further 10 by the end of 2022).
**The reduction in scope is illustrated by a comparison of the Status Codes available in R4 (active | completed | entered-in-error | intended | stopped | on-hold | unknown | not-taken) with those available in R5 (completed | entered-in-error | unknown) - noting that the binding strength to the related Value Set is required.
Rob Hausam (Apr 25 2021 at 01:59):
We've certainly been aware of the change to the resource name. But I'm not aware that we've actually had any specific discussion about the change in the resource scope (at least as that is reflected in the status value set), so it's good that you're raising the issue. I guess that the main question to answer is if the status of the medication itself (not the recording status only) and the specific set of codes that were removed from the value set (active | intended | stopped | on-hold | not-taken) is needed in the patient summary context? We definitely need to be discussing this and it would be great to hear any thoughts.
Lloyd McKenzie (Apr 25 2021 at 02:06):
In R5, it's clear that MedicationUsage doesn't convey any information about what's prescribed/authorized, including time period for authorization and status of authorization, only what's actually taken.
Morten Ernebjerg (Apr 25 2021 at 08:15):
The R5 status codes seem a little confusing to me. In R4, the code "completed" meant that the medication is no longer being taken. But in R5, the same code refers to the status of the recording of medication intake (def: "The action of recording the medication statement is finished."). On the other hand, the code "unknown" still refers to the status of the usage itself (def: "The state of the medication usage is not currently known.").
I think it will be crucial to understand if the R5 codes are meant to give the status of the recording or of the intake itself. If it is the latter, then it seems to me this would have an impact on IPS - e.g. with the three current R5 codes, there seems to be no way of saying the intake is ongoing. If the former, how can one then indicate the status of the intake (ongoing vs. completed) in R5, is it only via the time interval?
Morten Ernebjerg (Apr 25 2021 at 08:36):
(I'm wondering e.g. how this will impact the construction of the IPS meds section by mapping from MedicationRequest resources)
Lloyd McKenzie (Apr 25 2021 at 16:07):
The meaning of status has completely shifted in R5. It's now a status of the 'record', not the status of the patient's behavior. (Might be best to not use 'completed' as a code in R5 to avoid confusion though - you could submit a change request.) What the patient is doing is now reflected in MedicationUsage.adherence.
Peter Jordan (Apr 25 2021 at 21:09):
I've pushed back against this change in a Jira Ticket linked to a negative vote for the R5 Ballot.
IMO, this attempt to constrain the number of use cases for Medication Lists should be done via profiling of the R4 MedicationStatement resource by implementers whose requirements only have to satisfy those use cases - but they do NOT represent the whole, worldwide community.
Clinicians, informaticians and consumer representatives in NZ have made it very clear that they required medication summaries that include prescribing and dispensing activity as well as administrations.
Lloyd McKenzie (Apr 26 2021 at 02:35):
If you want to reflect a summary of what's ordered, you can (and should) use MedicationRequest
Vassil Peytchev (Apr 26 2021 at 03:35):
Clinicians, informaticians and consumer representatives in NZ have made it very clear that they required medication summaries that include prescribing and dispensing activity as well as administrations.
Is the requirement for all this summary data to be represented in a single resource? I don't think that is feasible...
Peter Jordan (Apr 26 2021 at 04:02):
MedicationRequest is for single orders. If all you require is a list of orders, all well and good. However, many of our use cases - some from well-established national HIE systems - go well beyond a list of orders. These require what's been ordered, dispensed and administered for a patient, over a set period of time, in a single list and that IS feasible using MedicationStatement in R4. So why remove that capability from R5?
If anyone working on a National e-Prescription Service has never been asked for a list that compares what been prescribed, dispensed and taken - for the purposes of medicines reconciliation (e.g. when attempting to decease the risks of polypharmacy in the elderly) - then I can almost guarantee you that, sooner or later, they will.
Morten Ernebjerg (Apr 26 2021 at 06:09):
@Lloyd McKenzie I opened FHIR-31972 on JIRA asking for a clarification of the new status code descriptions/names. Re. adherence/intake status. Thanks for the pointer, that would cover some aspects of it. However, I was mainly thinking about documenting the intake instructions themselves, rather than whether the patient is sticking to them For instance, MedicationUsage still aims to cover the use case where "[the patient] will be taking the medication in the future". In R4, you could then use the status code "intended", even if you could not supply any dates. How would you represent that in R5 if you do not have a concrete time interval in the future to put in effective[x]?
Rob Hausam (Apr 26 2021 at 13:40):
I agree with @Peter Jordan that the R4 MedicationStatement meets the needs for IPS (as the "single list" that he described), but the more restricted proposed R5 MedicationUsage in its current state will not. So this is clearly an issue that we do need to address for IPS.
Lloyd McKenzie (Apr 26 2021 at 17:40):
MedicationRequest isn't only for single orders. It's not limited to orders at all. MedicationRequest.intent can be plan and recommendation - and can be used to summarize the intent for a patient to take medication that spans many orders
Lloyd McKenzie (Apr 26 2021 at 17:40):
MedicationUsage doesn't convey what's authorized at all.
Lloyd McKenzie (Apr 26 2021 at 17:43):
MedicationUsage would allow you to say "I expect to start taking this medication in 2 weeks", but it doesn't allow you to indicate anything about what's prescribed.
Peter Jordan (Apr 26 2021 at 21:44):
@Lloyd McKenzie I think that you are missing my point. What is required is a resource that facilitates a singe list of what's been prescribed, dispensed and administered to a patient. You can't perform medication reconciliations on the basis of prescribing data only. We have that resource in R4 - MedicationStatement. IMO, removing that would be a serious mistake.
Lloyd McKenzie (Apr 26 2021 at 22:38):
You can't have a single resource that conveys both "what's ordered" and "what's actually happening" - those are two different statements with two different stets of state machines. MedicationStatement was munging them together and causing lots of confusion about what was supposed to go where and implementers were using it for things it wasn't intended to be used for. R5 makes things crystal clear - MedicationRequest for what's authorized/planned/intended; MedicationUsage for what's actually happening. Many use-cases will indeed require both.
Lloyd McKenzie (Apr 26 2021 at 22:40):
With MedicationStatement we often had some systems conveying "reported" prescriptions and "overall therapies" in MedicationStatement and others doing the same thing in MedicationRequest - and that's not useful. Also, there were complaints about the inability to differentiate "dose being taken" from "dose authorized" in MedicationStatement - when it was never intended to convey the latter.
Lloyd McKenzie (Apr 26 2021 at 22:40):
Two separate resources is much clearer and much cleaner.
Peter Jordan (Apr 27 2021 at 01:33):
@Lloyd McKenzie following that reasoning we shouldn't have two R5 resources that contain information about the taking of medication - MedicationAdministration and MedicationUsage.
Lloyd McKenzie (Apr 27 2021 at 02:41):
The purposes are quite different. One represents a specific administration occurrence of a specific drug (e.g. as in a hospital setting) and the other is a general statement of how a patient is currently taking a med (potentially spanning a period of months or even years).
Peter Jordan (Apr 27 2021 at 04:16):
OK, so MedicationUsage is a statement (and that word is contained 19 times in that resource's content page) - but my point remains that if you are constraining this statement to how a medication is currently being taken then it's not going to be a particularly useful resource for a large number of existing use cases....and how often is that usage information actually available in community systems?
Lloyd McKenzie (Apr 27 2021 at 04:31):
MedicationStatement captures 'use'. MedicationRequest captures 'intent'. Some cases will need one, some the other, some both. MedicationUsage will typically only be present in systems that monitor adherence or that capture medication information that is not prescribed at all.
Peter Jordan (Apr 27 2021 at 04:56):
From the R4 Spec. A medication statement...."is a report by a patient, significant other or a clinician that one or more of the prescribe, dispense or administer actions has occurred..."
Giorgio Cangioli (Apr 27 2021 at 12:12):
Thank you @Peter Jordan for pointing this out.
Giorgio Cangioli (Apr 27 2021 at 12:13):
As you correctly stated, the choice we made in the IPS was to try to keep things as possible simple and provide a way to list the medications taken or supposed to be taken, irrespective by the fact this information is obtained by a list of prescribed, dispensed or other kinds of medications.
This is what the MedicationStatement supported.
Giorgio Cangioli (Apr 27 2021 at 12:13):
I share your concerns in the change of scope and I think that the original IPS approach should be preserved
Giorgio Cangioli (Apr 27 2021 at 12:14):
The IPS is not supposed to be used for requesting medications
Giorgio Cangioli (Apr 27 2021 at 12:33):
A different topic might be instead if we'd like to consider to "extend" the medication summary to other kinds of medication resources for better support the automatic generation of IPS by systems natively managing FHIR prescriptions, administrations or dispensations. (Partially supported also now because the slice is open).
This without losing however the current option: one resource covering everything.
But this is separate topic to be better analysed.
Vassil Peytchev (Apr 27 2021 at 13:56):
@Giorgio Cangioli @Peter Jordan - it seems to me that the main issue is the perceived need for
one resource covering everything.
Can you help me understand why it is perceived that there is such a need?
Lloyd McKenzie (Apr 27 2021 at 14:07):
Any of the non-normative resources used by IPS can have breaking changes, so IPS should be prepared to deal with that.
Peter Jordan (Apr 27 2021 at 22:00):
Lloyd McKenzie said:
Any of the non-normative resources used by IPS can have breaking changes, so IPS should be prepared to deal with that.
It's very easy to say that - but maybe not quite so easy in practice! MedicationStatement is a required element in the R4 IPS and worldwide usage is likely to be extensive by the time that R5 is finally published.
Peter Jordan (Apr 27 2021 at 22:03):
Vassil Peytchev said:
Giorgio Cangioli Peter Jordan - it seems to me that the main issue is the perceived need for
one resource covering everything.
Can you help me understand why it is perceived that there is such a need?
@Vassil Peytchev - I suggest that you read the entire thread and the related JIRA ticket. In my case, that requirement is well established and not just perceived.
Lloyd McKenzie (Apr 27 2021 at 22:44):
Wanting a single resource doesn't make it a requirement. There are lots of situations where we might like all data to be in a single resource but need to access more than one. You can certainly ballot the change in R5, but this change has been driven by a LOT of implementer discussion and a strong desire to eliminate confusion and drive consistency. Combining "what's authorized" and "what's actually happening" into a single resource turns out to be a bad idea in practice - because a lot of the things you want to be able to say - about status, dose, start and end date, etc. are actually different for the authorization and "what's happening" aspects. Also, if you're dealing with two statuses, then in FHIR terms, that generally means "two resources". The fact that IPS will be widely implemented won't change that.
Vassil Peytchev (Apr 27 2021 at 22:47):
I've been following the thread from the beginning, and all I can discern is "We had this shiny widget, and we used it in a certain way, and we want to keep using it exactly in that way."
I have no doubts that
medication summaries that include prescribing and dispensing activity as well as administrations
is a real need. I just can't connect it to the insistence that it all has to be represented as a single resource. Is it not possible to use a combination of MedReq, MedAdmin, and MedUsage together to create a comprehensive medication summary? If there are missing pieces, what are they?
Peter Jordan (Apr 28 2021 at 01:53):
@Lloyd McKenzie - what particularly experience tells you that it's a bad idea to retain a widely-implemented resource that facilitates a comprehensive medication summary?
Is it the Medication Section in C-CDA?...
"The Medications Section contains a patient's current medications and pertinent medication history. At a minimum, the currently active medications are listed. An entire medication history is an option. The section can describe a patient's prescription and dispense history and information about intended drug monitoring.
This section requires either an entry indicating the subject is not known to be on any medications or entries summarizing the subject's medications."
Furthermore, adding a resource called MedicationUsage when there is one already called MedicationAdministration is far more likely to cause confusion and '2 statuses = 2 FHR resources' - really? We'd have a 1,000 resources if that rule were to be applied.
Lloyd McKenzie (Apr 28 2021 at 02:45):
There are very few resources that have multiple statuses. A couple of those we're looking at splitting. Others are talking about orthogonal aspects of the same action. Here, we're talking about two completely separate actions - what's authorized and what's being taken - each action having a number of characteristics that are specific to that distinct action. MedicationStatement wasn't meeting the full use-case because there was no way to distinguish the state of the authorization from the state of what the patient was actually doing. Also, there was overlap because MedicationRequest was intended to cover all use-cases related to "what's supposed to happen", so there were systems trying to cover exactly the same use-cases using different resources.
Peter Jordan (Apr 28 2021 at 03:05):
I'm going to take a forensic look at the status codes in the medication resources in R4 and R5. This isn't an academic exercise, I have two major NZ implementations to consider - i.e. mapping the entire NZePS Data Model to FHIR and the( C-CDA like) Medication Profile from our GP2GP Data Model to the IPS.
Last updated: Apr 12 2022 at 19:14 UTC
