Conflicts of interest and agenda review

Briefing note for review:

Duplicate concepts in the Computed Tomography imaging hierarchy

Discussion:

Decision:

Resolving Ambiguity – Options for Consideration

Following the last EAG meeting members were asked to consider the 3 options for resolving ambiguity for concepts where not all of the elements that make up full semantic equivalence could or should be offered as clinically suitable replacements.

We would be grateful if you could review the above and provide your views and comments In the comments boxes below.

The following simple example is used to demonstrate each option:

3094009 |Vomiting in infants AND/OR children (disorder)|

..has 3 potential meanings:

Vomiting in infants

Vomiting in children

Vomiting in infants and children

The sum of these 3 meanings gives complete semantic equivalence with the concept 3094009 |Vomiting in infants AND/OR children (disorder)|, however, from the perspective of clinical use “Vomiting in infants and children” is not likely to be helpful as a statement in the individual patient’s record as they cannot be both an infant and a child at the time when the record entry was made.

In order to resolve the inactivation of the ambiguous concept 3094009 |Vomiting in infants AND/OR children (disorder)|there are 3 potential solutions:

Option 1: Representing complete semantic equivalence with “POSSIBLY_EQUIVALENT_TO”:

3094009 |Vomiting in infants AND/OR children (disorder)|

Inactivated as “Ambiguous”:

POSSIBLY_EQUIVALENT_TO new concept |Vomiting in infants (disorder)|

POSSIBLY_EQUIVALENT_TO new concept |Vomiting in children (disorder)|

POSSIBLY_EQUIVALENT_TO new concept |Vomiting in infants and children (disorder)|

As a second stage:

new concept |Vomiting in infants and children (disorder)|

…would be inactivated as “Erroneous” with an annotation; “Vomiting in infants and children is an erroneous concept because an individual cannot be both a child and an infant at the same time”.

There is then a judgment to be made, whether to provide a potential replacement or not. Given that the concept is deemed “Erroneous” it would be acceptable not to provide a suitable replacement that is of equal or less specificity than the original, however, it may be more helpful to use a  historical association of “REPLACEED_BY” and point to the concept 422400008 |Vomiting (disorder)|.

This approach clearly indicates to the user and system implementer that 3094009 |Vomiting in infants AND/OR children (disorder)| is an ambiguous concept and that it is possible to provide full semantic equivalence using individual concepts to exactly represent each element of the ambiguity and from which the user must choose one as a target replacement.

If the user does not know whether this was intended to be vomiting in an infant or child, they would choose |Vomiting in infants and children (disorder)|, at which point the system would then indicate that this concept had been inactivated and replaced by 422400008 |Vomiting (disorder) as the replacement.

This approach intends to make explicit the thinking behind the inactivation and its resolution in a way that is both machine-processable and transparent to the end-user.

There is an impact on the author/editor in having to create and then inactivate the concept that is never to be released as an active concept but much of this process could be supported by enhanced tooling.

Option 2: Using a combination of both “POSSIBLY_EQUIVALENT_TO” and “POSSIBLY_REPLACED_BY”:

3094009 |Vomiting in infants AND/OR children (disorder)|

Inactivate as “Ambiguous”:

POSSIBLY_EQUIVALENT_TO new concept |Vomiting in infants (disorder)|

POSSIBLY_EQUIVALENT_TO new concept |Vomiting in children (disorder)|

POSSIBLY_REPLACED_BY 422400008 |Vomiting (disorder)

An annotation would need to be added; “This concept cannot be made fully semantically equivalent using only clinically useful “POSSIBLY_EQUIVALENT_TO” concepts and therefore a clinically relevant “POSSIBLY_REPLACED_BY” alternative has been provided for that element that is thought to be clinically in error”.

This approach appears to give the same end result as option 1 above, however, the end-user is shielded from the detailed judgment that the author/editor made to identify full semantic equivalence of the inactivated concept. How they then identified and replaced that element that was deemed not to be clinically useful. It also makes it more difficult for implementers if the resolution of ambiguity is sometimes achieved with “POSSIBLY_EQUIVALENT_TO” alone and sometimes in combination with “POSSIBLY_REPLACED_BY”.

3. Using “POSSIBLY_REPLACED_BY” alone:

3094009 |Vomiting in infants AND/OR children (disorder)|

Inactivate as ambiguous

POSSIBLY_REPLACED_BY new concept |Vomiting in infants (disorder)|

POSSIBLY_REPLACED_BY new concept |Vomiting in children (disorder)|

POSSIBLY_REPLACED_BY 422400008 |Vomiting (disorder)

The issue with this approach is that it implies that it was not possible to provide semantically equivalent concepts for ANY part of the concept 3094009 |Vomiting in infants AND/OR children (disorder)|. This is of course not true as we have already established that 2 of the 3 elements can be provided with semantically equivalent alternatives.

Discussion:

Decision:

Positive/Negative X (finding)

The hierarchy 118245000 |Measurement finding (finding)| includes:

74 concepts of the form xxx positive (finding)

e.g. 165816005 |Human immunodeficiency virus positive (finding)|

54 concepts of the form xxx negative (finding)

e.g. 165815009 |Human immunodeficiency virus negative (finding)|

In a comment on artf 222738 - Review hierarchy: Positive laboratory findings JCA stated:

"One consideration in assessing the proper use of HasInterpretation for these types of concepts is to disallow the use of the finding values "positive" and "negative" in the concept model. These have long been problematic and do not reflect the actual capability of the laboratory test. I have been advocating for a while that we only use "detected", "not detected" and "equivocal" as results for non-numeric laboratory results due to the limits under which a laboratory test operates. We can never be certain that a test is negative as the lower limit of detection prevents us from determining true absence. The term positive implies to some people much more than is warranted by a particular laboratory test."

Given that The hierarchy 118245000 |Measurement finding (finding)| is part of the QI project a decision needs to be made on whether now is the time to review these concepts or leave them for a later date.

The observables project has sanctioned the use of 260373001 |Detected (qualifier value)| and 260415000 |Not detected (qualifier value)| for detecting the presence of organisms and I would like to propose that we adopt this approach for the positive/negative findings in this hierarchy for the purposes of modeling. The question is then whether we should seek the agreement of the community of practice to update the FSN/PT. it would be good if we could avoid wholesale inactivation and replacement.

Therefore, the options are:

1. Leave the concepts as is and model consistently with 10828004 |Positive (qualifier value)| and 260385009 |Negative (qualifier value)|
2. Leave the FSN/PT as is but model using 260373001 |Detected (qualifier value)| and 260415000 |Not detected (qualifier value)|
3. Remodel and update the FSN/PT
   1. Inactivate existing and recreate new concepts OR:
   2. Inform and get permission from the community of practice to update the FSN/PT without inactivation

Discussion:

Decision:

Decision:

There have been 8 meetings of the project group and discussions of overall scope, mission and planning have been reviewed.  VA, NHS and Nebraska have contributed usage statistics to prioritize the initial scope of activity and the primary focus at this time is Evaluation procedures with READ coding maps that are in use for lab results coding in the UK.  The most frequent use case is "Creatinine measurement, serum (procedure)" and the migration to Observables has been prototyped in Protege in order to test interoperation use cases with commonly occurring LOINC lab codes in the US.  The updated Inception/Elaboration document is attached for discussion along with a spreadsheet of the  841 concepts initially identified to fit within the template for for the first migration use case.  An OWL file with the Nebraska deployment of lab LOINC observable concepts and the first use case is also attached.

Discussion: 

Decision:

May 26, 2021