The SEND Traffic Jam

I hope you enjoyed my last blog post that discussed the differences in the analogue world versus the digital world, and how this gets us into a debate about whether SEND should represent the data we collect, or represent the data we report.

Following on from that, this analogue-versus-digital discussion has got me feeling a little nostalgic. If like me, you are of a certain vintage, then I’m sure you can remember having to travel to a VHS rental shop if you wanted to enjoy a movie for the evening; or having to wait days to have your photos developed. Back then, living in an analogue world without streaming, meant things took time.

Yet now, it seems that the whole world has got faster due to digital data and standardized formats. So why are we hearing about studies getting stuck in the SEND Traffic Jam? Why are we seeing wait times for SEND conversions increasing and some organizations seeming to have an ever growing SEND backlog?

At a recent industry meeting, the FDA asked about the impact of SEND and the amount of time it is taking to convert a single study. While Instem’s average is 4 weeks, the consensus was an average of 8 weeks of elapsed time.

Living in the digital world, we are expecting things to be faster, not slower, so why are we seeing this extra time needed after the creation of the antiquated analogue appendices?

So clearly, we are talking about safety assessment data and not simply our holiday photos. As such, SEND datasets are not naively accepted as they first roll out of the machine. They’re checked for accuracy, compliance and human beings decide if the data are rendered in a way that best suits the study. This subjective element is often the most time consuming, and that’s because interpretation of the SEND standard itself, is highly subjective.

These are just some of the factors, and all of these things take time. So, there are good, legitimate reasons to explain why SEND conversions are not as instant as simply streaming Netflix on a Friday night. It’s more like restoring an old 35mm movie into a high-definition multi-media experience. Just like SEND, it requires time, expertise and the results can certainly vary in quality.

Organizations have more choices than ever, including internal IT departments for creating SEND. It’s vital that they have the right SEND partners and collaborators to ensure they are meeting the requirements of sponsors, the FDA and any other consumers of the data.

As always, if you’d like to continue this conversation, or have a topic you’d like me to address, drop me a line.

Till next time

Marc

Skeuo-what now?!

Does SEND include any skeuomorphs?

Okay, strange word I know – stay with me…..

Why does my phone make the sound of shutter when I take a photo? It doesn’t have a shutter, and even if it did, I wouldn’t be able to control its volume level. Yet, I hear that satisfying old school shutter sound every time I click. Do you think there are kids alive today who have only known digital cameras and don’t even know what that artificial sound is trying to mimic?

When I read a PDF on my tablet, why I am swiping to turn imaginary pages? Why are there even imaginary pages?

I guess its human nature to try to mimic the analogue in the digital world. It’s familiar. It makes the transition easier.

By the way, such idiosyncrasies are called skeuomorphs. Taking a strange functional artifact of one media into another where it no longer has function. In this case, replicating an analogue quirk in digital format.

Does SEND include any skeuomorphs? It’s an interesting question. On face value we’d probably say not, but scratch beneath the surface and I think we get into the debate about whether SEND should be a representation of the collected data or the reported data. Most of the time, in the nonclinical world, these are the same thing, but not always. Food and Water Consumption is the entrance to this particular rabbit hole. We collect Given Amount and Residue Amount, but report a calculated consumption. Ok, that’s not a skeuomorph in itself, but we are just getting warmed up here. What about scenarios where food is collected daily, but reported weekly, or by some other interval, usually to save space on the page? If the SEND dataset reflects the weekly reporting, then are we representing our data a certain way in SEND to save space on a page?

Now, that’s definitely starting to sound like a skeuomorph.

Well, here’s something that cropped up here at Instem, in the last week or two as we were converting a DART study, but don’t worry, you don’t need to be a DART expert to accompany me through this example. Due to the volume of data on Embryo Fetal Development studies, it’s common practice to only report positive findings, and not list pages of ‘Unremarkable’ or ‘Normal’ or what ever term your system uses. So, should SEND include all of these unreported ‘Normals’? If omitted from SEND, and therefore matching the report, we’d be omitting data simply to save space on a page. Clearly a skeuomorph. So, in our software, we have chosen to include these records. We are going with what is collected, not what is reported. Yet, remember that differences between the SEND datasets and the study report need to be clearly explained in the nonclinical Study Data Reviewers Guide (nSDRG).

We also encountered other examples where collected and reported differ,  and sometimes it seemed appropriate to go with what was collected, and at other times we go with what was reported, but I’ll save those examples for another day.

Finally, I’ll leave you with the next question on this particular trail: What about Rationalized data? Whether it’s Pathology data, Clinical Signs, or Fetal Pathology, data are often rationalized at report time for ease of analysis and/or the best use of the available space on the page. Which do we include in SEND?

And now you’ll forever be reminded of SEND whenever you hear the artificial shutter sound on your camera’s phone. That’s one of those Skeuo-what-now thingies.

Till next time…

Marc

Is the world of SEND moving too fast?

Well, March 2021 turned out to be a big month in the world of SEND. The FDA issued their 90-day notice for the enforcement of the Technical Rejection Criteria (TRC) for Study Data. This means that the FDA will begin rejecting studies that don’t meet the criteria effective September 15, 2021.

We also had a new Technical Conformance Guide (TCG) drop from FDA, and yes as this blogger speculated, immune response data in an optional custom domain for IS, was added to the Guide.

We saw the Federal Register Notice (FRN) and then the obligatory update to the Data Standards Catalogue to support and later require SENDIG-DART v1.1 which is the CDISC SEND standard for Development and Reproductive Toxicology. This coincides with a lot of FDA activity around their Fit For Use (FFU) pilot for that DART standard, including the selection of sponsors participating in the pilot and then the scramble to produce the datasets in record time.

That was all just in one month. Damn, do those FDA folks ever sleep?!

Not wanting to be left out of the party, CDISC published SENDIG 3.1.1. While limited to changes to PC and PP domains, publication of a new version of SEND is a very significant moment.

We also of course squeezed in the Society of Toxicology, ToxExpo. Even when virtual like it was again, for many of us it remains the largest and most influential industry event of the year.  Also, like many of you, I am very much looking forward to being back on-site next March in the San Diego sun!

How do you feel about so much happening in a single month?

Personally, I’m very proud and excited. I was part of both of the teams that authored the SENDIG-DART 1.1 and the SENDIG 3.1.1 standards. I’ve volunteered so many hours to developing these standards, I want to see them adopted and required as soon as possible, and applied to as wide a rage of studies as is feasible. But I know that’s not everyone’s opinion. I know there will be many who struggle to keep up with latest changes. Many who do not even know where to go to look to find out what’s changing (maybe that’s how you first stumbled upon my blog!).

I’m sure there are many that see all of these updates and announcements and feel that it’s too much, too soon. I’m sure there are many also still getting to grips with some of the challenges of SEND 3.1, and the idea of SENDIG 3.1.1 and SENDIG-DART probably fills them with dread.

I know there’s an opinion in some quarters that SEND is a burden, a necessary evil, an unwelcome expense. Those are valid opinions and I understand what leads people to those conclusions.

Yes, I understand that point of view, but I still see the benefits outweighing the cost. Most of industry is on board with SEND. Whether your solution includes new tools, partnering with a service provider, or a combination of the two, most of our industry is over the initial hurdle and now up and running. I’m continually reminded of the benefits that SEND brings both to industry and to FDA. As I look back at March, I’m really excited and encouraged to see the pace of SEND adoption is picking up.

How do you feel about it? marc.ellison@instem.com to let me know.

Till next time

Marc

Supported but not required by FDA – What’s the point?

SENDIG-DART v1.1 is currently supported by FDA, but not actually required, so should anyone really care? What’s the point of a standard that isn’t required yet?

In this context, supported means that a sponsor could choose to include SEND datasets, and the FDA are willing and able to receive them and would expect to use them when reviewing the submission.

However, as they would not be required, why would any organization actually do this?

I suppose the first thing that comes to mind is the fact that SEND costs money. It just does. I think we’ve all got accustomed to that idea. It also takes time. Time and money are two very persuasive arguments, yet there are organizations already getting on board with this new standard.

We have seen this before. Whenever the agency adds to the Data Standard Catalogue, they always add a support date that’s in advance of the requirement date. Typically, they issue verbiage along the lines of “…strongly encourage the use of…” to indicate their desire to receive the standardized data ahead of the requirement.  FDA cannot simply add the standard and require it immediately, so industry gets a period to implement the new standard.

Anyone who remembers their similar position for SEND 3.0 and SEND 3.1 will know that any implementation period comes and goes far too quickly. Two years can feel like a long time, but it will be over all too soon.

So ‘Supported but not Required’ is a siren. A great, noisy, clanging call to action, telling us that this requirement will drop onto our desks with all the grace and elegance of a sledgehammer.

Some of you are already underway with implementation. Many more are getting educated on the new standard, which is something I’d highly recommend if you haven’t begun this already. Being better informed about its scope, content and expectation sooner rather than later will enable you to identify the impact of this new requirement on your organization.

Some organizations have already thought about how many studies will be impacted and given that it’s a relatively smaller number than general toxicology, they have already set about identifying an outsourcing partner to handle the requirement on their behalf.

However, would any organization actually provide SEND datasets as part of a submission, where they are supported and even strongly encouraged, but not actually required?

Well, I believe that several organizations did exactly that for SEND 3.0 and 3.1. Granted, not a great number of organizations, but a significant group for sure. Once ready, these organizations did in fact see value in putting their capability, the capability of their CROs and solutions partners to the test, secure in the knowledge that they had a safety net of knowing that there would be no refusal to file. Knowing there are so many complexities and moving parts, there’s certainly an argument to be made for testing out a new standard during the limbo period of ‘Supported but not Required’.

As usual, please send your comments, thoughts, disagreements or questions to marc.ellison@instem.com

Till next time

Marc

DART, SOT & an FRN – Just another week in the world of SEND

First, I noticed that I was getting a lot of email notifications and messages. More than usual. Something happened and the news was spreading. It was a Federal Register Notice (“FRN”) and it honestly came as a bit of a surprise. It was announcing that the FDA were adopting SENDIG-DART and stating they would start to require it for submission. As a reminder, SENDIG-DART is the SEND Standard for Development and Repro tox, and if you’ve been following this blog, then you are well aware that it’s one of my favorite topics to discuss.

The FRN states that FDA will begin to accept SENDIG-DART in submissions from 15th March. That’s March 15th of this year. No, I couldn’t believe it either. It will become an actual submission requirement from March 2023; but that’s only 2 years away. FDA are actually accepting it now – but no doubt with their usual “strongly encourage the use of” tag. Also, yesterday the FDA’s Data Standards Catalogue was updated to add SENDIG-DART, reflecting the details in the FRN.

Regular readers will know that I was part of the team that wrote the SENDIG-DART, so seeing it being accepted by FDA and seeing a date for when the requirement will kick in, is huge. This came just a week after the closing date for organizations to register their application to participate in the FDA’s Fit For Use pilot of the SENDIG-DART.

We actually published the standard back in 2017, and since that time it’s been patiently waiting for its turn in the FDA spotlight. Obviously, this didn’t come completely out of the blue. We’ve been hearing noises from FDA for the past year about the desire for a Fit For Use pilot, but I have to admit that the date of March 15th took me by surprise. And I’m delighted. This is a full year ahead of what I was expecting. As regular readers will also know, with the anticipation of the pilot, I’ve been busy developing our tools and services to support DART, so while surprised, we are prepared.

While we are on the topic of DART and completely coincidentally, I’ve changed my role at CDISC. Again, regular readers may well recall that I was leading the PC/PP team developing the Pharmacokinetics domains. Well, this this week, I have handed that team over to a new leader, as I’m now the new team lead for the DART subteam. So, I’ll be leading the team in developing the next version of the SENDIG-DART which will focus on widening the scope to include Juvenile Tox studies.

What else is going on in March? Well, SEND 3.1.1 will be released from CDISC! This sees the PC/PP team’s hard work finally published. This month we also expect that the FDA will publish the next update to the Technical Conformance Guide. It will be fascinating to see their latest changes. Will it incorporate any updates driven by CBER?

And we also have the SOT/Tox Expo. For many of us, the biggest event of the year. I can’t think of SOT without lamenting the fact that this year again it’s virtual. Yesterday, as part of SOT, I delivered an online presentation looking at the some of the key issues organizations are grappling with at the moment to simply be in compliance with the SEND Standard; and then went on to talk about how some organizations are utilizing the SEND Standard Beyond Compliance. Again, a topic that will be familiar to regular readers.

March has always been a busy month in the SEND calendar, and I realize that this posting seems to have been a combination of news updates, and call backs to my previous posts, like some bizarre greatest hits album. That’s the nature of the beast.

My next post will return to musings and opinions. How about: When a standard is supported but not required – what’s the point? Would anyone submit SEND when it’s supported but not required?

Till next time, from your friendly neighborhood SEND-Geek

Marc

A picture paints a thousand words

I know the title is the obvious cliché, but I had to do it. Sometimes things are obvious for a reason.

I’ve just finished putting together my SOT/ToxExpo presentation and I’m still lamenting the fact that it’s virtual again this year. Anyway, as I alluded to in my previous blog post, this year’s presentation looks at both where we are today, and where we might be going tomorrow with SEND. I’m convinced that Visualization is key to that conversation.

It’s at this point I’m reminded of an experience at SOT a couple of years ago where we were demonstrating our own visualization solution known as, SEND Explorer® to someone who previously, had to draw their conclusions using only the PDF tables. The individual was shown all manner of graphs, charts and other visualizations and the demonstrator was able to dynamically drill into the results as the person was asking questions of the data.

They were getting more and more engaged and enthusiastic as they were seeing the speed and ease at which the demonstrator was able to bring up data, customize how it was viewed and perform various on-screen comparisons.

Yes, of course nonclinical data has been displayed in graphical form before. I’m not suggesting that this is all due to the advent of SEND, but SEND does change the landscape because the data are standardized. It’s this standardization which has paved the way for commercial off-the-shelf tools to be developed which can work with data regardless of the CRO responsible for running the study; regardless of the Data Collection system used for capturing the data.

Also, the introduction of services to convert historic study data to SEND, often locked away in old PDFs, has opened new possibilities for accessing value found in those old studies. Legacy conversions like this then provide visualization tools like SEND Explorer, with a wealth of study information to work with.

This has got me wondering: How long until this becomes just the run of the mill way of analyzing nonclinical data? How long until SEND simply replaces the PDF appendices in the study report? Back when SEND was first being introduced, that seemed to be the logical assumption for the next significant step. One day, there won’t even be PDF appendices.

That’s an idea I’ve been thinking about a lot. There are very good reasons why that won’t happen in the near term, but I think that there are ways to overcome these roadblocks. I think that will have to be the topic for a separate blog post….

For today, I’m really pleased whenever I get to see people getting excited about discovering the potential for working with visualizations of standardized nonclinical study data. I’m longing for in-person conferences and shows when we can have these types of conversations face to face again.

Till next time

Marc

Beyond Compliance?

Beyond /bɪˈjɒnd/ Preposition “more extensive or extreme than; further-reaching than.”

This week I have been writing the abstract for my talk at this year’s SOT meeting. Even though the event is again virtual, as you may have guessed by now, I’ll take any opportunity to inflict my opinions about SEND on anyone who’ll show up to listen. In writing the abstract, I think back to previous SOT expos and I’m reminded that across our industry, we are a wide and varied crowd when it comes to SEND.

There are still a significant number who are asking “What is this SEND thing, and does my study really need it?”. There are also the Many and the Few. The Many are up and running with SEND, but for them, it is harder than they imagined, more expensive and it’s slow. Oh boy, does it slow things down sometimes! In an industry where time, speed and expertise are often in short demand, the last thing anyone needed was something like SEND. Right?

Then there are the Few. Those exploring the opportunities of standardized study data. The small number for whom SEND is not a burden, it’s just a mechanism by which they can unlock a world of new possibilities.

The Many may have heard talk of this mythical place Beyond Compliance, but the Few are already heading out on the journey of exploration.

So, is there a SEND El Dorado that lays beyond compliance? Certainly, Big Pharma believe so. We can see their investment in consortia where they are pooling their knowledge and building warehouses of shared study data in SEND format. Obviously, such activity comes with considerable investment, and they would only do this if their belief was that the benefits and opportunities outweigh the cost.

However, we don’t have to be part of an exclusive consortia in order to see the benefits of working with standardized electronic data. Visualization tools like SEND Explorer allow regulators, sponsors, and others to interact with nonclinical study data in a fast, dynamic way. Previously, hours would have needed to be spent leafing through PDF pages of a study report, but now we click a button and graphs, charts and other visualizations can appear. See something interesting? Then just another click or two and we are drilling down so see what’s really going on in the study. Or zoom out and summarize to a higher level: Look across a set of studies to see if trends are consistent from study to study, or is there something peculiar about this one particular study?

It doesn’t matter which CRO supplied the data, it’s standardized. It doesn’t matter which collection system was used, it’s standardized. That standardization has allowed for tools like SEND Explorer.

However, that means that their value can only be seen when they are fed a good volume of standardized data.  I’ve often heard the opinion “Wow, that looks great, but I just don’t have enough SEND Data to make use of it”. I’ve spoken to those who know they have a wealth of historic study data, that they would love to be able to use with SEND Explorer, but unfortunately those study data are stuck in PDF. So, the challenge became: how to be able to scrape data from PDFs into SEND in order to feed the warehouses and visualization tools? The vast number of CROs can’t entertain doing this work. Understandably, they are grappling with the challenges of today, without trying to unlock the study data of the past. However, for those who are endeavoring to pitch camp in this land of Beyond Compliance, we’ve developed the tools and techniques to do just this. And we are doing it, today. In parallel with our work converting data for submission, we are also handling data that are going Beyond Compliance.

You can probably tell that I’d be quite excited to have my SOT presentation focus on the possibilities of the land beyond compliance, but I acknowledge that I need to deliver something that is going to be as relevant for the Many as well the Few.

Till next time…..

Marc

ADA & SEND: I’m conflicted

In the last CDISC SEND Core Team meeting, we got to discussing Anti-Drug Antibody (ADA) data, and its representation in SEND. We were debating what we’d recommend, and this is the cause of my conflict.

The purist within me wants to scream “Custom Domain!”. The pragmatist knows the industry isn’t ready for this. I want to shout about that fact that at Instem, we have the tools and services to support custom domains; but I’m not supposed to use CDISC for such promotion. I want to tell everyone listening that we have the products and services available to help industry create these custom domains; but that would be overstepping the mark. So, as a card-carrying member of the CDISC SEND Core Team – I’m forced to admit to myself that industry just isn’t there yet.

So, I’m conflicted.

This arose due to the work over at FDA CBER and their recent pilot of the SEND standard. They have a real need to see ADA in SEND. In the current version of SEND, there isn’t a domain for these results, however SDTMIG (the implementation guide for the clinical equivalent of SEND) has such a domain. It’s called IS – Immunogenicity Specimen Assessment; but it’s not in the SENDIG.

PHUSE have previously looked into this situation and came up with two solutions, which can be summarized as showing how to either, force-fit ADA data into the existing LB domain; or borrowing IS from SDTMIG and adding it to a SEND package as a custom domain. (I’m probably doing a huge disservice to its authors by reducing an entire white paper to a single sentence!)

At this point, I’ll acknowledge but completely sidestep the question of whether or not this would actually be considered in scope or not; and totally dodge the issues around SDTM version compatibly and the fact that CDISC are adding an IS domain to SEND 3.2. If you want to dive into that, then drop me a line, marc.ellison@instem.com, because I’d be happy at taking the discussion down that particular rabbit hole!

So, I’m conflicted; and a big part of that conflict is due to the fact that I relish being at the cutting edge of SEND. The ‘right’ answer is, that as these data are important for safety evaluation, that they should be represented in SEND. This being the case, then the IS domain is a better fit than a misused LB domain. However, by and large, the industry isn’t at the cutting edge and as such many probably don’t have the tools or expertise needed. This is unsurprising as at CDISC, I think we could have done a better job at making the information available. We have an Implementation Guide that includes custom domains, but at no point acts to guide implementation of a custom domain. That being the case, I’ll hold my hand up as a CDISC volunteer and take my share of the responsibility for that.

Being at the cutting-edge means having developed the tools and services already. Not only does our Submit™ software create and consume such domains, but our SEND Explorer software can visualize them, and our services team can create and verify them. So, we are now sitting pretty with our ducks all aligned. But I know that doesn’t really apply to many others.

So, I’m still conflicted.

This is not supposed to sound like shameless self-promotion, of “look what we can do”; it’s relating the personal challenge of taking my CDISC responsibility seriously and ensuring I don’t overstep my privileged position of having a seat at the SEND Leadership table.

Till next time

Marc

SEND verses the Study Report

SEND is just an electronic representation of your study report.”

This used to be my stock phrase. I actually believed it. It was how the world seemed a few years ago. I meant every word of it.

The concept is admirable, but the reality seems to be getting more removed all the time. The intention was that industry would have a standardized representation of the study’s results in order that they could be exchanged electronically, because previously they were just in PDF reports which, while being very human readable, are far from being machine readable. Data would be collected and reports produced as normal. The only change would be that the study report would now have corresponding files containing the data.

So, “SEND is just an electronic version of the study report” is what I used to tell people. Oh, how naïve. The world must have seemed like such a simple place.

Today I heard about a CRO who now refuses to produce SEND 3.0 because they’ve changed their data collection practices for SEND 3.1. My younger self would have been outraged at the idea that not only the SEND standard, but a particular version of SEND, would dictate how data are collected.

Yet, for where we are today, I know this is pretty reasonable for various reasons. Probably the main one is the significant change to Histo Pathology data that was introduced in SEND 3.1. As part of a move to be able to better compare microscopic findings from one study to another, SEND 3.1 brought in Controlled Terms and a much tighter specification of Histo findings. If these data were not collected using a SEND 3.1 compatible glossary, then retrospectively converting the data into SEND would cause challenges. At best this would be time consuming, and at worst this could be near impossible without the Pathologist on hand to unpick all the findings.

Another point worth considering is the idea that we don’t always want the report and the SEND dataset to match. “You mean the SEND data would be different from the data in the study report?!” I hear my younger self ask in horror. Well, actually yes. There are occasions where data on a page may be filtered, formatted or even summarized in order to best fit that page. A SEND dataset doesn’t have such constraints. This notion came up again this week. There are occasions where subjects are observed, and only abnormalities are listed in the report in order to save space. The report would also include a line to explain this. However, in the SEND dataset, all records should appear, and the consumer of the data can then filter them out using their own tools as they so desire.

The same principle could apply to something like food consumption on a longer-term study, which may well be collected daily, yet reported weekly. So, it’s entirely possible that the data on the page is summarized at a slightly higher level than the data in SEND.

The examples we’ve discussed here are probably the most obvious ones, yet there are many more.

So, here we are, and I look back on the naivety of the opinions of my former self. Conceptually, there’s still some truth in the notion that “SEND is just an electronic representation of your study report”, yet once we get into the detail, we see so many exceptions to this notion that the very idea can seem farcical at times.

As usual, hit me with an email (marc.ellison@instem.com) with your own thoughts on the matter, whether you agree, disagree or just wonder what on earth I’m rambling on about.

I’ll leave you with one final thought, “How do you write a good joke?”, “Well, I start with a laugh and work backwards!”. While a cheap gag in its own right, there’s a lesson there: Start with the end in mind. The end used to be a Study Report, but today that’s the SEND Dataset too.

Till next time,

Marc

Out with 2020, SEND in 2021

Well Happy New Year one and all!

After saying a final sayonara to 2020, I’m sure that you, like me and the rest of the world are hoping that 2021 ends up being so much better than its predecessor. That’s got me thinking about what’s happening with SEND in 2021.

As discussed a couple of postings ago, the recent Federal Register Notice specified the coming February 26 as the date by which Sponsors must register their application to participate in the FDA’s Fit-For-Use pilot for SENDIG-DART. The expectation is then that March through May should see participants creating datasets. Later in the year, the findings of the pilot together with any recommendations, should be made public by FDA.

As usual, we can expect FDA publishing Technical Conformance Guides in March and October again. Will they use this to further clarify their position on requesting that more studies should be submitted in SEND format (See this posting for more details)? Will we see updates to reflect the needs of CBER and that center’s recent pilot of SEND? I’m thinking specifically here about representing ADA in SEND.

I’m sure we’ll see an update to the Technical Rejection Criteria too.

Somewhere around the end of the first quarter, we should finally see the publication of SEND 3.1.1 from CDISC, with its associated Conformance Rules. For me personally, this will be a huge milestone. SEND 3.1.1 is change to the PC and PP domains and the reason this means so much to me personally, is that at CDISC, I lead the SEND PC/PP team. We have been working on this change since about 2017.

In its plainest terms, this change is simply that the PC domain has two timing variables moved from Perm to Exp while two others moved the other way going from Exp to Perm. Also, the PCUSCHFL variable was added as permissible in order to make it consistent with the other findings domains

SEND 3.1.1 has completed 2 rounds of public review, so the actual changes have been public for a while, but if you’d like further information, then feel free to drop me a line.

While on the face of it, this seems only a very slight change, the team have also completely reworked all of the examples and supporting text in order to be more applicable for nonclinical data. So yes, only a minor tweak to the actual variables, but a significant reworking of these sections of the IG and something that should improve the IG’s usability in this area.

2020 was the strangest of years. Here’s hoping that 2021 is better for us all.

Till the next post

Marc