I have already submitted this suggestion during the MEM v2 beta phase. However, I would like to submit it for the court of public opinion too.
I would like to see a Note field that is attached to a drug list item. This field could have Rx# and dosage placed in it. Or perhaps a better solution would to simply add a Rx# field and a dosage field to each drug item. However, even with Rx/dosage fields, I would still like a note field added for misc info.
Having a note field would be great, but I don't think I'd use a "pharmacist" data field. How do you even know which pharmacist fills the 'script? I looked on the info I get with my 'scripts and it only has the prescribing doctor name (and, of course, the pharmacy name).
The larger store-based pharmacies that we use always have the pharmacist name that filled it listed on the label or the description sheet that comes with the Rx now. However, I am simply wondering if anyone would use this as I'm not sure that I would myself. Nor would I know how to implement this as the pharmacist could change frequently, whereas the other info remains fairly constant. The other information fields are much more important to me.
group would be interested in or not, but what about a
field for which pharmacist filled the Rx? We had
notorious case here in KC where a pharmacist made
millions of dollars in part by watering down cancer
scripts - the Courtney case. Now I'm sure that
tracking the individual pharmacist in this case
wouldn't have made a difference because he probably
tainted entire batches of the drugs. However, I
wanted to toss this out for the court of comment.
LanMan,
Interesting suggestion; however, I can't see that this information would be of any significant use. I would hate to see too much "extra" data included in QMEM. Version 2 is already suffering from the underlying database changes. Scrolling and general navigation in Version 2 is quite sluggish. ;-)
underlying database changes. Scrolling and general
navigation in Version 2 is quite sluggish. ;-)
Wayward
Just remember that my speculation about the scrolling being caused by increased data complexity is just that: speculation. I've seen no form of confirmation of that theory in the forums.
Of course, my position has always been that I don't mind if the UI is slow, as long as it keeps track of the data that I need.
> to underlying database changes. Scrolling and general
> navigation in Version 2 is quite sluggish. ;-)
>
> Wayward
Tony Said:
Just remember that my speculation about the scrolling
being caused by increased data complexity is just
that: speculation. I've seen no form of confirmation
of that theory in the forums.
Understood. But if it's not the increased data complexity, then the cause of sluggish program response is of even more concern. This problem did not present itself in Version 1. My question for Quicken would then be, "If not the data structure what else changed?"
Tony said:
Of course, my position has always been that I don't
mind if the UI is slow, as long as it keeps track of
the data that I need.
I respectfully disagree. ;-) I purchased QMEM in December (too late to be accepted in the beta program ... but I asked) and entered all 2005 medical history over a couple of days. It was extensive due to a tough medical year for my spouse.
If the Version 1 interface had displayed the same sluggish response (scrolling, data entry updates, etc.) I strongly suspect that I would have abandoned the effort and asked for a refund.
I've given some serious consideration to reverting to Version 1 using the backup files. Unfortunately, that would probably create upgrade problems down the road.
All of that being said, I strongly feel that QMEM is unique in its market niche and has extraordinary potential. I don't think it's necessary to compromise interface for data structure. I have years and years of fairly detailed financial data in Quicken and don't see this problem. I deal with several excellent database programs (that's what QMEM is, after all) which have excellent interface response. :O
One more reason that I would like a Note field for the Drug list is that I would like to be able to enter the Brand>Generic or Generic>Brand names and the prices of one vs. the other for the Rx so that I can keep track of that info as well. A note field would also allow me to enter prices of various pharmacies so that I can price check them. With ever increasing or simply a lack of Rx insurance rates/copays it's very important to shop around and price check these days.
Okay, I know that you're sick of hearing from me about this, but Rx's are my families most expensive medical item to keep track of right now.
I would like to find a way to keep track of refill info. Some Rx's have Refill Until dates, and others have a set number of refills. I also need to keep track of Last Filled On dates, but I should be able to do that through the register that is already in MEM.
It would sure be nice if MEM could build some automation into this process. Such as when you have four refills on an Rx and each time it's entered into the system, MEM subtracts a refill from the total number remaining. Or it keeps track of your refill until dates and prompts you a month in advance of the end date. I suppose that a Note field and the built in Reminder function could take care of the refill until option, but it won't easily track the number of refills option.
I would like to find a way to keep track of refill
info. Some Rx's have Refill Until dates, and others
have a set number of refills. I also need to keep
track of Last Filled On dates, but I should be able
to do that through the register that is already in
MEM.
It would sure be nice if MEM could build some
automation into this process. Such as when you have
four refills on an Rx and each time it's entered into
the system, MEM subtracts a refill from the total
number remaining. Or it keeps track of your refill
until dates and prompts you a month in advance of the
end date. I suppose that a Note field and the built
in Reminder function could take care of the refill
until option, but it won't easily track the number of
refills option.
The one thing that I would like to add is that you'd also have to keep track of for whom the Rx is being refilled. If you have two family members on, say, Coumadin?, you'd need to know which one is being refilled so that you don't decrement the count, or reset the counter, on the wrong Rx.
This is why I recommended expanded Rx info to include
the "person" the rx was intended to be used (& yes I
know that some inter-person usage goes on).
I think that this is a good call, Barrie. There are occasions when more than one person in the family has, or has had the same Rx. Therefore, I agree that the Drug List should reflect which person that they are intended for. For example, adding a link to the People List when adding a drug to the Drug List. I suppose that a manual work around would be to simply enter the person's name in the drug name, but linking the person adds new reporting opportunities.
> This is why I recommended expanded Rx info to include
> the "person" the rx was intended to be used (& yes I
> know that some inter-person usage goes on).
I think that this is a good call, Barrie. There are
occasions when more than one person in the family
has, or has had the same Rx. Therefore, I agree that
the Drug List should reflect which person that they
are intended for.
I don't agree with this, and I was under the impression that this is different than what Barrie was trying to explain.
For example, adding a link to the
People List when adding a drug to the Drug List. I
suppose that a manual work around would be to simply
enter the person's name in the drug name, but linking
the person adds new reporting opportunities.
I think there needs to be a distinction made between a Prescription <Rx>, and a Prescription Drug <RxD>. A Rx is a relationship between a drug <most commonly a RxD>, a prescribing provider, and a person. As mentioned in another thread, the pharmacy that fulfills the Rx is different than the prescribing provider. The pharmacy is related to the Expense, not the Rx.
Thus, the Drug List would not contain any information per se about the person to whom it was prescribed, but would provide a linkage into the Rx set that contains each associated drug.
Under this scenario, the "inter-person" usage mentioned in Barrie's post would relate to a situation like this:
My daughter gets pink-eye... again. Her ped prescribes a standard med that he has prescribed to both her and her brother in the past <which only comes in quantities much larger than are actually necessary for one infection>. A day later, my son also starts showing symptoms. Whether or not we actually take him to the ped, we'd end up just using the remainder of the daughter's med to treat the son.
Barrie, I don't want to speak for you, so please correct me if I misinterpreted your meaning.
> > the "person" the rx was intended to be used (&
yes I
> > know that some inter-person usage goes on).
>
> I think that this is a good call, Barrie. There
are
> occasions when more than one person in the family
> has, or has had the same Rx. Therefore, I agree
that
> the Drug List should reflect which person that
they
> are intended for.
I don't agree with this, and I was under the
impression that this is different than what Barrie
was trying to explain.
> For example, adding a link to the
> People List when adding a drug to the Drug List.
I
> suppose that a manual work around would be to
simply
> enter the person's name in the drug name, but
linking
> the person adds new reporting opportunities.
I think there needs to be a distinction made between
a Prescription <Rx>, and a Prescription Drug <RxD>.
A Rx is a relationship between a drug <most commonly
y a RxD>, a prescribing provider, and a person. As
mentioned in another thread, the pharmacy that
fulfills the Rx is different than the prescribing
provider. The pharmacy is related to the Expense,
not the Rx.
Thus, the Drug List would not contain any information
per se about the person to whom it was
prescribed, but would provide a linkage into the Rx
set that contains each associated drug.
Under this scenario, the "inter-person" usage
mentioned in Barrie's post would relate to a
situation like this:
My daughter gets pink-eye... again. Her ped
prescribes a standard med that he has prescribed to
both her and her brother in the past <which only
comes in quantities much larger than are actually
necessary for one infection>. A day later, my son
also starts showing symptoms. Whether or not we
actually take him to the ped, we'd end up just using
the remainder of the daughter's med to treat the
son.
Barrie, I don't want to speak for you, so please
correct me if I misinterpreted your meaning.
-Tony
Both scenarios are correct.... The pink eye example has occurred in our house. Also, both kids use albuterol (in fact, the little one uses it more often than the older one surprisingly). We don't particularly care who's Rx applies to whom. We consider it community property as it lasts a fairly long time in our house. Whomever is sick at the time tends to use it. Does this make sense?
Hi, Bruce. It's good to know that you are looking to keep improving a product that has already proved very helpful to me. I really appreciate the effort that has already been made with QMEM and am looking forward to future releases as I believe that you will continue to make QMEM better. Hopefully Intuit will continue to back this product as it fills a great need in the industry. Especially with the boomer population hitting the age where pretty much everyone will need regular medical care.
Another thing that I really need to be able to track is the Rx's Expiration Date. Not the refill expiration, but rather the expiration date of the drug itself. This usually is labeled for one year after the Rx is filled. However, I was picking up some ointment for my son last night and I noticed that because it is a specially formulated compound it only has a shelf life (actually a refrigerater life) of about 4-6 months. Therefore, I will need to be able to keep close track of expiration dates for this as well as other Rx's. This should also work well with OTC's.
Another thing that I would like to be able to track in the Drug list is what type of drug it is, e.g. Pill, Meltable, Syrup, Powder, Nasal Spray, Eye/Ear/Nose Drops, Inhaler, Suppository, Patch, Gum, Injection, Ointment, etc.
And while I'm blue-skying, what does the group think about adding a "take-your-med" type of reminder to QMEM? In other words, a popup alarm that can be set to remind one to take their medication.
Another thing that I would like to be able to track
in the Drug list is what type of drug it is, e.g.
Pill, Meltable, Syrup, Powder, Nasal Spray,
Eye/Ear/Nose Drops, Inhaler, Suppository, Patch,
Gum, Injection, Ointment, etc.
Since many drugs come in multiple forms, I would think this would be a property of a prescription, and not the drug.
And while I'm blue-skying, what does the group think
about adding a "take-your-med" type of reminder to
QMEM? In other words, a popup alarm that can be set
to remind one to take their medication.
I really don't see the value in this since you wouldn't see the popup unless you're sitting in front of the computer at the time. It would, however, be valuable for Pocket QMEM. :-D
wouldn't see the popup unless you're sitting in front
of the computer at the time. It would, however, be
valuable for Pocket QMEM. :-D
-Tony
Actually Tony I tend to agree with you here. There is a very nice desktop/PDA app call OnTimeRx that will do this, but QMEM will eventually have all the info needed for this function so why not include it in the feature list. It could be a selling point for some. However, I would love to see a Pocket QMEM version and would buy it in a heartbeat. Come on Intuit and LandWare. Let's get to it! :)
Actually Tony I tend to agree with you here. There
is a very nice desktop/PDA app call OnTimeRx that
will do this, but QMEM will eventually have all the
info needed for this function so why not include it
in the feature list. It could be a selling point for
some.
Well, would you look at that. Another possible use of <url=http://www.quickenforums.com/message.jspa?messageID=100002759&tstart=0>data exported</url> from QMEM: updating PDA based Rx reminder software.
