The pros and cons of having a flexible standard

I feel I need to make a confession. I need to admit that being a vendor of SEND software and services, drives a strong bias in how I believe the SEND standard should be defined and implemented.

In the last couple of postings, we’ve been discussing how flexible, or ‘subjective’ the SEND standard is. You may have noticed from my tone, that I have a particular dislike for such flexibility.  I’ve tried to hide it, but unfortunately my own bias seeps through.

To explain how being a vendor drives that bias, I thought we’d have a quick look at a few of the pros and cons of having such a flexible standard.

Pros

Flexibility was meant to ensure that the SEND Standard was easier to adopt. Due to the vast differences in how some data are collected and reported, the SEND standard couldn’t be too prescriptive in what it expected of data. It needed to be loose enough that if the study had a particular piece of data or metadata associated with a result, then there was a place for it, but if it wasn’t captured, then that was ok too.

That has the advantages of meaning that all organizations can embrace SEND, regardless of whether or not they capture this particular piece of information. The same principle applies to timing variables. Looking at the study data, if there are only calendar dates, then that’s fine. If there are dates and times, then that’s fine too. However, if there are just study day numbers instead, then that’s equally acceptable. Just populate what timing information there is and don’t worry about what’s missing.

Taking this approach means we have a far more inclusive standard that should allow for a wider range of studies and collection methods.

That sounds great, right? So, what’s the problem?

Cons

For many organizations consuming SEND datasets, the lack of consistency from study to study presents various issues. The obvious one being a hamstringing of cross-study analysis. How can we compare 2 similar studies when the data are rendered so differently? This is a common struggle for anyone trying to develop such tools. It is difficult when we can’t rely on variables being populated in a consistent manner. As an example, just last week we were debating the Nominal label, as this is a variable that, as well as being able to contain either a day or week number, may or may not also include timepoint information, categorical information, or scheduling information. All of these are acceptable uses, but what does that mean for the tool consuming the data?

Another difficulty is that each organization has developed their own interpretation of the standard. That makes things difficult for the humble vendor who needs to produce tools to both create and consume SEND in a range of different ways to suit the various organizations. So, obviously my bias is coming through strong here as I’d much prefer it if we could all just do SEND the same way. No options, no flexibility.

I started this post with the confession that, as a vendor, I have a poorly concealed bias against allowing SEND to be so flexible, and by end, the post is laying that bias out for all to see. As well as making things much easier for the tool developers, I also think the whole industry would benefit from SEND being more restrictive. Whether you agree or disagree, I’d love to know your opinion. Emails to the usual address marc.ellison@instem.com.

Till next time

Marc