Responses to Dan Johnson's Tracking Start/Stop Dates

This is a response to Dan Johnson's Tracking Start/Stop Dates, where we try to show how we took his descriptions and explanations into consideration in the design of the application. At this point, most suggestions have been considered in a general and may not be fleshed out in all detail yet, because until now we were heads down into too much basic stuff. I will echo his bullet points here and provide a short paragraph to say how we functionally responded to them:

General Requirement

This is difficult because medications are stopped in many places, by many people, for many reasons or none at all. We must be able to

list the degree of confidence about stop dates

• in the medication history
• the model even supports quantitative expression of uncertainty on stop date
• some detail may need polishing, but mostly
• will users bother to enter these nuances?

list a reference to a progress note

or other record in explaining a medication stop.

• progress note feature could be placed right in today's problem editor.
• a text field (which looks dinky and messy right now, see issue #38)
• could to structured progress note (a la SOAP?)
• per problem or across-problem?
• across problem could be in the encounter screen (what comes up if you click appointment)
• with right-click context menu and drag&drop might be able to link a change specifically to a record.
• might summarize all changes automatically in the progress note screen
• a list of actions of present encounter could be gathered which shows all changes
• then on this list one could add comments
• there will be some issues with sub-transaction isolation and committing these
• could drag and drop these modification on a progress node
• can do many things, what would people use?

calculate the expected expiration

of a prescription and maintain this as a proxy for an anticipated or default stop date.

• Based on fills and consumption rate
• We are set up to do this because we interpret the SIG quantitatively
• Could integrate now into the prescription editor form
• It's like a spreadsheet, would augment the supply record editing
  • enter expected use time -> compute number of dose units
  • enter number of dose units -> compute expected use time

Flavors of start date

We created the prescription and captured the prescribing date, but the patient picked up the drug in his own good time, and can't remember just when it was -- "Not too long ago, doc!"

• Would this not come out in the medication history taken by office assistant?

Flavors of stop date

The prescription expires

Max # of refills

• recorded in supply/dispense order

Statutory expiration

(narcotics 1-3 months, other scheduled drugs 6 months, ordinary meds 1 year)

• recorded in supply/dispense order
• a limit on expected use time?

Formal expiration date specified on prescription

• can specify "for 10 days" or "X10D" in SIG line
• can specify "until 2006-12-13" in SIG line (not yet, but should)

A consultant or competing doc told the patient to stop the med

• Would surface as a change reason for patient changes

The patient decided on his own to stop the med

• Same as previous: change reason.

Precision of stop date

An actual date is known

Well, this is more likely the date the patient was <i>told</i> to stop the med

• Recorded in medication history

The patient makes a guess

• Recorded in medication history
• This is about vagueness in the date, see above (and below)

in terms of

how many weeks/months it's been

• Can implement a relative date "5 weeks ago" in date form
• But this would be converted on the spot to a date
• But this date could remain approximate (with an uncertainty)
• Some of the uncertainty infrastructure not yet implemented

in which month this occured

• 2006-12 should be a fine date to enter, it's imprecise but that we can handle no problem.
• Needs testing if the user interface text to TS conversion works properly

an indefinite time in the past

• No date specified
• With full uncertainty support, could specify "somewhere before may 2006"
• Priority?
• Will users edit this?

Epilogue: it would be awesome if we could show that all such information would actually be entered by people and that it would turn out useful to them. But can't make a lot of work for features no one would take the minimal time to enter or bother utilizing.