Rule blocked: CORERULES-246

[mhungria]

CG0546

2026-03-26 update:
I believe we discussed this ticket at a team meeting on May 13, 2024. It appears that I was asked if I could help addressing the rule logic and I said OK. I just created the git ticket linking to the Jira ticket to remember and complete later.
I was looking for the meeting minutes or recording of that meeting and I couldn't find those.
The notes added below correspond to the things that we discussed that needed to be taken care in the logic.

It appears that we were discussing the need of an operator/operation that could handle:

• get variable values ordered based on a string suffix translated to numeric.
  Note: we'll have to check if we already have the functionality implemented in one way or the other in the last engine version.

[chowsanthony]

Note the possibility of zero-padded sequence number. Excerpt from section 4.4.11, SDTMIG v3.4:

For example, if the type of disease milestone is "EPISODE OF DISEASE UNDER STUDY", the values of MIDS for instances of this type of event could include "EPISODE1", "EPISODE2"; or "EPISODE01", "EPISODE02", and so on.

[chowsanthony]

Also, the stripped sequence number is expected to start with 1. Excerpt from Domain SM assumption 2(b):

Sequence numbers should start with 1 and indicate the chronological order of the instances of this type of disease milestone.

[mhungria]

Note the possibility of zero-padded sequence number. Excerpt from section 4.4.11, SDTMIG v3.4:

For example, if the type of disease milestone is "EPISODE OF DISEASE UNDER STUDY", the values of MIDS for instances of this type of event could include "EPISODE1", "EPISODE2"; or "EPISODE01", "EPISODE02", and so on.

Yes, in this case the suffix is any text after "EPISODE", including a missing suffix ...
We'll need the suffix as a required parameter to such a function call.

[SFJohnson24]

@mhungria it appears your original ticket is blank-- we would like to address this ticket but there is no description about what is needed for CG0546 besides the comments above. Could you maybe add some details as to what is needed on the development side for you to proceed?

[mhungria]

@SFJohnson24, it is very strange! I'll look into it.

[eljanssens]

@mhungria to allow is to further progress toward v1.0, could you please check and provide additional details for this ticket?

[eljanssens]

@mhungria can you please add additional information on what is blocking you from programming CG0546 so that we can help you?

[mhungria]

Hi team, I added an update to the ticket description.

[gerrycampion]

I don't think we need the $records_per_usubjid_per_midstype record count operation check.
I think we need a matches_regex check to ensure that mids ends with numeric values.

Additionally, because there is the possibility of no padding even if MIDS goes past 9, I think we will need to modify the target_is_sorted_by operator, something like:

operator: target_is_sorted_by
regex: ".*(\\d+$)"

When regex is provided, it will sort only on the first regex-captured group of the string. Before sorting, it should convert to numeric if possible.

I'm not sure if 0-padded numbers will be converted properly to numeric. If not, the regex may need to be modified to ignore the zero padding.