Introductory thoughts

The initial steps toward creating an understandable and implementable pain model seem straightforward. Patient descriptions such as "I feel dull pain in my lower back". "I have pain in my back radiating down my left leg", "I have sharp pain in my left shoulder blade", could be fully represented with a pain model having 3 attributes:

Pain (initial) location, Pain (radiating) location, Pain quality.

However, a more expressive pain model poses challenges. Before going too far down the road of constructing a formal pain model (or in tandem with that effort), it would be good to have a clear(er) sense of the use and purpose of the model. "What needs to be retrieved and for what purpose and by whom?" are questions worth addressing, in order to focus our efforts.

The RxNorm drug model evolved from a very simple 3-part scheme of ingredient-strength-dose form that could not represent oral birth control preparations to a "5+ element" model that seems to work for users. The efforts resulted in a model and data that are useful beyond the initial intended purpose, which was to enable communication of a prescription from a prescriber to a pharmacist (i.e. e-prescribing). That success only happened because of the clear and prioritized focus on the part of NLM, coupled with frequent conversations with implementers (e.g. Walgreens, First Data Bank, CMS, etc.). For instance, early on it was decided to privilege the needs of pharmacists/dispensers over physicians/prescribers in the model-building efforts.

The decision of which aspects of pain to (initially) represent in a model, besides location and quality, may be easier to make when the speficic uses and users are better understood. For instance, there may be certain aspects of that don't need to be represented or included in the model initially.

Initial working example

A common aspect of pain reported by patients are exacerbating factors. Initial CIMI work produced this list of 10 values for an "exacerbating factors" attribute, represented as SNOMED CT concepts:

Activities of daily living (qualifier value) 24451000205105

Anxiety (finding) 48694002

Bending (qualifier value) 24351000205102

Breathing process (qualifier value) 719983008

Carrying (qualifier value) 24361000205104

Change in weather (event) 24301000205103

Change of dressing (procedure) 18949003

Cough (finding) 49727002

Deep breathing (finding) 289123006

Normal breast feeding (finding) 69840006

A red flag that something may be awry is that the range of values includes multiple SNOMED CT hierarchies (Qualifier value, finding, event, and procedure). Initial efforts suggested Observable entity as an additional hierarchy in the range of values of this attribute. The red flag makes this attribute and its initial set of values a good starting point for creating and refining a pain model.

For an attribute with values across multiple hierarchies, there are several things to think about:

Should the attribute be split into several, one for each taxonomy/area of concern?
Should the areas of concern (taxonomies) be merged into one? (i.e. Maybe they are not really different, a false dichotomy perhaps. Think finding vs observable entity nonsense...)
Should we just accept that for this type of information, we need to have values coming from several hierarchies?
Make the aspect (exacerbated by) a concern of the statement model rather than a concern of a post-coordinated topic (OWL EL expression) that is within the topic of the statement.

For this example, option #1 above would split a single, straightforward attribute having a clear meaning ("Exacerbating factors") into multiple attributes that would be difficult to name, and difficult to explain and use.

Option #2 would be difficult to implement, as the range of values includes both clinical and non-clinical items (i.e. weather), voluntary actions and activities, abnormal conditions (anxiety), and physiologic activities (breathing, coughing). Devising a single formal taxonomy that would include this wide range of phenomena might be challenging.

Option #3 may be reasonable, though the a benefit of a formal representation that allows "type checking", i.e. automatic QA checks for out-of-range values, would be lost.

I (John K.) don't fully grasp the implications (for users and implementers) of Option #4.