Clinical Modeling Core Principles

Clinical Modeling Core Principles

Stakeholders

• Healthcare Providers
• Terminologists
• Analysts, Modelers
• Vendors, Interface Specialists
• Research

Ten threshold concept of Basic Clinical Modeling

• You are not alone! – Teamwork
• Start talk talkative! – Data elements basics
• Divide and conquer! – Grouping
• Describe the kind of data! – Data types
• Guide to reality! – Examples, examples, examples
• Tell me why! – Evidence
• Foster proper answers! – Operationalization
• Profit from other art! – Re-usability and inheritance
• Document your expectation! – Cardinality and more
• Cycle through life! – Status and Versioning

Work based on a paper: Team competencies and educational threshold concepts for clinical information modelling. / Scott, Philip; Heitmann, Kai. Decision Support Systems and Education. ed. / John Mantas; Zdenko Sonicki; Mihaela Crişan-Vida; Kristina Fišter; Maria Hägglund; Aikaterini Kolokathi; Mira Hercigonja-Szekeres. IOS Press, 2018. p. 252-256 (Studies in Health Technology and Informatics; Vol. 255). https://researchportal.port.ac.uk/portal/files/11936801/ Team_competencies_and_educational_threshold_concepts.pdf http://ebooks.iospress.nl/publication/50513

You are not alone! – Teamwork

Active participation of clinicians necessary but requires (communication, soft, …) skills Collaborative environment with multi-stakeholder communication Healthcare providers must learn how to communicate well with non-clinical experts and vv Add Process / content analysts and terminologists Perform team-building activities

Start talk talkative! – Data elements basics

• The data elements shall have a short name that allows other to gather what this item means.
• This needs to be simple text in natural language, not acronyms or abbreviations.
  • Examples: Date of birth, Body weight, Type of specimen, Anatomic site, Specimen Collection Time
• Data elements shall always include a description that precisely explains in additional words what the subject of the item is.
• Examples
  • The date and time the specimen was collected
  • The reason why the immunization was refused
  • The administrative gender of a person
• Introduce an identifier (short number for example) for each data element, at least unique within the data set, eventually globally unique; this makes it much easier later to refer to the data element in further discussions.
• Agreement about naming conventions so that you are consistent

ART-DECOR®

Divide and conquer! – Grouping

• Grouping essential
• Not a natural approach for many healthcare providers
• Problem can be reinforced by using inappropriate tools
• Navigation
• The “tree” can be expanded to see its components.
• Good tools intuitively support this

Describe the kind of data! – Data types

• Data set is a definition of elements that will be populated with real values
• Datatypes: What is the expected nature of the data

Count

Countable (non-monetary) quantities

• 7, 11, 298
• Used for countable types such as: number of pregnancies, steps (taken by a physiotherapy patient), number of cigarettes smoked in a day

Code

A code for a real-world thing; a code is a system of valid symbols that substitute for specified concepts, usually defined by a formal reference to a terminology or ontology, but may also be defined by the provision of text. Dates and Times – represents an absolute point in time specified to the day or additionally the time. The partial form is used for approximate dates.

Dates and Times

Represents an absolute point in time specified to the day or additionally the time. The partial form is used for approximate dates.

Text/String

May contain any amount of legal characters arranged as words or sentences. Formatting may be included (text) or not (string).

Quantity

A measurement comprising a decimal number of arbitrary precision and a unit. There are some "special" quantities used in healthcare: for time durations Duration, for monetary amounts Currency.

• 87 kg, 1.83 cm, 10 mg/mL

Duration

A quantity representing a period of time with respect to a notional point in time, which is not specified. A sign may be used to indicate the duration is “backwards” in time rather than forwards.

Identifier

Type for representing identifiers of real-world entities. “Pure” identifiers are meaningless, but that is not usually the intent

• Example: “F564738573” (identifier), German Patient Identifier (context)

Ratio

unlike its usage in statistics, always a concrete ratio of two quantity measurements. Some apparent “ratios” are not this data type because the ratio is in the unit not the value:

• beats/minute (Heart rate), µmol/L (Serum creatinine).

Boolean

only “true” or “false” is possible

• Instead, this is often typed as a coded element with, e.g. “Yes” / “No” etc.
• Covers also “don’t know”

Ordinal

Rankings and scores where there is

• a) implied ordering,
• b) no implication that the distance between each value is constant, and
• c) the total number of values is finite.

Although the term ‘ordinal’ in mathematics means natural numbers only, here any integer is allowed, since negative and zero values are often used for values around a neutral point. Examples

• -3, -2, -1, 0, 1, 2, 3 – reflex response values (neurology)
• 0, 1, 2,… – APGAR score values, to quickly summarize the health of newborn children
• 1, 2, 3, 4,... – ASA classification, a score defined by the American Society of Anesthesiologists for assessing the fitness of patients before surgery
• I, II, III, IV, ... – Tanner scale, a scale of physical development in children, adolescents and adults.

Further Remarks

• Some of the data types add additional needs to be defined for a data element
• A data element typed as code may require a choice list of concepts you want to allow or see when it comes to real data
• Some terminologies such as SNOMED-CT already have a set of terms (along with codes) for specific purposes
• Choice lists may be found as so-called value sets, containing the choices along with their coded representation for proper implementation in software and *reliable communication.
• Example: data element “Reason for Refusal” in an immunization data set, following choices:
  • immunity
  • medical precaution
  • out of stock
  • patient objection
  • philosophical objection
  • religious objection
  • vaccine efficacy concerns
  • vaccine safety concerns
• Other simple examples of already existing value sets might be the
  • ABO and Rhesus Blood Groups
  • Administrative Gender of a Person
  • Professional Specialties
  • Laboratory Tests

Ranges

Measurements may define possible ranges, e.g. a Pulse rate has a value in expected “normal range” 60 to 100 or may never be lower than 0 or more than 350 just to detect “illegal” values

Length

Text may have an expressed/expected minimum or maximum length

Precision and Scale

Quantities and time stamps may have their (expected) Precision/Scale as an additional property Precision is the number of digits in a number Scale is the number of digits to the right of the decimal point.

• Example, body height in centimeters should have a Precision of 3 and a scale of 2, e.g. 1.89 cm

The same applies to dates and times.

• You might expect the creation date of a document to be precise to the second (thus year, month, day, hour minute and second being specified as real data)...
• but for a “Date of surgery” in a past medical history you may allow only year, or year and month.

Units

Quantities also shall define an associated allowed Unit or set of units

• terminologist can help here too: they know systems of predefined units to tell software builders what standardized units look like
• While standardized units are very important for the communication between systems e.g. 10*9/L as the “system” unit for Platelets, using a coding called UCUM), the display of the units should always fit the usual way clinicians are used to seeing them, like x 109/L Platelets

ART-DECOR®

Guide to reality! – Examples, examples, examples

• If a data element called “dose quantity” in a vaccination record data set is defined, consider adding examples like “20 mL” or “200 I.U.”
• Good tools allow for context examples and comprehensive examples anywhere

ART-DECOR®

Tell me why! – Evidence

• When defining a data set, a use case / rationale for the collection of the defined set of data overall and each data element individually shall be documented

Foster proper answers! – Operationalization

• When defining data elements, think about how to get proper values for the item
• There may be use cases where the circumstances of measurement make the data more comparable (a series over time), so you might want to define the details of measurement or the coding system specified for usage
• Perhaps a diagnosis in a discharge scenario has as a legal obligation to be determined as a free text but also as a code drawn from ICD-10, then your operationalization is “use ICD-10 for coding”

Profit from other art! – Re-usability and inheritance

• When defining a data set it seems likely that parts or components of the data sets may have already been defined elsewhere
• Re-usability is one of the most important features of (clinical) modeling: it saves time if you simply can take over definitions of others (which should be easy by optimal tooling support).
• In case you are not 100% satisfied you still can consider taking the “art work” of others, clone (inherit) it and start a refinement process to fit your needs; this is still better than starting from scratch and prevents unnecessary re-thinking of already well-thought structures, avoids errors and omissions.

Document your expectation! – Cardinality and more

• There will be the need to eventually assign another property to a data element, that is to determine whether it is: optional or required, repeatable or not
• This is referred to as cardinality and typically expressed as n..m
  • with n being 0 for optional data elements or 1 for required ones,
  • and m being 1 for non-repeatable items or 2, 3, etc. for reflecting the number of allowed repetitions
  • A special symbol * is used to express that there is actually no upper limit of repetitions if the item, so n..* means “n to many”.
• Examples
  • The item whether a person is pregnant or not might have the cardinality of 0..1

Condition

You also might consider making it 1..1 under the Condition that the person is female and your scenario requires information about pregnancy, for example patient safety reasons (prescription scenario, perhaps)

Cardinality and Conformance

Mandatory M

• The attribute is mandatory, i.e. a valid value shall be provided and no null value is allowed. The minimum cardinality is at least 1. This also implies that if the sender has no valid value for such an attribute, the message cannot be sent.
• A sender must support elements with “mandatory” conformance, and a receiver must understand these elements.
• Please use mandatory elements with caution as overly-strict requirements may result in not implementable templates or in situations that are not aligned with practice.

Required R

• The item is required, i.e. a valid value should be provided or if missing a null value is allowed if its minimum cardinality is 1 (“empty element”), or may be omitted if its minimum cardinality is zero (“missing element”).
• In messages, the element must be communicated if its minimum cardinality is one. In the case where the element is not mandatory, it may be communicated with a null value. Note that any element declared to be "Mandatory" must also be "Required" and have a minimum cardinality of one. If the minimum cardinality is zero, and the element is "Required", conforming applications need not send the element if data does not exist. In some governance groups this is referred to as “Required but may be empty”.
• For required elements, conforming applications must demonstrate their ability to provide and communicate not null values. Receiving applications must demonstrate their ability to receive and process (e.g. store, display to users) not null values for required elements.
• A sender must support elements with “required” conformance, and a receiver must understand these elements.

Optional O

• The item is truly optional, i.e. a valid value may be provided or if missing may be omitted.
• It is indicated as “O” in the template item table, a may be considered as a shorthand for an unspecified conformance with a minimum cardinality of zero.

Not permitted NP

• The item is not allowed, i.e. the number of allowable occurrences is 0. It is indicated as “NP” in the template item table.

Conditional C (typically with a condition table)

• This item has an associated condition predicate and may depend on the co-occurrence of other elements or properties of the instance or situations.

Cycle through life! – Status and Versioning

• The lifecycle of a definition should always be imagined as two-dimensional: a Status and a Version.
• An item has an initial Status, such as “draft” when you start defining it. It may mature over time to a status like “final”, is used and once no longer needed or replaced by a newer and better definition it might migrate to the status of “deprecated” or “retired”.
• This leads to a new Version of the definition: Versioning retains the original definition (also because it is still in use), “clones” the origin and adds the changes to the new version

Status

• Main axis
• More possible/desireable
• Transitions
• Status of Versions
• Status „machine“