API Reference
API Reference

Medication Threads, Medication Orders and Medications

Medication Threads and Medication Orders in Elation

Medication Orders

Most EHRs have the concept of a Medication Order, a resource designed to capture information about a provider's request to allow a patient to use of a medication.

For example, the FHIR spec uses the name Medication Request to capture the concept.

Elation is no exception.

In Elation's API described here, the resource is called medication and available at the endpoint of the same name.

GET <host>/api/2.0/medications/<medication_id>
{
  "id": 1212345,
  ...
}

With this resource an integrator can capture information about what is on a patient's current med list, what was prescribed historically to the patient and by who within the practice.

Medication Threads

But it often makes sense to ask questions like:

  • On what dosage did the patient start this medication? Did it change?
  • How many times did the patient receive a renewal? Who responded to the renewal request?
  • Is this a medication that should be taken permanently? Or is there a course of treatment that should finish?

Elation uses the concept of a Medication Thread, hereafter Thread, to provide answers to these questions by tracking a patient's history with a medication over time.

Example

  1. Provider A prescribes Medication A to Patient A -> Create Thread A, Medication Order A referencing Medication A
  2. Provider A changes dosage -> Create Medication Order B referencing Medication A w/ a different dosage, Update Thread A

The medication endpoint has the ability to filter by thread id:

GET <host/api/2.0/medications?thread=<thread_id>
{
  "id": 1234355
}

In this case we'd receive a response with two items. Both with a section with the key "thread", which should look the same:

  "thread": {
    "id": 12341234,
    "dc_date": null,
    "is_permanent": true
  },

The Thread id

You'll notice that the "thread" block includes an "id" field.

That is auto-generated by Elation when a new med order is created or re-used when a med order is created in an existing thread in-app.

Discontinues

Now let's discontinue the thread:

  1. Provider A discontinues Patient A's use of Medication A -> Create Discontinued Medication A, Update Thread A

We'd still receive a response with two items because Discontinued Medications is a separate endpoint. Both still with a section with the key "thread", which should look the same, but now indicating a dc_date:

  "thread": {
    "id": 12341234,
    "dc_date": "2017-02-12T06:44:31.493753Z",,
    "is_permanent": true
  },

Permanence

One key characteristic of a Thread is whether its "is_permanent==true" which would mean representing the patient's use of a medication for the foreseeable future.

For example a medication prescribed to address a chronic condition like high cholesterol. In that case we would see something like:

  "thread": {
    "id": 1234123,
    "dc_date": null,
    "is_permanent": true
  },

But often the prescription has a course of treatment that should finish, such as an antibiotic is often prescribed for a specific period of time, e.g. 14 days to address an acute infection. For which we would use a "temporary" thread, with "is_permanent=false":

  "thread": {
    "id": 12341234,
    "dc_date": null,
    "is_permanent": false
  },