Change WHO STAGE X Concept DataType

Hi

I have a set of concept dictionaries created with a N/A dataType and I’d like to edit the dataType do Coded in order to specify the possibles answers.

Is that a mistake if I go like that?

Cheers

1 Like

Hi @steliomo. It should work fine if you change the datatype from N/A to something else. They do that frequently with the CIEL dictionary for me. FYI: With any other datatype, it’s not possible to change the datatype if there is already data entered for that concept.

2 Likes

I think that will work fine only if one is maintaining their own dictionary metadata, but if it happens one update the dictionary to the latest CIEL, where such change is NOT effected, they would loss it and be required to go back a gain and change that concept datatype. Let us hear from @akanter if it is something that the entire community would find it useful and use when changed.

2 Likes

I believe the specific concepts @steliomo is talking about are WHO STAGE 1, WHO STAGE 2, etc. They are currently of type ConvSet / N/A. I think this is becase they are designed as answers to the question CURRENT WHO HIV STAGE.

However, instead of simply capturing the WHO STAGE, we have an MoH requirement to capture the conditions that the patient has that are associated with their WHO STAGE (i.e. the relevant conditions in the associated convenience set). Hence the proposal to change WHO STAGE 1 from ConvSet / N/A to Coded, with the possible answers being those in the ConvSet.

I also noticed the ADULT WHO CONDITION QUERY concept, which may be relevant in this discussion. It appears to be a Coded concept with possible answers consisting of the union of all concepts in the WHO STAGE X ConvSets.

How are people capturing the conditions for a patient that relate to their WHO STAGE and what do people think about the proposal to change the concept type for the WHO STAGE X concepts?

1 Like

It is important to consider how the data modeling is changing when the concept is changing. We frequently do change concepts from N/A to coded to support yes/no/unknown for people who rather record the presence of something explicitly. This is not really good practice for interoperability as a medical record which records a disease (for example) in an array of diseases, rather than a list of diseases, each with a Yes/No/Unknown answer. However, CIEL cannot enforce conformance with best practice and therefore we sometimes do this.

We also recognize that some people use a concept both as a set for UI purposes (a list of possible STAGE conditions) and as a question with those set members as possible answers.

In this case, having a WHO indicator condition really should be stored where those OIs and diseases are stored for longitudinal care reasons, and the Staging should be calculated and saved. If you have to save what actually produced the staging within the staging question, it really is redundant and not reusable. What happens when another diagnosis comes along either within the stage or to another stage?

I’d like to hear how others are handling this.

2 Likes