OHDSI Home | Forums | Wiki | Github

LOINC Concepts requiring 'Observation' Domain

(Polina Talapova) #1

In view of the fact, that the SURVEY_CONDUCT table was recently designed and implemented and it has a direct connection with the OBSERVATION table, I wish to draw your attention to the LOINC vocabulary. As you know, there are a lot of observational data and questionnaires which require ‘Observation’ domain, but do not have it. Previously all concepts with LOINC property of ‘classtype’ with values ‘1’ and ‘2’ were considered to be Measurements. However, we have conducted initial analysis of extended LOINC properties (such as ‘property’, system’, ‘scale_type’, ‘class’, ‘method_typ’, ‘definitiondescription’ and ‘survey_quest_text’) and realized that it is possible to make domains more accurate using combinations of LOINC properties. So we built a new logic for a LOINC domain distribution. See the full list of such concepts in the file attached.

Suggestions and remarks from your side will be highly appreciated!

LOINC concepts required ‘Observation’ domain .xlsx (601.0 KB)

LOINC: suggestion to change concept names for concepts indicating history
(Anna Ostropolets) #2

Do you consider Ophthalmologic treatment Right eye and
Ophthalmologic treatment Left eye as observations?

(Polina Talapova) #3

Yes, for sure. LOINC concepts ‘79755-5 Ophthalmologic treatment Right eye’ and 79756-3 ‘Ophthalmologic treatment Left eye’ both have property ‘Hx’, which always means ‘History’ (according to the LOINC Users’ Guide http://www.labdoc.it/osticket/documenti/LOINCManual.pdf).

There is the file with source values of these concepts for your convenience.
LOINC Concepts required ‘Observation’ domain (source extract).xlsx (871.0 KB)

(Anna Ostropolets) #4

Interesting! Would’ve never guessed by the name, which may be an issue for other users as well. Also, if you take a look at the LOINC answers to this concept ( Lamellar keratectomy, Nystagmus surgery, etc), they belong to Meas Value domain. This probably also should be changed for these pairs to be stored in the OBSERVATION table.

(Polina Talapova) #5

Thank you for your cooperation!

Would’ve never guessed by the name, which may be an issue for other users as well.

I completely agree! But I have no idea what decisions have to be made in this case. Do you?
And can ‘Meas Values’ LOINC concepts remain unchanged? The OBSERVATION table has a value_as_concept_id that is appropriate for Meas_Value too. Or are you talking about ETL?

(Alexander Davydov) #6

Good job, Polina!
I’ve been always confused looking at these Observations being stored as Measurements.

Just one thing - scores and scales results. Still the examination results, but obtained sometimes using a systematic/standardized approach. Do we have a convention? Please find some examples here using the domain_id filter. LOINC concepts required ‘Observation’ domain .xlsx (753.5 KB)


  1. To incorporate the Property or Time attribute to the concept name?
  2. To isolate the separate historical class using the source data (Class/Type: EYE.HX.NEI/Clinical).

(Christian Reich) #7

Can you open that up? What heuristic did you come up with?

(Polina Talapova) #8

@Alexdavv thanks for direction. I understand what I should do with those concept names.

Just one thing - scores and scales results. Still the examination results, but obtained sometimes using a systematic/standardized approach. Do we have a convention?

We should discuss this early in the week. I’m not sure, that such a convention exists…

Can you open that up? What heuristic did you come up with?

@Christian_Reich Yes, I can. Please, see the file attached.

(Christian Reich) #9

Thanks for the SQL code, but that doesn’t explain how you derived at the logic. It also isn’t English, and I would have to reverse engineer it to figure out what exactly you did there, and I am too lazy for that. :slight_smile:

(Polina Talapova) #10

The logic of the LOINC domain distribution seems to be messy, but it can’t be built automatically in other ways.

So, inclusion (and exclusion) criteria for LOINC concepts required Observation domain:

  1. values of a ‘classtype’ field are ‘1’ and ‘2’. They indicate all old LOINC Measurements

Then, in a case of non-compliance, we move from one to another:

  1. values of a ‘survey_quest_text’ field contain question mark (survey_quest_text ~ ‘?’), which always defines LOINC questions regardless of other LOINC properties
  2. scale_typ’ field has ‘Set’ value indicating concepts used for Clinical Attachments only.
  3. values of a ‘property’ field are represented by the following:
  • ID’ - Identifier - serial numbers, codes, IDs etc.
  • Pn’ - Person Name - administrative information about person
  • Tele’ - Telephone Number
  • EmailAddr’ - Email Address
  • Addr’ - Address
  • Xad’ - also Address
  • Loc’ - Location
  • ClockTime’, ‘Date’, ‘TmStp’, ‘TmStpRange’, ‘DateRange’ - time/date/date and time/ranges of different clinical and administrative events
  • Hx’ - History of different clinical and administrative events
  • Desc’ - Description of procedures or clinical events
  • Anat’ - Anatomical sites, points, body structure descriptions
  • Instrct’ - Instructions
  • Txt’ - Text - notes and comments
  • URI’ - Uniform Resource Identifier
  • Bib’ - Bibliographic Citation
  1. values of a ‘system’ field are represented by the following:
  • ^Family member’,’^Neighborhood’, ‘^Community’, ‘^Brother’,’^Daughter’, ^Sister’, ‘^Son’ - observational particular person-related data
    (But ‘^Father’ and ‘^Mother’ systems contain Measurements)
  • ^CCD’ - Continuity of Care Document
  • '^Census tract’ - information about people in a geographic region defined for the purpose of taking a census
  • ^Clinical trial protocol’ - Clinical trial protocol documentation and reports
  • ‘*’ - Mixed category defining sites, types, locations, device peculiarities etc.
  • ?’ - 1 concept - ‘ED discharge disposition’
  • ^Contact’, ‘^Emergency contact’ - contact information
  • ^Donor’ - donor type and ID
  • ^Event’ - information about incidents or events
  • ^Facility’ - information about services
  1. a value of a ‘method_typ’ field is ‘PhenX’ (the PhenX Toolkit has a lot of questionnaires) and a value of a ‘class’ field is ‘PANEL.PHENX’ (just ‘PHENX’ class is covered by previous conditions) and a value of ‘definitiondescription’ field contains words ‘interviewer’ or ‘question’ (this weeds out Measurements)

  2. values of a ‘system’ filed are ‘^Patient’ and ‘*^Patient’ (they contain a lot of observational data directly linked with a patient) and, simultaneously, values of:

A) a ‘scale_typ’ field are:

  • Doc’ - various types of documentation
  • Nar’ - narrative text
  • Nom’ - nominal or categorical responses that do not have a natural ordering
  • Ord’ - ordered categorical responses, e.g. ‘Yes’, ‘No’.
  • OrdQn’ - quantitative/ordinal - result can be reported as either ordinal or quantitative

while a ‘method_typ’ field value is not ‘Apgar’ (Apgar score is a screening test used to measure the vital signs of a newborn)


B) values of a ‘property’ field are represented by the following:

  • Imp’ - impression/interpretation of a study - is used to represent a property when the evaluation is a mental abstraction based on one a collection of measurements and/or data.
  • Find’ - findings (seem to be Observations in all cases regardless to the ‘system’, but not)
  • NRat’ - number = count/time - e.g. ‘How many cigars are you smoking per week now?’
  • Num’ - number - e.g. ‘[#] Pregnancies’
  • PrThr’ - presence of symptoms, historical facts, statuses etc.
  • RelRto’ - relative ratio - e.g. relative risk of developing disease
  • Time’ - time aspects - age, hours, years etc.
  • Type’ - a mixed category with a general notion of something
  • Arb’ - arbitrary - a mixed category, e.g. ‘Informed consent obtained’ or ‘RhoGam candidate’

while values of a ‘class’ field are not ‘COAG’ (it includes laboratory tests related to hemostasis) and ‘PULM’ (it is about measurements of respiratory function)

NB! All of such properties can be measurements in systems other than ‘^Patient’,’^Patient’, ^Family member’,’^Neighborhood’,’^Brother’,’^Daughter’,’^Sister’,’^Son’,’^CCD’,’^Census tract’, ‘^Clinical trial protocol’, ‘^Community’, ‘*’, ‘?’,’ ^Contact’,’ ^Donor’, ‘^Emergency contact’, ‘^Event’, ‘^Facility’.

  1. At the end, all results are filtered by a general exclusion criterion:
    values of ’ long_common_name’ field do not contain words such as ‘scale’, ‘score’ except those indicating ‘interpretation’ of the results.

(Christian Reich) #11

Oh boy. That is one complicated logical tree. I am sure you walked through it all and made those decisions. The danger is that with the next update of LOINC you are back at square one and have to walk through again, looking for exceptions.

(Polina Talapova) #12

I’m sure that the main LOINC attributes (and their meaning) mentioned at the LOINC Users’ Guide (1-2 pp) such as a property, system, scale and method shouldn’t be changed.

The logic described above can be easily implemented only by the use of two “CASE WHEN” in the load stage script: one defines domain_id, another - concept_class_id. In the future, to confirm correctness of the proposed query after the LOINC update, person will just have to run a check script, see results and only then decide whether script modifications required or not.

Currently in the LOINC, there are 118 790 valid concepts with a ‘Measurement’ domain and only 12 287 valid concepts declared as ‘Observations’ (but we know that there are considerably more such concepts).
Our approach can increase the observational LOINC pool by 6433 concepts.

Like we always do, we can provide a “beta version” of the new LOINC domain distribution and continue improving the approach during a routine maintenance. Of course we can’t avoid changes in the source, because the nature of data is to change throughout time. But it is a challenge rather than a problem :slight_smile: