Responses to Dan Johnson's Functional Roles of Prescription Record

This is a response to Dan Johnson's Functional Roles of Prescription Record, 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:

two types of records

The "prescription record"

is the list of medications that the provider has personally authorized.

The "medication record"

is the list of all prescribed, OTC, and alternative medications that the patient is known to be taking, continually or intermittently.

• Medication history
• Not yet supported
• Clearly needed
• As discussed before, likely reusing the same functions as the prescription record
• But marked with different semantic qualifiers to clarify the intended prescription from the record of what is happening (intended or not).

Information requirements

Information needed by Office Assistant

Identifying information sufficient to ensure that we have the record of the correct unique patient. Possibilities include:

name

• Person.name (includes first name(s), family name, etc.)

birth date

• Person.birthTime

home telephone number

• Person.tel attribute

social security number

• Person id, better playedRole ... (need to check the current implentation)

internal account number

• What exactly would that be?
• Where does it come from?
• Probably account Act.id.

internal medical record number

• Patient role.id

external patient identifier

• Patient role.id to other institutions.
• Where do these come from, how do we need to list them?
• Possibly (easy) a collapsible list-view of other identifiers listing (as a table) scoper-organization name and id.
• It's in the model already
• But how would it be entered?
  • If electronic data is submitted, it would come that way.
  • Does it need manual entering of those?

currently prescribed medications

The list of the currently prescribed medications (as understood by the database)

Generic name, Brand name(s)

• There is only one name, the name used by the provider.
• If generic is ordered, that is the name.
• If brand is ordered, that is the name.
• We have several modes of medicine specification
  • Brand name (e.g. "amoxyl")
  • Generic formulation name (e.g. "amoxicillin")
  • Ingredient name (e.g. "amoxicillin trihydrate")
• The difference between Generic and Ingredient seems minute, but
• When we detect a dose in mg (amount of ingredient) we switch to ingredient based
• When we detect a brand name and dose in mg, you can say you want the ingredient as by the formulation named with this brand (if you want).
• Some of these flips of the logic are transparent to you.
• We keep them to have the model represent precisely what actually is meant.

dosage strength or concentration

• Strength will show in the ingredient list as ingredient-quantity
• For single ingredients it is as clear as for multi-ingredient formulations.

delivery form

(pill, capsule, extended release, liquid, inhaler, cream, ointment, lotion, injectable, nasal spray, ophthalmic, rectal, vaginal, etc.)

• Medicine (Entity) formCode ("form")
• Value set populated from drug database loaded, now from FDA/SPL labels

schedule of administration

• Text field labeled "timing" in the form.
• You enter any semi-formal text you like
• We interpret on the fly to understand what you are saying

In addition we provide a combined SIG:

• Text field labeled "SIG" in the form
• You enter any semi-formal text you like, which may include form, route and timing.
• We interpret on the fly to understand what you are saying
• While we interpret your typing, we populate the other fields
• In the future we like to give a complete script on one line, with auto-complete on the parts
• This would represent your main column in your prescription tables.
• Not quite there yet, because auto-complete is complicated

prn versus routine use

• Not implemented yet
• Transparent on the SIG line, just type "prn" and it should be fine
• HL7 priorityCode PRN
• Could in addition be represented by a check-box
• Need condition criterion (trigger-precondition) if we want to specify more detail than indication name

expiration date of refill authorizations

• Supply effectiveTime (I think)
• The supply group on the form is not ideal yet
• Supplies are independent of administration instructions, and need to have a way of carrying them over between scripts and revisions of scripts.

(The number of remaining refills is not knowable by the provider)

• Right, we only show number of ordered refills.

Information entered by the Office Assistant

changes made

• This is about history taking, approximate confirmation of what was taken as opposed what was prescribed.
• Not supported yet
• Model supports it, but we have no user functions for it yet.
• Would be in the history list, but according to what was said above
• The medication history list is separate from prescription list
• Assistant would make records on patient consumption of prescribed medicines under the prescription line items in the list.
  • Taken as prescribed (copy specification from script (mood changes to EVN, no performer, only author and patient is informant)
  • Taken with different dose (as above, then edit)
  • Stopped taking

changes made by the patient

Changes made by the patient since the last update of their medications database, including the reason for the change, the (approximate) date of the change.

changes made by other providers

Changes made by other providers since the last update the the medications database, the reason for the change, the (approximate) date of the change.

• same information no matter who changed.
• but needs a way to say who recommended change.
• may be best done in free text right now.
• If more than free text, will user deal with data-entry burden?
• Prioritization of feature???

any comment by the patient on adverse responses to the medication

• Allow to record observations which are suspected to be caused by drug
• Use a causedBy link between observation and substance administration record.

any comment by the patient on favorable response to the medication

• Same as for adverse.
• But may need to be visibly classified?
• Not usually a condition, but just describing betterment of an existing condition?
• Examples of how user wants to record this?

Information needed by Prescriber

Start date of the medication

We must track start/stop dates, and this is challenging (see TrackDates?)

• discussed there

Purpose of the prescription (diagnosis, symptom, etc)

• entered (and displayed) in medication form under "for", e.g. "for headache".
• can drag and drop a problem list item on script to make the same link (displayed in the "for" field)
• known challenge to match what is hand-entered in "for" field with any problem list item
• medication for problem can also be created by right-click context menu "prescribe for this problem ..."

Stop date of previous medications

• Interesting what "previous" means
• Our system thrives on linkages between data, so we can handle it
• Challenge is how to enter it, usually with drag&drop and by the change trail.
• Challenge is also and how to display it without cluttering.

Reason for stopping

Reason for stopping previous medications (finished time-limited course, adverse effect, lack of benefit, trial of alternative therapy, etc)

• Every edit action will have a way to comment on the change (see earlier points).

Information entered by Prescriber

Corrections of typos and other errors

• Would presently come out as changes like any other changes.
• Will need some concept of "signing off" on such changes, which is not yet implemented.
• At this moment, hitting "SUBMIT" will commit the change.
• "CANCEL" (or "x" on the tab) rolls back any change made.

Alterations of any part of the med specification

• Same as minor changes, see previous point.

Notes of adverse responses

• Same as "any comment by the patient on adverse responses to the medication" above

Notes of efficacy

• Same as "any comment by the patient on favorable response to the medication" above

Decisions to stop or replace

• Part of normal edit audit trail discussed earlier.

Reconciliation

Deviations that otherwise aren't accounted for in the database forms

• Not sure what exactly this is.

What can go wrong?

Missing, vague, wrong, or incomplete data elements

The database and data entry process must accommodate missing elements, and must allow the user to efficiently, simply, and quickly indicate whether the data is approximate or suspect.

• This will be difficult on the fine grained level (e.g., for each field)
• But general annotations can be placed on logical units of records,
• e.g., one could flag a medication history item as "unsure"
• not implemented yet
• Prioritization?
• The model supports this already (Act.uncertaintyInd, I think)

Errors at any step of the process;

if caught, how easy to undo?

• just type over any changeable field
• this does create a new version
• no clear dichotomy between "major" and "minor" edit
• but possible in the edit comment
• however, will user bother to fill this in?

if missed, how significant the effect?

• effect could be huge, lethal even (dose times 100 that noone sees)
• this is the purpose of error checking in the second phase
• but max dose info is still hard to come by
• in the future (cool stuff) system could learn by experience (e.g., "doc, you never prescribed this drug at such a high dose, are you sure?")

if missed, how to record the correction?

• again just type over it
• but realize that the version management may need some refinement
• and control
• can you change the dose after you printed and faxed the script and patient is gone?

is an audit trail of corrections and entries needed?

• An audit trail exists for any changes.

Evolving needs for new types of data or display of data

How to accommodate the need for change:

user-modifiable data types or fields?

• New observation types can be defined.
• The logical design of the model has a lot of unrealized potential to address additional use cases.
• Observation data sets can be defined easily (on the back-end only right now), example is "vital signs"
• Could stick observation sets with other forms,
  • e.g., encounter form (which is non-existent yet, only the appointment stub)
  • patient form (extended demographics if you will)
  • problem form (standard way of characterizing pain, depression, etc.)
• Changes should be worked through with understanding of the model.

user modifiable reports?

• Prints, discussed above. How?
• On-screen reports, way down in future complex queries.
• Today one can make new forms to view data rather easily (requires XML editing)
• Possible in the future a drag&drop view builder (I can see how it can be done)
• Priority?

Evolving pharmacopeia

new medications

• SPL labels coming fresh from the FDA within hours after their approval

new forms of medications

• Ditto.

new brand names of old medications

• Repackaging, OTC not in SPL yet.
• Let's see where FDA's listing rule goes.

transiently unavailable medications (e.g., Avandamet)

• How do we know?
• Electronic submission or user edit?
• Possibly user will be able to edit the drug catalog.

Access Permissions

Who has institutional permission/access to change/update this identifying information?

• Currently every authenticated user can do everything.
• This could possibly change, but need good use case right now to move it up on the priority scale.
• It was assumed that you trust all your office staff not to overstep their boundaries