# How to represent "other" for coded values **Category:** [RM](https://discourse.openehr.org/c/rm/42) **Created:** 2020-05-08 12:05 UTC **Views:** 2684 **Replies:** 43 **URL:** https://discourse.openehr.org/t/how-to-represent-other-for-coded-values/669 --- ## Post #1 by @danka74 Dear All, being from the Swedish SNOMED CT NRC we need to advice our users on how to represent the notion of "other" in coded value sets (mainly because wo do not want to add "other" SNOMED concepts due to semantic volatility etc). I find that openEHR have null_flavor on the ELEMENT level, but there will still be a need to provide e.g. a DV_CODED_TEXT.value even though there is no DV_CODED_TEXT.defining_code. Further, the null flavors available seem to me not to meet the needs of this not too uncommon use case. I've likely just missed some important piece of documentation, and will be happy to be adviced on the best openEHR representation of this use case. Thanks, Daniel --- ## Post #2 by @siljelb Off the top of my head, "other" usually means "something other than this list, and you can write the exact thing here in this free text field", or "something other than this list, and we don't really care which other thing". In the former case, you store whatever they put in the free text field, and in the latter you store null_flavour "unknown". I'm not sure why this doesn't work? --- ## Post #3 by @thomas.beale [quote="danka74, post:1, topic:669"] find that openEHR have null_flavor on the ELEMENT level [/quote] Well don't forget that the purpose of that (as in HL7) is to indicate that a required data item is not supplied in the data set, for some exceptional reason. It doesn't perform the function of recording a data item that you would like to code, but can't find a code for - such a data item is not absent, it's just not coded, so maybe you just see a DV_TEXT in the data. Now, dealing with that latter problem is the subject of a long discussions (in fact many over the years, as you know!). The latest version is in the SEC discussions, so you can't see it, but in summary, we decided to: * introduce the FHIR-flavoured 'strength' idea to `C_TERMINOLOGY_CODE` in AOM2. This would enable local value-sets to be classified as `required | preferred | extensible | example`, as in FHIR. * Only `required` would be regarded as a true AOM constraint; the rest are just flavours of preferred usage. This allows the runtime user to introduce codes not in the archetype or template, as long as `strength != required`. However, when there is no code at all, i.e. you might have to enter text, then you need to have left DV_TEXT open as a possibility in the archetype, which is pretty common. We are also discussing a further addition to the reference model, which is to add a `DV_PLAIN_TEXT` child to `DV_TEXT`. This would address cases where you want to force a text-only (non-coded) response, if no code is available. I don't 100% understand this use case, but @ian.mcnicoll can explain better. Hopefully you can visualise the above changes, because we don't yet have them in UML or the docs! --- ## Post #4 by @danka74 Here, "unknown" is not right, because it is not unknown, not just on the current list. --- ## Post #5 by @danka74 FHIR does not have a generic notion of null flavors, but there is a recommendation (personally from LM, don't have any specs to refer to) to add codes from the v3 null flavors to the ValueSet at hand. ISO 21090 has null flavors, particularly OTH, but at the data type level, i.e. a level or so below the ELEMENT level. Don't know if that is relevant. There is a separate (and important) question about how to constrain data to allow or not allow exceptions, but that was not my question right now, sorry for being unclear. Just to make the use case more clear, think of a (mandatory) data entry field for conditions with a value set which contains 10 (or 10 000) things. Every once in a while (depending on the setting where this is used) there will be a patient with condition 11 (or 10 001) (e.g. think of COVID-19 in January) for which there is no code in the given value set. In an archetype to represent this information there would be a DV_CODED_TEXT, how would "condition 11" be represented if there is a requirement to distinguish this case from other reasons for not providing a code? Thanks, Daniel --- ## Post #6 by @thomas.beale Well if we assume the proposal I described above, then you would be able to set an indicator on any C_TERMINOLOGY_CODE constraint (which is what applies to DV_CODED_TEXT.defining_code) to say `extensible`, meaning: use one of the codes here if it applies, but you can add your own codes as well. Now, if you don't have a code, you are in the position of choosing between a coded term and just entering text. To do that (a common situation in archetypes), you need to have the DV_CODED_TEXT and DV_TEXT constraints both on the data point in question. --- ## Post #7 by @linforest Classifications like ICD often include such kind of "catch-all" codes as NEC(not elsewhere classified) codes. Terminologies/Ontologies, such as SNOMED CT, don't like these concepts which meanings are not persistent depending on the other sibling codes. You will never get a snomed ct code for such a concept. Maybe it's a open-vs-closed world issue. Related Links: When Is Content Rejected? https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=71172163 Comparison between a SNOMED CT Problem List and the ICD-10-CM/PCS HIPAA Code Sets http://library.ahima.org/doc?oid=301254#.XrXwBda-sTk --- ## Post #8 by @linforest Whether it's ontologically/terminologically reasonable, such “catch-all” codes are common. So it would need an explicit solution. --- ## Post #9 by @siljelb It may not be unknown for the person recording the data, but in effect it would be unknown for the record? Or is it necessary to record that it's not in the provided list? If so, could that be a possible new null_flavour? --- ## Post #10 by @thomas.beale [quote="siljelb, post:9, topic:669"] If so, could that be a possible new null_flavour? [/quote] This still wouldn't be a null flavour. If you have a data value, it's not null, even if you've only got text, or a rough numerical estimate instead of a proper value or whatever. Null flavour is for when you have on value at all. --- ## Post #11 by @siljelb I may have expressed myself badly. What I meant was something like this: > Question: > * Option 1 > * Option 2 > * Option 3 > * Other In this case, 'Other' means something like "Not option 1, 2 or 3, but otherwise unknown". So the "value" in 'Other' would be the fact that it's none of the other options? To me this feels like a sort of limbo state between null and an actual value? --- ## Post #12 by @danka74 Agree it is not a null flavor on the ELEMENT level, possibly a "null flavor" on e.g. a DATA_VALUE.value or DV_CODED_TEXT.defining_code. There is a generic notion of the scale and/or data type being insufficient for representing what the reporter wants to express, and this could be lack of an element in a ordinal or nominal scale list, i.e. lack of a code in a value set, or that interval or ratio scale lacks the necessary precision (likely less common) or that a value is outside of the boundary. --- ## Post #13 by @thomas.beale Right but if that 'other' is the true state of the clinician's knowledge of the response, then that's not a lack of data, it's a value that correctly represents the current understanding. Example: at the point in time when 'non-A non-B hepatitis' was recorded for hepatitis that wasn't one of the two known types, that was the medically correct answer. Null flavours are for situations like when a machine is malfunctioning and can't supply any value to its user e.g. battery runs out in a thermometer and you just can't take a temperature, or patient is unconscious and can't tell you anything about his/her allergies or meds. --- ## Post #14 by @thomas.beale [quote="danka74, post:12, topic:669, full:true"] Agree it is not a null flavor on the ELEMENT level, possibly a “null flavor” on e.g. a DATA_VALUE.value or DV_CODED_TEXT.defining_code. There is a generic notion of the scale and/or data type being insufficient for representing what the reporter wants to express, and this could be lack of an element in a ordinal or nominal scale list, i.e. lack of a code in a value set, or that interval or ratio scale lacks the necessary precision (likely less common) or that a value is outside of the boundary. [/quote] Well I see this as a bit different (maybe it's what @siljelb really meant) - if the provided choices are less representative than the true state of knowledge of the HCP, then possibly we do have a new kind of 'absent value'. This could happen when the technical means of providing values - UI forms, pick-lists etc, are simply missing possibilities that exist in real life. Maybe they have an 'other' item, but no box to record 'details', or the choices are simply too restrictive. So if I understand correctly, you are saying you would like a way to record 'value unavailable'. However, it seems to me that if the technical means of input has been built to prevent any proper recording of 'other' values, it will also probably not allow you to record the lack of that means of input - i.e. it's a UI design problem. Does this more closely describe the situation? --- ## Post #15 by @danka74 Non-A non-B hepatitis is a slightly (but not completely) different case. If in the 80ies only A and B were available in a paper check sheet, the reporter would tick the "other" box. That what was later to become (mostly) hepatitis C was initially called "Non-A non-B hepatitis" (and non-ABC --> D) might be more of a naming issue (the researchers knew they had found a new kind of virus), but highlights in a clear example that healthcare and medicine is constantly evolving. My initial question was not really a semantic one (negation semantics is tricky...), but a technical one. --- ## Post #16 by @danka74 [quote="thomas.beale, post:14, topic:669"] if the provided choices are less representative than the true state of knowledge of the HCP, then possibly we do have a new kind of ‘absent value’. [/quote] yes, this is the case I was trying to describe, but not necessarily in relation to any UI. In any constrained list of alternative values, for whatever reasons (novel cases, overly constrained value set, ... things happen) the alternatives might not always be sufficient. Some of these issue can be addressed by amending the archetype or the code system, some might not be worth the effort to address, some might need research to evolve, etc. etc. but at any given point in time, there can be a need to say "I could not express what I wanted to say under the current constraints". --- ## Post #17 by @ian.mcnicoll That's a good summary Thomas but there are 2 quite different scenarios. I agree that other is not really a null flavour', it is saying that I can answer the question affirmatively buth at the answer I want to give is not in the list you have provided Hepatitis is a good example 1. Operational. It is usually unhelpful to just record 'other' as a codedText and as Silje said earlier, other in this case is usually accompanied by a text box that allows other coded_text or free text to carry the actual response. In this case, 'other' can be regarded as a navigational directive and is never actually carried in the data. It is unusual to have 'other' coded as an actual response in operational clinical data but it can happen. As an example, I am working with a dataset to be used by paramedics in assessing possible COVID-19 risks and there are a couple of places where 'Other' (without further clarification) might be acceptable as-is because these folks are working quickly, with limited information and possibly without the clinical experience to capture more detail authoritatively. 2. Analytics, registries, research. In this situation, the use of 'other' as an acceptable final response is common. In this context specific knowledge of what the 'other' was, is not of any direct interest to the recipient. It is the old classification vs. terminology discussion. I agree that we should not be adding 'other' to SNOMED CT hierarchies, both in principle, but also because 'other;' is purely contextual to the actual alternative responses in the UI. Why not use 74964007 | Other (qualifier value) | and accept that the true meaning of this can only be inferred from the context of the question and alternative possible responses? --- ## Post #18 by @thomas.beale [quote="ian.mcnicoll, post:17, topic:669"] Why not use 74964007 | Other (qualifier value) | and accept that the true meaning of this can only be inferred from the context of the question and alternative possible responses? [/quote] I would have thought the standard modelling approach would be to do what you already do - keep the DV_TEXT (or, in future? DV_PLAIN_TEXT) around for precisely the situation where the coded choices are lacking? Or is the problem guessing when this is likely to happen? --- ## Post #19 by @danka74 [quote="ian.mcnicoll, post:17, topic:669"] Why not use 74964007 | Other (qualifier value) | and accept that the true meaning of this can only be inferred from the context of the question and alternative possible responses? [/quote] That is much like the FHIR solution, but where a code from another code system is used to indicate even stronger that no one should even think of trying infer any meaning from the position in SNOMED CT. --- ## Post #20 by @danka74 [quote="ian.mcnicoll, post:17, topic:669"] It is usually unhelpful to just record ‘other’ as a codedText and as Silje said earlier, other in this case is usually accompanied by a text box that allows other coded_text or free text to carry the actual response. [/quote] It might be, and often is, helpful to address areas where the value set should be expanded, although the value "other" itself is not clinically useful. --- ## Post #21 by @danka74 So in summary there has been a few solutions presented: * Using a choice of DV_TEXT or DV_CODED_TEXT * Adding an "other" code to the value set. There are three flavors of this: ** (If the code system is SNOMED CT) Add 74964007 | Other (qualifier value) | ** (For any code system including SNOMED CT) Add a code from a separate code system, e.g. OTH from v3 null flavors ** Choose the most generic code possible in the relevant hierarchy (solution not presented here, but has been used in implementations, e.g. choose 123037004 | Body structure (body structure) | to represent "other body structure") Would it be possible to have an agreed on standard recommended solution for this use case? Thanks, Daniel --- ## Post #22 by @ian.mcnicoll > * Using a choice of DV_TEXT or DV_CODED_TEXT Would be my first choice, particularly in any operational setting. > * Adding an “other” code to the value set. There are three flavors of this: > ** (If the code system is SNOMED CT) Add 74964007 | Other (qualifier value) | That would be my first preference in any SNOMED licensed environment. > ** (For any code system including SNOMED CT) Add a code from a separate code system, e.g. OTH from v3 null flavors That would be my first preference in any non--SNOMED licensed environment, though I don't think this is really a null-flavour in the openEHR world > ** Choose the most generic code possible in the relevant hierarchy (solution not presented here, but has been used in implementations, e.g. choose 123037004 | Body structure (body structure) | to represent “other body structure”) That sounds attractive but assumes that there is a relevant hierarchy for the valueset, which is not always possible. but for all 3 options, we are really just talking about a 'convenience' term, since 'other', however we express it can never really have any clear meaning without reference to the original question, and construction of the valueset. If it was openly licensed I would vote for `74964007 | Other (qualifier value) |` as that 'convenience term' --- ## Post #23 by @linforest `74964007 | Other (qualifier value) |` should be an adjective as its sematic tag says (i.e., a qualifier). So it doesn't have any meaningful meaning without a noun (e.g., a disaease or a anatomical structure...) it is intended to qualify. --- ## Post #24 by @ian.mcnicoll and in a pure terminology world, that is , of course correct. But, I think we are starting to see how, although such a world is theoretically possible, it is actually very difficult to achieve, and that combining the strengths of information models along with terminology, is a far more tractable solution. Broadly speaking in Daniel's scenario, the information model is acting as the 'noun' - it is acting the question, setting the context, because trying to shoehorn all of that into a single term, just becomes hugely complex. As an example I am working with an app where users are asked about a set of significant co-morbidities partly related to COVID-19. These are further sub-divided into rough groups of conditions e.g Diabetes, cardiovascular, respiratory. Within each group there is an 'other' condition. The context which the terminology would have to squeeze in would be patient-record context (situation), screening for conditions related (roughly) to COVID-19 but somewhat arbitrary, further subdivided into condition- related groups and within each of those groups, this in an 'other' condition e.g an 'other' Cardiovascular condition, not included the terms already offered. So I would argue that even combined with a noun like an condition, it is still not meaningfully meaningful, as you cannot know what 'other respiratory condition' means unless you know what has been offered. That does not take away there being utility in having a standard term for 'Other' used across various contexts, whether we use SNOMED-CT or not. --- ## Post #25 by @thomas.beale [quote="ian.mcnicoll, post:24, topic:669"] information model is acting as the ‘noun’ - it is acting the question, setting the context, because trying to shoehorn all of that into a single term, just becomes hugely complex [/quote] well... yes, but to create a structurally correct term include that 7464007 isn't hard - just grab the closest parent you can get in the hierarchy (as per @danka74's last bullet point) and post-coordinate with the `Other (qualifier value)` term. This approach probably doesn't improve the semantic situation of the example, but in a lot of other situations it could fairly accurately represent the situation. Anyway, I don't think using naked qualifiers is a good idea - it means the terms won't process properly in software making even the most basic assumptions about Snomed. --- ## Post #26 by @ian.mcnicoll but how many systems around the world can work with post-coordination and do we really see that changing in the next 10 years? If you live in a SNOMED only world , there is no option but we do not live in a SNOMED-only world, we have other more appropriate ways of querying contextually, where SNOMED is a very powerful part of the solution. [quote="thomas.beale, post:25, topic:669"] Anyway, I don’t think using naked qualifiers is a good idea - it means the terms won’t process properly in software making even the most basic assumptions about Snomed. [/quote] Will I agree but that assumes that the processing system is wholly reliant on SNOMED to safely and fully resolve meaning, which I would argue has been an unhelpful, and indeed untenable goal. Within carefully constructed settings (sometimes the headings will work well enough) but that is only because that is already accepting that we are not creating any kind of 'universal semantic' . This a purely dataset-specific construct. --- ## Post #27 by @linforest Maybe we should defer such a terminology binding to the openEHR implementer before a common ontologically formal representation for these is defined. --- ## Post #28 by @thomas.beale [quote="ian.mcnicoll, post:26, topic:669"] but how many systems around the world can work with post-coordination and do we really see that changing in the next 10 years? [/quote] I don't know in fact, but if systems that use Snomed cannot routinely handle the 'basic' post-coordinations of laterality, or the example we have here, Snomed isn't going anywhere... --- ## Post #29 by @ian.mcnicoll My understanding is that there is practically no use of even simple post-coordination - that is partly because if introduced (even only minimally) , it would have to be fully supported by the wider community. There are definitely some places where it might help, but many others where practically speaking, it is just much easier to coordinate attributes using an information model. Through FHIR and openEHR, I think we are starting to see real standardisation of workable 'universal' standardised information models, particularly for the big-ticket items like Meds, Allergies, problems etc, which also make it much easier to express wider context. That is not to underplay the very significant role of terminologies, particularly SNOMED CT - they play a critical role in the leaf node values, particularly the power of inferencing. Allergies is a great example - an ongoing issue in the terminology space has been the need to represent every possible medication substance X (and product Y) as an 'Allergy to X' and 'Allergy to Y' codes. Before SNOMED-CT this would have been simply a case of creating new allergy codes for every new substance and product. Clearly this is a place where pos-coordination should help since one can simply coordinate a generic 'Allergy to' code with a code for the substance. So far so good but in practice, there is no need ot do this, at least in EHR systems, since they invariably have an information model for 'allergy' which controls the context of the substance code as 'causative/substance/agent'. FHIR and openEHR handle allergies pretty well identically, so that string simple use-case has disappeared, unless you try to use only SCT and it's own concept models. I'm not sure that ever really makes sense, other than perhaps in some downstream analytics environments and perhaps that is where post-coordination might be useful, assuming that the 'target' audience does demand/prefer pure SNOMED expressions. I am actually increasingly positive about SNOMED CT uptake and use, precisely because it is being understood to have much more value when used in combination with other approaches. Attempts to push past the 'comfort zone' have actually held things back. --- ## Post #30 by @yampeku This is a tricky case :slight_smile: After reviewing the Snomed MCRM, there is not a single attribute that accepts `74964007 | Other (qualifier value) |` as part of its range. This means that **any postcordination that uses this concept as a value for an attribute is invalid per definition**. It's a leaf node with no other relationship than his parent. In my opinion, something that when used in a postcordinated expression will always violate the MCRM is not a desirable value to put, and in that case I would go with any other code in any other terminology (probably is even better to define a code in the openEHR one) that really encapsulates the meaning. PS: If we create a new openEHR code I propose to use the code "666", as nothing expresses better the feeling of "here be dragons" :see_no_evil: --- ## Post #31 by @linforest Loosely speaking, if the value set is {A, B, C, D, Other} and it's a concept of fruits, then the option/member "Other" could be defined as being a kind of fruit **AND** *NOT* any member of the set {A, B, C, D}. Am I right? --- ## Post #32 by @siljelb [quote="linforest, post:31, topic:669, full:true"] Loosely speaking, if the value set is {A, B, C, D, Other} and it’s a concept of fruits, then the option/member “Other” could be defined as being a kind of fruit **AND** *NOT* any member of the set {A, B, C, D}. Am I right? [/quote] That's my interpretation as well. --- ## Post #33 by @yampeku Yes, but probably not with that Snomed code if someone would try to automatically generate postcordinations from them. To elaborate a little more, MCRM tells you which kind of postcordinations are valid and which not. MCRM defines exactly which subset of snomed codes are valid for a given attribute (and attributes domains, etc.) For example, `733930001 |Regional part of (attribute)|` valid values are `<< 123037004|Body structure (body structure)|` (which means all descendants of body structure) Another example: `363699004 |Direct device (attribute)|`valid values are `<< 49062001 |Device (physical object)|`(which means all descendants of device) These valid ranges can come from several hierarchies (e.g. `118170007 |Specimen source identity (attribute)|`can come from 6 different subhierarchies (the expression is `<< 125676002 |Person (person)| OR << 35359004 |Family (social concept)| OR << 133928008 |Community (social concept)| OR << 276339004 |Environment (environment)| OR << 260787004 |Physical object (physical object)|`) This MCRM defines a Snomed "reference model" of sorts, so you cannot really use any code where you want. --- ## Post #34 by @yampeku Problem is, that same code would mean 2 completely different things depending on the context where it's put. Moreover, if (when) snomed releases more codes, the meaning would probably also change. That's one of the reasons why IHTSDO does not usually put codes such as "other unspecified form of whatever" --- ## Post #35 by @yampeku While its parent (106232001 |Adjectival modifier (qualifier)|) has 512 direct or indirect children, only 50 are even used as ranges by any attribute of the MCRM. "Other" is not one of these. --- ## Post #36 by @siljelb For sure. NEC codes are super problematic when coding for any other reason than statistics. --- ## Post #37 by @ian.mcnicoll Interesting challenge!! Looks to me as if we need.. 1. A way of expressing 'Other' as the defining_code of what was entered which means what Lin said [quote="linforest, post:31, topic:669"] a kind of fruit **AND** *NOT* any member of the set {A, B, C, D}. [/quote] 2. We cannot use the SNOMED-CT code for 'Other' in any way which fits the SNOMED concept model. 3. We can use some sort of immediate term in a suitable hierarchy but an appropriate term may not exist or be too broad to be truly meaningful. In that sense it is probably just a placeholder that allows 'something' to be said in the SNOMED compute space, but probably not something very meaningful or accurate. Even if (3) is the recommended approach, we will still need to express 'Other' as the defining_code, so there is an argument for having a universal 'other' code. I's exact meaning would be wholly contextual but at least that fact is flagged up. --- ## Post #38 by @yampeku For 3, there are a few "other" kind of codes in snomed, but seems only when the domain uses them in common practice such as: `258348004 | OTH (body structure) |` for anatomical site notations in tumor staging or `346602001 |Other foods (product)|` for diets. There seems to be a common use case in snomed to try to remove every "other" concept they have e.g. `212495009 | Other specified injuries (disorder)|` was made inactive in recent Snomed releases --- ## Post #39 by @ian.mcnicoll I understand and support the removal of 'Other x' codes from SNOMED CT but I'm not sure why the ones you mention should have any particular significance or use in common practice. Special pleading!! --- ## Post #40 by @yampeku I mean that there are refsets where "other" has an existing code, but not the general one discussed above. And should be ok to use these in their corresponding domain. But in general the use of "other" is dangerous as they tend to be inactivated. --- ## Post #41 by @linforest Such "Other" concept codes reflect one of the key differences between the"closed-world" system (classifications such as ICD-x) and an "open-world" system(terminologies/ontologies such as SNOMED CT) . These codes hardly fit into the latter even some of them are already inluded by the latter (for example, for mapping). The use of Such codes should be restricted explicitly. --- ## Post #42 by @Colin_Sutton I think two types of 'Other' are needed, one which just allows a DV_TEXT and one called e.g. "Other missing from list" that also allows a DV_TEXT. Then, when the new entry is eventually added to (e.g. SNOMED) it could be post-coordinated. Maybe I'm too optimistic about such a possibility. --- ## Post #43 by @heather.leslie Noting, of course, that the free text values inserted under the banner of 'Other' will often be reviewed at a later date and may be used to expand the original coded value set. --- ## Post #44 by @bna This is a challenge we often meet building models for clinical applications. We are building models for a colonscopy report these days. The data will be exported into (at least) two different national registries. For the new national screening program they have developed FHIR profiles for the data. I will share a few examples. **Further plan/follow up** As part of the procedure the clinician should make a statement about the follow up. This is the FHIR valueset for this statement: [nocolonoscopyfollowup](https://simplifier.net/norwegiancolonoscopyreport/nocolonoscopyfollowup) As you can see the valueset combines SNOMED-CT codes with the FHIR null flavor statement **"OTH::other"**. To make the openEHR model clean we decided to use the SNOMED-CT other qualifier. We ended up with the following valueset for our openEHR template: ``` [ "SNOMED-CT::10031000202109::No follow-up (situation)", "SNOMED-CT::10041000202103::Histology result not back (situation)", "SNOMED-CT::703993001::Colonoscopy planned (situation)", "SNOMED-CT::10051000202100::Referral to further evaluation and/or treatment (situation)", "SNOMED-CT::10061000202102::Virtual computed tomography colonoscopy planned (situation)", "SNOMED-CT::74964007::Other (qualifier value) " ] ``` **Current medication** The registry need a list of relevant drug categories, for use in reporting in connection with colonoscopy. The FHIR valueset is defined here: [nocolonoscopycurrentmedication](https://simplifier.net/norwegiancolonoscopyreport/nocolonoscopycurrentmedication) This is a mixed valueset from multiple systems. We wanted a clean openEHR model. First we wanted to create a specific archetype for this. The idea was to model the valueset as an archetyped DV_CODED_TEXT. But - the use of such medications is a precaution related to the colonscopy procedure. There is a reviewed archetype for precaution: [ openEHR-EHR-EVALUATION.precaution.v1](https://ckm.openehr.org/ckm/archetypes/1013.1.2593). We decided to use this. Then we had to make a valueset to add to the element *Condition*. We ended up creating a registry specific terminology: ``` SCREENIT-MEDICATION::M00::Nil Known SCREENIT-MEDICATION::M01::Aspirin (substance) SCREENIT-MEDICATION::M02::Other platelet inhibitors SCREENIT-MEDICATION::M03::Warfarin (substance) SCREENIT-MEDICATION::M04::DOAK SCREENIT-MEDICATION::M05::Low molecular weight heparin (substance) SCREENIT-MEDICATION::M06::Other anticoagulants SCREENIT-MEDICATION::M99::Other SCREENIT-MEDICATION::M100::Unknown / missing information ``` This is kind of dirty modelling approach combining different terminologies into a single valueset. Anyway we solved the problem at hand within a reasonable use of time and resources :-) --- **Canonical:** https://discourse.openehr.org/t/how-to-represent-other-for-coded-values/669 **Original content:** https://discourse.openehr.org/t/how-to-represent-other-for-coded-values/669