EDMS Integration Requirements: An Acceptance Checklist

An EDMS integration requirement should state what crosses the boundary, which system owns it and how the receiver proves it handled the right record correctly. “Has an API” or “connects to our QMS” does not establish those behaviors. Specify the expected outcome and failure response before evaluating a connector.

Use this checklist for interfaces between an EDMS and authoring tools, quality systems, source repositories, publishing services or archives. It is a proposed acceptance framework, not a universal regulatory specification or a tested implementation. Apply it to the exact products, configurations and record populations in your project.

The deliverable is a reviewed interface contract, an acceptance record and an owned exception path. An interface contract here means the agreed behavior and responsibilities; it does not have to be a separate commercial document.

Record the interface identity and permitted purpose

Complete one record for each direction of exchange. A two-way connector may need different rules in each direction. Identify the source and destination versions, environments, business owners, technical operators and document families.

Resolve the word “sync.” Does it mean copy a file, keep selected metadata aligned, register a reference or make the target authoritative? If the parties mean different things, the requirement is not ready for implementation. A connector should not silently acquire permission to approve or delete records because its service account can technically do so.

For computerized systems used in relevant EU GMP activities, Annex 11 section 5 addresses checks for correct and secure electronic data exchange. Section 4.8 separately addresses preservation of value and meaning during migration. These provisions support specifying the business meaning of the transfer; they do not establish an identical interface checklist for every EDMS. EU GMP Annex 11, revision 1.

Checklist A: preserve record identity and meaning

Use Pass, Fail, Unknown and Not applicable with a documented rationale. A required Unknown is an open gate. Record the tested configuration, evidence location and responsible reviewer beside each result.

Keep controlled values tied to their canonical registries. If the source sends a value the destination does not recognize, resolve the mapping instead of selecting a convenient default. A field called “approved” may represent different authority or timing in the two systems.

For a file transformation, check the result appropriate to the intended use. For unchanged content, an integrity comparison can help establish byte preservation. Neither check alone establishes that the selected file was the right approved record.

Checklist B: constrain identities and actions

OWASP's API Security Top 10, 2023, distinguishes authorization to a function from authorization to the particular object involved. It calls for checks on the requested record and action. Knowing a document ID, or authenticating successfully to an endpoint, is not sufficient authority to use that document. OWASP API1:2023.

Exercise denied cases through the actual integration identity and downstream reader roles. An administrator's successful demonstration does not establish the intended security boundary. Where the connector legitimately handles several programs, verify how each received record is assigned and restricted in the target.

Avoid recording secrets or unnecessary document content in diagnostic logs. Retain the identifiers and evidence needed to investigate without turning the exception queue into an ungoverned second repository. Define who can inspect the affected material when content-level investigation is necessary.

Checklist C: make failure visible and recoverable

HTTP method semantics do not automatically settle business-level duplicate handling. RFC 9110 describes idempotent methods by their intended repeated-request effect and limits automatic retries of non-idempotent requests without the needed knowledge. Ask how the actual API and connector establish whether repeating an operation is safe. Do not assume that repeating a document-creation request creates only one record. RFC 9110, section 9.2.2.

Define the scope and lifetime of any exchange or idempotency identifier the implementation uses. It must distinguish a retry of the same intended operation from a genuinely new revision or destination. These are design requirements to verify, not a claim that every product supports an identical header or protocol.

Worked example: a lost response and a late revision

Consider a fictional interface that copies an approved regulatory source into a publisher's intake area. It does not approve a submission or transmit to an agency. The agreed source is DOC-210 revision 3; the exchange reference is EX-210-3-PUB-A.

The receiver creates intake record IN-88, then the network connection fails before the sender receives the completion response. The sender now knows it attempted delivery, but it does not yet know the receiver's final result. A timeout must not automatically mean “nothing was written.”

The accepted recovery path queries or otherwise reconciles the result using the agreed exchange reference. If the receiver confirms IN-88 with the correct source identity, the sender records that result. If a retry is necessary, the documented duplicate-handling mechanism must avoid creating an unintended second accepted intake record.

Now assume revision 4 is transferred through a separate authorized exchange and becomes the selected baseline for the next preparation task. A delayed revision 3 message arrives afterward. The receiving contract must distinguish historical intake from selection of the current task baseline. It may retain the old event as history or route it for review; it must not silently reset that baseline to revision 3.

The test passes only for the conditions actually demonstrated. A simple sequential retry does not establish safe handling of simultaneous duplicate requests. Add concurrency or failure injection to the authorized test plan where it matters to the intended service.

Here is a filled acceptance record using fictional evidence labels, not results from an executed connector test:

The last row does not make approval controls irrelevant to the source system. It records that this connector has no authority to perform them. Keep that scope statement when someone later proposes a two-way connection.

Distinguish transport receipt from business acceptance

Define what each returned status proves. A request accepted for processing, a stored file and a reviewer-accepted package are different outcomes. A connector dashboard should not label all three “complete” without explaining the underlying state.

The receiving side should expose the resulting record identity and any unresolved condition through the agreed mechanism. If processing continues asynchronously, define how the sender discovers final success, failure or timeout and who handles an overdue result.

For publishing interfaces, keep the selected source, intake acceptance, technical preparation and transmission outcomes separate. A file arriving at a publisher does not establish that the package meets the selected authority's requirements or that an agency accepted it. Our quality-to-regulatory traceability guide explains the broader chain of decisions.

Close the acceptance record and operating handover

Use a final record containing the interface ID and version, environment, source/target configurations, required checklist rows, evidence references, unresolved issues, accepted limitations, owners and release decision. A critical failed or unknown row prevents approval of the proposed scope until corrected or legitimately removed through a reassessed scope.

Reconcile after supplier/API changes, mapping changes, credential changes and other events that can affect the demonstrated behavior. Retain the interface contract and the tests that expose its important failures. An earlier demonstration on another API version should not automatically remain proof for a changed integration.

Agree who operates the queue, investigates discrepancies, approves mapping changes and manages shutdown. At exit, preserve required records and unresolved work, then remove credentials and connections under the authorized plan. Stopping a connector does not itself settle the disposition of material already transferred.

For a wider assurance plan, see the computerized system validation guide. Assyro publishes this checklist. Bring the completed interface contract to a workflow discussion when evaluating a regulatory-document handoff, and require evidence for the exact offered connection and responsibilities.