Stream: implementers
Topic: Medication workflow and reference to MedicationRequest
Martin Grundberg (Dec 18 2018 at 10:59):
I am currently looking into the workflow aspects of FHIR.
Conceptually, an Event is basedOn a Request. This feels like a robust model.
Examples:
DiagnosticReport.basedOn Reference(CarePlan | ImmunizationRecommendation | MedicationRequest | NutritionOrder | ServiceRequest) What was requested
Observation.basedOn Reference(CarePlan | DeviceRequest | ImmunizationRecommendation | MedicationRequest | NutritionOrder | ServiceRequest) Fulfills plan, proposal or order
Procedure.basedOn Reference(CarePlan | ServiceRequest) A request for this procedure
Encounter.basedOn Reference(ServiceRequest) The ServiceRequest that initiated this encounter
....
But when it comes to Medication events, they do not have basedOn, instead they seem to have corresponding elements with different names
MedicationDispense.authorizingPrescription Reference(MedicationRequest) Medication order that authorizes the dispense
MedicationAdministration.request Reference(MedicationRequest) Request administration performed against
QUESTION
Is there a reason why Medication events seem to deviate from the FHIR Workflow standard? The elements listed above for the Medication events seem to correspond to what the basedOn element achieves for other events. Workflow is a complicated area, consistency is nice :)
SUGGESTION
If there is no reason to deviate from the FHIR workflow standard in the medication domain, maybe the Medication event elements should be renamed and called basedOn?
Martin Grundberg (Dec 18 2018 at 11:39):
I digged a bit further...
12.5.1.4 Event Resource Pattern
Events are resources that represent the ongoing or completed execution of some activity or observation. For example, a clinical procedure, a financial transaction, the recording of a diagnosis, etc. An Event pattern defines the common elements typically present on all event resources.
https://www.hl7.org/fhir/workflow.html#event
Event pattern
pasted image
https://www.hl7.org/fhir/event.html
This seems like a modelling error in the Medication events?
John Silva (Dec 18 2018 at 12:34):
@Martin Grundberg - thanks for raising this concern. When I was asking questions here about how V2 Medication (and other) Order workflows fit into FHIR there was a response (or a few -- from the FHIR experts) about the FHIR workflow pattern. However, it doesn't seem very clear (or well developed/explained) when it comes to the medication workflow. So, besides the consistency (or not) with the Event Resource pattern, it would be very helpful if the Pharmacy group could work with the FHIR workflow group (or is it really the FHIR experts) to come up with a pictorial view (model) of this pattern that makes it easier to understand and, then, to make sure the Medication-related resources use consistent property names with the FHIR Event pattern? (BTW, my question/concern was how to reconcile the ORC-1 - Order Control codes with the MedicationRequest.status property and was told that MedReqs are not workflow 'objects' but more of 'current state objects'. OK, so then I thought that the ORC-5 Order Status would more closely map to the MedReq.status property but that didn't seem a good fit either, though better than ORC-1. However, the ORC-1 states, which are uses for ALL HL7 V2 order types, do not map 'neatly' into the MedicationRequestStatus value set.)
Lloyd McKenzie (Dec 18 2018 at 15:10):
Alignment with the workflow patterns isn't mandatory - work groups determine what is "typically" supported by systems in their space and also what element names are going to be most intuitive. In the case of Medication[x] resources, the work group didn't feel that linking to care plans, ServiceRequests and other types of request resources fell within what most systems did and that the name "basedOn" wasn't sufficiently clear for their community. However, you should see mappings to basedOn in both resources.
Lloyd McKenzie (Dec 18 2018 at 15:11):
If you have need to link to resources other than MedicationRequest, you can do so via extensions
Lloyd McKenzie (Dec 18 2018 at 15:12):
The key thing with the patterns is that alignment is subservient to ease of understanding by implementers for the simple use-cases.
Melva Peters (Dec 18 2018 at 16:37):
Pharmacy has aligned with the workflow pattern but as @Lloyd McKenzie mentioned, we didn't bring all of the names. If you have examples of other requirements, please submit a tracker item. At the time changes were made to align with workflow, we didn't have use cases to support linking to other resources.
Martin Grundberg (Dec 20 2018 at 10:27):
@John Silva , @Lloyd McKenzie , @Melva Peters , thanks for you respective input and answers! Very appreciated!
I would still argue though that for long term ease of use for us implementers, following a common pattern across different resource categories is a good idea (hence, I really appreciate the Workflow pattern!). That includes standardizing element names which have the same meaning across resources. You can still add a Description text that explains that element in the context of its specific resource.
But the core support for referencing a MedicationRequest is there in Administration and Dispense, so that is good at least!
@Melva Peters , how do you report a ticket? And what is the main use case for reporting them? I don't think this will be my last question/issue like this, so maybe those are better posted as tickets then in the implementer stream?
Lloyd McKenzie (Dec 20 2018 at 16:04):
Common names are helpful for those systems that deal with multiple resources, but those are, by definition, more sophisticated than those systems that are pharmacy-specific. Our approach is to make things as simple as possible for the "simple" systems, even if that means extra complexity for more sophisticated systems.
Lloyd McKenzie (Dec 20 2018 at 16:07):
We have deep experience with what happens when we value consistent naming and modelling over domain intuitiveness. The result is significantly higher costs and reduced interoperability for everyone.
Grahame Grieve (Sep 03 2019 at 06:58):
Someone pointed me at this. I have several questions:
- is there a task around @John Silva's very reasonable request for some summary of the medication workflow?
- is it really true that a medication dispense can only come from a MedicationRequest which establishes the wider context? (e.g. careplan etc)
- I'm not entirely sure that MedicationDispense.authorizingPrescription is actually same as basedOn, but the definitions seem to imply that it is, just renamed. But the relationship between a dispense and it's authorizing prescription is different to (say) the relationship between a DiagnosticReport and the MedicationRequest that made it appropriate
I'm not sure that we're in a happy place here
John Silva (Sep 03 2019 at 13:54):
Thanks for raising this again @Grahame Grieve
Lloyd McKenzie (Sep 03 2019 at 14:39):
I'll defer to @Melva Peters on the first. For the second, "over the counter" meds aren't captured as dispenses that I've ever seen unless there's a prescription. AuthorizingPrescription is mapped to basedOn. Agree that DiagnosticReport being "basedOn" a MedicationRequest seems odd. I can't think of a situation where a drug prescription would authorize the creation of a DiagnosticReport. CarePlan and ServiceRequest make sense there. ImmunizationRequest and NutritionOrder are also suspect. @Eric Haas ?
Grahame Grieve (Sep 03 2019 at 19:01):
"over the counter" meds aren't captured as dispenses that I've ever seen unless there's a prescription
so how are they captured?
Jose Costa Teixeira (Sep 03 2019 at 19:01):
OTC meds are captured in a dispense, even if no prescription. Also in some situations, drugs are dispensed that don't have a prescription (yet), so there definitely is a need for dispense record even if there is no prescription.
Lloyd McKenzie (Sep 03 2019 at 19:46):
To the best of my knowledge, in Canada, a pharmacy would only dispense an OTC if there was an order for it. E.g. If a clinician prescribes Aspirin, then a pharmacy will dispense it (and you can claim it against your drug insurance). If you just go into the pharmacy and buy Aspirin, it's not going to be recorded against your record (or if it were, it'd be a MedicationStatement). Similarly, in an in-patient setting, no pharmacy would dispense Aspirin without an order. That said, I don't think the resource forces the existence of a MedicationRequest. It doesn't fall within 'core' to link a dispense to a CarePlan or some other sort of order though.
Jose Costa Teixeira (Sep 03 2019 at 20:45):
If you just go into the pharmacy and buy Aspirin, it's not going to be recorded against your record (or if it were, it'd be a MedicationStatement). Similarly, in an in-patient setting, no pharmacy would dispense Aspirin without an order.
Well, I agree we need some guidance on workflows :) This was happered flat in IHE (for V2, not FHIR). The cases were: 1. drug is dispensed but prescription will only be there later (e.g. emergency contraceptives). 2. drug is OTC and we want to capture it. We used the same notion "dispense" because there is no reason this would be any other data object. So IMO if a Pharmacy wants to say "i just delivered this drug to this patient" this is not a medstatement. this is functionally / semantically a dispense.
Eric Haas (Sep 04 2019 at 02:56):
I am assuming you mean why does DiagnoticRequest have basedOn MedRequest or ImmReqest, What about drugs ( like PB) that require testing prior to reauthorization or vaccines that (like rabies) that may require a titre before administration. That was the rationale behind this.
Grahame Grieve (Sep 04 2019 at 03:02):
I feel as though 'basedOn' is pretty loose - certainly by it's definition. At least, I don't feel that authorizingPrescription has the same semantic breadth as basedOn, but the definitions and the answer above imply that it does
Melva Peters (Sep 04 2019 at 18:51):
Typically if an OTC is "prescribed", then it will go through as a dispense - often it can be claimed on insurance if prescribed - at least in Canada. If it is not prescribed - patient walks in and wants an antihistamine, then it is recorded as a MedicationUsage. Typically these are recorded if it is chronic use (Aspirin 81mg) or seasonal use (like yearly antihistamines)
Jose Costa Teixeira (Sep 05 2019 at 03:19):
If it is not prescribed - patient walks in and wants an antihistamine, then it is recorded as a MedicationUsage.
So the flow for 'no prescription' is different depending if the drug is an otc or not...? In other words, if I go to pharmacy and say 'i forgot my antibiotics, but I can bring a prescription tomorrow. And please give me some paracetamol' - in IHE this produces 2 dispenses, one will be needed for reimbursement, the other not. In Canada this would be one dispense and one Usage? How does the system know that the antibiotics prescription will arrive?
Jose Costa Teixeira (Sep 05 2019 at 03:20):
I can see that approach causing issues from workflow perspective
Jose Costa Teixeira (Sep 05 2019 at 03:24):
Consistency is a key factor for workflow. IHE will provide comprehensive guidance on medication workflow.
Jose Costa Teixeira (Sep 05 2019 at 03:29):
We have always considered that IHE handles workflow. If HL7 produces guidance like this, we should perhaps align beforehand to avoid past problems (life was not very easy when we did this for V2)
Lloyd McKenzie (Sep 05 2019 at 03:49):
I don't agree with the statement that "IHE handles workflow". In your example above, for something like antibiotics, unless there was an indication of urgent need, the pharmacist would probably say "come back tomorrow". However, for something like asthma meds, the pharmacy might make an emergency dispense - and would likely record it in the shared record once the prescription had arrived. In terms of the paracetamol, they'd show you where it was on the shelf and if you wished, ring it through for you, but if they bothered to put it in the record at all, it would be MedicationUsage. They wouldn't think of it as a dispense and certainly wouldn't record it as one. The business workflow would be completely different.
Jose Costa Teixeira (Sep 05 2019 at 04:23):
"IHE Handles workflow" was the statement in a joint meeting between HL7 and IHE (or perhaps two, can't recall). This was a very reassuring position at the time, because it allowed both parties to focus on what they do best.
Jose Costa Teixeira (Sep 05 2019 at 04:26):
the antibiotics case I mentioned is an emergency indeed. this happens, and we don't want it to create parallel workflows.
Jose Costa Teixeira (Sep 05 2019 at 04:29):
The perception of what "dispense" is can change from place to place (not good but that is what we have). FWIW, in my experience, "they wouldn't think of it as being a dispense" is not binding for the system behaviour. The system sees "I have a patient being given medication for them - that is a dispense record"
Jose Costa Teixeira (Sep 05 2019 at 04:37):
I concur that there should be guidance . From an IHE side, I previewed how the IHE HMW diagram would be on FHIR.
And HL7 must provide the basic mechanisms - that is what we are doing. So we work in both IHE or HL7 to provide guidance on workflow.
Lloyd McKenzie (Sep 05 2019 at 04:37):
How the business sees it drives how the system sees it. The pharmacists don't want it in their dispense records. And the physicians don't want it in their dispense records. The only record they care to have is "patient may be on this medication". Quantity provided, etc. aren't relevant - because the patient could easily pick up more at the grocery store the next day (and there certainly wouldn't be a record of that).
Jose Costa Teixeira (Sep 05 2019 at 04:37):
Workflows are hard, and they grow exponentially if we don't enforce orthodoxy. And IHE has been through that. Hence my recommendation.
Lloyd McKenzie (Sep 05 2019 at 04:40):
You can't enforce orthodoxy if the business domains don't have consistency. I can tell you that if you tried to tell the pharmacists in Canada to capture an OTC as a dispense, they'd tell you to stuff it. (And if your argument was that the Europeans do it that way, they'd probably tell you to stuff it further :>) Technical standards organizations have to work their standards around business practice. If there's a desire to change business practice, the point of leverage is professional societies, not technical standards.
Lloyd McKenzie (Sep 05 2019 at 04:41):
(And generally, you pull on those levers very carefully and generally only when doing so will make significant difference to patient care - MedicationDispense vs. MedicationUsage doesn't seem like a situation where that applies.)
Jose Costa Teixeira (Sep 05 2019 at 04:42):
The pharmacists don't want it in their dispense records. And the physicians don't want it in their dispense records. The only record they care to have is "patient may be on this medication". Quantity provided, etc. aren't relevant - because the patient could easily pick up more at the grocery store the next day (and there certainly wouldn't be a record of that).
Yes, that may be the case in some cases, In other cases that info may be relevant - e.g. to continue a workflow. In some cases you want to say "this has been dispensed" (because it was). So we should have guidance on case by case basis, but I prefer to have one consistent frame from where the behaviour is obvious.
Jose Costa Teixeira (Sep 05 2019 at 04:44):
I'm just pointing that some guidance should be considered carefully, because it can multiply the workflow complexity.
Jose Costa Teixeira (Sep 05 2019 at 04:45):
I don't want to disagree on this case specifically but in this case I agree with the desired outcome but I can expect that before the Usage there could Dispense information.
Jose Costa Teixeira (Sep 05 2019 at 04:46):
I would actually capture it as a dispense, and if this is going to a dossier or a government report or a billing thing, then other resources could be derived.
Jose Costa Teixeira (Sep 05 2019 at 04:49):
Possibly this is related to the definition of dispense, possibly in Canada it has a different perception. That is not a new issue - If we have 10 experts on a table we typically have at least 11 definitions of Dispense...
Lloyd McKenzie (Sep 05 2019 at 04:49):
I understand that you want it consistent. But if the business isn't consistent, there's no chance that HL7 (nor IHE) is going to make it so. If the business has inconsistencies, that will indeed drive technical complexities - but standards organizations can't do much to fix business consistencies. The resources used are driven by where users want to see the data. And they don't want to see OTCs mixed in with the stuff relating to orders unless there's actually an order for it.
Jose Costa Teixeira (Sep 05 2019 at 04:52):
Not only I want it consistent, Business needs it consistent, and standards should at least allow that.
From v2, I learned that business is consistent. What was inconsistent was the many ways to use OMP/RDE/RDS... for the same reality.
Jose Costa Teixeira (Sep 05 2019 at 04:58):
I would like to study the OTC cases in more detail, and get back to this after some discussion. My point is: In this case, I think it is valid to expect a Usage, but also a Dispense could be needed. And I am inclined to say "everything gets a dispense" but I don't want to force it - but I don't want to exclude it either.
Lloyd McKenzie (Sep 05 2019 at 05:06):
I haven't seen any 'need' in the Canadian space for OTCs and prescribed meds to be handled consistently. In fact, every project I've been involved in, the stakeholders have been quite clear that they want them handled differently. They don't want them on the same screens. They don't use the same workflows. Dispenses of prescriptions are tightly regulated. They need to be tracked. There's insurance involved. With OTCs, the process is the same as if the patient was buying a bag of apples. The only difference is that, in some cases, there's seen to be value in capturing the medication in the record as "patient is likely taking" because of the possibility of adverse reactions. The fact that from a modelling perspective, both are clearly dispenses doesn't matter.
Grahame Grieve (Sep 05 2019 at 06:11):
The only difference is that, in some cases, there's seen to be value in capturing the medication in the record as "patient is likely taking" because of the possibility of adverse reactions. The fact that from a modelling perspective, both are clearly dispenses doesn't matter.
I'm not convinced about this, and I'd like wider input. Your argument basically appears to be: in the experience I have, pharmacists don't want non-prescribed things to be be called dispense, so therefore dispenses always are based on prescriptions, and not on other things. That seems a big jump to me
Peter Jordan (Sep 05 2019 at 08:36):
The FHIR Medication Resources need to support the OTC use case, so the modelling perspective does matter. Otherwise, it's not possible to perform medication reconciliation, using those resources, in cases where a patient is taking OTC meds. Noting that the FHIR Spec states ...
A medication statement is not a part of the prescribe->dispense->administer sequence but is a report that such a sequence (or at least a part of it) did take place, resulting in a belief that the patient has received a particular medication.
Pharmacy systems should be able to differentiate by looking at the requestor in the MedicationRequest that's linked to a MedicationDispense Resource via an authorizingPrescription reference. If they don't regard OTC sales as requests and dispenses, that's their perogative - but that shouldn't prevent other systems, with different requirements, from doing so.
John Silva (Sep 05 2019 at 13:30):
Here's a 'strange case' from the US -- in many pharmacies now there are certain OTC drugs that need to be carefully tracked because these need to be kept from getting in the hands of 'youngsters' or 'abusers'. So the pharmacist might not care about these but the (US and local) government do and might even require pharmacies to report on the 'dispense' (or purchase - don't care what it's called though for modeling consistency ...) of these.
On the discussion of MedDispense vs MedUsage -- why would the pharmacist care when these are used or what they are called as long as it doesn't affect their workflow? It seems to be a function of the PIS (Pharm Info System) that they are using, not the back-end FHIR data objects, that matter to the pharmacists. The PIS vendors need to get this right for their own individual markets and the FHIR (or HL7) technology that supports these systems needs to be powerful and flexible enough to support their information and product models.
Lloyd McKenzie (Sep 05 2019 at 15:26):
I'm not saying that dispenses are always based on prescriptions. (And the model doesn't enforce that.) I'm saying that supplying of OTC products to a patient typically won't be captured using MedicationDispense. If you need/want to, it'll certainly serve the purpose.
Melva Peters (Sep 05 2019 at 15:37):
In Canada, the drug information systems (DIS( have a mechanism to handle medicationUsage. This is used for medications purchased from a pharmacy where there isn't a prescription or where a patient gets a prescription dispensed from a prescriber in another jurisdiction. These are recorded on the pharmacy management system and sent to the DIS as "record other medication" (Canadian V3 interaction similar to MedicationUsage). This is done to make sure the medication profile is complete as possible. If the drug is prescribed, then it is typically put through as a dispense against the prescription because a claim is generated for dispenses (but not for medicationUsage). Sometimes the pharmacist may not know how the system is handling the record - some systems trigger the recording of the OTC automatically based on the drug by default. In Canada, often the jurisdictional Drug Information System where the pharmacist is practicing determines what message is captured for each type of record. The medication profiles that are returned for all clinicians to view from the DIS returns all types of records - MedRequests (prescriptions), MedDispenses, MedUsage. There may be different types of business rules on the type of alert checking that is done for each type of record. For example, in Saskatchewan where I worked, no checking is done when an OTC is added to the profile, but the OTC meds are included in alert checking when a new prescribed medication is added.
Jose Costa Teixeira (Sep 05 2019 at 16:03):
@Melva Peters is there any reason here why we should capture MedicationUsage and not a Dispense?
Jose Costa Teixeira (Sep 05 2019 at 16:06):
The "where are we going to use this data" is (arguably) never a good starting point to say what resource should be captured. It can determine what resources may be exposed, but not captured.
Jose Costa Teixeira (Sep 05 2019 at 16:08):
why would the pharmacist care when these are used or what they are called as long as it doesn't affect their workflow? It seems to be a function of the PIS (Pharm Info System) that they are using, not the back-end FHIR data objects, that matter to the pharmacists. The PIS vendors need to get this right for their own individual markets and the FHIR (or HL7) technology that supports these systems needs to be powerful and flexible enough to support their information and product models.
I think this is reasonable way to express it.
Jean Duteau (Sep 05 2019 at 16:09):
In Canada, we distinguish a dispense from a statement based on whether there is a claim attached. We have profiled Dispense so that it must always have a prescription because that is how it is perceived in Canada. Dispenses are against prescriptions, Statements are not.
Jose Costa Teixeira (Sep 05 2019 at 16:11):
Does Canada support the cases where a Dispenses is done before a prescription is entered?
Jean Duteau (Sep 05 2019 at 16:13):
Not in any jurisdictions Melva and I have worked/consulted with.
Jose Costa Teixeira (Sep 05 2019 at 16:14):
It feels that statement/usage is too fuzzy. Are we taking about a "statement of dispense" or "statement of presumed usage"? Here is a use case: Patient says "I have been prescribed and dispensed this medication but I did not take it". I don't think statement supports this. I'm not saying it should support this, just to say that Statement is fuzzy enough NOT to be in in the middle of workflow, if the meaning is fuzzy.
Jose Costa Teixeira (Sep 05 2019 at 16:15):
Not in any jurisdictions Melva and I have worked/consulted with.
Ok, thanks. This use case seems a must have in any hospital workflow (and in community is quite common)
Jean Duteau (Sep 05 2019 at 16:15):
MedicationStatement - soon to be MedicationUsage - is a statement of presumed usage. Someone has recorded this MedicationUsage into a patient's record because they felt it was important for a patient's healthcare providers to know that the patient is using the given medication.
Jose Costa Teixeira (Sep 05 2019 at 16:17):
MedicationStatement - soon to be MedicationUsage - is a statement of presumed usage. Someone has recorded this MedicationUsage into a patient's record because they felt it was important for a patient's healthcare providers to know that the patient is using the given medication.
is _presumably_ using the medication. I understand. But this for a workflow is not clearly actionable.
Lloyd McKenzie (Sep 05 2019 at 16:19):
@Jose Costa Teixeira "Where are we going to use this data" is not only a 'good' starting point, it is the starting point. FHIR is implementation requirement driven not model driven. What matters most is where users typically see (and want to see) the information. That's far more important than a desire for theoretical consistency or model purity. If users don't want OTC stuff with the other dispenses and do want it with their records of "other drugs a patient may be taking", then that's where it should go.
Lloyd McKenzie (Sep 05 2019 at 16:20):
MedicationUsage can indicate that a patient isn't currently taking a prescribed med. But it's still in their record as something they 'might' take.
Jose Costa Teixeira (Sep 05 2019 at 16:23):
"where we are going to use the data" means "will this be used for workflow? for insuranec? for reporting? - that is that i mean. And one of my requirements is that data must be reusable, because those requiremetns will always emerge and we should be prepared.
Eric Haas (Sep 05 2019 at 16:30):
This round robin is similar to the debate we have with OTCs and self-prescribing in US Core. MedRequest describes what was ordered, self prescribed or reported, MedUsage is more about compliance.
Jose Costa Teixeira (Sep 05 2019 at 16:31):
this is from implementation of several use instances, and more or less evolving business requirements, not aiming at purity of a model. Rather avoiding rigidity or shortcuts based on a narrow scope:
If we want to do dispense of OTCs as a Dispense, then we should be able to. If HL7 is going to provide workflow orientations like "this is a statement" , they should not be based on the use cases that we had in Canada so far. if hl7 says "this may be a statement" then everyone is happy, i think.
Jose Costa Teixeira (Sep 05 2019 at 16:32):
If we do not have consistent and broad guidance, we will be having challenges and debates forever, or worse, every 2 implementations of FHIR will use different resources - as we had for v2.
Jose Costa Teixeira (Sep 05 2019 at 16:35):
the job of IHE is to prevent this. if we want to work this also in HL7, we can also work together.
Jean Duteau (Sep 05 2019 at 16:37):
If we want to do dispense of OTCs as a Dispense, then we should be able to. If HL7 is going to provide workflow orientations like "this is a statement" , they should not be based on the use cases that we had in Canada so far. if hl7 says "this may be a statement" then everyone is happy, i think.
But HL7 isn't saying that. If your implementation wants to treat OTCs as dispenses, then you can do that. If your implementation wants to separate Dispenses from Statements, then you can do that.
Lloyd McKenzie (Sep 05 2019 at 16:38):
When a drug is given to a patient, you have a choice of recording a MedicationDispense, a MedicationUsage, both or neither. When it comes to OTCs, in Canada the most common is "neither" - because the acquisition of the drug happens in a context where: a) there's no incentive to track it; b) the purchaser and the patient are quite likely not the same. The second most common is MedicationUsage because the only use-cases for tracking it is the useCase MedicationUsage is for - a desire to know "what meds is the patient likely on" - for drug-drug interaction checking. There's no notion of "compliance" with OTCs because there's nothing to "comply to". There's no need to monitor supply of the drugs because they're not considered sufficiently risky to manage them as prescription drugs. The only times OTCs would be tracked formally as a MedicationDispense is if there's insurance involved - which means there has to be a prescription. And if there's a prescription, the OTC is handled the same as any other prescription medication.
Lloyd McKenzie (Sep 05 2019 at 16:39):
IHE isn't going to change that business process - and shouldn't try. There's zero healthcare benefit to doing so.
Jose Costa Teixeira (Sep 05 2019 at 16:39):
Good. I reacted to an above statement. sorry for the snowball - but it is absolutely normal discussion in workflow. Wht is possibly seen as "modeling" from my side is more "let's analyse what we are saying to find the devil in the details"
Jose Costa Teixeira (Sep 05 2019 at 16:41):
IHE does not change a business process. IHE is very happy with this already:
When a drug is given to a patient, you have a choice of recording a MedicationDispense, a MedicationUsage, both or neither.
...
Jose Costa Teixeira (Sep 05 2019 at 16:43):
in whatever guidance we have on HL7, I would personally make sure that "prescribing after dispensing, even if OTC" is supported, and I would advise that it is supported in the same resources as "dispensing after prescribing, even if OTC".
Jose Costa Teixeira (Sep 05 2019 at 16:43):
There are surely more important workflow guidance questions, so I think this is OK for now.
Jose Costa Teixeira (Sep 05 2019 at 16:44):
MedRequest describes what was ordered, self prescribed or reported, MedUsage is more about compliance.
hmmmm..... not sure, but feels not critical
Grahame Grieve (Sep 12 2019 at 23:17):
@Claude Nanjo this thread
Last updated: Apr 12 2022 at 19:14 UTC
