Digital Medication Prescription System with JSON

Liverson Paulo Furtado Severo

and Jean Everson Martina

Department of Informatics and Statistics, Federal University of Santa Catarina, Florian

opolis, Santa Catarina, Brazil

Keywords:

JSON, JWS, FHIR, JAdES, Signature, Interoperability.

Abstract:

The rapid evolution of digital health solutions, accelerated by the COVID-19 pandemic, highlighted the ne-

cessity for secure and efﬁcient electronic prescription and medication dispensing systems. This paper presents

a study on integrating HL7 FHIR standards and JAdES signatures to facilitate the digitalization of healthcare

documentation. By addressing key challenges such as interoperability, data volatility, and security, the research

proposes a framework that ensures the authenticity and integrity of electronic prescriptions—Emphasizing the

importance of self-contained digital documents that eliminate reliance on external references to enhance the

reliability of health information exchange in Brazil. Furthermore, it outlines the legal implications of elec-

tronic signatures in Brazil, advocating for compliance with national standards to ensure the legal validity of

digital prescriptions. The ﬁndings indicate that the proposed solutions not only streamline healthcare processes

but also foster a gradual transition from traditional paper-based systems to a robust digital infrastructure, ulti-

mately improving patient care and operational efﬁciency in the healthcare sector.

1 INTRODUCTION

Like the rest of the world, Brazil faced a signiﬁcant

health crisis due to the COVID-19 pandemic. This

situation accelerated the adoption of electronic medi-

cal documents and their digital processing (Conselho

Federal de Medicina, 2021). Brazilian law states

these documents can be electronically signed with

legal validity. However, qualiﬁed electronic signa-

tures are mandatory for special control prescriptions

and medical certiﬁcates (Presid

encia da Rep

ublica do

Brasil, 2020).

Currently, in Brazil, prescriptions and medication

dispensing are issued through printed documents with

a handwritten signature, and dispensing is done all at

once. This system is inﬂexible to the patient and has

security issues related to falsiﬁcation, problems with

prescription legibility, and lack of traceability.

The aim is to transform this process by using digi-

tal technologies and introducing a new concept of par-

tial dispensing, where patients can access medications

gradually based on their needs. Electronic signatures

represent a crucial step in facilitating the ﬂow of dig-

ital documents, making it easier to share information,

streamline bureaucratic processes, and enhance stor-

age solutions.

https://orcid.org/0009-0006-3962-8593

https://orcid.org/0000-0003-4104-1741

Electronic signatures are a way to authenticate and

validate documents digitally using tools speciﬁcally

developed for this purpose. There are three categories

of electronic signatures. The simple electronic signa-

ture is similar to traditional signatures made on pa-

per. The advanced electronic signature employs cryp-

tographic algorithms to ensure the signature cannot

be forged. Finally, the qualiﬁed electronic signature

is used in more speciﬁc contexts, incorporating time-

stamping and offering greater robustness. These cat-

egories serve different needs and levels of security in

the digital signing process.

Electronic signatures can be categorized as em-

bedded or detached. Embedded signatures are inte-

grated with the document, resulting in a single signed

document. In contrast, detached signatures sepa-

rate the document and the signature into two ﬁles.

These two components demonstrate that the signature

is valid when submitted for validation.

Qualiﬁed signatures are advanced signatures cre-

ated using a qualiﬁed signature creation device based

on certiﬁcation qualiﬁcations for electronic signa-

tures (European Parliament and Council of the Eu-

ropean Union, 2014). In Brazil, a qualiﬁed signa-

ture complies with the terms outlined in Law No.

14,063 regarding qualiﬁed signatures (Presid

encia da

Rep

ublica do Brasil, 2020).

834

Severo, L. P. F. and Martina, J. E.

Digital Medication Prescription System with JSON.

DOI: 10.5220/0013315700003911

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 18th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2025) - Volume 2: HEALTHINF, pages 834-843

ISBN: 978-989-758-731-3; ISSN: 2184-4305

This framework has paved the way for the evolu-

tion of signatures in the health sector; however, there

are still potential improvements to be addressed. One

area that requires enhancement is the interoperabil-

ity of signed patient documents, as there is currently

no standardization to facilitate information exchange

between different healthcare institutions. To address

the issue of data interoperability, the National Health

Data Network (RNDS) project was initiated, aimed

at the digital transformation of healthcare in Brazil

(Minist

erio da Sa

ude do Brasil, 2020). Interoperabil-

ity can be understood as the standardization of vocab-

ularies, data representation structures, and messaging

protocols between systems. However, the develop-

ment of these standards is slow, and their adoption is

even slower (Roehrs et al., 2021).

The RNDS project uses the Fast Healthcare Inter-

operability Resources (FHIR) standard Health Level

Seven International (HL7) created for data ﬁles to en-

hance interoperability. To enable the use of ﬁles gen-

erated in the FHIR standard, they must be transformed

into digital documents, as relevant information must

be self-contained for them to qualify as such. In the

case of HL7 FHIR, external references for pertinent

details may pertain to the healthcare provider or the

patient.

Despite this, using the FHIR standard can facili-

tate the electronic registration and dispensing of med-

ical prescriptions. A medical prescription document

must be signed by a physician in a manner that al-

lows for determining when the signature was made

and ensures that the physician has the authorization to

practice, as stipulated by the Federal Medical Coun-

cil (CFM) and registered with the Regional Medi-

cal Council (CRM) of the physician (Presid

encia da

Rep

ublica do Brasil, 1957).

To dispense medications, it is essential to ensure

that the pharmacist is authorized to practice, as indi-

cated by their registration with the Federal Pharmacy

Council (CFF) (Presid

encia da Rep

ublica do Brasil,

1960). Therefore, during the dispensing process, a

separate ﬁle is created solely for the total or partial

dispensing of the prescribed medications. This ﬁle

must also be signed, including information on when

the signature was made.

The hypothesis is that the HL7 FHIR pattern with

digital signature JAdES effectively enhances the in-

teroperability and the security of the prescription and

dispensation of medicines in Brazil, promoting a pro-

cess transition from paper to robust digital infrastruc-

ture. To do that, this research looks to develop a dig-

ital system to prescribe and dispense medicines, ex-

ploring technologies such as the pattern HL7 FHIR

and JAdES digital signatures. The following features:

• Allow the generation of digital prescript and its

registration with support to the partial dispensa-

tion of medicines;

• Validation of documents through APIs and the im-

plementation of a database to control the dispen-

sation of medicines;

• Implement an interoperability and signature pat-

tern to medical prescriptions and dispensations;

• Validation of the project in a controlled environ-

ment.

2 SIGNATURE IN DOCUMENTS

IN JSON FORMAT

Despite the existence of other formats, such as XML,

JSON is a simple format that provides the necessary

structures for information exchange and can be self-

explanatory for humans (Pohls, 2015). JSON syntax

has increasingly become prevalent in electronic trans-

actions, extending beyond just support for web tokens

(JWT). As a result, the JSON Web Signature (JWS)

has been deﬁned for digital signatures (Ibarz, 2020).

2.1 JWS

According to (Jones et al., 2015), JWS represents se-

cure content using signatures or message authenti-

cation codes (MACs) with data structures based on

JSON and Base64 encoding. Three ﬁelds are used in

the composition of these structures: the JSON Object

Signing and Encryption (JOSE) header, the JWS pay-

load, and the JWS signature.

The JOSE header is a JSON object that contains a

description of cryptographic operations and parame-

ters used, all compressed into header parameters. It

consists of a protected JWS header and an unpro-

tected JWS header, where the protected header in-

cludes parameters whose integrity is ensured by the

JWS signature. In contrast, the unprotected header

lacks this integrity protection. The JWS payload is the

message that must be secured in octet format, which

can be in an arbitrary sequence. The JWS signature

is the digital signature or MAC that protects both the

protected JWS header and the JWS payload.

JWS can be serialized in two forms: JWS Com-

pact Serialization and JWS JSON Serialization. In

JWS Compact Serialization, the unprotected header

is not used; thus, the JOSE header and the pro-

tected JWS header are the same. The JOSE header,

JWS payload, and JWS signature are concatenated

as Base64-encoded strings, separated by periods. In

contrast, JWS JSON Serialization requires at least

Digital Medication Prescription System with JSON

835

one of the headers mentioned above, or both, with

the JOSE header representing the combination of the

header information (Jones et al., 2015). Figure 1 il-

lustrates an example of a JWS signature.

Figure 1: JWS signature example.

2.2 JAdES Signature

In 1999, the European Telecommunications Stan-

dards Institute (ETSI) established the ETSI Elec-

tronic Signatures and Infrastructures Working Group,

a committee focused on developing the European

standard for digital signatures and related infrastruc-

tures (Ibarz, 2020). According to (Kutyłowski and

Bła

skiewicz, 2023), these signatures possess the fol-

lowing characteristics:

• They are uniquely linked to a signer;

• They are capable of identifying the signer;

• They are created using electronic signature cre-

ation data that the signer can use exclusively and

with a high level of conﬁdentiality;

• They are connected to the signed data so that any

subsequent changes will be detected.

After updates, the committee published the Euro-

pean standards, approved by the National Standard-

ization Organizations of the European Union Member

States, which deﬁned the family of Advanced Elec-

tronic Signatures (AdES) for digital signatures. The

following features characterize these:

• A set of signed and unsigned attributes with a spe-

ciﬁc syntax (initially using ASN.1 dictionaries,

followed by XML, PDF, and later JSON);

• Mechanisms to incorporate these attributes into

the digital signature structure;

• A series of signed and unsigned attributes combi-

nations are called levels.

In the case of basic electronic signatures, if the

signing certiﬁcate expires, the signature automatically

becomes invalid. To address this issue, formats al-

low incorporating additional information in the sig-

nature to ensure long-term validity. This information

includes evidence from a third party (such as certiﬁ-

cation authorities) and time stamps in the signature to

verify the status of the signature at the moment it was

created (Ibarz, 2021).

In 2021, a new advanced electronic signature was

created using JWS, known as JAdES. The general

requirements for a JAdES signature are the compo-

nents deﬁned in the JOSE header (Ibarz, 2020). For

a JAdES signature to be valid, it must not only con-

tain the header parameters of a JWS but also include

new parameters for signature qualiﬁcation based on

the speciﬁed level. JAdES features four classiﬁcation

levels that function incrementally, each designed to be

used according to the application’s needs. The avail-

able levels are:

• Level B-B incorporates signed header parameters

and some unsigned components within the un-

signed header parameter etsiU when the signature

is generated.

• Level B-T requires the generation and inclusion

of a trust token that proves the signature existed at

a speciﬁc date and time in an existing signature.

• Level B-LT mandates incorporating all signature

validation materials into the signature document,

allowing for the long-term availability of valida-

tion materials.

• Level B-LTA necessitates the inclusion of time

stamps that enable the validation of the signature

for extended periods after its creation, ensuring

the long-term validation and integrity of the doc-

ument.

The ﬁrst level is the simplest to implement, re-

quiring fewer parameters to create. Generally, this

advanced signature utilizes the header parameters al-

ready deﬁned as mandatory by the JWS signature,

adds the requirement for optional JWS parameters,

and introduces new parameters.

HEALTHINF 2025 - 18th International Conference on Health Informatics

836

The header parameter JWS deﬁnes as mandatory

for a signature is the Algorithm (alg). This parameter

is protected and serves to identify the cryptographic

algorithm used for the security of the JWS. There-

fore, a JWS signature will be invalid if the alg does

not contain a supported algorithm or if no associated

cryptographic algorithm exists for the MAC content

(Jones et al., 2015). The mandatory header parameter

deﬁned for a JAdES signature is the Claiming Sign-

ing Time (sigT). This is a protected parameter whose

function is to specify the moment the signer intends

to perform the signing process. Thus, the record must

include a string in Coordinated Universal Time (UTC)

format indicating the time of the signature.

The protected header parameter Critical indicates

which extension parameters are used in the signature

and must be processed and understood. Thus, a list

that should never be empty is generated when it in-

cludes parameters that need to be processed (Jones

et al., 2015). In the case of JAdES, the attributes eligi-

ble to be included in the Critical list are: sigT, x5t#o,

sigX5ts, srCms, sigPl, srAts, adoTst and sigPId (In-

stitute, 2021). The content type (cty) header param-

eter is used to indicate the media type contained in

the JWS payload of the document. This parameter is

included when more than one type of object may be

present in the JWS payload, allowing the application

to use the value of this parameter to eliminate ambi-

guity regarding the data that may be present in the

document.

The header parameters X.509 Certiﬁcate SHA-

256 Thumbprint (x5t#S256), X.509 Certiﬁcate Digest

(x5t#o), and X.509 Certiﬁcates Digests (sigX5ts) are

protected parameters intended to indicate the message

digest responsible for hashing the document. The

x5t#S256 was deﬁned in JWS as an optional attribute

and is speciﬁc for use with SHA-256. The parameters

x5t#o and sigX5ts are deﬁned by JAdES, where x5t#o

is used for any hashing algorithm other than SHA-

256, while sigX5ts is utilized when multiple certiﬁ-

cates are used in the signature. In addition to deﬁn-

ing the requirements for the parameters as mentioned

above, the deprecation of the X.509 Certiﬁcate SHA-

1 (x5t) deﬁned for JWS signatures is noted due to

its vulnerability, making it easier to break encryption

and retrieve information from the signature (Institute,

2021).

The header parameter X.509 Certiﬁcate Chain

(x5c) contains the X.509 public key certiﬁcate or the

chain of certiﬁcates corresponding to the key used to

sign the JWS digitally. Thus, x5c is a list of cer-

tiﬁcates represented as a string value in Base64 for-

mat. This parameter must be present if the parameters

x5t#S256, x5t#o or sigX5ts are not included; other-

wise, its inclusion is optional. In addition to includ-

ing protected parameters, it is possible to add unpro-

tected parameters, which are inserted into a list of pa-

rameters called etsi Unsigned (etsiU), with all entries

formatted in Base64. Table 1 shows the minimum pa-

rameters required for creating a JAdES document at

level B-B.

Table 1: Minimun parameters needed to create a JAdES sig-

nature.

Parameter Mandatory level

Alg Mandatory

SigT Mandatory

Crit Mandatory (sigT)

Cty Mandatory (multiple media)

X5t#S256 Conditioned (without x5c, x5t#o, sigX5ts)

X5t#o Conditioned (without x5c, x5t#S256, sigX5ts)

SigX5ts Conditioned (without x5c, x5t#o, x5t#S256)

X5c Conditioned (without x5t#S256, x5t#o, sigX5ts)

3 HL7 FHIR

HL7 is a nonproﬁt organization providing frame-

works and standards that facilitate the exchange, in-

tegration, sharing, and retrieval of electronic health

information to support clinical practices and the han-

dling, delivery, and veriﬁcation of healthcare services

(Health Level Seven International, 2023). HL7 FHIR

is a platform speciﬁcation that deﬁnes a set of capabil-

ities for interoperability processes within the health-

care sector (Health Level Seven International, 2023).

According to (Monsen et al., 2023), it is a solution for

sharing health data information using modular com-

ponents, with numerous developers working tirelessly

to contribute to various speciﬁcation components that

can be utilized in different contexts, such as best prac-

tice guidelines, clinical document architecture trans-

lation, and clinical care of injuries.

Before the HL7 FHIR standard, other standards

were developed with the same purpose. Still, they had

a lower level of human-readable abstraction, which

resulted in greater effort required for data interpre-

tation. One example is HL7 V2, created in 1989 to

integrate various hospital systems, including admin-

istrative processes and clinical systems (Bender and

Sartipi, 2013). Despite its application, the HL7 V2

standard lacked good scalability. It could not adapt to

other use cases, such as the judicial system, and was

difﬁcult to comprehend, as illustrated in Algorithm 1.

The next standard developed was HL7 V3, created

in 1995 to address the deﬁciencies of its predecessor.

Semantic and lexical element structures were deﬁned

for this standard to generate message artifacts auto-

matically. However, the standards are not directly im-

plementable and require tools to create software sys-

tems. It offers available XML schemas but not norma-

Digital Medication Prescription System with JSON

837

1 MSH | ˆ˜\& | R e gion a l MP I || Ma s ter MPI | A lph a

Hosp i tal |2006 0 5 01

2 14 0 010|| ADT ˆ A28 | 3 94837 5 | PˆT | 2 .4||| ER <cr

3 EV N | A 28 | 2 0 0 6 0 5 0 1 1 4 0 0 0 8 | | | 0 0 0 3 3 8 4 7 5 ˆ

Aut h or ˆ Art h ur ˆ ˆ ˆˆˆ

4 ˆ R egion a l MPI

&2.16.840.1.113883.19 . 2 0 1 & I SO ˆ L

|200 6 05011 4 0008 < cr >

5 PI D | ||000197 2 4 5 ˆ ˆ ˆ N a t ionalP N

&2.16.840.1.1138 8 3 . 1 9 . 3 & I SO ˆ PN

˜45 3 2ˆˆ

6 ˆ C a r e f u lCareClini c

&2.16.840.1.113883.19.2.400566& I SO ˆ

PI ˜ 32423 4 6 ˆ ˆ

7 ˆ G oodma n G P

&2.16.840.1.113883.19.2.450998& I SO ˆ

PI ||

8 Patie n t ˆ P artic i a ˆˆˆˆ ˆ L | | 1 975010 3 | F ||

9 | R a ndomr o a d 23 a& R andom r o a d &23 a ˆˆ

Any t own ˆˆ12 0 0ˆˆ H ||

10 55 5 354 2 557ˆ ORN ˆ PH ˜55 5 354 2 5 58ˆ ORN ˆ FX

|555 555 7 865ˆ WPN ˆ PH < cr >

11 PV 1 || N | < cr >

Algorithm 1: Example of a HL7 V2 message.

tive ones, primarily for veriﬁcation purposes. Despite

the evolution of the model, the use of HL7 V3 in-

volves complex transformations of models, operating

at a level similar to that of a compiler.

HL7 FHIR was created in 2011, building on

the standards that preceded it and combining their

advantages with modern data transfer technologies.

The standard speciﬁcation provides basic resources,

frameworks, APIs, and a platform for implement-

ing different solutions. To address information not

included in the basic resources, HL7 FHIR of-

fers an embedded extension mechanism that can be

adapted for speciﬁc use cases to ensure interoper-

ability. Therefore, this standard can cover different

healthcare domains and manage resources, making

it suitable for various purposes, contexts, and work-

ﬂows (Vorisek et al., 2022).

There are two main types of FHIR solutions: re-

sources and proﬁles (Monsen et al., 2023). Resources

are data organized in packages that can be formatted

in JSON or Extensible Markup Language (XML) and

transported using HTTPS. Proﬁles are the rules for

data exchange, including constraints and additional

data elements (Duda et al., 2022). Implementation

guides serve as procedural standards for the consistent

use of FHIR resources and support Application Pro-

gramming Interfaces (APIs) to facilitate workﬂows in

speciﬁc domains (Duda et al., 2022). FHIR resources

have the following characteristics (Bender and Sar-

tipi, 2013):

• They must have a clear boundary that corresponds

to one or more logical transaction scopes;

• They must be different in meaning, not just in us-

age;

• They need to have a natural identity;

• They should be very common and widely used in

commercial transactions;

• They must not be too speciﬁc or detailed to hinder

support for a wide range of commercial transac-

tions;

• They must be mutually exclusive;

• They can use other resources but must not be

merely a composition of resources;

• They need to provide new content;

• They should be recognized within a logical frame-

work based on the similarity of the resource and

what it is connected to;

• They must be large enough to have a meaningful

context.

4 CORRELATED WORKS

The exploration of FHIR resources for interoperabil-

ity is not a new concept. In the research by (Monsen

et al., 2023), the technology is employed to standard-

ize nursing practices to improve the quality of data

outputs. This information can be utilized within the

standard for assessments, care planning, and outcome

measurement, demonstrating its potential to enhance

data transmission, information storage, and knowl-

edge discovery in nursing and public health. Their

research shows the utility of FHIR in creating stan-

dardized healthcare data focused on the nursing sec-

tor and does not address the digital signature require-

ments critical for secure prescription and medication

dispensing processes. While this study focuses on us-

ing the standard for nursing data interoperability, it

does not explore the use of digital signatures to ensure

the authenticity of documents, a crucial factor for the

functionality of prescription and medication dispens-

ing addressed in this article’s study.

The study by (Bender and Sartipi, 2013) compares

the evolutions of the standards set by HL7, highlight-

ing the properties of each standard that allow for a

comparison of their strengths and weaknesses. It em-

phasizes that the FHIR standard has garnered signif-

icant attention from the relevant community due to

its simplicity and the potential for FHIR to leverage

the experiences gained from the implementations of

HEALTHINF 2025 - 18th International Conference on Health Informatics

838

preceding standards to enhance the state of commu-

nication in healthcare systems. Therefore, their study

highlights FHIR’s potential for improving healthcare

communication but lacks the possibility of using a ﬁle

with an FHIR pattern as an authenticated digital doc-

ument and digital signatures to use these documents

to prescribe medications and create a rastreability on

it.

(Vorisek et al., 2022) analyzes the beneﬁts of HL7

FHIR in improving the interoperability of health in-

formation. This article compiles a review of existing

literature to enhance understanding of the standard,

with less emphasis on its application. Thus, the arti-

cle aims to identify potential use cases for HL7 FHIR

in health research while highlighting the associated

limitations and providing a realistic perspective on its

implementation in medical research. While the article

identiﬁes potential use cases for HL7 FHIR in health

research, it does not address practical applications in-

volving digital signatures to ensure the authenticity

and security of medical documents, a gap this study

aims to ﬁll.

(Gruendner et al., 2021) developed a preprocess-

ing service to enable the direct loading of FHIR data.

The data is transformed into ready-to-analyze subsets,

converting JSON information into PostgreSQL data

format. This facilitates the transition from data acqui-

sition to relevant clinical research, allowing for more

efﬁcient handling of large-scale clinical data without

reliance on cloud servers. While the study focuses

on storing data without needing cloud servers, it does

not address the resolution of data exchange between

healthcare centers and pharmacies. Consequently, it

does not bring the need for data validation within the

database, as demonstrated in the project presented in

this article.

(Cheng et al., 2021) introduces a module for clini-

cal data interoperability services to the REDCap soft-

ware, designed to create databases for clinical trial re-

search and any electronic health record systems that

utilize the HL7 FHIR standard. This module facili-

tates the independent collection and mapping of data

to REDCap ﬁelds while enabling real-time data ex-

traction to support data collection for clinical studies

through intuitive interfaces requiring minimal IT in-

volvement. Although the survey implements FHIR

interoperability to facilitate the collection and map-

ping of clinical data, it does not address the use of dig-

ital signatures to authenticate documents, a key fea-

ture explored in the present work to ensure security

and compliance in medical prescriptions.

(Georgioska, 2020) aimed to analyze the practical

feasibility of using digital signatures in the public pro-

curement system of North Macedonia. The objective

was to enhance the security and authenticity of docu-

ments, primarily focusing on providing a method for

verifying the signer’s identity to ensure the authen-

ticity of signed data. The research demonstrates sig-

niﬁcant effectiveness in security and improves pro-

curement processes’ efﬁciency by reducing bureau-

cratic paperwork and fostering better communication

among the parties involved. Although the study ex-

plores the use of digital signatures to ensure secu-

rity and authenticity in public procurement systems,

it does not address the application of these technolo-

gies in the healthcare sector, particularly in the con-

text of digital prescriptions and medication dispens-

ing, which is the focus of this study.

5 METHODOLOGY

To digitalize prescription and medication dispensing

documents, it was essential ﬁrst to understand the

standards used for information exchange in health-

care. In the medical ﬁeld, HL7 is renowned for its

data standardization, having established HL7 V2 and

HL7 V3 as initial solutions for health information

standardization. However, despite well-established

standards, interpreting data within these frameworks

requires signiﬁcant effort, and developing an applica-

tion capable of performing this interpretation poses an

even greater challenge.

Thus, the search shifted toward the evolving HL7

FHIR standard, which has shown great potential. This

standard employs more user-friendly formats that fa-

cilitate easier association and transport, reducing ef-

fort for humans and applications in data interpreta-

tion. Among the possible formats for generating a ﬁle

in HL7 FHIR are JSON and XML, which are more

manageable for applications and can effectively sup-

port electronic document signatures.

With its high capacity for information transfer and

low storage and memory requirements, along with the

ease of understanding the contained information due

to the hierarchical organization within the ﬁle, the

JSON format has proven to be the ideal choice for

advancing the next steps of the research. In contrast,

while XML also has a well-deﬁned hierarchical struc-

ture, it requires more effort for data transition and in-

terpretation, as illustrated in Table 2.

There were issues to be resolved regarding using

HL7 FHIR, particularly due to the reliance on hy-

perlinks as references. While bundles and contained

resources are used, references with links associated

with those bundles remain possible. This approach

hindered the creation of a signed document, as a dig-

itally signed document must contain its entire scope.

Digital Medication Prescription System with JSON

839

Table 2: Comparison between JSON and XML adapted

from (Nurseitov et al., 2009).

JSON XML

Number Of Objects 100000 100000

Total Time(ms) 7497.36 310017.47

Average Time(ms) 0.07 3.10

Average System % CPU Utilization 11.30 36

Average memory % utilization 68.06 68.79

Furthermore, these references are volatile and would

invalidate the generated prescription because of the

information change after the signature. To address

this, these references were incorporated into the doc-

ument, ensuring that all necessary information is self-

contained, regardless of the possibility of external

links. These issues were resolved by embedding this

information within the document to guarantee com-

pleteness and preserve the integrity of the signed doc-

ument.

Thus, what were previously external references

and hyperlinks are transformed into self-references at

other points within the JSON object. All necessary in-

formation in the ﬁle ensures that the document is self-

contained and capable of providing all the required

data to generate a digital prescription. This step is

crucial, as there are instances where, in HL7 FHIR,

the information retrieved online tends to be volatile,

especially considering the high rate of updates based

on changes in the circumstances of the doctor and the

patient.

The next step to be deﬁned is the signature stan-

dard to ensure the document’s validation in JSON.

The ﬁrst consideration was JWS; however, its imple-

mentation has two issues. The ﬁrst is the requirement

for header parameters that qualify the electronic sig-

nature, as qualiﬁed signatures are mandatory for med-

ication prescriptions. This necessitated a deeper ex-

ploration of JSON signatures. The JAdES standard,

created by ETSI, emerges as the most suitable for-

mat. The parameters for Claiming Signing Time and

those providing information about the certiﬁcate used

for signing are essential for qualifying the signatures

made by doctors when prescribing medications and

pharmacists when dispensing them.

The highlighted signature was chosen because it

allows veriﬁcation of its validity without sharing doc-

ument information. HL7 FHIR proposes implement-

ing the DaVinci signature in its framework. While this

signature is also based on JWS, it was not selected for

use due to the greater robustness of the security of-

fered by JAdES. JAdES allows for the deﬁnition of

different levels, enabling more efﬁcient validation of

signed documents over the long term.

With the assurance that the document to be signed

contains updated information from the moment it was

generated, the focus shifts to executing the qualiﬁed

signature. Here, the most critical parameter to con-

sider is the one that indicates when the document was

signed; thus, the sigT parameter is essential for con-

textualizing the timing of the signature. This enables

an application to generate and sign an electronic doc-

ument related to a prescription for a patient. In the

API, the credentials of the doctor or pharmacist are

validated before recording a prescription or dispens-

ing. The architecture diagram of the project in Figure

2 illustrates how the applications are interconnected.

Figure 2: Architecture diagram of the project.

The Signature Validator API was developed to

create the adapted FHIR document and perform se-

mantic validation of the information in the signature.

In the prescription, this API is responsible for match-

ing the doctor’s social security number (CPF) with the

number of CPF registered with a consult on the CFM

database of this doctor’s CRM number. All this pro-

cess is done when the doctor requests the API to sign

the document. This process is crucial to prevent peo-

ple who are not qualiﬁed doctors from prescribing any

medication to a third person.

The signed prescription must be valid according to

the Brazilian Pattern of Digital Signatures (PBAD) to

be accepted. A Signer API was developed to ensure

the signature is valid with PBAD and conﬁrm that it

will be trusted and valid in Brazilian territory. This

API will create a signature with valid parameters us-

ing the certiﬁcate uploaded by the doctor in the user

interface to sign the document. It will also conﬁrm

whether the certiﬁcate and its trust anchor are valid,

according to PBAD.

After creating and validating the prescription, the

Signature Validator API is also responsible for creat-

ing the prescription register in a database. To insert

HEALTHINF 2025 - 18th International Conference on Health Informatics

840

Figure 3: State machine diagram of a registry of medication prescription.

Figure 4: State machine diagram of a registry of medication prescription.

the prescription information into the database, a hash

value for each prescription is made with the date it

was created. It also creates a table with the prescrip-

tion ID and available medications to be consulted in

the dispensation. In this way, the API stores the data

and the document as shown in Figure 3.

It is important to highlight that data storage was

carried out on a local test server when the research

was conducted. However, a server with shared ac-

cess across different hospitals, clinics, doctor’s of-

ﬁces, medical centers, and pharmacies would be es-

sential to ensure the solution’s applicability in a real-

world setting. A third-party organization interested

in implementing this solution must provide the neces-

sary infrastructure to achieve this.

To dispense the prescription medications, the

pharmacist needs the prescription’s hash value and

uses it to access its information. The Signature Val-

idator API will bring the document, check if it’s cor-

rect semantically, and send it to the Conformance Ver-

iﬁer API. The Conformance Veriﬁer API will check

the validity of the signature and its trust anchors and

validate the signature parameters according to PBAD

to return to the Signature Validator API, which will

perform a query at the database and return the med-

ications prescribed and their amounts. Signer and

Conformance Veriﬁer APIs have some common im-

plementations; therefore, these implementations were

detached and called core libraries to enhance compre-

hension and make the development easier.

After this process, the Validation API is respon-

sible for consulting possible previous dispensations

linked to that prescription by ID key and performing

the same veriﬁcation made in the prescription if nec-

essary. The pharmacist has two options for dispensa-

tion: partial dispensation, which will dispense some

prescribed medications, and total dispensation, which

will dispense all prescribed medications.

To perform the dispensation, the pharmacist will

select the amount of each prescribed medication and

ﬁll out a form with his information and CFF number.

This will allow the Signature Validator API to con-

sult the CFF database. After this conﬁrmation, the

pharmacist will select the amount to dispense. If dis-

pensing medication is not allowed anymore, previous

dispensations will show a stack trace of dispensations.

Otherwise, the document of dispensation is created,

and the pharmacist will sign it to pass through the

validation process of the Signature Validator API and

Signer API, which will be stored with its respective

prescription as seen in Figure 4.

Unit tests were developed to guarantee the correct

functionality of APIs. Tests on Signer API verify if

all needed parameters were inserted in the signature,

it also verify if the signature was made and use arte-

facts to verify the insertion of the digest algorithm pa-

rameter. The Conformance Veriﬁer API has tests to

see the validity of the signature, non-repudiation of

the signature, its certiﬁcate chain, and the validity of

the signature parameters.

Document Validation tests verify the correctness

of the professional’s credentials and the consistency

of the signatory’s information with the data retrieved

from the CFM and CFF databases. They also ensure

Digital Medication Prescription System with JSON

841

that the credentials are included in both the prescrip-

tion and the dispensing of medications. Additionally,

tests were developed to verify the validity of the pre-

scription and dispensing and the functionality of the

database.

After implementing all unit tests, a pilot test was

conducted with one doctor to test the API’s behav-

ior during the prescribing process and a pharmacist

to test its behavior with the partial and full dispens-

ing of medicines. In this pilot, the system behavior

was tested with valid and already dispensed receipts,

valid and invalid CRM and CFF, and valid and invalid

signatures.

6 RESULTS AND CONCLUSION

The project holds great potential to improve the pre-

scription and dispensing process, and the pilot test

showed its technical viability. It can also revolution-

ize dispensing practices with a new concept of partial

dispensing, increasing patients’ ﬂexibility in purchas-

ing their medications. The combination of FHIR stan-

dardization and digital signatures, where the JSON

format and JAdES served as crucial communication

bridges between these concepts, demonstrated a vi-

able path toward digitalizing the medication prescrip-

tion process.

In addition to the problems already faced, this ap-

proach still needs to be facilitated for common pa-

tients. For this, the solution under analysis is to use a

PDF representation for the patient that will be issued

digitally, containing a QRcode referencing the hash

of the ofﬁcial medication prescription and dispensing

document. The generated PDF will be signed by the

doctor upon prescription and signed by a pharmacist

upon dispensation, and the objective is to use it as a

human-readable document.

Although adaptations are necessary, the transfor-

mations implemented have been feasible and leave

room for further evolution. The technologies em-

ployed are still considered new and can be explored in

various ways. A Brazilian deﬁnition based on FHIR

can be established, allowing for a gradual transition

from current paper prescriptions to a digital format.

For future work, a real case of use with a hospital

and pharmacy needs to be done, and in case of suc-

cess, blockchain implementation for medication dis-

pensing is proposed. This technology aligns well with

the theme by leveraging the key properties of consis-

tency and information tracking. It can potentially en-

hance security and fraud prevention, which could sig-

niﬁcantly improve the safety of prescriptions and the

dispensing of controlled medications. This technol-

ogy can also improve the performance and the scala-

bility of this solution.

REFERENCES

Bender, D. and Sartipi, K. (2013). HL7 FHIR: An agile

and RESTful approach to healthcare information ex-

change. In Proceedings of the 26th IEEE Interna-

tional Symposium on Computer-Based Medical Sys-

tems, pages 326–331. IEEE.

Cheng, A., Duda, S., Taylor, R., Delacqua, F., Lewis, A.,

Bosler, T., Johnson, K., and Harris, P. (2021). RED-

Cap on FHIR: Clinical data interoperability services.

121:103871.

Conselho Federal de Medicina (2021). Resoluc¸

ao cfm

2.299/2021. https://sistemas.cfm.org.br/normas/

visualizar/resolucoes/BR/2021/2299. Acessado em:

09 jun. 2024.

Duda, S. N., Kennedy, N., Conway, D., Cheng, A. C.,

Nguyen, V., Zayas-Cab

an, T., and Harris, P. A. (2022).

HL7 FHIR-based tools and initiatives to support clin-

ical research: a scoping review. 29(9):1642–1653.

European Parliament and Council of the European Union

(2014). Regulation (EU) no 910/2014 of the european

parliament and of the council of 23 july 2014 on elec-

tronic identiﬁcation and trust services for electronic

transactions in the internal market and repealing direc-

tive 1999/93/EC. http://data.europa.eu/eli/reg/2014/

910/oj/eng. Acessado em: 09 jun. 2024.

Georgioska, M. (2020). Application of digital signatures in

the electronic system for public procurement in repub-

lic of north macedonia.

Gruendner, J., Gulden, C., Kampf, M., Mate, S., Prokosch,

H.-U., and Zierk, J. (2021). A framework for criteria-

based selection and processing of fast healthcare inter-

operability resources (FHIR) data for statistical anal-

ysis: Design and implementation study. 9(4):e25645.

Health Level Seven International (2023). Fhir modules.

https://hl7.org/fhir/modules.html. Acessado em: 09

jun. 2024.

Ibarz, J.-C. C. (2020). Bringing JSON signatures to

ETSI AdES framework: Meet JAdES signatures.

71:103434.

Ibarz, N. (2021). Development of a tool for validating

etsi ades digital signatures as deﬁned by the european

standard etsi en 319 102-1.

Institute, E. T. S. (2021). Electronic signatures and infras-

tructures (esi); jades digital signatures; part 1: Build-

ing blocks and jades baseline signatures.

Jones, M. B., Bradley, J., and Sakimura, N. (2015). JSON

web signature (JWS). Num Pages: 59.

Kutyłowski, M. and Bła

skiewicz, P. (2023). Advanced elec-

tronic signatures and eIDAS – analysis of the concept.

83:103644.

Minist

erio da Sa

ude do Brasil (2020). Rede nacional de da-

dos em sa

ude (rnds). https://www.gov.br/saude/pt-br/

composicao/seidigi/rnds/rnds. Acessado em: 09 jun.

2024.

HEALTHINF 2025 - 18th International Conference on Health Informatics

842

Monsen, K. A., Heermann, L., and Dunn-Lopez, K. (2023).

FHIR-up! advancing knowledge from clinical data

through application of standardized nursing termi-

nologies within HL7® FHIR®. 30(11):1858–1864.

Nurseitov, N., Paulson, M., Reynolds, R., and Izurieta, C.

(2009). Comparison of JSON and XML data inter-

change formats: A case study.

Pohls, H. C. (2015). JSON sensor signatures (JSS): End-

to-end integrity protection from constrained device to

IoT application. In 2015 9th International Conference

on Innovative Mobile and Internet Services in Ubiqui-

tous Computing, pages 306–312. IEEE.

Presid

encia da Rep

ublica do Brasil (1957). Lei n

3.268, de

30 de setembro de 1957. http://www.planalto.gov.br/

ccivil 03/leis/l3268.htm. Acessado em: 09 jun. 2024.

Presid

encia da Rep

ublica do Brasil (1960). Lei n

3.820, de

11 de novembro de 1960. http://www.planalto.gov.br/

ccivil 03/leis/l3820.htm. Acessado em: 09 jun. 2024.

Presid

encia da Rep

ublica do Brasil (2020). Lei

14.063, de 23 de setembro de 2020.

https://www.in.gov.br/en/web/dou/-/lei-n-14.

063-de-23-de-setembro-de-2020-278574432. Aces-

sado em: 09 jun. 2024.

Roehrs, A., Da Costa, C. A., Righi, R. R., Mayer,

A. H., Da Silva, V. F., Goldim, J. R., and

Schmidt, D. C. (2021). Integrating multiple

blockchains to support distributed personal health

records. 27(2):146045822110075.

Vorisek, C. N., Lehne, M., Klopfenstein, S. A. I., Mayer,

P. J., Bartschke, A., Haese, T., and Thun, S. (2022).

Fast healthcare interoperability resources (FHIR) for

interoperability in health research: Systematic review.

10(7):e35724.

Digital Medication Prescription System with JSON

843