The short summary is that MedicationStatement is for things that are described in less detail, or are not as well structured as a MedicationRequest.
An example use of MedicationStatement would be record that the patient said âI take St Johns Wortâ. This is an unqualified âanecdotalâ statement - no dose, no timing, no formal prescription, and not made by a practitioner. A MedicationRequest typically represents a prescription by a medically qualified person.
Rik is correct but in practice, at least in the UK, the use of MedicationStatement goes well beyond anecdotal statements by the patient and will eventually include full computable data including complex dose timing. Very few develiopers wil use MedicationRequest directly, whose use is restricted to actual prescribing, whereas most use-cases will simple be about listing medications or perhaps updating those lists, but without the force or intent to act as a prescription. So basically use MedicationStatement for a typical Get a list of medications requirement.
Hi Ian, are we saying that it is usual to create a parallel set of MedicationStatements to go with the order/fulfilment set of resources that cover the actual prescribing process?
That doesnât seem like the intended use of MedicationStatement as I understand it.
Yes that was the decision for the CareConnect work. It was the clear preference for all those involved, including the system vendors, esp the GP vendors. Ther ewas quite careful deliberation before this decision was made. They wanted a clear split between the actionable (prescribable) request and the answer to a question, what is the patient taking?.
The other advantage of using MedicatonStatement is that allows some of the complex dispensing, administration, reauthorisation information to be âsummarisedâ.
I can see the logic, and that itâs nice to have a prepared summary. But there is a question of whether this covers everything in all cases.
In the general case, outside of CareConnect, it is not safe I believe to only rely on MedicationStatement for the full list of known medications (unless the other resources are not supported at all).
Thinking on, is it possible that a system that conforms to CareConnect may import, or be sent, the other medication resources?
Is there a requirement to create MedicationStatements that summarise those resources?
If not, how could I know for a given system that it is safe to only ever look at MedicationStatements?
MedicationStatement is used to state a patients medication at a point in time. It is also a method of recording things like Rik said âI take St Johns wortâ and also summary medication information.
So for transfer of care the use of MedicationStatement is more appropriate, as transfer of care is also a point in time recording this is appropriate.
If you are calling a prescription system then I would expect it to support MedicationRequest and MAY support MedicationStatement. (If youâre working on Transfer of Care, you would call MedicationRequest (RESTful) and or MedicationDispense and then create a MedicationStatement based on that information to send via FHIR Document (messaging)).
I would agree that a system that has an active prescribing system and wants to expose that functionality e.g to an out of hours service, is going to expose MedicationRequest but we agreed that they should always support MedicationStatement as the primary means by which a 3rd party can get a simple and consistent answer to the question 'what medications is the patient taking; which will be a far more common than âprescribe drug xâ . AFAIK all of the GP systems are doing both. I think we are in spectacular agreement!
And we have hopefully documented here for future googles that not everything in the UK will necessarily work the same as a GP system
But I am curious if CareConnect inherently has this rule that all medication shall be exposed as MedicationStatements? Or is it just the GP system implementation?
That sounds like a wider API behaviour issue than FHIR profiles can describe for instance.
But I am curious if CareConnect inherently has this rule that all medication shall be exposed as MedicationStatements? Or is it just the GP system implementation?
That sounds like a wider API behaviour issue than FHIR profiles can describe for instance.
Yes, you are quite right that more properly this is part of the API spec but the curation group which included secondary care suppliers was happy with the approach so I doubt if Richardâs group who are developing the API will take a different view. It just seemed sensible to have a single, consistent and simple call to âget current medsâ without knowing too much about the internal architecture or whether the system supports prescribing natively.
Is that written down anywhere? The rough pattern Iâve seen stated is:
Messaging/Document exchanges - MedicationStatement is used but for (pharmacy to GP) then MedicationDispense and Immunization is used. [The use of MedicationStatement is written down]
RPC API (e.g. GP Connect) - MedicationStatement is used as a summary (I need to check if MedicationRequest is also included) [The use of MedicationStatement is written down]
RESTful API - Not aware of any written rules. Should the rule be: if your system is master for prescription information MedicationRequest should be used. If youâre holding a copy of prescription information, you should use MedicationStatement.
** Not sure on this but if weâre working with dispensing, prescribing, nursing, etc systems then I feel we would want to use the MedicationRequest->MedicationDispense->MedicationAdministration cycle.