Responses to Dan Johnson's Prescribing Overview

This is a response to Dan Johnson's PrescribingOverview, 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:

Efficiency is achieved by

avoiding duplicate entry

• No duplicate data entry should ever happen. Any field that has dependency to other fields is filled by default and in real-time as those other fields are updated. Where this is not the case, it is a bug.

keeping hierarchies short and mnemonical

• Assuming that this refers to data entry and selection, we are in fact not dealing with any drop-down hierarchies. All of the data entry is keyboard activated auto-completing data entry (although we are not principally limited to this, we strongly believe in this approach.)
• This means, you advance into a field by (a) default, (b) mouse click, or (c) tab key, and you will begin to say whatever you would write. As you type, the auto-completer will try to suggest reasonable completions which it shows in a short drop-down box, a mouse click allows you to select an item and move on. Or, you can keep typing until only one alternative is left, which will then be displayed as highlighted text in your entry field; this text is accepted simply by leaving the field (mouse or tab).

providing easy and straightforward error correction

• At this point you can start over with every edit action simply by cancelling the action and start over.
• In all text fields we should (!) have implemented the escape key, which will allow you to restore the value of the field before you entered it.
• We do not have a control-Z type undo operation where you can undo a whole sequence of edits.

making transitions from one field to another or one subtask to another fast and straightforward

• Tab always moves you to the next logical field.
• Subtasks are all lined up in the main tab-folder, so you can quickly flip around in your subtasks.
• If you are selecting an object for editing after you have already such subtask ongoing, you are simply sent to that subtask.

any list of medications is only a snapshot

It is one thing to keep a database of medications; but any list of medications is only a snapshot of what the patient reports taking, or has been instructed to take, at a particular time.

• More on this as response to the other writings.

Time Travel

It is harder to ensure that a physician can go to any point in time and recreate the snapshot from that date of the patient's medications. But this is often necessary in investigating a patient's historical complaints.

• Each prescription record is kept. When you click on it and modify it, you are not actually modifying the old record, instead, you are creating a new record which just starts out with the same data in it as the old record.

• A link is also kept between new and old record. This link is in the database, and can easily be shown in the user interface allowing you to browse through old versions of prescription items. This would allow you to track the changes not only of dose, but also of the kind of drug.

• It would be cool to see the temporal development of the case in a visualization. This function could be useful or a gimmick, the data supports it, but the development of such a visualization is presently very low priority.

sort though changes

Even more difficult -- because neither paper charts nor electronic records are designed for this -- is to be able to sort through a patient's record to find out when and why a medication change was made (incl. dose change, change in administration schedule, a change from or to generic from brand-name)

• These changes can be tracked as described above, the system's data supports this function, even if it is not actually visible (yet). It is a relatively minor task to enhance the views to allow browsing in historical data.

• Each change is furthermore connected with a record of when the change was made and who made it. This same record allows to annotate the reason for the change, and to connect to other data (e.g. progress note, when we have it). The data model supports this already,

• Creating the function to actually view and edit such change notes is not hard given the infrastructure framework.

review all the medications of a particular class

More challenging, to review all the medications of a particular class that have been prescribed, when they were begun, changed, or stopped, and the reasons.

• This is not a frightening challenge at all. Once we know the use case and work-flow context of such search, we can prioritize it vis-a-vis the other work items we have and eventually can address it without any worrisome ripples. This is considered a cool function and I wish we were ready with everything else to focus a few days on making this real.

two facets of interest in change tracking

There are really two facets of interest, the change itself, and the date of the change, which automatically links it to the date of a progress note which (should) explain it.

• Yes, once we implement progress notes, we can do this. And we have a hook for the notes already.

export the explanation of the change

We need to be able to export the explanation of the change to whatever progress note format the doctor uses.

• That needs to be looked it in detail. We do not currently export anything other than (working on) prints. Much can be done and hooks are there. But would prefer to support progress note writing in the application because it is so closely tied with problem list management and (changes to) interventions.

trails of changes in specific fields

This [may] create a need for two different trails: One, a standard audit trail of record editing, such as this wiki keeps. Two, a trail of changes in specific fields: drug name, doseage strength, and sig.

• We only have one trail. Specific flagging of field changes can be readily accomplished by comparing the two versions.

• Perhaps this could be done automated in such a way that the text which annotates the change would be created automatically, describing the change. For example, when the dose changes, we could generate a text "dose increased from 100 mg to 200 mg" or when the timing increases "timing changed from 2 times a day to 3 times a day" etc. Or "drug changed from captopril ... to enalapril ...", etc, and then allowing you to continue the sentence with "... because blah blah".

• Alternatively this is all obvious from the data and all that you need is to tie this change action with (a sub-item of) your progress note.