|
|
|
|
Medication Management Module (proposal) |
|
| From: | Karsten Hilbert |
| Subject: | Re: [Gnumed-devel] Prescription printing in arbitrary countries and services. |
| Date: | Sun, 29 May 2005 22:02:20 +0200 |
| User-agent: | Mutt/1.3.22.1i |
On Sun, May 29, 2005 at 11:03:46AM +0100, Adrian Midgley wrote:
> For local reasons I feel a need for two things, here, which I will
> possibly write:-
>
> A way of injecting a prescription into the queue for printing;
>
> A way of printing an item from the queue and recording it has been
> printed.
>
> A prescription in this instance is a single item,
Ah, I see. My design idea on this would take separation one
step further (although it need not look like several steps to
a user in the frontend):
1) selection of "things" to prescribe into a queue
- "things" are (in Germany): medications, physical therapy
items, care articles (think Anus praeter bags etc)
- various sources, most prominently drugref
- arbitrary levels of selection support sophistication
- we are lacking most of this in GNUmed
2) generating a prescription
- pull items from the "prescribed" queue
- group according to requirements
- generate electronic "form" (in meta-format)
- put into "to-be-processed" queue
- we pretty much have the backend infrastructure to do this
3) output the actual prescription
- pull from queue in 2)
- generate final target format:
- may be a binary (say, PDF) ready for printing
- or an email
- or a fax file (say, g3 format)
- or a file to be stored on the patient's health card
- push to target transmission mechanism
Does that sound about right ?
> but up to three items
> can be fitted onto the same UK NHS prescription form (FP10)
Just like in Germany.
> It occurs to me that separating these functions, and the formatting
> information for an eventual paper form, from the business of picking an
> item and then recording it is a common approach, and if I managed to
> write anything useful it would be nice if it was re-usable.
IMO the more easily reusable parts would be steps 2) and 3). 3
even more than 2.
If you want to start FreeP working on those two aspects
(I would suggest starting with 3 and working towards 2)
you can count on me. You can surely use our Wiki to document
design decisions. The TORCH website features an RFC by Tyrus
Maynard on the issue which we should take into consideration.
Since I cannot find it anymore on the web I am attaching a
copy.
The aspect 1 should be approached from the GNUmed (or
rather any PM) side and from the drugref side (eg writing a
generic drug picker).
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Request for Comment Document
August 2003
Tyrus Maynard MD
This document intends to pull together concepts for a Formulary and Medication Management module in an Electronic
Medical Record EMR. Although relevant to any EMR software, the discussion is applied to TORCH :http://www.openparadigms.com
, an open source EMR software based on Zope which is evolving to include elements of practice management.
The sequence of presentation is:
1. Narrative regarding practice behaviors,protocols,and software tools to support Prescribing
2. Listing of Variables and Brief Database Roles for a Medication Module
3. Discussion of Design Specifics for certain Variables and Databases, whether deployed in relational
database or object oriented database
Narrative
The Current Formulary and Rx Writing Module
The current formulary concept of TORCH in July 2003 includes a picklist of Medications that can populate an
individual prescription input form . The completed prescription display is signed with password input and the prescription
is attached within the individual health record - an object file which contains all the data and attributes generated
during various types of encounters.
The "formulary" is a separate object file with medication entries; it functions as a picklist to populate
an entire prescription item/event. In reciprocal fashion when a newly completed prescription is "saved"
into the formulary, it is appended into the formulary object file for future recall. The picklist can be filled
"en masse" or by individual new entries during actual practice. The picklist can save the entire prescription
event including the "Sig." dosage instructions, but the demonstration formulary file contains object
records that may (and often do) lack an associated Sig. attribute/field. This mixture of completeness in the current
"unitary" picklist stems from it being populated first as a reference list. Such population as a formulary
traditionally does not contain any fields representing Sig. instructions.
Later in the software design it serves as a picklist for prescriptions, able to hold a record of complete prescription
objects created from an Rx Form. In this capacity, a Sig. field is retained if "Saved" at the Rx input
form, and the Sig. field is as diverse as the free form text composed at that Rx Form. Although a saved Rx form
is divided into some attribute/fields the Sig. field itself is not uniform for assigning any mathematical value
which can be used to calculate drug dosing and timelines for medication supply.
Duty of Primary Picklist
Some discussion has occurred on the TORCH mail list archive in June 2003 under the subject "Dual Level
Picklist" . A proposal in that discussion was to maintain a large primary reference list of medications that
is inert except when periodically mirrored from an outside source.
http://www.topica.com/lists/torch/read/message.html?mid=1713534719&sort=d&start=136
A duty of the primary picklist would be to carry at least generic name (with proper spelling), medication
class and class description , delivery mode, packaged unit dose (manufactured unit). In a proposed primary picklist
for TORCH (as in most formulary lists), any attempt to store a recommended or commonplace Sig. field for a given
medication entry would be conspicuously absent.
Anonymous User - Sep. 2, 2003 4:43 pm: A fairly extensive formulary of generic names with exiting available dosage forms would help speed up medication entries and allow business logic to check for known interactions with other prescribed medications for a particular EMRClass. Sam Bowen, MD
Derivation/Use of the Term "Sig."
Although the term Sig. derives from "signature", in the realm of pharmacy it has meant more than the
mere signature. It is the practitioners individualized medication plan for a patient ...the instructions as to
how much to take, how often,when, and in what manner. The Sig. is underwritten by a "signature" and applies
to a stated name and packaged unit dose ( which the Sig. modifies with any dose multiple statement). An Rx. Sig.
should be tailored to the circumstance of the individual patient and problem and probably should not be easily
applied to another patient circumstance without study.
This is the inverse of the Sig. as recently used in email and internet communication. Such an identity handle is
configured to a single individual and readily repeated in multiple communications. Sig. as a "handle"
is used to impart unique identity and is used in automated habit; it probably becomes more valuable with use that
propagates the identity. The concept of Sig. in prescribing probably should be questioned over extended
use, should not blend unique patients into excessively habitual practice, and probably becomes less valuable with
habitual use.
Anonymous User - Aug. 7, 2003 12:47 pm: Regardless of etymology, "sig" means "label directions," and no longer has anything to do with the prescriber's authorizing signature. The label directions for medications are highly ritualized, and so are appropriately available as picklist boilerplate, both to reduce redundant typing and to avoid accidental errors via typos or forgetfulness. (e.g., 1 qid, 2 tid, etc.) But often some of the label directions are customized for the patient, so if any boilerplate is used, it must be easily edited. In addition, it is appropriate to include in the label the diagnosis, symptom, or condition for which the medication is prescribed; for example, warfarin 1 tab daily for atrial fibrillation; propranolol 1 tab twice daily for agitation; neurontin 2 caps at bedtime for foot pain ...and so on. Future prescription regulations are likely to *require* us to include the diagnosis, symptom, or other indication with the prescription, and this will not always be appropriately part of the label directions. Dan Johnson md
Anonymous User - Aug. 7, 2003 11:55 pm: In this document I contend that there is little value in saving a Sig field for repeated use in association with a medication name. I advocate a picklist for the discrete patterns of Sig that have meaning for assigned value in calculating medication timelines. I advocate a supplementary free text field in the Rx form that wouldnt be consulted for any calculations but which could express some of the details that are described by Dan Johnson. At present I think of such supplements as being diverse enough that I would not want to have a picklist to fill fields; and in the case of things like symptoms should often be expressed in the vernacular of the patient , which can be very diverse. If the day is coming as described, a field for diagnosis would seem to be best delivered in terms that communicate to other professionals and a picklist could/should include active diagnoses on the problem list (and the current diagnosis if it is not yet graduated to the active problem list). Based on the future described ,this sounds like two more variables to be named and "filled" in the Rx form in a Med Module for TORCH. Tyrus Maynard MD
Anonymous User - Sep. 2, 2003 4:48 pm: The I define "Sig" is closer to Dr. Johnson. It definitely has at least 2 fields. The first field is (1) 1 pill two times daily. The second field is (2)a common english explanation to the patient as to why he/she is taking the medication. Certainly a formal diagnosis field (3) would be easy to add and useful for more sophisticated users/patients/third parties/Big Brother etc. Sam Bowen, MD
Anonymous User - Sep. 3, 2003 2:53 pm: Definitions aside, the use of the Sig is as above, and I use it this way, but the directions for taking a medication is not usually as flexible as we are talking here. For example, It is unusual to give most extended release medications more than once daily, so "one tablet by mouth daily" is all you will write, with very little variation. I feel that an editable boilerplate would be a good solution to save time, and prevent errors. ( like inadvertantly telling a patient to talk 1/2 tab of a 'structural release' medicaion, ie Oxycontin) but the ability to edit this field is a must as it will come up. Most medications are given all patients the same way, based on the half life of the medication, with the exceptions being few, but noteable, ie renal failure.
Anonymous User - Sep. 12, 2003 5:11 pm: While most drug companies prefer that the extended release formulary be given qd clearly a number of the qd drugs can be broken in half and taken 1/2 pill qd to save money for the patient. Most are not intended to be crushed. Sam Bowen, MD
Duty of a Working Picklist (redundancy with EMR?)
Before mourning the proposal that Sig. should be banished as a stored field in a primary picklist of medications,
the reader should be reminded that TORCH provides for retrieval of a given prescription directly from its object
as stored in an individual EMR and editing can be applied before renewal of the medication. Storage of Sig. field
in any picklist is somewhat redundant at least for medication refill in view of the existing EMR. The corollary
question is whether Sig. is valuable to store in "any picklist" location other than an individual EMR
(from which ongoing medications can be renewed in an individual context)? It is possible to conceive of a more
closely managed picklist which could be referred to as the "working picklist". Presumably a smaller "working
picklist" would be fully understood because of informed use and would be a frequent ergonomic aid because
of frequent usage.
It is proposed that a "working" collection of Sig.s should be very small if not linked to additional
expert information such as PDR (Physician Desk Reference) or other reference texts. The moment of composing a Sig.
should be a reflection on all prior practice experience (including other EMR's) and information systems that are
available. Plainly, the speed acquired by having a bank of Sig. fields residing under certain drug names may not
be worth the habit that is reinforced by maintaining the working collection.
It is proposed that a picklist of Sig. fields should not reside with drug names, but should
simply be offered as picklist of "patterns" to compose the Sig. field. The patterns can be offered locally
at the RxInput Form, and in this location a Sig. is a generic pattern not automatically associated with any medication
name. Such a placement honors the mandate of ergonomic efficiency which is partially driving the wish for a picklist.
Offering discrete choices of Sig. also helps to avoid the proliferation of many variations of free form text
to describe the same instruction.. Such a generic Sig. is not an offering of links to stored treatment suggestions
for any given medication.
Anonymous User - Sep. 2, 2003 5:13 pm: I tend to agree with Rusty above in that the main "pick list" need only contain the generic name (optionally common brand names) and known dosage forms. The "sig" field can easily be added as part of the torch business logic with a drop down box of common options to be entered (ie 1 pill bid) and a free form text box for a common english explanation. Optionally another field could be used for the actual diagnosis. Sam Bowen, MD
Sig. Field for Ergonomic Speed or Component Data
Providing the finite picklist of generic patterns (instead of providing the pattern in association with
a medication) also accomplishes the larger mandate for a Sig. picklist. Each pattern can be associated with
specific factors for background calculations of daily dose count, the daily intake in terms of unit of measure
(mcg, mg) and supply in terms of duration of treatment. In pediatrics and geriatrics the daily total intake is
the springboard for prescribing and the Sig. pattern is an elaborated means for customized delivery of that dose
in the patient's environment. TID and q8hr have the same dose rate for 24hrs and over a course of treatment.
More than offering speed, the offering of discrete choices for Sig. allows translation into mathematical
terms (? how much? how often?) It is essential to record the component parts into a database regardless,
for one overriding reason. It is not possible to estimate chronic dose exposure or cycles of medication depletion
without applying consistent algebra. A Sig. field which is not parsed (or broken into parts a priori) is of no value.
Just as the patient must parse the instructions, so must any system of quality control or chart audit.
Although a position has been taken against storing Sig. fields in association with medication names,
it must be remembered that extensive information exists on medication dosage range. It would be wrong to
reduce that information to a list of common Sig. fields when the information is really a range from a low
dose shown to have some effect and a high dose shown to have at least some tolerance and freedom from side
effect. A dosage range is often stated in units (mg or gm) per 24 hours and the Sig. is a
method of intake adapted to the characteristics of uptake and also diurnal and eating cycles. If such
a dosage range is stored with a medication range, then it can only be compared to an actual prescribed event if
a Sig. field is translated into mathematical terms.
A pattern picklist for composing a Sig. field may have ergonomic benefit,but the real
importance of picking Sig. from a pattern list is that the patterns are uniform discrete choices that can be assigned
value factors in advance for calculating dates of drug depletion or dosing over time. This is preferred over the
same in free form text that is otherwise understandable to a pharmacist and a patient.
The Primary Duty of of all Picklists - accuracy not speed
It is already proposed that picklists are only limited information systems; it may be more proper to say that
picklists are identified objects that have meaning in an information system that resides elsewhere.
Therefore, the main duty of a picklist is to enforce accuracy at the time of data entry. One form of accuracy is
the certainty of choosing from an approved pool, even if very large...eg. FDA approved.
An additional value in a formulary picklist is to treat unit doses as individual inventory items in which
each packaged unit dose and unit of measure is permanently joined to a medication name. This storage of "Atenolol
50 mg." as an inseparable information string and a single inventory item is more valuable than the joining
of any Sig. field to any medication. Such storage is more likely to prevent gross prescribing error when
deployed in the writing of a customized Sig. Of course the information need not reside in a single
data string as long as the two strings of name and packaged unit dose are stored in a single record
in a maintained file. The individual records for each unit dose also serve as a reminder of the increments of dose
choice available in the marketplace. Multidose sizes enter the market place based on dispensing patterns (as long
as patients shun swallowing multiple pills to achieve a given dose).A primary picklist is most important in the
accuracy of the entry when a new data object is created. For a name, spelling is the concern, allopurinol vs. alopurrinol.
For a packaged unit dose, a number and unit of measure is the concern , 40 mg vs. 40gm
Accurate spelling is the key for search fields in external information systems and for automating local search
for matches to warnings ...such as allergy warnings stored elsewhere in an EMR. So far, discussion has only centered
on making a new prescription object accurate, but a picklist should also be employed when creating a new
allergy record so that software parsing tools can be used for dependable warnings. Fuzzy search may be a helpful
adjunct in matching for retroactive study, but the power of allergy records is enhanced by enforcing proactive
reference to a formulary picklist (or a background spelling check against the same list).
Other Functions of the Prescription Event
The Prescription as a Timer
Once a chronic medication is shown to be beneficial for a given condition the next concern in writing a prescription
is to identify the timeline for monitoring the condition. The quantity of medication dispensed is usually an enforcement
mechanism.. Sometimes a refill is set for an interim report by phone which can be optionally upgraded to an in-office
visit. Sometimes reporting is also concerned with compliance questions, and it may well be that neglect of protocols
occurs when patients perceive that inquiry is not mandated. Though the algebra is simple, multiple medications
with differing unit doses, (sometimes halved, sometimes doubled in the Sig. field) are a distracting aspect of
a patient visit. The dialogue should be about the reasons and goals for reporting back, not the details of when
medication will deplete according to the algebra. Where clinics have an in house pharmacy it is often preferred
that the Sig. field actually coopt the statement of quantity dispensed and state the supply in units of time rather
than quantity of doses. The pharmacy dispenses based on an extended Sig. " one tablet BID for 4 weeks"
(dispense 4 week supply at prevailing Sig.)
With computer resources underpinning an EMR the tedious algebra should become a diversity of input choices
and calculated display. Quantity could be input by timeline and the computed quantity of doses would be displayed
rounded to some standard increment (many practitioners dispense 100 for a month of TID doses). If timeline and
Sig. are used to dispense then calculated quantity should be displayed, but the converse is true also...if quantity
is prescribed, then timeline should be displayed to the practitioner and also routed to other programs in the medical
record.
Cumulative Discrepancy
A variation of timeline statistics is the attempt of a provider to confirm when a prescribed treatment results in requests for early refills or replenishment delays. Such calculations are especially meaningful when prescription refill requests are received in a hasty context by phone and out of phase with regular followup. At the time of any refill or simply during a chart review, the current date should be the basis for estimating and displaying a quantity of time or of doses remaining (or a time period of presumed non treatment following depletion). Over multiple prescription periods a cumulative statistic can also be maintained, for either passive display within medications lists ....or for threshold alarms triggering followup.
Timeline Linked to Staff Protocols - Renewal vs. Refill
Often the physician and or an immediate [assisting] nurse are the only staff concerned with review of medication timelines.
It often appears that the mandate for a schedule of refills comes only from patients who may only be able to purchase
in small increments, according to cash flow. Another worthy (but undeserved) mandate for a refill
event could be to obtain patient information , but a "refillable" prescription carries no enforcement
method to document patient circumstances. For purposes of discussion let's define a refill that is accompanied
by a report of patient information as a "renewal" , and any thing else as merely a prescribed,permitted
"refill". Let us also emphasize that "No Refill" is not a gateway to
a renewal protocol.
If electronic prescriptions have reduced the clerical burden of renewing "solitary"
prescriptions, then tools should also be devised to link a "continuing" medication to a "renewal"
protocol (instead of the traditional "refill" protocol, which prescribes the refill permission in advance).
Patient actions on "refill" are actually remote and unmonitored in most practices and almost never generate
any information about the patients condition. Presumably a "renewal" protocol would be devised for patients
requiring more scrutiny, both for the benefit of patient and to minimize liability to practitioner.
If a medication has been declared "continuing" in a renewal protocol and uses a model
of the patient initiating the call back report, then the timeline of a chronic medication dictates
a daily or weekly allotment of followups for any recalcitrant patients (those who have not called). This could
consist of generated reports with contact information and medication lists. This could also evolve (or devolve)
to automated mailings, emails, or phone contact.
As to the value of personal contact,it can be argued that selected patients can readily be consigned
to report to a clerical staff person for a standard,scheduled renewal in which a visit requirement is not presumed.
The act of reporting and of not expressing a self referral for care is some documentation of compliance and a stable
status quo. The charted report by a clerical person, can be merged into other tools for review of EMR and renewal
of Rx by provider.
Anonymous User - Aug. 7, 2003 1:05 pm:
This paragraph is difficult to parse.
- do you mean "nurse intermediary"? I'm not sure what an "immediate nurse" is.
- is "medication timeline" a euphemism for "dates of actual refills"?
- "mandate for a schedule of refills" is confusing.
A "refill" behaviorally is the attempt by the patient to get an empty
pill-bottle refilled by the pharmacist. As all prescriptions have an expiration
date, either indicated by the prescriber or fixed by law, when the patient asks
the pharmacist/chemist for a refill, it may be necessary to seek a new
authorization from the prescriber before refilling the bottle. We docs call
these requests "refills" but in reality they are prescription "renewals",
whether or not there is also a patient visit and evaluation.
Typically, chronically used medications must be refilled periodically. Medications
needed only sporadically (e.g. pain meds, asthma meds) go out of date and must
be refilled then even if a new authorization isn't required. Third party payors
often limit patients to a 1-month supply, requiring monthly refills of
"continuing" medications.
It may be appropriate to include in the prescription a message to the
pharmacist that physician eveluation is required for renewal of the medication
beyond a certain date. This may or may not belong on the label ("sig").
In this regard, I often write personal communications to the pharmacist on
prescriptions, indicating that the prescribed medication is replacing one or
more others, or adding a note about medication allergies or intolerances.
Dan Johnson md
Anonymous User - Aug. 7, 2003 8:36 pm: Thanks for pointing out the ambiguity in "immediate" nurse , I will add "assisting" in brackets. The key to the paragraph is the last 5 words "renewal of Rx by provider", if one considers that the discussion above that is about the flow of information to that provider. In other words a renewal protocol begins by not authorizing any refill , but it does not burden the patient and staff with ambiguity (despite any ambiguity in this document). The intent of the Provider to consider a "renewal" is documented for all parties to administer the flow of information to the provider who acts based on receiving it. It is proposed that a "renewal" protocol carried out by practice staff should be suppported in TORCH software. "For purposes of discussion" , refill is an automatic process that historically is not designed to gather information. I also do not advocate trying to get information from pharmacists by any supplementary note on an Rx that allows "refill". When refills are prescribed, I consider them to be permitted and not a means for intercepting patient information. The intent of the paragraph is to provide tools in software that aid a "renewal" process as used in this discussion (with all due respect for those who may view a refill to be renewal.) By this or any other name ...."renewal" is defined in this discussion as a process of quid pro quo ....for information flowing to the provider with the aid of office staff, the provider decides whether to issue a solitary new prescription (using an efficient open source prescribing software of course) . Obviously medications invited to a "renewal" protocol are intended to be "continuing" within certain boundaries of knowledge ...many of which do not require an office visit or an encounter with the provider. If a flow of information is needed, then the module to provide it is proposed for an efficient open source software that can be customized to a given practice. I don't expect closed source software to be able to design this for practices (and this document advocates without casting a final design), the design will evolve in practices starting with open source. Tyrus Maynard MD
A Baseline for Discussing Cost
A common barrier to discussing cost of medication is the view that retail purchase is up to the patient shopper
and the practitioner does not have a current knowledge of such costs. The advantage of a primary picklist database
derived from a practicing supply pharmacy is that costs are known for an inventory such as at the Veterans Administration.
Large purchasers may have favored prices, but the published datasets can serve as a relative _expression_ and a baseline
for cost. http://www.vapbm.org/pbm/primevendor.htm
To convert a baseline cost into a real world retail estimate, local price samples can be reviewed in the way that
a sample "shopping basket" provides a Consumer Price Index for adjusting the value of all consumer goods.
Most distributor markup is a percentage "across the board" for ordinary inventory items. An adjustment
factor can be applied to all of the base prices at least for purposes of comparing medications in a class or estimating
all monthly medication cost. Based on subsequent patient reports, individual medications in the database can be
toggled to retain a "specific retail adjustment" factor instead of using a "pooled adjustment"
factor. Even an ongoing survey of a "shopping basket" can be maintained by the patients themselves, perhaps
by a workstation running the software module where patients report into a reception area.
Such interactions have therapeutic value at least in showing that cost is not "of no concern" to a practitioner.
Software has the ability to make this a discussion instead of an extended math exercise.
Listing of Variables and Brief Database Roles
Variables for Medication Management Software
The following table describes variable names for purposes of subsequent discussion of specific software
modules attending to the narrative above.
A few of these variables would be mapped to the published VA formulary system which could be mirrored as a
"primary database" and picklist as described above.
The term "variable" is used to mean both "fieldname" in traditional relational
database record or an attribute or property as used in an object record. To enable later discussion, the
variables are grouped in topical regions, but that is not intended to declare specific segregation into any solitary
database. Databases are sometimes joined in hierarchies which are more efficient for certain purposes.
The term database is intended to mean collections of records whether a record is visualized as held in a row of
a database table or contained in an object.
BASIC VARIABLES
genname txt generic name
packudose num packaged unit dose
packumeas txt packaged unit of measure
packutype txt packaged type (cap,tab,oint,sol,emol)
deldev txt delivery device (neb,injector
delmode txt mode of delivery (PO,IM,SQ,IntraNasal,IntraOral
catprime txt primary category inherited VA
unitcost num VA derived cost packudose (may be fractional $ = 0.0723)
dateenter date date acquired into Primary database
source txt source of entry (VA,localMD,newFDA)
LOCAL SUPPLEMENTS (Brand or Cost)
brandnm txt brand name
writebr toggle specify "brandnm" in Rx form
lclunicost num local unit cost factor from "shopping basket" surveys
specifcost num specific cost to override survey factor
catexpand txt replace expanded category def (otherwise=catprime)
catcondens txt replace collapsed category def "
SIG COMPONENTS Foreground Factors
sigux num unit dose factor (1/2,1,2)
(multiplies "packudose")
sigchoice list discrete sig choice picklist
nameday list sub picklist for day of week pattern
sigext list extended instruction picklist
(AC,PP,AC and HS)
freetxt txt free text supplement instruction
SIG COMPONENTS Background Factors
sigperiod num time period explicit or implied by Sig
sigdayfact num per day sig consumption factor
(derived from sigchoice)
PRESCRIPTION EVENT Basic
rxdate date date of Rx
rxname string forced identifier EMR
rxrefill toggle Yes No
provsig txt provider name
signoff toggle signed off status
refillnum num number of refills
refilldead date sunset date for any refill
PRESCRIPTION TIMELINE Prospective for Input (Rx Leash)
inquan num input quantity of packaged unit doses
altday num alternate input as days
altweek num alternate input as weeks
altmo num alternate input as months
quant num calculated final quantity for signature
datestop date stop order prior to depletion
dateout date calculated date of depletion
TIMELINE Display and Review
(per Rx med name- carried in last Rx event)
queryall toggle to auto carry a timeline review for all meds in EMR
reachbkdef num reachback default value (for auto query)
today date todays date
p_rxdate date prior Rx Date
p_pkudose num acquired from priorRx pkudose
(pkumeas mg. gm etc is inherited by cumnum)
useddays num number of days used
numremain
cumremain num expected remaining dose units in prior dispensed Rx
cumarrive num accumulator arriving (from immediate prior dispensed Rx)
(express as pkumeas (mcg.mg.gm etc)
(acquired from prior Rx event)
cumfwd num cumulative excess value carry forward in Rx object
cumarrive + cumremain (converted)
(convert to express in pkunitmeas (mg. gm. etc)
( Ad hoc query - result stored to Rx object or EncounterNote)
EMR ID# num selected and known during encounter
genrev txt generic name for query request (input)
reachback num number of past Rx events to include in review (input)
reachdate date date of start in First Rx event (acquired)
COST DIALOGUE
unitcost num mirrored from lclunitcost in WorkDB
(or specifcost when known and added in WorkDB)
rxcost num calculated cost of the Rx current
costpermo num monthly total cost for med at Sig rate
RENEWAL PROTOCOL (in-house)
rxrenew toggle yes no
renewtype string longterm,longterm episodic,
typecont string phone,minivisit,withBP,online,survey
(each of these types implies a protocol)
whofrom string name of agent (may not be patient)
fromis string relation of agent
whoto string staff contact (may be implied in protocol)
dowhat string probably implied by typecont
briefask string succinct question or reminder
(to be administered by staffperson)
cutoff date sunset for any in house protocol
Anonymous User - Aug. 7, 2003 1:08 pm:
I have run out of time to review and comment; I will only say that some of
these variable names are cryptic, some variables are specific to the VA and to
the particular practice of the author.
I would suggest reviewing the variables and their function with a view to
making them more universal, more general, and flexible.
Dan Johnson md
Anonymous User - Aug. 7, 2003 9:57 pm:
The variable names are offered as a basis for discussion ... though somewhat
cryptic like many variable names, their meanings are expanded a little in the
section above.
It is proposed that the following would be derived from the VA database in
order to populate the database called PrimaryDB:
genname ,packudose , packumeas, packutype, deldev , delmode ,
catprime, unitcost (those variable names are not used at VA)
The variables were named to aid specific discussion on module design (they may
not be the best named aids and can be changed when the time is right based on
discussion). They are proposed for software in a practice that is
hypothetical..it is particular in that I am advocating some things...and asking
about certain things. Giving variable names may help discussion on specifics
proposed (such as mirroring the VA database in a Primary Database,tools to sift
that down to a Working database, calculating medication timelines from discrete
Sig patterns)
Tyrus Maynard MD
Brief Database Roles
Note the "TRANSITIONAL" status of all Sig. field components between either Working Database or Prescription
Database
Primary Database
Carries the "Basic Region" variables
duty to mirror source DB (in this case VA)
serves as common definition of correct spelling
serves as common definition of name and associated package unit dose
index keys and sorted displays by genname name and catprime
rare entry of BrandName must still include a generic name field in the entry
(parallels with VA tradition of generic use except by replacement in the negative
see VA Negative formulary: http://www.vapbm.org/natform/negativepolicy.pdf)
where VA formulary may lag, new entries which are added should be flagged for later synch to VA
Working Database
subset of the Primary Database repeating all " Basic Region" variables
all entries carry genname key for index and reference to Primary Database
carries local preference (including specific BrandName "brandnm" entries)
repository of "shopping basket" local cost data
spelling check maintained by reference to primary database
no record entry allowed without sibling record carried in primary database
TRANSITIONAL
all components of Sig. field Foreground and Background
discrete patterns are basis of calculation for dose exposure,timelines,cost estimates
(should these variables reside in a database or only as a dictionary local to the code
routines which
serve the Rx Input Form ?)
Prescription Event
Database
key and index on genname
key and index on EMR ID
key and index on provsig , provider
If RDB, then this should pool all prescription events otherwise dispersed-
-into individual objects residing in EMR's. Requires added field for patient ID.
If ODB, then method needed to harvest object records from existing EMR's
carries all Basic Rx variables to compute and accumulate Timeline
if all Renewal variables not carried, then must have key to Renewal DB
if Timeline Audit not carried then key to Timeline DB
carries at least the toggle for Renewal Protocol
Timeline Display and Review
key to ID
key to date
key to genname
most valuable for "numremain" when asking during refill request to state number remaining
Cost module
key to pt ID
representing current prevailing cost per wk per month etc.
Renewal Database
key to pt ID
key to genname
key to typecont, which implies the in house protocol for trained staff
RDB vs. ODB
Either a relational database RDB or an object database ODB, along with other software logic, could carry out
the designs to address the software services discussed in the narrative, but a brief discussion of relational databases
and object databases is appropriate. In the lexicon of variables above, some variables might simply hold information
for future reference in an EMR ; others might be the subject of sort or index in order to display choices or reference
other databases; some variables might contribute to another computed variable; some variables might hold a value
as a gate/switch to call another module or service. The name variable is used to include both fieldname in a relational
database record and attribute/property contained in a object record. It must be remembered that some
of the variables may be sufficiently provided for within the program code as a short list or a short dictionary
of keywords, and as such, may not require residence in a separate file that is perceived as a separate "database".
One factor is the pre-existence of a maintained source database which is to be mirrored into the "primary
picklist" already discussed. Such a source database is commonly maintained as a rigid relational database
as is the case with the VA formulary. It seems expedient to to mirror these variables into an RDB available
to TORCH programs as a backend database. SQL capable databases are ready for the task and the RDB as a reference
can be managed separately from TORCH..
A practical reason for maintaining the variables in a backend RDB is the availability of programmers familiar with
SQL language, and there is temptation to consider the deployment of other relational databases
containing more than the traditional formulary fields. Such relational databases could be used
as the repository for all the variables itemized so far and also for a database archiving the
individual prescription events. In the current TORCH, if prescribing patterns are to be examined across EMRs or
across diagnostic categories, then each prescription record must be gathered from places of chronologic storage
in each EMR. The variables which comprise a prescription record are as well defined
as those for other aggregates such as name, address, city , state, zip, which are classical for
an RDB. If an RDB is deployed once as a tool within TORCH , then the larger question is
where to not deploy? If an RDB is useful once in a Medication Management system then where
is it not useful for well defined data?
A practical reason to not maintain an RDB in parallel with the object oriented environment
of TORCH would be that the variables for questions and study across EMRs may not be anticipated. However
the variables described for medication management can possibly be sufficiently defined in advance in order to deploy
either type of database. TORCH is already highly evolved for aggregating data elements to create documents
which represent a patient encounter , and this includes a prescription document. Since
the TORCH interfaces have been mainly developed for generating and retrieving an ongoing patient
record, the challenge for its underlying object database is how to offer query tools and
particularly query tools that aggregate statistics across EMRs. Zope and the object
database (ZODB) already provide search in free text of documents across individual EMR collections,
but this is not statistical reporting on variables per se.
The question which an RDB alternative poses for future of TORCH could be stated: Is there a query language or a GUI driven query interface that can provide the equivalent of SQL for the ZODB?
Primary Database (PrimeDB) Mirroring
The PrimeDB would be relatively large and with few stored variables (the Basic region above). Most would provide
a local mirror of the variables and values maintained by the VA Pharmacy Benefits Management office. The formulary
databases are available at http://www.vapbm.org/PBM/natform.htm
This serves as a large reference collection of generic medication names to maintain accuracy and uniformity in
prescriptions dispensed and search queries employed for any medication management.
Once a given Prime DB functions as a reference for a period of time then there are concerns when it is updated
to mirror a new VA source. At such an event, it seems reasonable to first parse the existing PrimeDB for any differences
not found in an incoming VA source. These prospective omissions should be considered for deletion only after parsing
existing allergy lists for the presence of an allergy name that depends on the entry in PrimeDB considered for
deletion. If PrimeDB is to carry the common parsing definition for warning of allergy to a new medication
pick (from WorkDB or PrimeDB), then no entry should be removed if already represented in WorkDB or AllergyDB. PrimeDB
carries the final reference for all spelling checks and allergy matching, so it should be indexed for genname.
Another way of describing the uniformity duty of PrimeDB is that no Rx event and no Allergy
event is recorded into an EMR nor any record added to WorkDB without reference or addition to PrimeDB. Reference
can be accomplished either via a picklist or background confirmation search on "genname". Referencing
is an improvement on even the most conscientious keyboard entry of free text in a fieldname and the need for fuzzy
search tools is reduced. The addition of multiple entries into PrimeDB with slightly different generic name but
similar molecular species would diminish the value of PrimeDB in this final reference role.
This means that named additions to the database are inherently risky if such can duplicate an existing species.
This is not an issue unless an allergy value is already stored under a duplicate or deleted generic name.
Thorough retention of all current database entries which match an existing allergy value is
only a means to retain future opportunities to recognize an existence of duplicate entry within PrimeDB. If the
entry is deleted entirely, then all future possibility of recognizing functional duplication of a molecular species
is missing. Duplicates, the crux of the problem, are the reason that additions to the PrimeDB should not be casual
or "on the fly" events. It may be valuable to archive those entries retired from PrimeDB which are believed
not represented in WorkDB or AllergyDB.
Catprime would be mirrored from VA source and it is assumed that VA categories are
consistent, but when refreshing a mirror, it may be worth parsing the associations of catprime and genname to identify
changes in VA category assignments between the data of an old mirror and an incoming mirror. A completely new entry
would be one sourced from VA and differing in any of the Basic Variables.
PrimeDB should allow entry of medications beyond the juried VA formulary, in which case generic naming should prevail
and the source authority should be recorded for the entry. Probably such entries would be small in number on the
authority of person agent (practitioner) rather than imported as a mass of records from another reference
archive (in which case the source is an institution). Entry of new drug items from VA or any source should
be noted for date of entry into PrimeDB.
Because PrimeDB is large and is the keeper of unique combinations of the inseparable genname,pkudose,and
pkumeas, its index will be frequently referenced regardless of how often it is employed for a pick. It is important
to maintain index and sort on genname and the category description.
To further align categories with the practitioners functional use of categories, additional field variables should
be provided to extend (catextend) or condense (catcond) the initial VA category values. An additional category
field should also be provided for supplemental or new categories (catnew) to be defined. Sorted views and indexed
search on category would be desirable for such a large list. If PrimeDB is rarely used as a picklist, then these
same category extensions and search tools could be deployed only into WorkingDB.
Working Database (WorkDB)
A WorkDB can be built incrementally during practice, or it can be populated to a meaningful size by initially
reviewing the PrimeDB for all familiar medication entries regardless of when use of the medication is expected.
For such direct populating, a pick method must be defined that supplements the existing method of saves from the
RxForm. Of course entries populated from the larger PrimeDB will not contain a Sig. field (and it is proposed that
WorkDB should not be employed to save Sig. fields from individual RxForms either). A method of populating
WorkDB from PrimeDB should be available as a side routine during the composition of a prescription,
because a given medication may not be already provided in the Work DB. By the same reason that
WorkDB serves as a buffer dataset between the PrimeDB reference and composition occurring in the Prescription
form, it is redundant to "save" into WorkDB from a Prescription form. Presumably the picklist of
WorkDB would be maintained by a dual level pick process - pick from WorkDB or request "more" to
pickfrom the larger PrimeDB (and automatically include into WorkDB).
By embracing the model of an exhaustive reference formulary, TORCH would be moving away from
its earlier practitioner centered mechanism of saving a single prescription event as a template for other
prescription events. The model has moved to a finer definition of inventory parts that must be assembled
into that event. As already presented in the earlier narrative, Sig. fields are not consider a part
of the formulary inventory, but are instead patterns stored separately for driving the logic of medication
algebra.
It is proposed that the WorkDB would be keyed on genname and be the holder of supplements
to the data found by reference in PrimeDB. WorkDB would include variables such as, decision to "print"
a BrandName (writerx), the BrandName itself (brandnm), and local retail pricing information .
In a dual picklist procedure either PrimeDB or WorkDB can function as a picklist , as long as PrimeDB maintains
its status as a the referee for allergy matching.
Prescription Database RxDB
It has already been described that the storage of Rx forms and related variables is accomplished in TORCH in
each EMR and these can be further mirrored in an ongoing relational database once the salient variables are defined.
This is storage of a recurring group of variables through time. Storage within EMRs is dispersed in object records
within multiple EMR object files. The EMR already contains pertinent attributes of current age and weight and the
record of allergy.
It accomplishes little to mirror Prescription events into an RDB merely to proclaim that they are no longer dispersed.
Of course each Rx event would require an identifier for patient ID and through time each would be dispersed throughout
the mirror database. SQL capable databases offer ready tools to calculate other fields and drive report generation,
but not integrated display in the TORCH application. Providing the parsing logic within Zope would
require more detailed scripting code, however the same code can attend to issues of display and integration into
the remainder of TORCH. SQL language is limited to retrieving and placing streams of data according to selection
criteria and does not provide a platform for other development.
Certainly an EMR is the basis for inquiry at the time of encounter when a given patient is the universe for study.
The question to answer is whether the EMR files are the ideal database for inquiry across EMRs. Such statistics
require parsing logic which goes beyond archiving and the presentation of event variables which is the current
role of retrieval during patient care. This role of inquiry across EMRs is discussed further under Prescription
StatisticsDB.
Two additional protocols or routines have been represented by variables and in the schematic. These
are Timeline Review and Cost Dialogue.
It must be decided whether the service is always on or optionally provided in at least 2 dimensions.
1. either service could be enabled by a toggle based on EMR for the protocol to be applied to that
patient
(or toggle on the service for all EMRs)
2. either service could be toggled on for a medication by generic name (or Activate as an All Meds feature or toggle)
The Cost Dialogue and Timeline Review services are represented by cumulative values that are incremented at each
prescription event and span all events for one medication. These values can be appended to the object representing
the prescription event for reference in running the protocol, as long as the LAST Rx event for each medication
is identifiable and parsed for inheritance to the next. Once in motion each ongoing service spans successive prescription
events and its values must be stored somewhere, if not in a separate database.
One consideration is the congruence between Rx events and operating protocols. If a practice expects to deploy
a protocol across all medications, then it is just as well to maintain values for the protocol in the most recent
prescription object by that medication genname. If a protocol is to be administered for only selected medications
or EMRs then it may be better to isolate the data to a separate database in the case of an RDB.
But for the same service to be offered optionally using an object database, the installments of new
records which include the routine are already an inherently separated database.
Timeline Variables
Medication quantity discrepancy is obtained by a math exercise and the display of a calculated value can function
as a feedback, prompting for a documentation of the clinical reasons for a discrepancy of over or under
usage. The calculation depends on each pattern of Sig. instructions and the siginterval for the format. In practice,
most common Sig patterns communicate a daily dose beginning with qd and q 24hrs. TID and q 8hrs share a one
day "sigperiod" and a "sigdayfact" of 3 times the unit of dosing.
It is proposed to avoid the minute by minute patterns of IV administration and treat IV as a procedure,
outside of the mandate of this Medication Module. Pump SQ therapy is also a category of procedure not within the
scope of traditional pharmaceutical dispensing. A 1 week sigperiod is convenient to assign to patterns such as
alternate day doses or specific days of the week eg. Tuesday and Thursday. Next, a 4wk sigperiod is convenient
because it approximates a month and also synchronizes well with the contraceptives and hormone medication. A month
or annual sigperiod could be used for some types of Sig.
For simplicity it is proposed to convert all sigperiod into a daily _expression_ or sigdayfact. This
means that a burden of dose may become a fraction. For example, " 5mg., one tablet Tuesday and Thursday"
becomes 2/7*dose/day. Applying the formula to 20 days elapsed on the prior example: pkudose x
sigux x sigdayfact x days =5 x 1 x .285 x 20=28 mg. (pkumeas) =5+ tablets. This is good enough to estimate
a remaining count by simply rounding to the whole number and subtracting from quant previously dispensed. Ongoing
display of such a calculation is a valuable aid at the time of a call from a patient (or an emergency room).
In the variables described, it is proposed to use actual units of measure (pkumeas) as the common
_expression_ for accumulated discrepancy in medication. Accumulated discrepancy is a carrier of information from
prescription event to prescription event. _expression_ in units of milligrams instead of a tablet count allows for
an accumulator variable to span multiple prescriptions (whether dosed as two of 30mg or one of 60mg). However for
purposes of display it would be preferred to express both the total (eg in mg.) and also as a tablet count
based on the pkudose of prior prescription.
An accumulator variable such as cumfwd should be viewed as a statistic and not convertible to a pill
count. The statistic has meaning over a sequence of medication renewals or refills. cumremain
which is the amount (in mg. or any other pkumeas) remaining during any current prescription
period, is the only value that should be convertible to numremain, a pill count. A patient is not assumed
to be hoarding medication; cumfwd represents an ongoing mismatch of consumption and prescription not an
accumulated inventory. This is the equivalent to counting the degrees in degree/days of temperature. The
corollary information is the stated period for gathering the statistic in elapsed time..
When a patient returns early for refill of a continuing medication, the mismatch
is an over usage in treatment terms. When a patient returns late the presumption must be converted
from days beyond the calculated depletion time for treatment . Either of these are a concern in the
separate manner of cooling degree days and heating degrees above and below a compliant target. It may
be appropriate to segregate cumfwd in two separate counters for treatment periods of over and under usage.
All calculation of either estimated day of depletion (dateout) or estimated remaining quantity (numremain) are based on the conversion through "unit-days" of dosing (if the sigperiod is a unit day)
Cost Dialogue
The principle of doing a survey to obtain a conversion factor for cost (lclunitcost) has been discussed and the WorkDB is a place to store the factor. Otherwise cost is a calculated value that can appear during the composition of a prescription event. A variety of accumulators can be devised to sum cost based on a time line or based on sample time period (all current medications for a one month supply). It may be helpful to be able to capture an estimated cost as a brief statement to include in a medical encounter representing the social economic situation of the patient.
Renewal Protocol Database
It is proposed that Renewal protocols are better served by a separate database. Any renewal protocol would
be in force for only selected patients,complete with its own toggle to start and stop. Each activated
protocol could be viewed as equivalent to a treatment procedure with multiple visits,installment notes, and some
consolidation of pertinent variables held in the Rx Events of the EMR. As discussed, the purpose of a renewal protocol
instead of a simple refill is to obtain basic update on patient status, so a separate database is more likely to
adapt to the evolution of features in the future..
Consideration is needed as to the multiple use of a renewal protocol. Should it expire after one use or be ongoing
for an interval of time or multiple renewals? What is the feedback loop between a provider reviewing info and giving
OK to a "compliant" renewal and the patient who complies with the protocol by contacting staff? These
open ended questions are compelling for a separate database for one or more protocols to be active. It is believed
that renewal protocols fill an emptiness in medical practice, in an age where the exercise of a permitted refill
is usually not linked to even an informal update on patient status.
The variables described would likely contain some values representing very simple protocols , such as "with BP" to link medication renewal to report of blood pressure. The value of a renewal protocol is to move some simple followup procedures out of repositories (such as the last encounter or miscellaneous notes appended to an EMR) and link the followup tightly to the known timeline of medication supplies.
Prescription StatiticsDatabase- RxStatDB
It is proposed that some RxStatDB should exist as the initial holding place for pooled statistics on a medication.
The proposed variable to pool is a tabulation of medications by name, dosage and discrete Sig. pattern.
After all the discussion opposing the storage of Sig. fields in association with specific medication names, we have
come full circle to the recognition that RxStatDB can function readily as a picklist for the Sig. portion
of an Rx form (if one is not opposed to providing that). In fact, statistics gathered on Sig. across all EMRs can
function to display the full range of prescribing habit and provoke thought about the range of practice experience.
This qualifies as a reference to an information system of sorts.
When a range of discrete Sig. patterns is displayed (complete with frequency count), this could
be offered as a picklist for a currently composed Rx form. Another variation would be to also retain the EMR reference
ID for the last (most recent) occurrences of each Sig. pattern. It is not unreasonable to consider storing a string
of the last 20 or 50 EMR ID numbers in a short list form for immediate review. This allows a practitioner
to stop and review other practice experience in detail before prescribing for a new patient. After pulling initial
genname and packudose into an Rx form, the practitioner can review not just a choice as saved at some solitary
past Prescription form. The practitioner could briefly review the statistical count of the entire range of Sig.
for the given med and pull one from the picklist. This is in keeping with the principle of causing Sig. to be a
reflection on all past experience and available information systems.
If it is imperative in the provision of "features" to provide an arbitrary picklist of complete
Sig. fields for given medications, then the current TORCH method of saving a single Rx form suffices and the WorkDB
could be employed for storing the fields. However this method is not a step toward gathering statistics of
any sort, it is only populating a solitary entry for future reference. If one seeks such a picklist for Sig. it
must be remembered that such a picklist is only a tool to expedite an individual encounter and effect a duplicate
for input...it is not a tool for decision making.
The writer is certainly in favor of beginning tools for gathering statistics on Prescription Events across EMRs.
Once in place, the same framework of parsing logic can be modified and applied to pooling statistics based on other
objects and attributes residing in EMR's. Such pooled reporting is the basis of all practice management and inquiry.
Tools for practice management study can benefit many areas of a practice, but the ubiquitous arena
of pharmaceutical treatment is active with a steady accumulation of new events for study. It may not matter
whether the variables are stored in distributed database across EMRs or mirrored into a relational database, but
as the volume and the length of time to parse all records accumulates it may be more efficient to build the separate
RxStatDB for new Prescription event..
The display of the discrete variables could be as simple as a tabular report or a graphical display such as a frequency
graph.
Medication name
Medication unique item (genname+pkudose+pkumeas)
Sig. unique pattern
Prescriber
Pt Id
Date
A sort heir achy to generate a personal provider history as a picklist for Sig. would be, sort on: prescriber,Medication
name, Medication unique item, Sig. unique pattern . Additional sorting can be added to enable chart review within
individual EMRs
Summary
This proposal has been a discussion of value systems which a medical provider might consider when deploying
an EMR software. The proposal outlines directions for TORCH to evolve and there are some strong themes, aside from
the questions left open.
- Provide a gateway primary database to mirror the VA open source
formulary
- provide tools for editing that formulary with safeguards for the final reference role of a primary database.
- add tools for mirroring updates and for archiving changes
- Avoid dual uses of a working formulary
- retain Work DB as a tool for accuracy which is a subset of PrimeDB
- do not attempt to make Work DB a tool of ergonomic speed only
- retain its value as a limited information database
- use the working formulary to store local supplementary info not mirrored from PrimeDB
- Cut through the Gordian
knot of storing Sig fields
- accomplish Sig field ergonomics by offering a picklist of patterns dissociated from any specific medications
- acquire a true local information system on prescribing history (that can be deployed also as a picklist for Sig.
- Add tools that aid the
health care interactions that surround prescribing
- Timeline display
- Cost estimate display
- Renewal Protocols as an alternative to unmonitored refills
- Demonstrate statistical inquiry in the arena of prescribing
- deploy a database or extraction methods to tally the discrete elements of prescribing across distributed EMRs
- begin study with retaining a matrix of the discrete fields of a prescription including Sig. fields
- consider using that as a picklist for Sig fields when composing an Rx Form
Post Note
This proposal ends in a cursory summary and the entire proposal, with all its redundancy, is only a starting point
for open process dialogue. It is hoped that the dialogue will result in a major upgrade to open source TORCH software.
It is believed that Medication Management is a module as important as the frequently expressed interest of seamless
third party billing or accounting. In fact billing and accounting can be contracted or added with ports to other
software more readily than Medication Management, which is at the heart of patient interaction. Medication
management truly must be done during patient contact and parts of billing and accounting can be done removed from
patient contact.
The Process
The host proposal is Copyright © 2003 by Tyrus Maynard, excluding comments received, as this is a Request for Comment document. Where provocative portions of this document are cited elsewhere please offer a link back to the full redundancy and also commentary that is intended at this site.
It is hoped that the processes which follow commentary on this proposal can demonstrate one way for open source software go through dialogue for a major upgrade that includes input from users who are not programmers. The HTML version of this proposal is intended to hold comments at least to a level of subheadings and serve as a reference location for email lists to point to. Where email lists have HTML archives that are pertinent, a visitor may also reference with URL in any comment here. Visitors are encouraged to add comments as threads under topics already defined in this document. The thread length under certain sub topics (in red) can be viewed as a mandate for further documents, which can in turn host comments. For those wishing to spin off such further Request for Comment documents contact Tim Cook
|
|
|
|
Medication Management Module (proposal) |
| [Prev in Thread] | Current Thread | [Next in Thread] |