Pharmaceutical Audit Trail Blockchain-Based Microservice

Stefano Loss

, Lucas Cardoso

, N

elio Cacho

and Frederico Lopes

Department of Informatics and Applied Mathematics, Federal University of Rio Grande do Norte, Natal-RN, Brazil

Metropole Digital Institute, Federal University of Rio Grande do Norte, Natal, Rio Grande do Norte, Brazil

Keywords:

Pharmaceutical Systems, Auditing, Audit Trail, Blockchain, Immutability.

Abstract:

Pharmaceutical manufacturing in Brazil requires that its processes are carried out by following rules deﬁned

by a supervisory body: the National Health Surveillance Agency (ANVISA, in Portuguese). ANVISA requires

that all pharmaceutical systems guarantee all product information’s integrity, security, and traceability. These

rules ensure that the manufactured products do not pose a risk to their consumers. One of the difﬁculties for

pharmaceutical industries is to provide evidence that production procedures were carried out under internal

regulations based on these rules. One way to do this is by using an audit trail. It can store this informa-

tion automatically using a computer system to record all actions. However, only using audit trails does not

guarantee data security; ensuring that all information is immutable is necessary. Therefore, in this paper, we

propose an audit trail blockchain-based microservice. This technology stores all transactions in linked and

encrypted blocks to avoid illegal modiﬁcations. It also guarantees data immutability, security, and traceability.

In addition, we present a case study to evaluate the proposed approach using Nuplam’s (Nucleus for Research

in Food and Medicines) Integrated Management Systems. A stress test was performed in this case study to

evaluate the applicability of the proposed solution in pharmaceutical systems.

1 INTRODUCTION

The use of medicinal products made from plants, ani-

mals, or minerals has existed since ancient times. Ac-

cording to (Dailey, 2018), there are historical records

of civilizations that performed this practice, such as

the herbal compendium written by Emperor Shen

Nong in China in 100 BC. While the pharmaceuti-

cal industry, as it is known today, began to develop in

the mid-19th century, according to (Daemmrich and

Bowden, 2005). As a result of the emergence of these

drugs, it was possible to observe an improvement in

birth and mortality rates.

In this evolution, the rigor of regulations and bu-

reaucracies was increased. In this way, bodies re-

sponsible for supervising and guaranteeing the qual-

ity of the medicines produced were established and

strengthened. Among these bodies are the Food and

Drug Administration (FDA)

in the USA founded

in 1906 and Brazil’s National Health Surveillance

Agency (ANVISA) in 1999

. ANVISA is also re-

sponsible for regulating and inspecting computer sys-

https://www.fda.gov/

https://www2.camara.leg.br/legin/fed/lei/1999/lei-97

82-26-janeiro-1999-344896-publicacaooriginal-1-pl.html

tems used by pharmaceutical companies to manage

the production of medicines. It deﬁnes standards

based on normative resolutions and instructions to be

complied with by all drug manufacturers.

However, the scenario of advances in systemati-

zation and access improvements also takes time and

effort. ANVISA also requires all its systems to un-

dergo systematic testing and veriﬁcation of industry

documentation, a complex activity called validating

computerized data. One of the requirements of regu-

latory bodies is to ensure data integrity, and all infor-

mation must be traceable and immutable. ANVISA

must know who took such action, when and for what

reason. Through these requirements, the development

process becomes more complex and complete.

In this way, it is necessary to record information

about every stage in the production process. However,

relying only on tools that need manual input of this in-

formation to perform the recording is unreliable. An

individual may need to remember to write down some

data or make mistakes during writing. Therefore, a

system capable of automatically storing this data is

necessary to guarantee the registry’s integrity.

In addition, it is also necessary to ensure that every

piece of information is immutable and not to compro-

mise the integrity of the whole record. The data must

368

Loss, S., Cardoso, L., Cacho, N. and Lopes, F.

Pharmaceutical Audit Trail Blockchain-Based Microservice.

DOI: 10.5220/0011685100003414

In Proceedings of the 16th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2023) - Volume 5: HEALTHINF, pages 368-375

ISBN: 978-989-758-631-6; ISSN: 2184-4305

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

remain consistent with the values expected by produc-

tion. This system must also be able to provide trace-

able data for external ANVISA audits, for example.

One of the ways to automatically record

medicines production information is to use an audit

trail in which the system capture and automatically

stores the creations, updates, or deletions of informa-

tion from all records to be audited. It assists in recon-

structing events chronologically of the recorded infor-

mation to facilitate auditing.

However, using the audit trail alone does not guar-

antee that this data is immutable. Since people with

direct access to the database can easily modify some

records to circumvent some information. The modiﬁ-

cation usually happens because the data is located in

one place (database) in an isolated way where editing

one segment of information does not affect the others.

Therefore, blockchain technology can be inte-

grated with audit trail components, allowing secure

and reliable auditing through systems. Since the prop-

erties provided by the blockchain’s nature can im-

prove the system’s management and security (Berdik

et al., 2021). Therefore, with this integration, it is pos-

sible to share data transparently, securely, and reliably

without centralizing entities.

Hence, this work presents an innovative solution

to register medicines production information using an

audit trail blockchain-based microservice. With this

microservice, all data is shared to facilitate the au-

diting process in an immutable, secure, and traceable

way. In this context, the contributions of this paper

are threefold. First, we present the key concepts to un-

derstand this work better (Section 2). Second, a novel

pharmaceutical audit trail blockchain-based microser-

vice is introduced in Section 4. Third, related works

are described in Section 3.

Afterward, we describe a Case Study involving

two pharmaceutical systems controlling the produc-

tion of Nuplam drugs that would beneﬁt from the pro-

posed solution (Section 5). In addition, we present

an architecture to facilitate the audit process involv-

ing possible control bodies such as ANVISA and the

Ministry of Health. Finally, We evaluate our proposed

approaches through a stress test (Section 5).

2 BACKGROUND

2.1 Audit Trail

The audit is ”an independent, objective assurance and

consulting activity designed to add value and improve

an organization’s operations. It helps an organiza-

tion accomplish its objectives by bringing a system-

atic, disciplined approach to evaluate and improve the

effectiveness of risk management, control, and gov-

ernance processes.” according to Institute of Internal

Auditors

The pharmaceutical audit is usually called a “qual-

ity audit” falling into the regulatory type. Therefore,

the bodies responsible for its execution require the

companies inspected to comply with speciﬁc regu-

lations. The companies establish these regulations

based on standards created by the auditing body, aim-

ing for better ﬁnal product quality. The body respon-

sible for this regulatory audit in Brazil is ANVISA,

which regularly audits pharmaceutical laboratories.

Meanwhile, an audit trail is a process that captures

creations, updates, or deletions of information from

all records to be audited. This track can be stored

either on paper or electronically. It assists in recon-

structing events chronologically of the recorded four

essential questions (who, what, when, why) to register

the main corresponding modiﬁcation details (Ahmad

et al., 2019).

An automated electronic or computerized au-

dit trail eliminates human intervention, reducing the

chances of a registration failure and guaranteeing the

recording of all information that passes through the

system. The FDA, in 2003, recommended its use

for companies in the ﬁeld. This recommendation

in which this regulatory body describes the impor-

tance of applying some historical information record-

ing tools within a pharmaceutical company, highlight-

ing the audit trail.

However, maintaining an audit trail fulﬁlling the

requirements is complex. In (RANA, 2021), the difﬁ-

culties encountered in maintaining and managing an

audit trail are mentioned. One of these is the in-

crease in storage costs resulting from the eventual

large amount of records generated in the life cycle of

a track in a computer system. In addition, there is usu-

ally no deﬁned period after which this data would no

longer need to be kept.

2.2 Blockchain

Appearing in 2008, in the work of an unknown author

with the pseudonym Satoshi Nakamoto (Nakamoto,

2008), blockchain technology was initially developed

to create a secure and decentralized environment in

which it was possible to carry out Bitcoin virtual

currency transactions. A blockchain has four main

components, which allow its operation and guarantee

its transactions’ immutability, auditing, and security.

According (Puthal et al., 2018), the blockchain’s main

https://www.theiia.org/en/about-us/about-internal-

audit/

Pharmaceutical Audit Trail Blockchain-Based Microservice

369

components are the distributed ledger, cryptography,

the consensus algorithm, and the transactions.

The distributed ledger is the component respon-

sible for recording transactions in a chronological

and sequentially dependent way and all the informa-

tion entered in the network. This ledger is structured

in a chain of sequential blocks, which store the trans-

actions carried out on the network and are connected

through a digital signature generated by cryptogra-

phy. In this chain, the blocks are sequentially in-

serted, in which the last one represents the most re-

cent transactions. For each new block, this signature

is generated based on the immediately previous block,

its transactions, and the creation instant (timestamp).

Blockchain transactions are based on exchanging

information between network nodes in a Peer-to-Peer

(P2P) manner. The P2P concept deﬁnes that sev-

eral nodes form a blockchain network, each storing

a copy of the ledger with all the information that has

passed through it (Puthal et al., 2018). In this way, all

network nodes are responsible for storing and man-

aging network transactions. Regarding its structure,

a blockchain transaction is contained within blocks.

Each block can contain one or more transactions and

use them to generate its signature. Each transaction

on a blockchain network corresponds to the state of

information on the network, which may represent data

creation, update, or deletion.

Lastly, the consensus algorithm is responsible

for assuring the immutability of blockchain infor-

mation along with the ledger. This mechanism en-

sures the security of network data through decision-

making techniques used to choose which data is valid

in a blockchain. This technique uses P2P character-

istics where all network nodes maintain a copy of the

ledger. Therefore, it is possible to decide through con-

sensus, involving most network nodes, which data are

correct and discard erroneous data.

2.3 Orthus

Orthus is a blockchain platform to provide interoper-

ability between systems by securely sharing informa-

tion in the Smart Cities context (Loss et al., 2019).

It enables the creation of solutions in distributed net-

works to share data and services in a transparent, se-

cure, and reliable way without centralizing entities.

The Orthus architecture comprises Java Actor classes

implemented using the Akka toolkit

focused ins scal-

ability and uses a Broker for indirect communication

between all nodes.

Each system must implement the Orthus compo-

nent to be part of the network. Orthus components are

https://akka.io/

instantiated once for each system, and this association

(System + Orthus components) is called a node. Com-

munication between a system and the Orthus Gateway

component occurs through REST requests. The Or-

thus network is comprised of distributed nodes and a

network of brokers that enables data exchange, in the

form of contextual elements, by sharing transactions

and blocks that were created by one of the nodes and

validated by all.

3 RELATED WORKS

Many other solutions in different contexts have used

audit trails to store data. In the health area, the arti-

cle written by (Rostad and Edsberg, 2006), in which

an analysis of the audit trail generated by an elec-

tronic patient record system is performed. Based on

this analysis, this article tries to improve this system’s

role-based access control model by reducing excep-

tional situations in which it is necessary to access the

system with administrator permission.

Another article in this area is (Cruz-Correia et al.,

2013), in which the authors gather information from

audit trails implemented in four Portuguese hospitals

to analyze them. They performed records evaluations

based on the audit trail’s completeness, comprehensi-

bility, and traceability standards. In addition, they in-

terviewed the members of these hospitals to ﬁnd out

if they were adequately consulting the audit trail.

The legal area paper (Allinson, 2001) researches

the use of audit trails by Australian security forces as

evidence for legal cases. It explains that these forces

have a legal obligation to keep all information an in-

formation system generates in an audit log.

After analysis, it is essential for an audit trail

that its information is readable and secure. The

authors highlight the importance of having a well-

implemented path for reconstructing the processes

carried out within the system. Furthermore, in the

works of (Cruz-Correia et al., 2013) and (Allinson,

2001), it is possible to observe how neglected the au-

dit trail is in the hospitals and security forces.

Still, in the research on audit trails, blockchain

technology has much to offer in this area. In par-

ticular, in the paper written by (Abreu et al., 2018),

the possibilities brought by the usage of blockchain in

audit trails are explored. Some companies that devel-

oped products trying to integrate both concepts are in

it. Beyond that, this paper introduces other computer-

based assisting tools for auditing and exposes some

of the authors’ thoughts on how to make blockchain

technology more accepted by the populace.

Another related work in which an audit trail ap-

HEALTHINF 2023 - 16th International Conference on Health Informatics

370

plication based on private blockchain was developed,

called by the authors BlockTrail, (Ahmad et al., 2019).

This article focused on implementing a blockchain in

which it was structured hierarchically to reduce the

retrieval time of its information. This work proposed

the blockchain implemented to be of the private type.

It is necessary to know all network users, as they

may need to be held legally responsible for any errors

recorded in the audit trail.

Apart from the previous ones, another blockchain-

based solution found while searching the literature

was an article in which a private blockchain network

was designed and implemented to ensure the secu-

rity and reliability of an audit trail for conﬁguring

technical manufacturing components (Regueiro et al.,

2021).

This literature review concluded that a

blockchain-based audit trail is also suitable for

laboratory situations, as it allows the control of

writing data. This control is relevant because organi-

zations that may have access to the track for viewing

should not be able to enter data into the blockchain

network. In addition, if the amount of information

recorded eventually becomes too large, it will be

possible to limit the access of users who do not

perform actions relevant to ANVISA’s audit, such as

purchasing ofﬁce supplies.

4 AUDIT TRAIL MICROSERVICE

The auditing microservice studied in this article has

an architecture, as depicted in Figure 1, with a struc-

ture composed of six core components: a controller,

a service, a model, a repository, a consumer, and a

supplier. Besides them, there are three other auxiliary

ones: a blockchain adapter, a report template, and a

report builder.

These core components work as their names in-

dicate: the controller works as the REST API; the

service handles the business logic; the model deﬁnes

data structure; the repository connects to the database;

the consumer and supplier both control the data ﬂow

to a broker.

Within this architecture, the controller and the

consumer/supplier handle two different kinds of data

ﬂows. On the one hand, the controller is used to

communicate with an external application; for exam-

ple, one reads the information from the microservice.

In this case, this application would use the available

API GET routes to access the auditing information

recorded in the microservice and display it to a user.

On the other hand, the consumers and suppliers

handle the communication with the integrated sys-

tems. These brokers handle this communication by

organizing the ﬂow of information between the inte-

grated members. This architecture’s service and the

repository have no special functions besides what they

would usually have. The service helps connect all

components while maintaining an appropriate busi-

ness logic, and the repository serves as an internal

database representation.

The audit object model, in this microservice, de-

ﬁnes the structure with which the transaction infor-

mation has to conform to be accepted. According to

the structure deﬁned in this case, the model needs to

have: an object identiﬁer (ID) to track the transac-

tion; a revision, to maintain the timeline information

through versioning; the user responsible for a trans-

action; the name of the integrated service that sent

the transaction; the operation type (create, update or

delete); the name of the entity modiﬁed by the opera-

tion; the current state of the object, with the modiﬁca-

tions; a timestamp of the transaction to know when it

happened. All this structure is depicted in Figure 1.

Regarding the auxiliary components, the

blockchain adapter converts the transaction data

handled by the microservice to a format readable

by the integrated blockchain. The report template is

composed of a set of ﬁxed phrase molds to be ﬁlled

with the transaction information to convert it into a

readable form. At the same time, the report builder

is responsible for correctly ﬁlling these template

phrases with the information.

Figure 2 depicts, in a superﬁcial manner, the path

a transaction goes through in this architecture. The

transaction path starts from the integrated system and

into the microservice via a broker until it reaches the

blockchain and returns a status result message regard-

ing its completion.

5 CASE STUDY - NUPLAM

The Nucleus for Research in Food and Medicines

(Nuplam, in Portuguese)

is a chemical and pharma-

ceutical laboratory within the Federal University of

Rio Grande do Norte (UFRN). Nuplam has, among

its competencies, to research, develop and produce

medicines for the Brazilian Ministry of Health (MS),

supplying medicines throughout Brazil.

One of the most challenging factors for Nuplam

is to record all events throughout the medicine’s life

cycle using SigNuplam and OPDigital. This cycle be-

gins with the arrival of raw materials, goes through

production, and ends with the delivery to the Ministry

https://Nuplam.ufrn.br/pagina.php?a=historia

Pharmaceutical Audit Trail Blockchain-Based Microservice

371

Figure 1: Class Diagram of Audit Trail Microservice.

Figure 2: Sequence Diagram of Audit Trail Microservice.

of Health. This process involves different entities, and

at each step, all historical data must be recorded in im-

mutable, secure, and audit ways complying with the

regulations established by ANVISA.

To better fulﬁll the ANVISA requirements, Nu-

plam developed its computerized systems to man-

age its internal procedures. This decision was in-

ﬂuenced by advances in the Information Technology

(IT) sector at UFRN that resulted in the development

of an Integrated Management System for the Nuplam

(SigNuplam) and a system for controlling Nuplam

medicines production (OPDigital).

All information systems developed within the

pharmaceutical context are regulated by the National

Health Surveillance Agency (Anvisa). The systems

must undergo systematic testing processes and veri-

ﬁcation of industry documentation, a complex activ-

ity called Computerized Data Validation, which re-

quires the creation of a speciﬁc sector to carry out

these checkings.

The ANVISA requirements for this system are di-

verse and must guarantee the data’s integrity, secu-

rity, and traceability. In other words, in addition to

people who cannot access them improperly, we must

also know who took which action and for what reason.

Through these requirements, the development process

becomes even more complete and complex.

5.1 SigNuplam

SigNuplam

is an Enterprise Resource Planning

(ERP) developed and implemented following AN-

VISA regulations. This web system must ensure

that all access points are via the Local Area Network

(LAN) within NUPLAM, including wi-ﬁ. It guaran-

tees that all laboratory employees with internal access

to a computer can access and use the system only if

they are registered.

SigNuplam was initially developed in modules

that sought to replicate Nuplam’s physical organiza-

tion in departments, each with speciﬁc needs. In this

way, the laboratory departments corresponding mod-

ules were developed into seven modules: 1) Docu-

ments of Quality; 2) Quality Assurance; 3) Mainte-

nance Management; 4) Logistics; 5) Purchases and

Contracts; 6) Human Resources Management; 7)

Support.

In this way, SigNuplam also needs all module in-

formation to be recorded securely and audited. The

audit trail can store this information automatically

using a computer system to record all actions taken

while manufacturing medicines, helping to provide

evidence.

5.2 OPDigital

OPDigital is a mobile app that aims to monitor all

stages of drug production lines. While executing the

steps, this system automates ﬁling a production or-

der document. This document contains the rules and

steps of the drug production line that operators must

conﬁrm during production. These operators ﬁll in real

time using tablets running OPDigital to add photos

and a description of the fulﬁllment of the steps of

these activities.

In addition to facilitating the ﬁlling of production

orders, this system also facilitates real-time monitor-

https://pluni.imd.ufrn.br/pluni/30/visualizarProduto

HEALTHINF 2023 - 16th International Conference on Health Informatics

372

Figure 3: OPDigital Architecture.

ing of the execution of these orders by those respon-

sible for this department. OPDigital is also respon-

sible for generating reports from other Nuplam de-

partments (e.g., Logistics, Quality Control) and for

inspection by ANVISA.

OPDigital was implemented following the mi-

croservice architecture style. As shown in Figure 3,

OPDgital architecture is divided into two packages:

back-end and front-end. The front-end contains the

Planning App and Control App. These apps use an

API Gateway to integrate to back-end.

Discovery Service works as a microservice or-

chestrator to organize the execution of the requests

that use a broker to interact with other microser-

vices. At the same time, as detailed above, Control

and Planning Services are responsible for the Nuplam

production line.

Like SigNuplam, OPDigital also requires that all

drug production line information be securely recorded

and audited. The audit trail can automatically store

this information helping to provide evidence and fa-

cilitate the audit.

5.3 Case Study Architecture

Aiming to implement this blockchain in the SigNu-

plam and OPDigital audit trail, it was necessary to

deﬁne how its main components will be used in this

case. Starting with the encryption implemented us-

ing the asymmetric public and private keys method.

Every user registered in SigNuplam or OPDigital will

receive a private key that will be used to sign trans-

actions while keeping its content transparent. This

key will be managed on the SigNuplam server using

the user’s existing credentials to access different ma-

chines.

Regarding the ledger, all transactions carried out

through SigNuplam or OPDigital will be stored after

veriﬁcation of the user’s signature. These transactions

Figure 4: Case Study Blockchain Integration.

will be replicated to all nodes on the network. After

applying a consensus mechanism, such transactions

are grouped, forming a block inserted into the ledger

and sent to all network nodes.

There are several consensus mechanisms, and the

choice depends on the blockchain implementation

used. The blockchain used in this case study is

Orthus, described in Section 1. The rationale of

this choice is that Orthus uses a Broker to receive

the requests and is focused on scalability with high

throughput (transaction per second). Regarding the

chosen broker, RabbitMQ

was chosen since it was

already used in implementing OPDigital and sup-

ported by Orthus. The only integration difﬁculty

would be with SigNuplam since this system did not

use this broker.

As Orthus is a private blockchain type, a less ex-

pensive algorithm can be used as there is conﬁdent

trust in the network participants. In this way, Byzan-

tine algorithms can be used, in which consensus is

achieved through the election of a reliable leader who

generates the block. This block is checked by all other

nodes and accepted if considered valid by more than

two-thirds (Lamport et al., 2019).

Participants in the proposed blockchain network

for this case study, besides SigNuplam and OPDigital,

must include at least two or more organizations, such

as ANVISA and the Ministry of Health. These two

other network members will be allowed to view the

audit trail, thus being able to audit the transactions.

This network structure is exempliﬁed in Figure 4.

Figure 5 describes the ﬂow followed by a trans-

action performed by a network user. When using

SigNuplam, all modiﬁcation actions a user performs

through the system will be sent to all network nodes

and gathered in blocks. Then, a node will be chosen

to close the block and send it to the others to be vali-

dated by the consensus mechanism. After validation,

the block is inserted into the chain of all system nodes

and becomes immutable.

https://www.rabbitmq.com/

Pharmaceutical Audit Trail Blockchain-Based Microservice

373

Figure 5: Flow of insertion of transactions in blockchain

from the SigNuplam trail.

Although blockchain brings advantages in secu-

rity and auditing to the audit trail, there are also some

disadvantages. The cryptography and the consensus

mechanism increase the processing time needed to

record new information. In addition, another disad-

vantage, querying an ancient track record can take a

long time due to the use of the blockchain structure.

However, comparing the disadvantages with the

blockchain’s beneﬁts, the increased data immutabil-

ity, transaction transparency, and the security of block

information can overcome the disadvantage of direct

access to a database. It ensures that the audit trail

serves for a regulatory audit, such as ANVISA.

5.4 Systems Integration

Integrating the audit trail microservice with the exist-

ing SigNuplam was done using the concept of Aspect

Oriented Programming (AOP) inside Spring’s library

. An Aspect class was implemented to intercept the

system’s transactions and send them to the RabbitMQ

and the microservice.

This class watches over all methods responsible

for sending data to the database. Upon noticing any

save, update or delete operation, it would ﬁrst send

the data to the RabbitMQ before continuing with the

normal ﬂow asynchronously. Using an Aspect class

was a choice because it would not warrant refactoring

the existing code in SigNuplam. While using an asyn-

chronous ﬂow was chosen to not generate unneces-

sary bottlenecks from the microservice or blockchain

response time.

As OPDigital uses an orchestrated microservice

architecture, every request information has to go

through a conductor, which is the DiscoveryService.

The integration between this system and the audit mi-

croservice is done by the conductor using the informa-

https://docs.spring.io/spring-framework/docs/4.3.15.

RELEASE/spring-framework-reference/html/aop.html

tion coming back from other microservices concern-

ing saving, updating, or deleting operations. This in-

formation is then sent by it to RabbitMQ on the topic

listened to by the audit microservice.

6 CASE STUDY EVALUATION

In order to assess the proposed microservice, a stress

test against the implemented case study was per-

formed. The proposed solution aims to simulate these

systems’ usage daily, where all operations should be

registered. Therefore, this test will determine the

maximum request number of simultaneous users this

solution supports.

6.1 Test Environment

The 2vCPU, 4GB RAM, and Ubuntu 18.04.2 LTS vir-

tual machines in the cloud were used to deploy and

simulate the proposed solution in a distributed way.

Four Audit Trail Microservice were deployed accord-

ing to the case study using Docker Compose

to con-

ﬁgure and create containers of the components of the

microservice and besides Orthus.

After that, Apache JMeter

was used as a load

testing tool for measuring and analyzing the solution’s

performance for this test running outside the cloud.

The requisitions simulate a high number of simulta-

neous requests.

6.2 Test Results

For these tests, it has been conﬁgured to reach up to

500 instances. After this test, the average time of each

requisition for the different scenarios (10, 50, 100,

and 500 users) was analyzed.

Table 1: JMeter Summary Report Table (in milliseconds).

Users Samples Avg. Min Max Deviation

Throughput

10 300 26 8 295 28.56 113.2/sec

50 1,500 77 6 681 97.75 208.1/sec

100 3,000 107 4 645 96.26 230.7/sec

500 15,000 246 4 1446 217.99 497.7/sec

Table 1 shows the number of simultaneous users,

number of samples, average time (in milliseconds),

minimum time, maximum time, standard deviation,

and throughput (transaction per second) of each test.

It is essential to highlight the average response time

for each request to create a transaction; for 10, 50,

100, and 500 concurrent users. In this table, it is

https://docs.docker.com/compose/

https://jmeter.apache.org/

HEALTHINF 2023 - 16th International Conference on Health Informatics

374

possible to notice that the throughput gets proportion-

ally smaller with increased users. It starts at about 11

times bigger than the number of users, counting down

to a little below one time.

Still, in Table 1, it is not shown that the error per-

centage is 0% in the ﬁrst three entries. While in the

fourth, it reaches 12.39%. This fact shows that be-

tween 100 and 500 simultaneous users, there is a mo-

ment (probably close to the 250) when the server can-

not keep up with the requests. It is also perceptible

that the throughput has reached a threshold.

On the upside, that auditing system was developed

in a factory with few employees. Besides that, the PCs

would not all be used simultaneously through most of

the expedient. From these circumstances, it is possi-

ble to conclude that this microservice will be able to

show its best performance most of the time.

7 CONCLUSIONS

This paper presented a pharmaceutical audit trail

blockchain-based microservice intending to store all

pharmaceutical system operations with integrity, se-

curity, and traceability besides facilitating the au-

dit process. Using this proposed microservice, any

pharmaceutical system can automatically register and

share its operations within a blockchain. This in-

formation sharing can facilitate the audit process

by the competent bodies and prevent possible fraud

by ensuring the immutability of data stored on the

blockchain.

Moreover, we presented a case study involving

two systems related to medicine production (SigNu-

plam and OPDigital) and two supervision systems

(ANVISA and the Ministry of Health). This scenario

was used to evaluate the proposed solution through

load testing. In this test, an increasing number of si-

multaneous users was simulated, making requests in

the system that should be registered in the blockchain

through the proposed solution.

From the results, it is perceptible that the audit

trail microservice can handle at least 100 to 200 si-

multaneous users without any data loss and with good

throughput. Therefore, it can be used in small or

medium-sized companies with around that amount of

simultaneous users.

In future works, the search for speciﬁc informa-

tion within the blockchain must be analyzed, consid-

ering the performance (time required), since the infor-

mation is stored in a chained and chronological way

and tends to increase over time. Another factor to

consider is the readability of the audit trail during the

audit process.

ACKNOWLEDGEMENTS

This work is supported by the Nuplam

and Smart

Metropolis Lab

REFERENCES

Abreu, P. W., Aparicio, M., and Costa, C. J. (2018).

Blockchain technology in the auditing environment.

In 2018 13th Iberian Conference on Information Sys-

tems and Technologies (CISTI), pages 1–6. IEEE.

Ahmad, A., Saad, M., Njilla, L., Kamhoua, C., Bassiouni,

M., and Mohaisen, A. (2019). Blocktrail: A scalable

multichain solution for blockchain-based audit trails.

In ICC 2019-2019 IEEE International Conference on

Communications (ICC), pages 1–6. IEEE.

Allinson, C. (2001). Information systems audit trails in le-

gal proceedings as evidence. Computers & Security,

20(5):409–421.

Berdik, D., Otoum, S., Schmidt, N., Porter, D., and Jarar-

weh, Y. (2021). A survey on blockchain for informa-

tion systems management and security. Information

Processing & Management, 58(1):102397.

Cruz-Correia, R., Boldt, I., Lap

ao, L., Santos-Pereira, C.,

Rodrigues, P. P., Ferreira, A. M., and Freitas, A.

(2013). Analysis of the quality of hospital informa-

tion systems audit trails. BMC medical informatics

and decision making, 13(1):1–10.

Daemmrich, A. and Bowden, M. E. (2005). Emergence

of pharmaceutical science and industry: 1870–1930.

Chem Eng News, 83.

Dailey, J. W. (2018). Pharmaceutical industry. Encyclope-

dia Britannica.

Lamport, L., Shostak, R., and Pease, M. (2019). The byzan-

tine generals problem. In Concurrency: the works of

leslie lamport, pages 203–226.

Loss, S., Cacho, N., Lopes, F., and Valle, J. M. (2019). Or-

thus: A blockchain platform for smart cities. In Pro-

ceedings of IEEE International Smart Cities Confer-

ence ISC2 2019. IEEE.

Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic

cash system. Decentralized Business Review, page

21260.

Puthal, D., Malik, N., Mohanty, S. P., Kougianos, E., and

Das, G. (2018). Everything you wanted to know about

the blockchain: Its promise, components, processes,

and problems. IEEE Consumer Electronics Magazine,

7(4):6–14.

RANA, K. (2021). How audit trail can lead to increased

compliance and transparency. The Economic Times.

Regueiro, C., Seco, I., Guti

errez-Ag

uero, I., Urquizu, B.,

and Mansell, J. (2021). A blockchain-based audit trail

mechanism: Design and implementation. Algorithms,

14(12):341.

Rostad, L. and Edsberg, O. (2006). A study of access con-

trol requirements for healthcare systems based on au-

dit trails from access logs. In 2006 22nd Annual Com-

puter Security Applications Conference (ACSAC’06),

pages 175–186. IEEE.

https://nuplam.ufrn.br/

https://smartmetropolis.imd.ufrn.br

Pharmaceutical Audit Trail Blockchain-Based Microservice

375