Template renamed, repeatable structures

In Ocean’s Template Designer, you couldn’t rename a container or element and simultaneously keep it repeatable; you had to choose between renaming and repeatability.

Technically this made sense, because the method used for telling the repeated instances apart was to append ‘#1’, ‘#2’ etc to the name at run-time. This of course isn’t technically valid when you’ve pre-constrained the structure’s name in the template.

However, for non-technical modellers this approach doesn’t make sense at all, and Better’s Archetype Designer removed the constraint a few years back. The way I understand it, and correct me if I’m wrong, Better handles this validation issue by overriding the name validation against the template in the case of repeated structures with the appended ‘hashtag number’. This works in practice, but seems slightly hacky to me.

What I’m wondering about though, is how other implementations handles this issue.

DIPS doesn’t currently handle it, and expects templates to conform to the strict interpretation from Ocean’s Template Designer. From a modelling POV this is unintuitive and cumbersome, but works as long as you’re only creating templates for internal use. However, once you want to share your models more widely you run into trouble.

But what about for example EHRbase and EHRserver? How do you handle this peculiarity?

As a PS, have there been any initiatives in the SEC to create a way to uniquely identify instances of repeatable structures independently of the name of the structure?

2 Likes

Now that you’ve all had a month to think about this, what are your thoughts? :innocent:

I believe the Ocean and EhrBase CDRs do the same thing.

The unique path rule was relaxed in the spec, from my understanding, at least for run-time repeatable structures.

There have been a few attempts to get consensus on how to uniquely label repeating structures (basically some kind of item number vs uid) but none reached so far.

2 Likes