Life Sciences
How to build a universal translator for pharma data with FHIR
Pharmaceutical data is often described in different ways across multiple disconnected systems. This causes delays, errors and compliance risk – but by using the FHIR data standard, you can streamline the data exchange and increase efficiency.
In short:
Challenge: Because the same data is often stored under different descriptions and formats, pharma companies spend huge resources manually moving and reconciling data between regulatory, laboratory, quality, manufacturing and supply chain systems. This is inefficient and increases the risk of mistakes and regulatory compliance violations.
Solution: By using the FHIR (Fast Healthcare Interoperability Resources) data standard, NNIT can construct an API that acts as a universal translator between systems. This ensures that the data is always imported correctly into the target system.
Benefit: The FHIR API eliminates much of the manual effort and shifts life sciences operations from document-based communication to data-driven interoperability. This turns regulatory submissions, manufacturing, and quality processes into continuously connected data flows. For example, data could be extracted from LIMS and QMS, used to generate sections of an eCTD document and stored in RIM after human review, to facilitate faster, error-free submissions to regulatory authorities.
It is hard to be efficient if you must manually translate everything you communicate to other departments. But that is exactly what happens in many life sciences companies.
– Every day, vast quantities of data are generated and passed from one system to the other. Detailed research findings are gathered for regulatory submissions in RIM, new customer orders arrive in the ERP system, lab test results are recorded in LIMS and batch production is managed via the MES. The problem is that these systems often communicate in different languages – both literally and technically, says Kåre Hyttel, Managing Consultant at NNIT.
For example, what is listed in RIM as the “active ingredient” of a specific product might be described as “substance name” in the QMS. And your LIMS could describe concentration as “mg/mL” while your MES stores that data as “mg per unit dose”.
Old habits die hard – and create huge manual workloads
This fragmentation is rarely caused by deliberate decisions or incompetence. It is the results of decades of professional practices and culture where each function designed their systems and terminology to meet specific regulatory and operational needs rather than focus on interoperability and shareability.
– The systems have evolved into silos. So, when Production exchanges information with the Quality team, the data must be reconciled or “translated” manually. The same applies to the submissions Regulatory Affairs send to the FDA or EMA. Typically, the data is exported to pdfs, presentations or spreadsheets, shared via email, then entered manually into the target system, Kåre Hyttel explains and continues:
– This creates a huge manual workload that is both immensely time-consuming and a frequent cause of errors and compliance risk. Your audit trail is weak, and time-to-market takes longer. It also makes it difficult to automate business processes and to meet the expectations of regulators who increasingly move towards real-time data exchange and fixed data standards like IDMP, SPOR and PQ/EMC.
The problem is that systems like RIM, QMS and MES often communicate in different languages – both literally and technically.
Kåre Hyttel, Managing Consultant, NNIT
FHIR data standard acts as universal translator
To solve the issue of conflicting data descriptions and formats, NNIT has developed a custom API that can be used as a “universal translator” between systems.
The API is based on FHIR (Fast Healthcare Interoperability Resources), a data standard developed by HL7 for exchanging healthcare information electronically. Originally developed as a way for hospitals and other healthcare providers to accurately share patient information, FHIR is a robust standard that is rapidly gaining popularity.
– FHIR is specifically designed for interoperability between healthcare systems and format like IDMP, SPL and SPOR. It acts as a messenger that you can trust to convey the information accurately and align formats, eliminating the risk of misunderstandings and manual errors, says Kåre Hyttel.
Eye-opening concept mapping
The hardest part about applying the FHIR API to an organization is not the technical challenges. It is the painstaking concept mapping that binds attributes together across systems. This task requires equal parts domain knowledge, detective work and diplomacy.
– We always recommend starting small, by mapping the most stable standard IDMP attributes like product name, active substance, manufacturer and strength. Then you can move on to more dynamic values such as batch information, product variants and change control references, Kåre Hyttel says.
A key part of the content mapping is establishing ownership over every single attribute within the organization. This frequently causes discussions that can be both tense and eye-opening, especially for senior management who may not have a detailed understanding of the complexity involved. Once ownership is clarified, cross-system governance can be automated, with every attribute gaining a steward, version history, and validation rule.
– I have been in meetings where stakeholders from different departments spent hours debating the definition of a single attribute. But the beauty is that once you have established attribute ownership and definitions for one product, you can usually scale that to all other products in the organization.
– Consultancies like NNIT can accelerate the process, because we have been through these discussions before and know where to locate the attributes in the different systems, Kåre Hyttel says.
Auto-generate content for submissions
By using the FHIR API, you get an effective tool with a wide range of use cases.
For example, data can be extracted from LIMS and QMS, used to generate sections of an eCTD document and stored in RIM after human review. This would facilitate faster, error-free submissions to regulatory authorities.
Another use case could be to build an IDMP Master Database, where data from RIM, ERP, and other systems is processed via a FHIR validation gate to ensure that you have a single, IDMP-compliant source of truth for all your product data.
– What we have found while working with clients who implement the FHIR API is that once the first applications are live, the organization quickly begins to suggest additional features and use cases. The value is so visible that momentum builds very rapidly, Kåre Hyttel says and finishes:
– Over time, you can tie all your data dependencies together with FHIR as the semantic backbone. It will completely streamline your communication with regulators, CROs and CMOs. I am convinced that the first company to get just 10 percent of the way to successfully applying this on a large scale will blow past their competitors. The race is no longer just about software or integration. It is about who builds the cleanest validated and fully automated data streams across the enterprise.
Want to get started with FHIR in your organization?
If your organization also struggles with excessive manual workloads and data silos, NNIT is ready to help you streamline your communication and processes. Starting with a small and agile proof of concept, we can apply and expand the FHIR API to create serious business value for your entire organization.
