Custom MDTO integration for government bodies
Appfront builds software that pulls your information objects and files from the case management system or DMS, maps the fields to the MDTO schema, flags missing and incorrect values, calculates a checksum per file and assembles a delivery package the archive can ingest. Every transfer is logged, including who changed what. So your team no longer has to compare column by column in Excel and rebuild rejected deliveries.
What is MDTO integration for transfer to the e-depot?
MDTO integration software converts the data from your source systems into metadata according to the Metagegevens Duurzaam Toegankelijke Overheidsinformatie (MDTO) schema. The software retrieves information objects and their files, fills the MDTO elements from your fields, checks which values are mandatory, calculates checksums, validates the result against the XML schema and assembles the delivery package that the receiving archive institution ingests. Errors surface before you send.
Without such a layer, the mapping work happens in spreadsheets. A municipality exports cases from the case management system, an adviser fills in the archive service's mapping form, a colleague writes a script around it, and only at ingestion does it turn out that appraisal, retention period or terminology don't match. The delivery is sent back, the export is out of date and the work starts again.
We build custom software because your mapping depends on your own systems: the case types in your case management system, the folder structure in your document management, your selection list, your terminology lists and the delivery agreements of the archive service you transfer to. The route from TMLO to MDTO also differs per organisation. A generic export package doesn't know those agreements and leaves you to resolve the exceptions by hand.
Mapping per source field
For each case type or document type, you define which field goes to which MDTO element, with fixed values, derivations and references to terminology lists. The mapping is version-controlled and reusable for subsequent deliveries.
Checks and validation
Before sending, the software checks mandatory and conditionally mandatory elements, coverage periods, relationships between objects and checksums, and validates the whole against the XML schema of the National Archives (Nationaal Archief).
Delivery package and log
The software assembles a package per batch with metadata and files, records which objects were included and stores the ingestion result from the receiving institution.
How we build your MDTO integration for transfer to the e-depot
We start with a real export from your case management system and the mapping form of the archive service you transfer to.
We go through which systems contain information worth archiving, which selection list applies and which requirements the receiving archive institution sets. From that it follows which object types go into the first delivery.
For each source field, we define the MDTO elements, including identification attributes, appraisal, retention period, file formats and the terminology lists you use. Deviations per case type get their own rule.
Administrators see per batch which objects are blocked and why, and can correct values or report them back to the data owner. Approved objects move on to the delivery package.
We connect the software to your source systems and to the e-depot's ingestion, run trial deliveries, and then take care of management, monitoring and adjustments for new schema versions.
What MDTO integration for transfer to the e-depot actually does
The components below come up in almost every MDTO integration. Which ones you need depends on your source systems and on the archive institution's delivery agreements.
Mapping management
For each case type or document type, you define which source field maps to which MDTO element, with fixed values, derivation rules and version control on every change.
Schema validation
The software validates every metadata file against the XML schema and reports, per object, which element is missing or contains an incorrect value.
Package assembly
Metadata and the associated files are combined into a transfer package in the folder structure the receiving archive institution expects, including each file's reference to its information object.
Source integrations
Information objects and files come in through integrations with your case management system, document management system or line-of-business application, in scheduled batches or continuously, with an alert if a source fails.
Retention periods
Appraisal and retention period follow from your selection list, so you can see per object what will be transferred and what may eventually be destroyed.
Look-up per object
For every transferred object you can find the source reference, the mapping version used, the checksum and the ingest feedback.
Who we build MDTO integration for e-depot transfer for
The software is intended for government organisations and archive institutions where information from multiple systems must remain sustainably accessible.
Municipalities
Many sources besides the case management system, from permits to the social domain. Mapping per case type and translation from existing TMLO fields are the core here.
Regional archive services
Receives deliveries from dozens of connected organisations. Upfront validation and clear feedback per rejected object save the most rework on both sides here.
Water authorities and provinces
Long-running files on permits, flood defences and projects. Coverage periods, relationships between objects and non-standard file formats demand the most attention in the mapping here.
Implementing organisations
Large volumes from line-of-business applications and little room for manual work. Batch processing, checksums per file and a complete log per transfer are central here.
Technology and integrations
This page covers an integration layer between your source systems and the ingest of an e-depot, and ties in with our work on smart API integrations and broader software development. If it involves many sources and strict role allocation, also look at developing enterprise software. You can read about our approach on building software.
Why Appfront for your MDTO integration for e-depot transfer?
A transfer is only as good as the metadata beneath it. That is what we build on: mapping that follows your sources, checks before you send and a trail you can follow afterwards.
Errors should be visible before sending
Every rejected delivery costs a new export and another round of discussion. We put the check up front, so only objects that meet the schema and the agreements are sent.
A mapping is ongoing management, not a one-off project
Case types change, selection lists are revised and schema versions follow one another. That is why the mapping is version-controlled and adjustable without any code having to be rewritten.
Traceability is part of the result
For every object you can still see which system it came from, which mapping was used and what the receiving institution reported back. That makes accountability afterwards straightforward.
Security and privacy in MDTO integration for e-depot transfer
The software holds metadata about government information and often the files themselves, including documents containing personal data. Access is role-based: a source owner sees only their own objects, an archive officer sees the transfers. Every change to mapping, appraisal or retention period is logged. Retention periods and destruction proposals follow your selection list, within the framework of the Archiefwet (Dutch Archives Act) and the GDPR.
The software runs in a European data centre, with encrypted storage and daily backups. Integrations with case management systems, document management and the e-depot ingest use their own keys, which can be revoked per integration.
Frequently asked questions about MDTO integration for transfer to the e-depot
Questions that information managers and archive inspectors ask before they get started.
The software retrieves information objects and files from your source systems, maps your fields to the elements of the MDTO schema, checks mandatory and conditionally mandatory values, calculates checksums and assembles a submission package for the receiving archive institution. Rejections surface before you send, and for each transfer you can see which objects were included.
MDTO stands for Metagegevens voor Duurzaam Toegankelijke Overheidsinformatie (Metadata for Sustainably Accessible Government Information), a standard from the Nationaal Archief (National Archives of the Netherlands) for recording and exchanging metadata about information objects and the files in which they are stored in a consistent way. The standard replaces the earlier application profiles TMLO and TMR and includes an XML schema as well as a metadata schema.
Yes. During setup we map your existing TMLO fields to MDTO elements and record for each field what can be carried over and what needs to be supplemented. Fields with no direct equivalent get their own rule or a fixed value. This way, old and new transfers can run side by side during the transition.
In practice, with case management systems, document management systems, line-of-business applications and the e-depot ingest you transfer to. Integrations can use APIs, database views or periodic export files, depending on what your supplier offers. For each integration we record which fields are retrieved and how often.
The ingest feedback is recorded per object, together with the reason for rejection. The objects concerned appear in a repair list, where an administrator corrects the value or adjusts the mapping. After that, only the corrected part is resubmitted, without you having to rebuild the entire transfer.
Schema versions and selection lists change periodically. The mapping and the validation rules are therefore data in the software rather than fixed code. A new schema version means we replace the validation schema and flag the changed elements in the mapping. Transfers in progress remain traceable to the version they were built with.
Check that first. Some case management systems and document management packages can export MDTO metadata, and if you work with a single source and the standard fields are enough, that is sufficient. Custom software makes sense when you combine several sources, use your own case types and concept lists, or when repair work and feedback currently happen outside the package.
Want a transfer that passes ingest in one go?
Tell us which systems your archival information comes from, which archive institution you transfer to and how your mapping is currently documented. We will show you what mapping management, pre-submission validation and the per-transfer log look like when you build software.