ICH M11 Is Final, Not Mandatory: What a Machine-Readable Protocol Changes for Clinical Systems

Where M11 Stands Today, Region by Region

Before anything about systems, the status has to be right, because a good deal of commentary on M11 gets it wrong in one direction or the other. Some describe it as a future initiative still in consultation. Others describe it as a new mandate that sponsors must comply with. Neither is accurate as of September 2026. The dates below come from the ICH, FDA, and EMA documents themselves.

ICH: adopted at Step 4 on November 19, 2025

The M11 package has three parts: a short guideline that explains the design principles, a protocol template, and a technical specification. Their document histories differ. The guideline records two milestones, Step 2 on September 27, 2022 and Step 4 on November 19, 2025. The technical specification and the template each record three, because a second round of public consultation opened on February 3, 2025 on the technical specification. The updated template released at that point was provided for reference only and was not itself consulted on. Adoption by the Regulatory Members of the ICH Assembly under Step 4 was on November 19, 2025.¹²³ Step 4 is the point where ICH recommends the final text for adoption by the regulators of each region. Step 5 is regional implementation, and each authority does that on its own timeline.

United States: final guidance published May 22, 2026

FDA’s notice of availability appeared in the Federal Register on May 22, 2026 (91 FR 30310, Docket No. FDA-2022-D-3054). It announces a final guidance for industry titled “M11 Clinical Electronic Structured Harmonised Protocol (CeSHarP)” and states that the guidance “includes three documents: a guidance, a template, and a technical specification document.” The notice describes the technical specification as containing “harmonized terminologies and standardized data fields to enable electronic exchange of clinical protocol information.” It also records that this final guidance replaces the draft guidance issued on December 22, 2022 and the draft technical specification issued on June 6, 2025.⁴

On the question of whether sponsors have to use it, the notice is explicit in the way every FDA guidance is: “FDA’s guidance documents do not establish legally enforceable responsibilities. Instead, they describe the Agency’s current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited.”⁴ The guidance document itself, dated May 2026 and issued jointly by CDER and CBER, carries “Contains Nonbinding Recommendations” on every page of its substantive text and adds that the word “should” in the guidance “means that something is suggested or recommended, but not required.”⁶ There is no implementation date and no transition period, because there is nothing to transition to in a legal sense. The FDA guidance landing page lists the status as Final with an issue date of May 2026.⁵

European Union: CHMP adoption December 11, 2025, effective June 11, 2026

EMA’s Step 5 version of the guideline (EMA/CHMP/ICH/778799/2022) shows final adoption by CHMP on December 11, 2025 and a “Date for coming into effect” of June 11, 2026.¹ EMA’s guideline page lists all three documents at Step 5, with the keywords “protocol, harmonised template, interventional clinical trials, technical specification, data exchange, non proprietary standard.” The page states no mandatory-use requirement and no transition period.⁷ In the EU, “coming into effect” for an ICH scientific guideline means it becomes the reference CHMP works from. It does not amend the Clinical Trials Regulation or create a new submission format requirement in CTIS by itself.

Other ICH regions

Japan, Canada, Switzerland, the United Kingdom, and the other ICH regulatory members implement Step 4 texts on their own schedules. We were not able to confirm a published Step 5 implementation date for those regions from primary sources at the time of writing, so we do not state one. Sponsors with programs in those jurisdictions should check the authority’s own notice rather than assume the FDA or EMA date applies.

So the honest framing is this: M11 is in force as the harmonized reference in the two largest regions, regulators are prepared to receive it, and nobody is being fined for continuing to write protocols in a sponsor-specific Word template. That is exactly the situation in which the sponsors who move first set the terms for their systems and their vendors, and the sponsors who wait find the choice made for them by a CRO or a platform supplier.

What “Structured” Actually Means in the M11 Documents

The word “structured” is doing a lot of work in the M11 name, and it helps to be precise about what the three documents define and what they leave open.

The guideline: five design principles

The guideline is only six pages. Its purpose statement says that the template “presents the format and structure of the protocol, including table of contents, common headers, and instructions for content,” and that the technical specification “presents the data elements and technical attributes (e.g., definition, conformance, cardinality) that enable the interoperable electronic exchange of protocol content.”¹ Two of the five template design principles matter most for systems teams. “Define content for electronic exchange” states that protocol content “can be electronically exchanged among parties, including sponsors and regulators, using current (e.g., electronic common technical document) and future technologies.” “Design for content re-use” states that the protocol “is a rich source of information that can be re-used as a part of the clinical trial management and review process, for publishing on clinical trial registries to promote clinical trial transparency, or for standardised clinical trial data capture.”¹

The guideline also draws a boundary that sponsors should read carefully. It states that neither the guideline nor the template nor the technical specification “are intended to specify processes related to development and maintenance of a protocol,” and that they “do not supersede or negate other guidelines that establish requirements for protocol content.”¹ M11 tells you where content goes and how it is tagged. It does not tell you how to run your protocol development process. That part is on the sponsor, which is the whole point of this article.

The template: what goes near the front, and why

The template is organized so that “the most vital information for execution (e.g., Synopsis, Schema, Schedule of Activities)” is near the front, with a main body and appendix framework where “Content in the Appendix carries equal weight and rigor as the content in the Main Body.”¹ Section 1.3 of the template, the Schedule of Activities, instructs that it “must capture the procedures that will be accomplished at each trial visit, and all contact with participants,” including “any tests that are used for eligibility, participant randomisation or stratification, or decisions on trial intervention discontinuation.”³ For anyone who has built an EDC casebook or an IRT specification, that sentence describes the exact content those builds are derived from today by reading a PDF.

The template also carries a dedicated Amendment Details section with fixed statements for an original protocol, a first amendment, and a subsequent amendment, and it routes prior amendment history to Section 12.3.³ That matters for version control, which we return to below.

The technical specification: 575 entries, each with a conformance rule

The technical specification is the document that turns the template into something a system can validate against. Its stated purpose is “to serve as a technical representation of the ICH M11 protocol template.”² Every heading, data field, and text block in the template appears as an entry with a data type, a classification as Heading, Data, or Value, a definition tied to a concept code, user guidance carried over from the template instructions, a conformance rule, a cardinality, a relationship to the table of contents hierarchy, allowed values, business rules, and repeat or reuse rules.

We counted the entries in the adopted specification rather than estimating. There are 575 “Term (Variable)” entries. Of these, 288 are marked Conformance Required, 168 are Conditional, and 118 are Optional. The remaining entry, {<Trial Oversight>} under section 11.2, is truncated in the published PDF and carries no conformance row and no cardinality row at all. The counts are ours, from a text extraction of the Step 4 PDF, and anyone can repeat them.²

Two design choices in the specification have direct systems consequences. First, terminology. The specification states that “CDISC publishes semantics for the ICH M11 protocol data elements and valid value sets,” that the terminology set “is published and stored in the NCI Thesaurus Subset C217023 – ICH M11 Terminology,” and that “each ICH M11 concept will be assigned an NCI C-code.”² ICH object identifiers for M11 are published on the ICH ESTRI page. Second, relationships. The specification defines relationships between elements beyond the table of contents, giving as its own example “an Amendment number to a Protocol Identifier.”² A protocol identifier, a version number, and an amendment identifier are all first-class elements with defined cardinality. That is the raw material for version control at the data level, not just at the document level.

What the specification does not define

This is where precision matters most, because it is easy to overstate. The M11 technical specification does not prescribe an exchange file format. A search of the adopted text finds no reference to JSON, XML, or FHIR as a required format, and no reference to USDM or to the Digital Data Flow initiative. The guideline’s stated intent is to “enable development of a data model and an open, non-proprietary exchange message standard.”¹ Enable, not define. The data model and the message standard are being built by others, principally CDISC and TransCelerate, and the regulators have been testing them. That is the bridge described in the next section, and it is important to understand that it is a bridge built next to the ICH document, not inside it.

The Bridge From Template to Systems: USDM, Digital Data Flow, and the CPT

M11 gives the industry an agreed structure. Three pieces of industry work turn that structure into something systems can exchange: the ICH and CDISC terminology agreement, CDISC’s Unified Study Definitions Model with the TransCelerate Digital Data Flow reference architecture, and TransCelerate’s realignment of its Common Protocol Template.

ICH and CDISC on controlled terminology

The technical specification records that “ICH and CDISC have signed an agreement for the maintenance and facilitation of the governance process for ICH controlled terminology,” with goals that include curating and maintaining the terminologies, following a public review and publication process, and ensuring the terminologies “are freely available to the public following CDISC public review.”² CDISC announced the memorandum of understanding in a news release that carries no publication date. Its president and CEO, Chris Decker, described the purpose as “the establishment and maintenance of controlled terminology for a future digital protocol where study design information is driving better research and review of products.”¹⁰ CDISC’s ICH terminology page confirms the division of responsibility: “ICH retains ownership of its specific terminologies, while CDISC ensures their ongoing publication and accessibility,” with the terminologies “made publicly available through the NCI Thesaurus using CDISC’s established governance processes.”⁹

For a systems team, the practical meaning is that the code lists your EDC, CTMS, and registry tooling will need to validate M11 protocol values against are published in the same place, under the same governance, as the SDTM and CDASH terminology your data management group already consumes. The reference data management problem does not go away, but it does not become a new one either.

USDM and the Digital Data Flow reference architecture

The Unified Study Definitions Model is a CDISC standard developed with TransCelerate’s Digital Data Flow initiative. CDISC describes DDF as an effort to “modernize clinical trials by enabling a digital workflow with protocol digitization,” and describes USDM as “a standard model for the development of conformant study definition technologies.” It is a logical data model expressed as UML class diagrams with a data dictionary, controlled terminology, API specifications, and conformance rules. USDM version 4.0 was released on June 3, 2025.⁸

The alignment to M11 was deliberate and phased. CDISC’s DDF page lists Phase 3 (August 2023 to April 2024) as including “Representation of the draft ICH M11 Protocol template in USDM” along with SDTM Trial Design support and clinical trial registry alignment, and Phase 4 (May 2024 to May 2025) as “Continued alignment with ICH M11” plus complex and observational study support and conformance rules.⁸ So the model that vendors are being asked to implement was shaped against the M11 template while the template was still in consultation, and finalized in the same window as M11’s Step 4.

The architecture around USDM has a component that clinical IT leaders should know by name. The Study Definitions Repository, or SDR, is described by TransCelerate as “a novel central component aimed at facilitating the exchange of structured study definitions across upstream systems (e.g., study builder) and downstream clinical systems.” The SDR reference implementation is open source under the Apache 2.0 license, is “meant to be vendor agnostic,” and exists to “demonstrate the ability to flow digital study definition information between systems through API connections to systems such as study builders, EDCs, and CTMS.”¹⁴ It is not a product. It is a working example of the pattern.

TransCelerate’s Technology Architecture Scenarios Tool goes further and lays out seven implementation patterns a sponsor might adopt, from manual authoring with an SDR, through a distinct study builder feeding a repository, to a single platform spanning study builder, repository, and study execution. It lists the consuming systems plainly: “Protocol data and content may be exchanged with various USDM-consuming systems (e.g. EDC, DCT, CTMS, IRT, Registries, Submission Repositories). New systems can be added at any time if they conform with CDISC’s Reference Architecture for DDF (USDM, API Specs).”¹⁵ That sentence is the systems thesis of M11 in one line.

What FDA has already tested

It is worth knowing that the regulator side of this exchange has been exercised, not just described. In an October 2024 presentation to CDISC, Ron Fitzmartin of FDA’s Center for Biologics Evaluation and Research, the ICH M11 rapporteur, described the PRISM research collaboration on the precisionFDA platform. In Phase 1 Part 1, sponsors created M11 protocols in DOCX and PDF. In Phase 1 Part 2, sponsors created M11 protocols “in machine-readable FHIR exchange format expressed as JSON,” and the use case’s outcomes included the “Exchange of protocols using both human and machine-readable formats: DOCX, PDF, and JSON, FHIR.” The same presentation noted that the use case “leverages TCB Digital Data Flow and CDISC USDM standard for automation and standardized terminology.”¹⁶ The presentation carried a personal-views disclaimer, so it is not policy. But it tells you which formats FDA staff have handled and which industry standards they mapped to.

TransCelerate’s Common Protocol Template, realigned in 2026

Many sponsors do not write protocols from a blank page or from the ICH template. They use TransCelerate’s Common Protocol Template, which has been in use for over a decade. TransCelerate’s Clinical Content and Reuse initiative page states that “In 2026, the CC&R team reconvened to align the CPT with the ICH M11 Template and Technical Specification,” and that “As of March 2026, the initiative is complete, with no new solutions or updates planned.”¹³ The assets page describes the result, CPT version 11: member company experts “have aligned the Common Protocol Template (CPT) Basic Word edition with the finalized ICH M11 Protocol Template and Technical Specifications now available publicly, as well as to the Unified Study Definitions Model (USDM) developed by CDISC and the DDF Initiative.” Use of CPT V11 “will align with key elements of the new ICH M11 standard while still utilizing the additional granularity and detail stakeholders have found valuable in the CPT for the past 12 years.”¹²

Two things follow. A sponsor on an older CPT version has a published mapping to move to V11, and V11 is aligned to both M11 and USDM. And the initiative that produced the CPT is closed. Future evolution of the digital protocol at TransCelerate runs through Digital Data Flow, not through the Word template. If your protocol authoring roadmap still treats the CPT as the end state, it is pointed at a finished project.

CDISC 360i: the downstream half

USDM handles the study definition. The question of what happens after the definition reaches data management is the subject of CDISC’s 360i program, which describes itself as “a multi-year initiative with the aim to transform the way we develop and use standards within clinical research creating connected and interoperable information enabling automation.” Its stated objectives include to “Define and digitalize end to end standards from study design endpoints through the analyses” and to “Demonstrate the automated data flow from raw data source to the generation of the targeted result,” connecting USDM, Biomedical Concepts, CDASH, SDTM, ADaM, and HL7 FHIR.¹⁹

CDISC’s first USDM implementation handbook, dated June 1, 2026, shows what that looks like for one concrete case: generating the SDTM Trial Design domains (TA, TE, TV, TI, TS) from USDM metadata. The handbook states that today “this structuring and verification process is a highly manual and time-consuming process” that “typically takes 8-32 hours of defining and programming,” and that in the future process the programmer “can just run the tooling and review the output.” It adds that “the same information, logic, and approach for creating SDTM Trial Design domains can be applied to create regulatory registry submissions, for example to the European Medicines Agency Clinical Trials Information System or the US ClinicalTrials.gov.”¹¹ That is the registry posting use case, from CDISC, with the caveat that the handbook itself does not walk through it.

The Protocol as a Data Object: Authoring, Versioning, and Tool Selection

Everything above is public. What follows is the part that sponsors have to do themselves, because, as the guideline says, M11 does not specify the process. The first decision is about what the protocol is.

From document with metadata to data with a rendered view

In nearly every sponsor today, the protocol is a Word document that becomes a PDF. Its version is a number on the title page. Its content is prose, tables, and a schedule of activities grid. Structured data about the study, such as arms, epochs, visits, and endpoints, is derived from that document by people in four or five different functions, each producing their own artifact: the EDC build specification, the CTMS study setup, the IRT specification, the statistical analysis plan shell, and the registry record. Each derivation is a manual read of a PDF. Each carries its own interpretation. None is linked back to the sentence in the protocol it came from.

The M11 and USDM model inverts that. The study definition is the data. The protocol document is one rendered view of it, alongside the casebook, the CTMS setup, and the registry record. CDISC’s handbook puts it this way: “In a USDM-driven environment, the Trial Design domains are the digital blueprint of the study. If the blueprint is accurate at the source, the foundation of the clinical data remains rock-solid through submission.”¹¹ The reverse is also true, and that is the failure mode section below.

Treating the protocol as a data object means three things in practice. It has an identity that is stable across versions (the M11 Sponsor Protocol Identifier). It has versions that are themselves data, with the M11 Version Number and Amendment Identifier elements and the defined relationship of amendment number to protocol identifier.² And it has a change history that can be diffed at the element level, so that “what changed in Amendment 3” is a query, not a redline comparison of two PDFs.

Version control that clinical operations can actually use

Software teams solved versioning decades ago and clinical teams have mostly not borrowed the solution. A structured protocol makes it possible to do so without asking a medical writer to learn a version control system. The requirements are modest. Every element carries the version it was introduced or last changed in. A released version is immutable. A draft amendment is a branch from a released version, and approval merges it. Every consuming system records which protocol version it was built from. That last point is the one most often missed. If the EDC casebook does not carry the identifier of the protocol version it implements, then the day an amendment is approved, nobody can answer from data alone which sites are collecting against which version. The Tufts benchmark data in the amendment section shows how long that ambiguous period runs.

Authoring tool selection: the criteria that matter

Sponsors are being offered three kinds of authoring solution: Word-based templates with structured tagging added, purpose-built protocol authoring applications that produce USDM output, and platform solutions that combine authoring, a repository, and execution setup. TransCelerate’s scenarios tool describes all three patterns and is explicit that “Sponsors and vendors must make their own decisions about whether and how to use DDF assets.”¹⁵ The criteria below are the ones we would put in front of any evaluation.

One selection trap deserves its own warning. A tool that is excellent at producing a compliant M11 document but has no repository behind it recreates the current problem one step later: the structured content exists only inside the authoring tool, and every downstream system still gets a PDF. The scenarios tool’s distinction between a study builder and a repository is not academic. Decide where the released study definition lives, who owns it, and how it is retained, before deciding what writes to it.

Vendor Readiness Questions for EDC, CTMS, IRT, and Statistical Teams

The value of a structured protocol is realized in the consuming systems, and most sponsors do not own those systems. They license them. So the second change in the next two protocol cycles is contractual and technical due diligence with each supplier. The questions below are drawn from what the public standards actually require, so a supplier who has done the work can answer them specifically, and one who has not will answer in generalities.

Some of these answers will be “not yet.” That is fine, and it is more useful than a vague yes. The purpose of asking in the current protocol cycle is to know which of your systems will consume structured protocol content in the next one, so that the authoring and repository decisions are made with that in mind. It also puts the request on the record with the supplier, which tends to move roadmaps.

The Amendment Workflow Is Where the Value Shows Up First

The case for a structured protocol is often made with the initial study build, and the initial build does benefit. But the amendment workflow is where the current process is most painful and where a structured source changes the most, so it is the better place to look for the first measurable gain.

The benchmark numbers

The most recent industry-wide data comes from a Tufts Center for the Study of Drug Development study, published as a preprint in July 2023 and in Therapeutic Innovation & Regulatory Science in March 2024. Sixteen pharmaceutical companies and CROs provided data on 950 protocols and 2,188 amendments. The authors report that since 2015 “the prevalence of amendments in phase I – IV protocols has increased substantially (from 57–76%) and the mean number of amendments per protocol has increased 60% to 3.3, up from 2.1.” They found that 77% of amendments were deemed unavoidable, with regulatory agency requests and changes to study strategy as the top reasons.¹⁸

The two numbers that matter most for this article are about time and version ambiguity. The study reports that “the total average time to implement an amendment has nearly tripled during the past decade,” that “the time from identifying the need-to-amend to last oversight approval now takes an average of 260 days,” and that “the mean duration during which investigative sites operate with different versions of the clinical trial protocol spans 215 days.”¹⁸

Read those together. On a typical study, three amendments each open a window of roughly seven months in which different sites are running different versions, and the systems that should know which version each site is on generally do not, because the version is a title-page number and the system builds were derived by hand.

What a structured amendment looks like

With the protocol as a data object, an amendment becomes a change set: a list of elements that differ between version N and version N+1, each with its M11 concept code and its relationship to the table of contents. From that change set, three things become computable that today are written by hand.

• The impact analysis by system. If the change set touches the schedule of activities, the EDC and IRT need a mid-study change. If it touches only the background or rationale sections, they do not. Today someone reads the redline and decides. With element-level change tracking, the affected downstream mappings are identified directly.
• The summary of changes. M11 requires an Amendment Details section and routes prior amendment history to Section 12.3.³ When the change set exists as data, the summary of changes is generated from it, and the two cannot disagree.
• The registry update. The elements that map to ClinicalTrials.gov and CTIS fields are known. If any of them are in the change set, a registry update is due. If none are, it is not. The disclosure team stops re-reading the whole amendment to find out.

The 215-day version-ambiguity window does not shrink because of any of this by itself. Ethics committee and regulatory review timelines are what they are. What changes is that during that window every consuming system carries an explicit protocol version identifier, so the state of each site is a fact in the CTMS rather than a question for the monitor. And the amendment package itself is produced faster, because the document, the summary of changes, the system impact list, and the registry delta are all derived from the same change set.

Data Quality Gains and the New Failure Modes

One structured source feeding many systems is the right architecture. It is also a concentration of risk, and it is worth being honest about both sides.

The gains are real and specific

The Tufts protocol design benchmarks give a sense of the volume being transcribed today. Getz, Smith, and Kravet report that Phase II and III protocols now average roughly 30 inclusion and exclusion criteria (30.9 and 30.4 respectively), around 20 endpoints (20.7 and 18.6), and roughly 34 distinct procedures (33.5 and 34.5) performed a total of more than 250 times per protocol (259.7 and 266.0), with total procedures per protocol having grown 67.3% over the decade to 2020.²⁰ Every one of those endpoints and procedures is currently read out of a PDF into an EDC specification, a monitoring plan, an IRT specification, and a statistical analysis plan by different people. With a structured source, the transcription happens zero times. The interpretation still happens, but it happens once, in the study definition, where it can be reviewed.

Consistency across systems is the second gain. When the EDC visit schedule and the IRT dispensing schedule are both derived from the same USDM ScheduleTimeline, they cannot disagree about visit windows. When the CTMS milestones and the registry record both derive from the same arm and epoch definitions, they cannot disagree about the number of arms. Reconciliation work that today is a data management activity largely disappears, and the reconciliations that remain are between the study definition and reality, which is where attention belongs.

Traceability is the third. CDISC’s handbook describes the current Trial Design domain process as one where the programmer must “thoroughly go through the full protocol,” and notes that because these datasets “are among the first items regulatory reviewers examine to understand study structure, this form of manual technical debt creates significant compliance risk.”¹¹ Derivation from a structured source gives every SDTM Trial Design record a lineage back to a specific protocol element in a specific protocol version. That lineage is exactly what a reviewer, or an auditor, asks for.

The failure modes are new, and most sponsors have not designed for them

Four failure modes deserve specific controls.

Source errors with perfect propagation. A visit window entered as 3 days instead of 7 in the study definition will appear as 3 days in the EDC, the IRT, the monitoring plan, and the CTMS, and each will be traceably correct against the source. The control is review of the study definition itself, by the functions that today review their own derived artifacts, before release. The data management review of the casebook does not go away. It moves upstream to the study definition, and it has to be scheduled there.

Version skew across consumers. If the EDC consumed version 2.0 and the IRT consumed version 2.1 because the IRT vendor’s integration ran a day later, the two systems now disagree, and the disagreement is invisible unless every consumer records the protocol version it consumed and something compares them. The control is a version identifier on every consuming system and a reconciliation report across them, run on every release.

Terminology version drift. ICH M11 terminology and CDISC controlled terminology are versioned and updated. A consuming system that validates a released protocol against a newer terminology release can reject values that were valid at release, or, worse, remap them. The control is that a released study definition pins its terminology version, and consumers validate against that pinned version. This is the same discipline that already applies to MedDRA and SDTM terminology versions, extended to the protocol.

Mapping errors at the consumer boundary. The study definition can be correct and the EDC vendor’s mapping from USDM to their casebook model can still be wrong. Each consuming system’s mapping is a piece of configuration that needs its own verification. The good news is that the verification can be automated: generate from the study definition, compare to the expected build, and diff. The less good news is that this verification is a new validation deliverable that does not exist in most sponsors’ computer system validation plans today.

The validation question

Once the protocol is the source of truth for GxP system builds, the authoring tool, the repository, and the transformation from study definition to each consuming system are all within scope of the sponsor’s validation approach. That does not mean a full IQ/OQ/PQ package for every integration. It does mean applying a risk-based approach under GAMP 5 principles, treating the study definition as a GxP record with an audit trail, and documenting the mappings as specifications that are verified against the delivered builds. The transformations are exactly the kind of well-bounded, testable logic that suits automated verification, and a sponsor that builds the test harness once reuses it on every study.

A related point on Good Clinical Practice. ICH E6(R3), whose principles and Annex 1 came into effect in the EU on July 23, 2025, with Annex 2 scheduled for January 15, 2027, places emphasis on quality by design and proportionate, risk-based approaches.¹⁷ A structured protocol with documented derivation of the system builds is a strong piece of evidence that the sponsor designed quality into the trial rather than inspecting it in afterward. The M11 guideline itself says the template is “aligned with quality by design principles, as set forth in other ICH guidelines.”¹

A Plan for the Next Two Protocol Cycles

A protocol cycle here means the period from the start of authoring a new protocol to its first amendment. For most sponsors that is nine to eighteen months, which puts two cycles inside the next two to three years. This plan is deliberately modest. It does not require a platform replacement. It requires that decisions which are going to be made anyway get made with the structured protocol in view.

Nothing in that plan depends on a regulator requiring M11, which is good, because none does. It depends on the sponsor deciding that the protocol is data, and on doing the unglamorous work of owning that data properly. The sponsors that do this in the next two cycles will be the ones whose systems, vendors, and validation approach are ready when a regulator, a partner, or a CRO does start asking for the structured version. The ones that wait will be adopting whatever their platform supplier decided for them.

Conclusion

ICH M11 reached Step 4 in November 2025, FDA issued it as final nonbinding guidance in May 2026, and the EU guideline came into effect in June 2026. That much is settled, and it is worth stating plainly that no region has made the template mandatory or set a transition deadline. The technical specification defines the structure, the conformance rules, and the terminology, and it deliberately leaves the data model and the exchange format to the industry standards work that CDISC and TransCelerate have now largely published: USDM version 4.0, the Digital Data Flow reference architecture, the realigned Common Protocol Template, and the first USDM implementation handbook. The pieces are in place. What is not in place, at most sponsors, is the decision to treat the protocol as a version-controlled data object that other systems consume, and the controls that decision requires. The benchmark data on amendments, with 260 days to approval and 215 days of sites on mixed versions, shows how much of the current process is spent managing the absence of that decision.

Sakara Digital works with pharma and biotech organizations that are deciding how their clinical systems, data management, and validation approach should change as the protocol becomes structured data. If you are evaluating authoring tools, preparing the questions for your EDC and CTMS suppliers, or working out what a single-source protocol means for your validation plan, and you want an independent perspective on where to start, we are happy to have that conversation.

For Further Reading