An HL7 Vulcan track took a complete regulator-applicant workflow, from submission to signed approval, and ran it over HL7 FHIR (Fast Healthcare Interoperability Resources) for the first time. Four independently built systems took part. Every scenario passed.
4
Independently built systems working together
4
Regulatory domains carried by one pattern
3
End-to-end workflows tested
0
Design failures found: every defect was in implementation
The Problem APIX Is Tackling
The exchange of medicinal product information today is defined by extreme fragmentation: different formats and portals for human drugs vs. veterinary drugs vs. medical devices; entirely different communication channels for clinical trial applications, marketing authorizations, and post-approval changes; and applicants often have to chase progress rather than being notified automatically.
What APIX Is
APIX (API for the Exchange of Medicinal Product Information) is a new HL7 FHIR Implementation Guide developed within HL7ās Vulcan Accelerator. It establishes a common framework for applicants and regulators to exchange and track regulatory transactions for any product type and any procedure through standard application programming interfaces (APIs).
September was the guideās first Connectathon, where independent teams could build against it and test their systems together. The aim was simple. Does the design hold up during real-time testing?
THE TRACK
Who Took Part
Craig Anderson (Johnson & Johnson) and Filippo Napoli (HL7 Vulcan) led the track. The participants were not observers: every organization at the table was actively testing. The systems were proofs of concept, not commercial products, built to find out whether the design would hold up.
PORTALS
Humanized Health Consulting
Applicant-to-regulator scenario for a drug submission exchange.
PRODUCT DATA WORKFLOW
ACCURIDS
Applicant-to-regulator scenario for a product authorization using structured data that conforms to the Identification of Medicinal Products (IDMP) standards.
SAFETY REPORTING
Uppsala Monitoring Centre
Applicant-to-regulator scenario for an Individual Case Safety Report (ICSR) submission.
SHARED BACKEND
HAPI FHIR server
Open-source FHIR server (provided by HL7 Vulcan) where every exchange took place.
Track participants: Craig Anderson (Johnson & Johnson), Filippo Napoli (HL7 Vulcan), Heiko WaldmĆ¼ller and Konrad Krebs (Accurids), Jose Galvez (IgniteData), Magnus Wallberg (Uppsala Monitoring Centre), Matt Elrod (Office of the National Coordinator for Health IT, ONC).
THE DEMONSTRATION
How A Full Procedure Ran Over FHIR
Neither side talked to the other directly. The applicant and the regulator both read from and wrote to one shared FHIR server, and each was notified when something changed.
ALSO TESTED
Two More Workflows
Adverse event reporting
The team reviewed a complete ICSR exchange and agreed APIX could support the process end to end: submission, acknowledgment, validation, acceptance or rejection returned on the same record, follow-up as a sub-step, and error correction.
Human Medicinal Product Submission
Both sides subscribed to receive automated notifications anytime the application was updated. In this testing scenario, the applicant initiated an application as a new Task, submitted with DocumentReferences and Binaries, responded to an invoice with payment and receipt, responded to regulator questions, and received a letter of approval.
THE RESULTS
What it Proved
THE HEADLINE FINDING
One pattern carried every domain tested, with no change to the underlying model. Only the terminology changed.
Regulatory exchange is usually built domain by domain, and often regulator by regulator. A single consistent pattern means implementers can build on a common technical framework and reuse it across use cases or product domains. You also don’t need to change existing business processes, because this technical framework supports new or existing workflows.
Domains tested: Human medicinal products, Adverse events (ICSR), IDMP product data, Clinical trials.
The Track Also Showed That:
- Sub-processes work as their own steps. Regulator questions and invoice payments ran separately as sub-branches under one procedure, each being independently trackable.
- The exchange can be data, not just documents. The team demonstrated that APIX transactions can carry any message because the framework is file-format agnostic.
- Notifications solve the one-to-many problem. An authority publishes updates to its own FHIR server and applicants are notified automatically and in real time. Anyone building one-to-many regulatory exchange can reuse this approach.
- Decisions can be signed and verified. The team discovered the ability to digitally sign medicinal product authorizations, which can then be linked to site inspections, packaging, and batch information.
- Every file is handled the same way. The team agreed to apply the Task, DocumentReference, and Binary pattern to all use cases to ensure tools built for one domain work for all of them.
WHAT COMES NEXT
An Honest First Outing, and a Clear Road Ahead
This was the guideās first Connectathon, and the team was clear about where more work is needed. Subscriptions and electronic signatures need fuller guidance. Each domain needs its own code systems. The guide also needs clearer rules for managing status and lifecycles.
Developing the Guide
- Terminology layered per regulator and per domain
- New scenarios: adverse event reporting with worked rejection examples, clinical trial applications, and in-trial data exchange
- Minimum requirements for applicant systems, with the regulatorās record as the single source of truth for each procedure
- Dashboards to track incoming and in-progress tasks
Building Adoption
- Sharing these results with regulator communities and industry forums
- Inviting regulators to join the next round of testing
- Engaging regulators on their API submission plans, and making the case for APIX in their roadmaps
- Exploring the end-to-end supply chain traceability use case, including digitally signed authorizations and the connection to packaged product and batch records
WHY IT MATTERS
The Standards Are Being Written Now
Organizations testing it are shaping how regulators receive submissions in the future.
- Pharma and biotech: Shape regulatory exchange alongside peers, rather than adapting to it once it is set.
- Technology providers: Build against a real regulatory workflow, working directly with the sponsors and regulators who will use it.
- Regulators: Test alongside industry. The most important next step for APIX is regulators at the table.
Join the Next Round of APIX Testing
HL7 Vulcan brings pharma companies, technology providers, and regulators together to build and test the standards that will connect research and care. We work alongside the Clinical Data Interchange Standards Consortium (CDISC), TransCelerate, and PHUSE, not in competition with them.
You do not need to be an HL7 International member to take part in a Vulcan project.
Talk to us about APIX: Vulcan@HL7Vulcan.org
Visit the APIX project page: https://hl7vulcan.org/projects/api-exchange-for-medicinal-products-apix/
Source: Vulcan APIX: Regulatory Exchange with APIs and Subscriptions, Track Report, prepared by Craig Anderson, Filippo Napoli, and the APIX team, HL7 Confluence, September 2026.
