Ignifyr is ideal for hospitals, regional health services or any healthcare organizations looking to enable data interoperability across different healthcare systems, prepare healthcare data for research or clinical use in FHIR format, and implement HL7 FHIR^® standards within their infrastructure without extensive coding expertise.

You will need access to your data sources, a basic understanding of your data structure, and a deployment environment for Ignifyr (local, cloud, or containerized setup). Our team can assist you with the setup and configuration.

Ignifyr offers an open-source version that allows you to freely test its core functionality. For enhanced features such as a web-based graphical interface, built-in OMOP CDM support, high-performance scalability, advanced mapping configurations, and dedicated support, the Ignifyr Enterprise license is available.

With its intuitive interface and guided tutorials, users can learn the basics of developing mappings within a few hours. Advanced mappings using the FHIRPath editor may take additional time based on your familiarity with the FHIR standard and FHIRPath expressions.

With our team’s professional services, an initial set of mappings can be developed within 1 month given that all source data, data schema, required documentation and the infrastructure are available during the development. With extensive tests, archiving and security configurations, generally we make everything operational within 3 months.

Ignifyr works with any FHIR profile, including US Core, the International Patient Summary (IPS), the German MII core data set and your own implementation guides. Import the profile StructureDefinitions from a FHIR server or as a ZIP file, and select a target profile, with its version, for each mapping. Ignifyr then processes the profile definitions and guides you through the required and constrained elements while you develop the mapping. Generated resources are validated against the selected profiles inside Ignifyr, without a FHIR server, before you run the mapping on the full dataset.

Ignifyr supports HL7 FHIR^® R4 and R5. The base resource definitions of the configured version, together with any profiles you import, are available during mapping development, and existing R4 resources can be mapped to R5.

Yes. The OMOP CDM is built into Ignifyr Enterprise: the tables of CDM versions 5.3, 5.4 and 6.0 are available in every project, and you pick a table as the target of a mapping just like a FHIR profile. The mapping editor shows the columns of the table with their types, which of them are required, and the OHDSI guidance for each. Concept IDs are filled through concept maps or terminology services, as for any other code translation. The results are appended to the tables of an existing OMOP CDM database on PostgreSQL, or written to CSV, Parquet, NDJSON or Delta Lake files, and they are validated against the table definition in the same way as FHIR resources are validated against their profiles. OMOP tables can also be the source of a mapping, for example to map an OMOP database to FHIR or to move a database from one CDM version to the next. For any other flat model, define the target schema yourself and map to it the same way; this also works with Ignifyr Community.

Yes, Ignifyr can aggregate data from different data sources (e.g., some from a relational database, some from CSV files) to map to a single FHIR resource. 1-to-1, 1-to-many and many-to-1 mappings are possible.

Yes, Ignifyr supports external terminology servers provided that it conforms to FHIR Terminology Server specification.

Ignifyr can automatically integrate FHIR terminology servers and the corresponding terminology service function calls (within FHIRPath) interacts with the configured terminology server. On the other hand, Ignifyr ships with a local terminology server to which code systems, value sets and terminology translations can be loaded and then used during the mappings.

Ignifyr supports a wide range of data sources, including file systems (CSV, TSV, Parquet, JSON, NDJSON, also inside ZIP archives or on HDFS), SQL databases over JDBC (including OMOP CDM databases), REDCap projects, FHIR servers, and Apache Kafka streams. File folders and Kafka topics can be configured as streaming sources so that Ignifyr processes all new or updated source data as it arrives.

Yes, Ignifyr can connect to platforms like REDCap and LimeSurvey and allows you to use their data within your mappings. That is, REDCap or LimeSurvey results can be mapped to corresponding FHIR resources.

Based on your preference, created FHIR resources can be sent to a FHIR server (such as Repofyr, HAPI, Firely etc.) as batch or transaction bundles, or saved to the file system as NDJSON, CSV or Parquet files, or as Delta Lake tables. File output can be partitioned by resource type. Mappings that target the OMOP CDM append their rows to the tables of an OMOP CDM database.

No. Ignifyr appends to an OMOP CDM database that you create with the OHDSI DDL scripts and load with the vocabulary. The mapping produces every column, including the primary and foreign keys; the hashed-ID functions of the mapping language create stable integer identifiers from your source identifiers. Before anything is written, Ignifyr checks that every mapped table belongs to the chosen CDM version and that every required column is produced. It then writes the tables in foreign-key order and reports the rows that do not fit a table, together with the source row that produced them.

Ignifyr runs on Apache Spark. For sources with tens of millions of rows, the batching strategy splits a job into parameterised batches (for example by date range or ID range), runs them one after another and reports progress per batch. Recurring loads can use scheduled jobs that only pull the records changed since the previous run.

Ignifyr belongs to an ecosystem of products that we develop around FHIR. We offer Repofyr that is a high-performant FHIR repository. You can also use its limited open-source version to test your Ignifyr installation.

Yes. Ignifyr is deployed on-premises or in your private cloud, next to your data sources, so protected health information (PHI) does not have to leave your environment. The Ignifyr API can be served over TLS, and connections to source and target FHIR servers can be secured with OAuth2 client credentials, bearer tokens or basic authentication. Every execution is logged, and Enterprise deployments can ship these logs to Elasticsearch and Kibana. HIPAA compliance also depends on your wider system, including access control, hosting and business associate agreements, and our team can help you configure Ignifyr for your requirements.

Ignifyr is designed to support GDPR-compliant processing of health data. It runs inside the data controller's own infrastructure, so data residency stays under your control. Mappings let you process only the elements a use case needs (data minimisation), and execution logs record every job run and its results. In the DataTools4Heart and AI4HF projects, Ignifyr is part of a federated platform where the data of each clinical site is harmonised locally and only models and aggregate results are shared.

Ignifyr's mapping functions can generate deterministic hashed IDs from source identifiers, so the same patient always receives the same resource ID without the original identifier being copied. Direct identifiers and free-text fields can simply be left out of a mapping. Ignifyr does not include a full anonymisation toolkit, so techniques such as generalisation or k-anonymity should be applied with a dedicated tool before or after the transformation.

Wherever you deploy Ignifyr. It is delivered as Docker images and standalone Java applications that run in your data centre or your cloud tenant, close to the data sources. Ignifyr does not send your health data to Pontegra or to any third-party service, unless you configure an external service yourself, such as a remote terminology server.

Ignifyr provides an automated environment for testing and validating mappings and scripts at any stage of development. It offers a powerful FHIRPath editor with smart auto-completion, making it easier to create accurate mappings. Additionally, Ignifyr validates the generated FHIR resources against their profiles, and OMOP CDM rows against their table definitions, in the mapping tester and as an option of the file output, without a FHIR server.

Yes, Ignifyr supports mappings from FHIR R4 to R5. We already have the mappings from FHIR R4 to R5, that is, once you connect Ignifyr to your data, you can transform to R5 right away.

Not necessarily. Once mappings are configured, Ignifyr can automate the process and allow you to reuse mappings for recurring data transformations. This can be done through scheduled executions within Ignifyr or by configuring your source as a stream.

Yes, Ignifyr supports both batch processing and real-time streaming for continuous data ingestion.

Yes, Ignifyr provides a user-friendly web interface where you can set up and customize your mappings and monitor the execution of mapping processing in real-time through an execution monitoring platform.

Our dedicated support team is available to assist with technical issues, provide guidance, and resolve any challenges you encounter. Support plans are included with the Enterprise license.

Yes, we offer professional integration services to help you develop mappings on Ignifyr quickly and effectively. Our team will help you to transform your data to be HL7 FHIR-ready while meeting your specific requirements.