Resarch abstract: Open-source technology stack for creating registries seeding interoperable data via REST and GraphQL API

Objectives and Background

The primary aim was to evaluate the feasibility and time of adopting open-source software frameworks for creating electronic registries providing access via several Application Programming Interfaces (API). The proposed approach also aimed to contribute to the open-source movement on health data interoperability and improve the process of medical records management. The specific project objectives were: • migrate existing registry of drugs available as .xml source file into a new admin control panel • develop coding algorithm and attach a unique identifier to each drug in the register • harmonise “drug forms” and “package types” in accordance with IDMP, SPOR and EDQM standardisation methodologies.[1-3] 


We reviewed and adopted publicly available headless content management system (CMS) and open-source (Apache 2.0 or MIT licence) object-relationship mapping (ORM) solutions to create external access channels via REST and GraphQL APIs to data initially housed in a relational database (SQL Postgres). [4-8]. 

Lists of standardised terms (INN, Dose Form, Packaging Type, Units of Measurement, Labellers) were used to harmonise the data and create a unique stock keeping unit (SKU) identifier for registry records (Figure 1). Minor versions of SKU identifiers were additionally added to allow for changes in prescribing information (PI) and specifically in indications and counter-indications without changes in the unique identifier itself. Additional automated checks for duplicate ID records were implemented as a part of quality assurance process.

Figure 1: Unique ID Code composition








It took approximately 6 weeks and a team of 2 people (research analyst and software engineer) to deliver the working prototype of the new registry. It was also possible to adopt an administration interface with enhanced tracking of records (createdAt, createdBy, updatedAt, updatedBy) and define levels of access for several roles (user groups) using available of-the-shelf solution and it’s features (Figure 2). 

Figure 2. Administration functionality provided off-the-shelf by KeystoneJS headless CMS [6] 




The final solution allowed to setup following most important features required for a minimum viable product (MVP): set granular access rules for data fields for registry administrator(s), define document(s) schema, setup users and permissions, log all events and translate the interface. High-level architecture diagram (Figure 3) portraying the relation between services, as well as the unique identifier coding algorithm (Figure 4) are presented.

Figure 3. Services relationship diagram 

Conclusions & Discussion 

Open-source software frameworks (in Javascript and Ruby) provide valuable and battle-tested solutions for medical registry development, requiring relatively small initial investment of time to adopt them. A newer GraphQL API appeared to be a more performant solution leading to less redundant data at transfer. 

Development of methodology for unique drug identifiers (codes) at the level of SKU (secondary packaging) is an important step towards better compliance, traceability and reporting for pharmaceutical industry and price regulators. In 2021 still not all EU countries are sharing similar format for drug coding. The reference for our study was SUKL code implementation by Czech Republic, although exact coding algorithm is not described in public domain.[9] 

Danish was used as a reference and example of well organised public database including drug list prices, consumption levels and codes[10Development of such public sites by other countries is an important step towards transparency and better informed decision-making, as it would allow easier cross-country comparisons and analytics.

Open-source registries can also feed live data cost-effectiveness and budget-impact models, as described in our previous article about data interoperability in health economic modeling.



1. IDMP –

2. EDQM Standard terms –

3. SPOR –

4. Headless CMS review and comparison –

5. Digital Ocean –

6. KeystoneJS headless CMS –

7. ORM –

8. GraphQL vs Rest API Web article –

10. State Institute for Drug Control in Czech Republic –

11. Registry example from Denmark

12. About digital health outcomes. Website –

Leave a Reply

Your email address will not be published. Required fields are marked *