Hi all , I am trying to modelling the following document for Systemic Lupus Erythematosus Disease Activity Index (SLEDAI) - http://www.sledai-2k.com/sledai2k.pdf
But I am in doubt what should be the best modelling approach for this case. I had a talk with @ian.mcnicoll and already found 3 different ways to make the same thing, but I don’t know exactly what should be the best or if there are some modelling patterns/styles for this case.
In the following links you can see the 2 archetypes that I created quickly for testing. One uses an ordinal type with the different descriptors as internal runtimes codes and uses the weights as ordinal values ( example: Archetype Designer) which can later be multiplied at the template level and will look something like this:
, the other uses one single field “descriptors” with multiple occurrence and all descriptors are within the ordinal value ( example: Archetype Designer )
Other case would be creating an element ordinal type for each descriptor, like a list, similar to this example: (Archetype Designer)
From the community perspective what could be the best approach?
I’d mimic it, using an OBSERVATION archetype containing 24 DV_Ordinal data elements, one for each question, with No = 0 and Yes = n, plus final DV_Count data element for the ‘Total score’. All of the content can be simply and unambiguously represented within the archetype so that it is clear for others creating templates and implementing, and the bonus is that it is most consistent with other Scale/Score modelling patterns. Your other options have all been worth exploring and I appreciate you offering them as possible options but are using modelling patterns that are quite different from most other archetypes.
But only marked and counted the ordinal value at the options marked with “yes” - the yes is mapped to the ordinal values to the template and then the sum is calculated and saved on the total score element (dv_count).
But i agree with you, since this is a score it makes sense to save the no values as 0 too. I did it in the last example and as you suggest it i will re-do in this case too. (EDIT: here it is the rebuild version - Archetype Designer )
There’s a couple of minor copy/paste edit issues where ‘Yes (+8)’ is associated with the +4 value. In truth, I would suggest we just go with Yes/No options throughout and no values TBH. The person entering the data probably doesn’t need to see it and we don’t do it for any other data elements.
The concept and ID naming convention we are using can be found here: https://openehr.atlassian.net/wiki/spaces/healthmod/pages/304742407/Archetype+content+style+guide#Scores-and-Scales.
Given the full name Systemic Lupus Erythematosus Disease Activity Index 2000 (SLEDAI -2K ) is really, really long, it might be worth compromising to “SLE Disease Activity Index 2000 (SLEDAI -2K)” and the ID as you suggest, above. The concept name is capitalised to align with the acronym.
The SLICCACR index is even worse I note that the SLICC group refers to it as the SLICC/ACR index, but it seems to be shortened to SLICC Damage Index - SLICC Damage Index :SLICC. Maybe we could go with that and ensure that ACR is included in the keywords and the concept description. I’d suggest a compromise concept name of ‘SLICC damage index’ with an ID of OBSERVATION.slicc_damage. The concept name is only capitalised as ‘sentence case’ because there is no acronym.
Agreed description and comment phrasing for the Extension SLOT can be found here: https://openehr.atlassian.net/wiki/spaces/healthmod/pages/304742407/Archetype+content+style+guide#Data-elements
Hi! thanks again for your reply. i have changed accordingly to your suggestions - i think the ADL designer URLs now show the updated version. I just can’t change anymore from today on because it breaks the forms that I already build - low code things… - and i don’t have really more time to keep changing it, but once it goes to ckm if any necessary change is needed, feel free to change it of course
There’s a couple of minor copy/paste edit issues where ‘Yes (+8)’ is associated with the +4 value. In truth, I would suggest we just go with Yes/No options throughout and no values TBH. The person entering the data probably doesn’t need to see it and we don’t do it for any other data elements.
Yes I agree, but this can be changed at the application level, showing only “Yes” and not “Yes (+4)” or “Yes (+8)”. The reason why I have added in the DM it’s more for self-explanatory element value. I have noticed that in translations, the translator will see “Yes” with different AT codes (but many of them don’t even know what the atcodes mean) so I added the (+X) to be easier to realize that actually are different “yes” - I know semantically they mean the same but I guess it facilitates later?
it might be worth compromising to “SLE Disease Activity Index 2000 (SLEDAI -2K) ” and the ID as you suggest, above. The concept name is capitalised to align with the acronym.
If I understood it correctly, do you mean this way? before i had “SLEDAI-2K” only
Agree that this can be adjusted at the application level, but the Editorial pattern for all the similar archetypes in CKM goes the other way, not displaying the value. If it is proposed to CKM, this annotation would be likely removed. The +4 or +8 is effectively redundant because it is represented in the Ordinal value and not usually displayed to a clinician filling out the form. If there was an error or divergence between the ordinal value and the text, it adds more complications (although conceding it may also help pick up an error ). So it comes down to a longstanding Editorial decision, rightly or wrongly, and I’m not sure it’s a critical issue. I also wonder if it could be argued that seeing the score may influence the way a clinician enters data - there must be a research project about that somewhere, or it is just me?
Ok, i will change it since it’s a non-breaking case.
I also wonder if it could be argued that seeing the score may influence the way a clinician enters data
I usually avoid to display any kind of scorings in the UI due to that reason.
Thanks for all the help. I will send the archetypes in the end of this month to the ckm, they will likely go into production at my side in the same period.
I note that the SLICC group refers to it as the SLICC/ACR index, but it seems to be shortened to SLICC Damage Index - 
