From EDI to APIM: a brief history of how interchanges with the ecosystem have transformed

A reminder of the origins and operation of EDI (electronic data interchange)

What is EDI (electronic data interchange)?

EDI emerged in the 1960s from the long-standing and widespread observation that processes based on paper documents are the source of many errors. Such processes are slow, difficult to trace, costly and offer low productivity.

EDI, for Electronic Data Interchange, accordingly replaces the interchange of hard copy documents and data with the electronic transfer of data through standardised, automated messages.  EDI consequently avoids multi-stage procedures entailing data entry and re-entry, and the impact of such steps in terms of time and risk of error (e.g. creating an order, dispatch, receipt, entering the order again into the supplier’s system, then repeated in reverse for the invoice).

A more precise definition is provided by France’s National Institute of Statistics and Economic Studies (INSEE) : “Electronic data interchange (EDI) is a technique that replaces physical exchanges of documents between companies (orders, invoices, delivery notes, etc.) with exchanges, following a standardised format, between computers connected through specialised connections or through a (private) value-added network (VAN). The data are structured according to reference international technical standards.”

EDI was first used to automate commercial procedures in the US car industry. It is now used in all countries, in all sectors of the economy, and for various types of data, although it is still mainly used for processing data between a buyer and a supplier, and in particular in the context of procurement transactions.

How does an EDI system work?

One of the foundations of EDI is data structuring through technical standards (such as EDIFACT, meaning Electronic Data Interchange for Administration, Commerce and Transport, EDI X12, Odette, XML, etc.).

Standardisation of data exchanged is based on a common language between all stakeholders, and therefore between the different information systems and applications involved. EDI standards define how data is structured within an EDI message, thereby enabling data to be transferred directly from one application to another. This standardisation is essential to ensure different businesses can communicate.

Several organisations are responsible for defining EDI standards such as GS1, Etebac, Odette, Tradacoms, Peppol, ASC X12, etc.

To implement electronic data interchange, companies can make use of specific EDI software to generate, translate and track messages following the defined format. Such software will consequently:

• Retrieve and organise data;
• Translate and map data following a given format;
• Transfer messages to partners’ information systems, using the right protocol and, if necessary, by encapsulating transactions.

These are, of course, the most basic functions. The scope often extends beyond these basics, to storing messages, tracking interchanges, etc.

Focus on electronic data interchange in the pharmaceutical industry

The pharmaceutical industry has to deal with considerable data integrity constraints, and work with a variety of partners, such as CDMO firms, suppliers, hospitals, pharmacies, government bodies, etc.

Control over the data produced and information continuity through the entire lifecycle are essential to the pharmaceutical quality system and Good Manufacturing Practice. Digitalising interchanges with partners directly helps improve continuity in the information chain, boosting both performance and quality.

As in other industries, standardised messages are a pre-requisite for digitalised interchange. Historically in France, the role of codifying medicinal products (market authorisation code, dispensing unit code) and standardising messages and documents to fit EDI processes has fallen to the Club Inter Pharmaceutique (CIP). The medicinal product sector (manufacturers, government health insurance funding bodies, healthcare providers) collectively opted to use EDIFACT as its message standard.

With the requirements for pharmaceutical product serialisation, interchange standardisation and automation will only continue to develop. Pharmaceutical manufacturers must, for example, upload serialisation data to the EMVS (European Medicines Verification System) hub, which then makes the link with national systems (NMVS).

Limitations of EDI as the pace of interchange with the ecosystem increases

EDI offers certain long-standing benefits, in that it provides a first level of automation through the structured exchange of data:

• Shorter interchange cycles allow for greater responsiveness, shorter delivery times to end customers, optimised inventories, and better cash flow for vendors;
• Digitalising data, by avoiding re-input and erroneous data on paper invoices, reduces errors and makes the data exchanged more reliable;
• Businesses have visibility over transactions. Interchanges have an audit trail, which can serve as evidence in disputes;
• Costs generated by handling paper and administration are reduced.

However, while EDI has evolved, it did first appear in the 1960s, when the context surrounding B2B interchanges was different. Digitalisation has also continued on its path, and digital communications (to replace fax, mail, etc.) are no longer an innovation. 

EDI does not fully meet the challenges of agility and scalability

Companies are no longer transforming alone. The development of new business models, the creation of new services, the enrichment of your own services… all these now require the involvement of the ecosystem, with suppliers, customers, partners, and open data all relevant.

Digital transformation is becoming synonymous with flexibility and agility in integrating with other firms in the value chain. This ecosystem is constantly developing, becoming more complex and expanding. Organisations are seeking to gain control over data interchanges not just partner by partner, but with their whole, changing ecosystem. Transformation has to be scalable in its application.

As regards these crucial factors of agility, speed of response and scalability, EDI does have some limitations:

• Connections are point-to-point;
• It runs asynchronously;
• Diversity in standards and technology;
• Lead times needed to add a new partner or interchange type.

When EDI is already implemented in long-standing areas of application (ordering, billing, supply chain, etc.), it often meets requirements. However, EDI’s inertia and standardisation difficulties are obstacles to providing a response to the new boom in interchanges and the challenges of connectivity.

From EDI to APIM

Adding to EDI, APIs provide a connectivity and interchange solution that is more flexible, scalable, upgradeable, lends itself to standardisation, etc.

APIs can provide interchange in real time, which EDI cannot. They are customisable and can be used to create new services.

However, it should not be forgotten that one of EDI’s strengths is standardised interchanges and formats, reinforced by its longevity. Formats such as EDIFACT have had time to become established and to be used by organisations extensively.

We firmly believe that APIM (API Management) and API governance are crucial if APIs are to truly add value to a business.

We define API Management as the discipline of making the best use of APIs without compromising the information system and without adversely affecting the user experience. The purpose of API Management is therefore to manage and standardise API (Application Programming Interface) exposure, i.e. the publication, promotion and supervision of interchanges between a supplier service and a client service. 

Of the many promises held by API and APIM, three in particular leap out, in comparison with EDI:

• Respond under pressure from functional business departments, react quickly and improve the flexibility and adaptability of data streams to and from the ecosystem;
• Control the impact of growth in service consumption;
• Offer new unbranded services, and enhance your own services…

At Blueway, we firmly believe that the response to data stream management issues is not just a technical or technological matter. The real question is that of your crucial transformation needs and how interchanges with your ecosystem are changing. How many services do you need to expose to suppliers and customers? Is scalability of data interchange a priority? Do you want to monetise your services, or at least monitor their consumption?

Let’s talk about it!