Mayo score - ready for publication

Hi, everyone

The archetype “Mayo score” has been through one review. There were no major issues to solve, only minor changes in wording. The editorial team suggest publishing.

If you have any comments or objections, please note them here, at the latest in time of the planned publication date, April 20th 2021.

Link to the archetype: Mayo score

3 Likes

Congratulations. Good to see as a community we can do a quick and simple review and publication for a simple archetype:)
I saw one comment in the review: “ Should the Mayo score be calculated from the use of individual observation archetypes such as rectal bleeding or endoscopy findings or stool observations?”
And I’m interested in the editors response, but could not see it.

The answer is no in principle because we have just represented a validated and commonly used score/scale. If an application can be smart and propose/derive possible answers to the clinician recording, I guess that is always possible, but not directly intended as part of recording the score.

2 Likes

Any recommendations or best practices where to put the semantic part of that propose/derive logic?
So I mean the information/logic that rectal bleeding value in the element in the score can be proposed/derived from a rectal bleeding element in a sign/symptom cluster?

Not off the top of my head. It is feasible that an OBSERVATION about bowel motions might record the bleeding in some semi-qualitative way, but reliably deriving the most severe is probably more complicated than we first think.

Hi Heather, thanks for your answer. And if there would be a perfect archetype that contains this specific information (e.g. a sign/symptom cluster with a matching name element of “rectal bleeding”). Where would the logic/information that the presence of this cluster, implies presence of rectal bleeding in this score archetype go?

Hmmm - I’d forgotten this early draft, Examination of faeces - https://ckm.openehr.org/ckm/archetypes/1013.1.3543. It clearly still needs some work. In a template it could be nested within either the OBS for Physical exam or Faecal output.

If you can suggest how you would ideally link from this archetype to the Mayo score, then it should be added as a change request.

Hi Heather,

I don’t know the ideal way to link this information, this was in fact my question. I see several directions but no ideal way yet.

  • change the rectal bleeding element to (add a) DV_EHR_URI that will store the link to the rectal bleeding element in Examination of faeces. Then implementers will have to build the logic to resolve this information when rendering. But to do that the automatically, the DV_EHR_URI needs to contain a regex to constrain it to only link to that element (like we do with use_archetype).
  • we could build an aql query that resolves the info at the Examination of faeces rectal bleeding element. But how do we store an aql query in an archetype? rules could work but doesn’t at the moment.
  • we could rebuild this archetype and replace the element with the cluster, but that would add superfluous information, that can only be hidden in a template(overlay).
  • we could use annotations section of this observation archetype to specify the linked information, but to make this computable we would need a specification for this type of information. And it doesn’t feel like the right place.

Any other thoughts?

Hi Joost,

As I understand it, all elements have an attribute LINK class as part of the RM including a DV_EHR_URI. The specs seem to suggest that it is better to link at archetype level, but it can happen when required at element level. “Links can potentially be used between interior (i.e. non archetype root) nodes, although this probably should be prevented in archetypes.” So we don’t need to archetype it, otherwise we’d have data element/URI pairs throughout every archetype. Happy to be corrected by an RM expert who knows better.
This archetype is good to go. Not sure what you mean by replacing part of it with a CLUSTER but we need to represent the content correctly. Implementation conundrums would be best solved using tooling - if you’re identifying an issue here, then it is likely to be occurring in other places as well. It seems a little ‘tail wagging the dog’ scenario if we build archetypes to solve implementation issues.
Others might be able to respond to your other comments.

Cheers

1 Like

I agree Heather.

@Joost - definitely have a look at GDL2 - this is exactly what it is designed to do, including recognising that depending on the exact scenario, the ‘source data’ can be handled in quite different ways.

https://gdl-lang.org/

1 Like