Extending the Fast Healthcare Interoperability Resources (FHIR)

with Meta Resources

Timoteus Ziminski

, Steven Demurjian

and Thomas Agresta

Department of Computer Science and Engineering, University of Connecticut, 371 Fairfield Way, Storrs, U.S.A.

Department of Family Medicine, UConn Health, 263 Farmington Avenue, Farmington, U.S.A.

{Timoteus.Ziminski, Steven.Demurjian, Thomas.Agresta }@uconn.edu

Keywords: Data Design, FHIR, Interoperability, Medication Reconciliation, Patterns.

Abstract: The Fast Healthcare Interoperability Resources (FHIR) from the international Health Language Seven (HL7)

organization has been mandated by the United States Office of National Coordinator to promote the secure

exchange of healthcare data for patients through the use of cloud-based APIs. FHIR reformulated the HL7

XML standard by defining 135+ resources that conceptualize the different aspects of healthcare data such as

patients, practitioners, organizations, services, appointments, encounters, diagnostic data, and medications.

Developers of healthcare applications select a subset of the resources that are required to solve their problems.

However, the standard provides no way to effectively organize a subset of resources into a higher-level

construct similar to software design patterns. This paper leverages the design pattern concept to extend the

FHIR standard by defining meta resources that are a conceptual construct that clearly defines the involved

resources and their interactions into one unified artifact. To illustrate the concepts of this paper, we use a

mobile health application for medication reconciliation that integrates information from multiple electronic

health records. We leverage FHIR extension mechanisms such as profiles and Bundle resources to integrate

the meta resource into the resource contextualization layer of the FHIR standard.

1 INTRODUCTION

Electronic health records (EHRs) have reached a

market saturation nearing 92% (Heath, 2016) but

cross-institutional data-sharing is still challenging for

stakeholders (e.g., medical providers such as

physicians, hospitals, clinics, labs, etc.) and fails to be

fully supported by health information exchange

(HIE). Particularly when clinical providers use

different health information technology (HITs)

systems in geographically separate locations. The

demand for interoperable HIE that allows multiple

HITs (e.g., EHRs, e-prescribing systems, pharmacy

information systems, patient portals, etc.) to interact

with one another for healthcare data sharing between

providers is growing rapidly (De Pietro & Francetic,

2018). Increasingly, this exchange is being facilitated

utilizing Fast Healthcare Interoperability Resources

(FHIR) (FHIR, 2021), an HIE standard introduced in

2014 to promote secure sharing of healthcare

https://orcid.org/0000-0001-8259-1438

https://orcid.org/0000-0003-0654-9910

https://orcid.org/0000-0002-6062-067X

data. The standard has passed through an initial

maturity level and is currently widely endorsed and

accepted by HIE stakeholders, policymakers, and

developers of healthcare application systems. FHIR is

mandated by the Office of National Coordinator for

Health Information (ONC, 2021) for making data

available via APIs to patients and for data sharing.

In support of HIE, we have done prior work

(Ziminski et al., 2015) on different software

architectural alternatives and proposed a hybrid HIE

architecture that leverages paradigms that include

service-oriented architecture, grid computing,

publish/subscribe paradigm, and data warehousing to

allow the HITs of stakeholders to be integrated to ease

collaboration among medical providers. Our follow-

up work (Ziminski et al., 2020) extended that effort

to detail an architectural solution for HIE using FHIR

to integrate HITs to facilitate collaboration among

medical providers. Our focus in this paper is to

explore the interoperability at a coarser granularity

Ziminski, T., Demurjian, S. and Agresta, T.

Extending the Fast Healthcare Interoperability Resources (FHIR) with Meta Resources.

DOI: 10.5220/0010546501670176

In Proceedings of the 16th International Conference on Software Technologies (ICSOFT 2021), pages 167-176

ISBN: 978-989-758-523-4

167

level that considers the way that the architectures in

our prior work use FHIR for HIE more effectively.

The FHIR standard has 135+ resources, which are

data elements to capture all types of healthcare data

organized into different layers. For example, the base

resource layer contains patients, practitioners, and

family relationships, organizations, services,

appointments, and encounters. The clinical resources

are for a patient’s health history, diagnostic data,

medications, care provision, and request/response

communication. Further resources are organized in

the foundation, financial, and specialized layers.

One of the limitations of the FHIR standard is that

it is left up to the discretion of each designer and

developer to individually choose a set of resources

that is used to solve a particular problem. However,

at a design level, there is no way to effectively

organize the subset of FHIR resources required for a

particular problem in any way that would promote

reuse. One of the classic software engineering design

and development approaches is design patterns which

were pioneered in (Gamma, 1995) and came into

widespread use. Design patterns originated in an

investigatory process when software engineers and

developers realized that they were constantly copying

and reimplementing similar code in different projects.

For example, the Observer pattern is utilized to define

a one-to-many relationship between objects. The

Model View Controller pattern has: a model to

capture business rules for accessing and updating

data, a view that renders the contents of the model for

the presentation of the stored data, and the controller

that translates the view into actions such as button

clicks, UI actions, or HTTP calls.

Design patterns can fit into an Enterprise

architecture (Zachman, 2019) as well as with the

architecture of FHIR (FHIR Arch, 2021) as part of an

overall information architecture. In addition to

resources organized in the mentioned layers, FHIR

also includes a Resource Contextualization

component containing FHIR profiles and graphs.

Within this context, this paper will propose a meta

resource, which is a set of resources created using

containment and relationships and which is geared

towards solving specific problems in the design of

healthcare applications. We believe that meta

resources can fit into the FHIR’s resource

contextualization layer, thereby extending its

architecture with additional relationship types,

attributes, and constraints.

The intent is to have an identifiable construct that

can meaningfully relate multiple FHIR resources in

an ordered manner and that allows sharing and

exchange to happen at a higher granularity level akin

to a design pattern. To facilitate this process, we

define the meta resource as a named construct that

associates multiple resources so that they can then be

utilized in multiple contexts.

For this purpose, we leverage the extension

concepts of FHIR profiles along with the grouping

operation of Bundle resources to integrate seamlessly

into the FHIR standard. This provides a design

pattern-like capability that can augment and extend

the existing functionality of FHIR by higher-level

conceptual named constructs that, for particular

workflows, clearly define the involved resources and

their interactions into one unified artifact.

To illustrate the potential of the concepts of this

paper, we will leverage our work on the development

of a mobile health application and framework

(Agresta et al., 2020) for medication reconciliation

that integrates information from multiple EHRs. We

show how the FHIR resources used in our solution

can be better conceptualized into a meta resource,

which also could be effectively utilized and deployed

in different settings for purposes related to medication

reconciliation. For this, we combine the resources

(Patient, Medication, MedicationStatement, Detected

Issues, etc.) into a MedicationReconciliation meta

resource which supports the actions of the

application, including: retrieving medications from

multiple EHRs, personal health records, and other

HITs; combining and reconciling medications into a

best medication list that identifies potential conflicts

between the same or different medications; and,

supporting an adaptive multi-use algorithm for

medication reconciliation.

The remainder of this paper has four sections.

Section 2 provides background information on the

critical FHIR concepts and our medication

reconciliation work which will be used for examples

throughout the paper. Section 3 presents a model that

extends FHIR with meta resources. Section 4

explores the algorithmic process for integrating meta

resources based on FHIR bundles. Section 5 contains

concluding remarks and outlines ongoing work.

2 BACKGROUND

This section provides background material in three

areas. Section 2.1 explores medication reconciliation

and its importance for healthcare. Section 2.2 presents

the concepts of the FHIR relevant for the paper.

Section 2.3 discusses our medication reconciliation

architecture and app.

ICSOFT 2021 - 16th International Conference on Software Technologies

168

2.1 Medication Reconciliation

Since a patient’s medication regimen is the basis for

treatment decisions, medication lists must be accurate

to maximize therapeutic impact and prevent

potentially life-threatening events. Discrepancies

between the medication lists in HITs where patients

receive care can potentially harm patients. This

challenge is significant enough that in Connecticut

(CT), the CT General Assembly passed Special Act

18-6: An Act Requiring the HIT Officer to Establish

a Work Group to Evaluate Issues Concerning

Polypharmacy and Medication Reconciliation

(CTACT, 2018) which produced a number of

recommendations to the legislature which includes

the development of technology to support the ability

to generate the Best Possible Medication History via

an automated electronic means (OHS, 2019).

Medication Reconciliation is defined as: “the

process of comparing a patient’s medication orders to

all of the medications that the patient has been taking.

This reconciliation is done to avoid medication errors

such as omissions, duplications, dosing errors, or

drug interactions.” (JC, 2006) Transitions of care

(hospital to ambulatory care, nursing facility to home)

can be particularly dangerous without an accurate

medication list. Different EHRs at these locations can

lead to medication errors that contribute to this harm.

Medication errors account for over 1M ED visits,

3.5M office visits, and 125k hospital admissions

annually (ADE, 2020). Medication reconciliation can

address these issues by compiling a list of

medications from various EHRs into a single source-

of-truth resource for seamless access by users for

medication management.

In regards to prior work, we highlight a number

of related efforts, the first (Coons, et al., 2019) is the

development of a mobile application for a medication

list leveraging FHIR. The next related effort

(Pandolfe, et al. 2016) provides a framework that

improves accuracy of the medication reconciliation

process focusing on an outpatient medication list

through a centralized architecture. Another study

(Schnipper, et al., 2012) concluded that concordance

between documented and patient-reported medication

regimens and reduction in potentially harmful

medication discrepancies can be improved with a

PHR medication review tool linked to the provider’s

medical record. Finally, (Yang et al., 2018) discussed

the importance of improving standardization of the

process and technology used for Medication

Reconciliation by exposing some of the challenges

and potential harms when a clinician attempts to

discontinue a medication electronically using an

approved HL7 messaging standard called CancelRx

that their system has only partially implemented. It

left medications that should no longer be taken on

different EHR and Pharmacy HIT system lists.

2.2 The FHIR Standard

FHIR is structured around the concept of resources,

which are comprehensive data elements that hold the

information that can be expressed in FHIR. Formally,

a FHIR resource R is defined as an entity with the

properties set P = (Identity, Type, (Data Item*),

Version). The Identity property is used to address a

given resource entity within a FHIR system

consisting of one or more FHIR servers. The type

property specifies one of the resource types that are

provided by the FHIR specification. The data items

property is a set of structured data elements, which

holds the resource's actual data content as specified

by its definition. The identified version property

implements a version counter which tracks changes

that occur to the contents of a resource through its

lifetime. The record version automatically changes

each time the resource changes, allowing a full audit

trail. The business version changes each time the

content in the resource changes. The FHIR standard

defines representation formats in XML, JSON and

Turtle. Figure 1 contains an abbreviated portion of the

patient resource XML schema and Figure 2 for the

Medication resource. Note that for these two

examples and all other examples we have omitted

some of the details as it impacts the single column

display; see (FHIR Res, 2021) for complete versions.

</identifier>

</telecom>

<deceased[x]>

</deceased[x]>

</maritalStatus>

<other>

<!-- 1..1 Reference(

Patient|RelatedPerson) -->

</other>

</link>

</Patient>

Figure 1: Patient XML schema.

Extending the Fast Healthcare Interoperability Resources (FHIR) with Meta Resources

169

</identifier>

</manufacturer>

<item[x]>

<!-- 1..1 CodeableConcept|

Reference(Substance|Medication) -->

</item[x]>

</ingredient>

<batch>

</batch>

</Medication>

Figure 2: Medication XML schema.

The FHIR standard provides an explicit extension

mechanisms called profile to satisfy the need for

adjustments to specific organizational needs. This is

integrated already at the core specification level and

allows to define extensions, constraints, and additional

APIs for FHIR implementations that need to provide

functionality in addition to the built-in capabilities.

2.3 MedRec Architecture and App

Following a hackathon in spring 2019 (OHS, 2019),

we developed an architecture for our MedRec

application, as shown in Figure 3. To establish our test

environment, we set up four separate HITs: one as a

gold standard to have the exact correct medications for

every patient without any duplications or problems

and three HITs with perturbed versions of that gold

standard with missing medications, different

medications, errors in dosage, old medications etc.

This scenario models what happens in practice.

A HAPI FHIR client iterates over a list of other

FHIR sources, parses the response, and merges them

into a single Bundle. Reconciliation is then performed

on the Bundle by making requests to the RxNorm API

(RxNorm, 2021) for similar medications on a per-

medication basis, then attempting to find duplicates

within the Bundle. Duplicates are removed from the

queue for RxNorm requests for efficiency, since they

have already been matched. When a duplicate is

found, a DetectedIssue resource (FHIR, 2021) is

created and added to the bundle. The returned

medication list is intact as returned from the multiple

FHIR sources, and the duplicates must be displayed in

the app through processing the DetectedIssue

resources, so that final authority as to which

medications are duplicates rests with the user.

Figure 3: MedRec Architecture.

To explain medication reconciliation, Figure 4

presents a simplified process: a User selects a patient;

App initiates the reconciliation and triggers the

backend; Backend requests medications for the patient

from both EHRs; MedRec algorithm processes

medication lists and detects issues; App displays

medication list with highlighted issues; User

reconciles conflicts; Reconciled list is returned to the

backend; Backend identifies which sources were

contributing the data causing identified issues;

Affected sources are notified (in this example a

warning is sent to EHR2); and, Sources may issue a

warning to their users.

3 META RESOURCE MODEL

This section introduces a formal model for the meta

resource extension of FHIR. Section 3.1 presents a set

of core definitions for resources from the FHIR

standard used as the foundation for the meta resource

definitions in Section 3.2.

3.1 Core Definitions

The Fast Healthcare Interoperability Resources

(FHIR) standard is built around data elements called

resources and application programming interfaces for

exchanging them. Definitions Defn. 1 to 5 describe

ICSOFT 2021 - 16th International Conference on Software Technologies

170

the core capabilities of FHIR resources from a general

perspective in order to support the rest of the meta

resource model to be presented in Section 3.2.

Figure 4: Medication Reconciliation Process.

Defn. 1. The resource identity (𝑅



) is given by

an URL that allows to identify and address a

resource uniformly.

Defn. 2. Let 𝓡𝓣



 𝑡



,𝑡



,…,𝑡



 be the

list of different resources that are defined in the

resource list of the FHIR specification (FHIR

Res, 2021). Then the resource type is defined as

𝑅



 𝑡



∈ 𝓡𝓣



Defn. 3. The resource data ( 𝑅



) is the

specific collection of data fields that a resource of

type 𝑅



receives in the FHIR specification.

Defn. 4. The resource version (𝑅



) is a

sequence number that increases each time the

resource changes.

Definitions Defn. 1 to 4 support the following two

definitions.

Defn. 5. An FHIR resource is described by the

four-tuple 𝑅 𝑅



,𝑅



,𝑅



,𝑅





Defn. 6. Let 𝓡𝑅



,𝑅



,…𝑅



 be the set of

all FHIR resources.

Example 1 illustrates a Patient (FHIR Res, 2021)

instance according to the schema in Figure 1 using the

model concepts introduced in Defn.1 to 6.

Example 1. An FHIR Patient resource instance

for patient John Doe after five changes is

represented by

𝑅



 𝑅





,𝑡



,𝑅





,𝑥 

where

𝑅





 ℎ𝑡𝑡𝑝://𝑡𝑒𝑠𝑡. 𝑓ℎ𝑖𝑟. 𝑜𝑟𝑔/𝑟𝑒𝑠𝑡/𝑃𝑎𝑡𝑖𝑒𝑛𝑡/123

and

𝑡



𝑃𝑎𝑡𝑖𝑒𝑛𝑡

and

𝑅





 "𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑖𝑒𝑟" ∶ "ea44426f",

"active": "true",

"name": "John Doe",

"telecom": "555-370-8047",

"gender": "male",

"𝑏𝑖𝑟𝑡ℎ𝐷𝑎𝑡𝑒" ∶ "1970  12  12", . . . 

and

𝑥 5

3.2 Meta-Resource Definitions

We are introducing the concept of meta resources to

leverage the design pattern idea and define higher-

level design constructs that can represent multiple

resources needed to implement a particular

application. This transcends the resource-centric view

of FHIR on clinical data. Meta resources provide

reusable workflow-centric patterns that allow a

conceptual view for implementing functionalities in

an already FHIR enabled system. Sample workflows

include medication reconciliation, patient admission,

or vaccination support.

The definition of a specific meta resource

determines the properties, components, relationships,

and requirements that the given meta resource has to

an implementing system. When facing implementing

a particular workflow, a meta resource from a library

of previously implemented solutions can be used as a

pattern for the high-level design of applications and

as a schema against which actual implementations are

checked for full functionality.

In detail, a meta resource is described by a

selection of descriptive properties, a set of resources

Extending the Fast Healthcare Interoperability Resources (FHIR) with Meta Resources

171

organized using composition and relationships, and

API extensions for interaction. The related model is

given in Defn. 7 to Defn. 12. First, to support the

classification and management of meta resources,

they require identifying properties.

Defn 7. The meta resource identifier (𝑀𝑅



) is

a unique identifier for the meta resource.

Defn 8. The meta resource name (𝑀𝑅



) is

a human-readable name for identifying the meta

resource.

The overall objective of a meta resource is the

larger granular organization of resources for a

specific health-related workflow, described via

human-readable description.

Defn 9. The meta resource description

(𝑀𝑅



) is a textual description of the medical

workflow that a meta resource enables.

Combining definitions Defn 7 through Defn 9, we

define a meta resource.

Defn. 10 (v1). A meta resource (intermediate) is

described by the three-tuple 𝑀𝑅  

𝑀𝑅



,𝑀𝑅



,𝑀𝑅



.

Defn 11. Let 𝓜𝓡  𝑀𝑅



,𝑀𝑅



,…,𝑀𝑅



 be

the set of all meta resources.

Example 2 shows an instance of a

MedicationReconciliation meta resource for the

medication reconciliation app in Section 2.1 and

implementing the structure shown in Figure 5, which

gives an overview of the meta resource: the Patient

resource holds demographic information of the

affected patient. It references one or more

MedicationStatement resources. The

MedicationStatement identifies that a patient is or

was taking a medication. It contains a Medication

resource identifying the actual medication. It also

references one Endpoint resource to indicate from

where the statement was retrieved. Finally, it also

references one Practitioner resource that identifies

that individual that should be notified about issues

regarding this statement. A DetectedIssue resource

references two or more medication statements,

indicating a potential problem between those

statements, which must be resolved during

reconciliation. An Endpoint records information on

which system needs to be notified regarding a

discovered issue. It references a practitioner as

designated contact in the scope of this endpoint. An

endpoint represents a health information technology

system such as an electronic health record that could

be at a hospital, a rehab facility, a clinician’s office,

etc., that must be notified whenever a change is made.

A Practitioner resource identifies the practitioner that

needs to be contacted regarding issues detected for a

given medication statement during reconciliation.

Example 2. The MedicationReconciliation meta

resource is represented by

𝑀𝑅



  𝑀𝑅





,MR





,𝑀𝑅







where

𝑀𝑅





 ℎ𝑡𝑡𝑝://𝑡𝑒𝑠𝑡. 𝑓ℎ𝑖𝑟. 𝑜𝑟𝑔/𝑟𝑒𝑠𝑡/𝑚𝑒𝑡𝑎

/𝑀𝑒𝑑𝑖𝑐𝑎𝑡𝑖𝑜𝑛𝑅𝑒𝑐𝑜𝑛𝑐𝑜𝑛𝑐𝑖𝑙𝑖𝑎𝑡𝑖𝑜𝑛/123

and

𝑀𝑅





 𝑀𝑒𝑑𝑖𝑐𝑎𝑡𝑖𝑜𝑛𝑅𝑒𝑐𝑜𝑛𝑐𝑖𝑙𝑖𝑎𝑡𝑖𝑜𝑛

and

𝑀𝑅





 ”Medication reconciliation is the

process of comparing a patient’s medication orders

to all the medications that the patient has been taking

and eliminating potential errors, resulting in a new

up to date list of medications.”

Patient

MedicationStatement

1..*

DetectedIssue

Endpoint

2..*

0..*

Medication

1..*

Practicioner

1..*

Figure 5: Medication Reconciliation Meta Resource.

Each of the resources in a meta resource is

classified according to the service it provides, such as

consumer, producer, data source, or data generator.

For example, in Figure 5, the Medication resource

will serve as data sources for performing the

reconciliation. In contrast, the FHIR

MedicationStatement can serve as a producer of

further medication resources.

Defn 12. Let 𝓡𝓒



𝑐



,𝑐



…,𝑐



 be

the set of all recognized classification categories

for a resource within the scope of a meta resource.

Example 3 shows the definition of a category.

Example 3. The MedicationReconciliation meta

resource utilizes categories 𝓡𝓒





𝑐



,𝑐

,

𝑐



,𝑐



 ⊂

𝓡𝓒



Fundamentally, a meta-resource is a composition

of standard FHIR resources enriched with meta-

information to define the structure and interactions of

ICSOFT 2021 - 16th International Conference on Software Technologies

172

FHIR resources on the design level. A meta-resource

definition contains a specification of FHIR resources

that must be available to instantiate the meta resource,

known as the participating resources.

Defn. 13. The participating resources of a meta

resource are defined as the set 𝑀𝑅





𝑝𝑟

,

𝑝𝑟

,

…𝑝𝑟

,

, where a participating resource

𝑝𝑟



  𝑟



,𝑐



 is a tuple in which 𝑟



identifying either an FHIR standard resource or

recursively a meta resource, therefore 𝑟



∈𝓡 ∪

𝓜𝓡. The category of the participating resource

is given by 𝑐



∈ 𝓡𝓒.

For supporting a meta-resource, the application

being developed needs to provide a matching API:

Defn. 14. The meta resource API extension

(𝑀𝑅



) is defined as an FHIR profile (FHIR Pro,

2021) providing the API extensions needed for

interacting with the meta resource.

Participating resources relate to one another by

reference or composition, leading to:

Defn 15. The meta resource reference structure

is defined as the set 𝑀𝑅





𝑟𝑒𝑓



,𝑟𝑒𝑓



,…𝑟𝑒𝑓



 , where 𝑟𝑒𝑓



 𝑝𝑟



,𝑝𝑟





with 𝑝𝑟



,𝑝𝑟



∈𝑀𝑅



and 𝑖  𝑗 is a tuple of

distinct participating resources and 𝑝𝑟



references

𝑝𝑟



Defn 16. The meta resource composition

structure is defined as the set 𝑀𝑅





𝑐𝑜𝑚



,𝑐𝑜𝑚



,…𝑐𝑜𝑚



 , where 𝑐𝑜𝑚





𝑝𝑟



,𝑝𝑟



 with 𝑝𝑟



,𝑝𝑟



∈𝑀𝑅



and 𝑖  𝑗 is a

tuple of distinct participating resources and 𝑝𝑟



contained in 𝑝𝑟



Definitions Defn. 11 to 16 require a revision of

Defn.10:

Defn. 10 (v2). A meta resource is described by

the seven-tuple

𝑀𝑅   𝑀𝑅



,𝑀𝑅



,𝑀𝑅



𝑀𝑅



,𝑀𝑅



,𝑀𝑅



,𝑀𝑅



Example 4 illustrates the revised Defn.10.

Example 4. An instance of the meta resource

MedicationReconciliation can be represented by

𝑀𝑅



  𝑀𝑅





,𝑀𝑅



,𝑀𝑅





,𝑀𝑅





,𝑀𝑅



𝑀𝑅





,𝑀𝑅







where

𝑀𝑅





 http://test.fhir.org/rest/meta/

MedicationReconciliation/123

and

𝑀𝑅



 𝑀𝑒𝑑𝑖𝑐𝑎𝑡𝑖𝑜𝑛𝑅𝑒𝑐𝑜𝑛𝑐𝑖𝑙𝑖𝑎𝑡𝑖𝑜𝑛

and

𝑀𝑅





  𝑠𝑡𝑟𝑖𝑛𝑔 



𝑠𝑒𝑒 𝐸𝑥𝑎𝑚𝑝𝑙𝑒 2



and

𝑀𝑅



  𝑝𝑟𝑜𝑓𝑖𝑙𝑒 

and

𝑀𝑅





𝑝𝑟



,𝑝𝑟



,

𝑝𝑟



,𝑝𝑟



,

𝑝𝑟



,𝑝𝑟



,

𝑝𝑟



,𝑝𝑟





and

𝑀𝑅





 𝑝𝑟



,𝑝𝑟





4 FROM META RESOURCES TO

FHIR BUNDLES

Figure 6: FHIR Bundle in UML Representation.

This section presents the process and an associated

algorithm that can automatically transition a meta

resource definition into a destination FHIR bundle at

the schema level. FHIR bundles are container

resources built explicitly into the standard to group

other references, for example, in the context of search

results or for the exchange of messages. FHIR

bundles allow both references and containment and

are therefore capable of reflecting the relationships

shown in the meta resource in Figure 5. In Figure 6,

the UML representation of the FHIR Bundle (FHIR

Res, 2021) is shown, where we focus on the Bundle,

Link, and Entry. The corresponding XML schema for

the FHIR bundle is found in Figure 7. As one

transitions from design to the development of the

healthcare application, the FHIR bundle can facilitate

the exchange with another system. This approach

aims to ensure baseline compatibility with systems

that are not aware of meta resources while

simultaneously leveraging existing communication

APIs for interacting with other meta resource enabled

systems.

Extending the Fast Healthcare Interoperability Resources (FHIR) with Meta Resources

173

To illustrate the process, a meta resource as

presented in Defn. 10v2 in Section 3.2 needs to be

transitioned to a suitable FHIR artifact to construct a

representation that is amenable to realization within a

particular healthcare application. Figure 6 has the

UML representation of an FHIR bundle that gives an

overview of its components and interdependencies.

Conceptually, a bundle consists of meta-information

about the bundle itself (such as an identifier), entries

encapsulating FHIR resources, and links between

those entries (and potentially further outside

resources). Additionally, the request, response, and

search components can be used to make the bundle

suitable for workflows such as search queries to a

system. To transition from a meta resource to a

bundle, we utilize only the Bundle, Link, and Entry

components shown in Figure 6.

Figure 7: FHIR Bundle XML Schema.

Our algorithmic process takes the meta resource

as defined in Defn. 10v2 in Section 3.2 and, using the

XML schema of Figure 7, creates a meta resource

bundle that captures all components and

relationships. For the meta resource presented in

Figure 5, this would use all the defined resources in

the figure and the indicated relationships and

components to generate the medication reconciliation

bundle XML as shown in Figure 10. Note that adding

any Search, Request, or Response components of

Figure 6 is left to the responsibility of the developer

of the healthcare application where required.

Figure 8 gives an overview of the processing steps

that our approach takes to generate the bundle.

Specifically, for every medication reconciliation meta

resource, the initial generation is of the top-level

bundle element and a single patient element. Then the

participating resources, as given in Figure 5, are

processed into matching bundle entries. The

comments in the pseudo code relate which parts of the

example in Figure 10 are generated by a given step.

Figure 8: Pseudo-code Algorithm for Bundle Generation

(comments indicate lines generated in Figure 10.)

In summary, Figure 10 contains an excerpt of the

bundle schema (shortened for readability) that was

generated for a MedicationReconciliation meta

resource (see Figure 5) for a patient John Doe. The

resource recorded a drug interaction between two

drugs while reconciling the patient’s medication

statements from an openEHR instance and another

HIE system. Lines 1-4 define the bundle, assign an id

and a collection type, which defines a simple

collection without further constraints. Lines 5-8

contain an entry for the participating Patient resource.

Note that for every entry, a fullUrl property defines

the referenceable identity for the serialized resource

of the entry. We use this URL to reference

participating resources within the bundle itself.

Entries for the participating Practitioner (lines 9-

13) and Endpoint resources (lines 14-18) provide the

location and the person necessary for issuing an alert

about the drug interaction. Lines 19-32 contain the

participating MedicationStatement resource for a

medication which the patient is taking. The structural

references to the related Patient, Practitioner, and

Endpoint resources (as introduced in Figure 5) are

explicitly serialized to the link elements in lines 21-

23. While links handle the references introduced by

the meta resource concept, aggregations are serialized

to FHIR built-ins, i.e., the contained element of

MedicationStatement, as shown in line 27. Note that a

reference is always serialized to a link for consistency

within the meta resource model representation. This is

the case even if a potential built-in exists (e.g., the

Patient resource in the subject entry in line 29).

ICSOFT 2021 - 16th International Conference on Software Technologies

174

Further medication resources are omitted in this

example (lines 33-34). The drug interaction risk is

recorded in lines 35-46, where a participating

DetectedIssue resource flags two medication

statements. References from the meta resource are

expressed as links for a possible meta resource

deserialization (lines 37-38). Additionally, the built-in

FHIR relation in the implicated elements (lines 42-43)

is preserved for usage as regular FHIR resources.

Figure 9: Meta Resource Serialization to Bundle.

The generic high-level concept of our

transformation approach and its related information

flow between systems is illustrated in Figure 9. The

EHR at the top of the figure uses the previously

introduced medication reconciliation meta resource

for enabling a reconciliation workflow. However, the

information encapsulated within the meta resource’s

participating resources can be read by different

involved HITs. For this, the meta resources are

serialized to an FHIR bundle by iterating over the

meta resource’s participating resource and adding

them to the generated bundle one by one. The

resulting bundle conforms to the FHIR standard and

reflects the contents of the meta resource in a flat

structure (depicted in the middle of Figure 9). In the

serialization

process,

the

relationships

introduced

Figure 10: Generated Bundle.

the bundle by the meta resource are preserved in three

cases: by using FHIR built-ins (for cases such as the

relationship between a MedicationStatement and a

Medication resource); by setting appropriate link

elements in the bundle; or by adding them to

extensions via the StructureDefinition mechanism

(for cases such as the relation between a Practitioner

and an Endpoint resource). The first case can be

understood by systems without meta resource

knowledge, while the two later cases must support the

meta resource extension themselves for deserializing.

Other healthcare applications can use the

generated bundles by processing the participating

resources as direct information or reconstructing the

bundle’s meta resource. This operation is depicted at

the bottom of Figure 9, where an e-Prescribing system

extracts just the Patient and Medication resources

from the bundle while a PHR system processes only

on the Patient and MedicationStatement resources.

5 CONCLUSION AND ONGOING

WORK

This paper has presented the extension of the FHIR

standard with the concept of a meta resource which

allows for a design pattern level capability to support

reusable components that can be automatically

generated and easily exchanged among healthcare

applications that need to share the similar kind of

data. The meta resource extension can be

incorporated into the information architecture of

FHIR in the resource contextualization layer as

Extending the Fast Healthcare Interoperability Resources (FHIR) with Meta Resources

175

discussed in the introduction. To present our work,

we reviewed background on FHIR and the medication

reconciliation application that we use for examples in

Section 2. Next we presented a formal model to

represent meta resources in Section 3, which in turn

was used as the basis to present an algorithm and

associated process that automatically translates a

meta resource to a FHIR XML bundle schema in

Section 4. The generated bundle schema can be used

as a basis for the developer to create an instance of

the schema as the healthcare application is

transitioned from a design level to an implementation.

The resulting healthcare application would have

the bundled component that would be more easily

exchanged and transferred among different HITs. Our

work could improve healthcare interoperability by

having meta resources for recurrent parts of clinical

workflow such as for medication reconciliation.

Ongoing work is focusing on several different

areas. We intend to work with the team of the

medication reconciliation application to assist in

reformulating their usage of resources into the

medication reconciliation bundle as given in Section

4. This will allow us to fully understand the way to

transition from the bundle schema to the actual

exchangeable bundle instance. Another area is to

formally define the appropriate notation so that the

meta resource can fully fit into the defined FHIR

standard by using only predefined FHIR conventions.

REFERENCES

ADE, 2020. Office of Disease Prevention and Health

Promotion, “Adverse Drug Events,” February 2020.

https://health.gov/our-work/health-care-quality/adver

se-drug-events.

Agresta, T., Demurjian, S., Sanzi, E., DeStefano, J., Ward-

Charlerie, S., Rusnak, R., Tran, R., 2020. A Mobile

Health Application for Medication Reconciliation

Using RxNorm and FHIR. Proc. of the Fifth Intl. Conf.

on Informatics and Assistive Technologies for Health-

Care, Medical Support and Wellbeing, HEALTHINFO.

Coons, J. C., Patel, R., Coley, K. C., & Empey, P. E. (2019).

Design and testing of Medivate, a mobile app to achieve

medication list portability via Fast Healthcare

Interoperability Resources. Journal of the American

Pharmacists Association

CTACT, 2018. CT State Legislature, "Connecticut

SB00217 | 2018 | General Assembly," LegiScan,.

https://legiscan.com/CT/bill/SB00217/2018

De Pietro C, Francetic, I., 2018. E-health in Switzerland:

The laborious adoption of the federal law on electronic

health records (EHR) and health information exchange

(HIE) networks. Health Policy, 122(2), 69-74.

FHIR, 2021. HL7 International, “FHIR Overview,”

https://www.hl7.org/fhir/overview.html.

FHIR Arch, 2021. HL7 International, “FHIR Architecture,”

https://www.hl7.org/fhir/overview-arch.html

FHIR Pro, 2021. HL7 International, “FHIR Profiling,”

https://www.hl7.org/fhir/profiling.html

FHIR Res, 2021. HL7 International, “FHIR Resource List,”

https://www.hl7.org/fhir/resourcelist.html

Gamma, E., 1995, Design patterns: elements of reusable

object-oriented software Addison-Wesley.

Heath, S., 2016. Outpatient EHR Adoption Reaches 92%,

Nears Market Saturation. EHR Intelligence.

https://ehrintelligence.com/news/outpatient-ehr-

adoption-reaches-92-nears-market-saturation

JC, 2006. Medication reconciliation sentinel event alert.

The Joint Commission. https://www.jointcommission.

org/resources/patient-safety-topics/sentinel-event/senti

nel-event-alert-newsletters/sentinel-event-alert-issue-3

5-using-medication-reconciliation-to-prevent-errors/

OHS, 2019. OHS Connecticut, “Work Group – Final

Report,” Please see pages 25-76 of https://portal.ct.gov/-

/media/OHS/Health-IT-Advisory-Council/MRP/MRP_

WG_FINAL_Recommendations.pdf

ONC, 2O21. Office of the National Coordinator for Health

Information Technology, “ONC's Cures Act Final

Rule,". https://www.healthit.gov/curesrule/

Pandolfe, F., Crotty, B. H., & Safran, C. (2016). Medication

Harmony: A Framework to Save Time, Improve

Accuracy and Increase Patient Activation. AMIA

Annual Symposium Proceedings.

RxNorm, 2021. National Library of Medicine, “RxNorm,”

https://www.nlm.nih.gov/research/umls/rxnorm/

Schnipper, J., et al. 2012. “Effects of an online personal

health record on medication accuracy and safety: a

cluster-randomized trial. Journal of the American

Medical Informatics Association, 19, 728-734.

Yang, U., et al. 2018. Analysis of Medication Therapy

Discontinuation Orders in New Electronic Prescriptions

and Opportunities for Implementing CancelRx. Journal

of the American Medical Informatics Association, 25,

1516-1523.

Smart, 2021. Smart on FHIR. https://smarthealthit.org/

Zachman, 2021. Enterprise architecture.

https://www.zachman.com/resources/zblog/item/enter

prise-architecture-defined-architecture-abstractions

Ziminski, T., Demurjian, S. A., Sanzi, E., Agresta, T.,

(2015). “Toward Integrating Healthcare Data and

Systems: A Study of Architectural Alternatives.

Chapter 16 in Maximizing Healthcare Delivery and

Management through Technology Integration, Iyamu,

T., Tatnall, D. eds.), pp 270-304.

Ziminski, T. B., Demurjian, S. A., Sanzi, E., Baihan, M.,

Agresta, T., 2020. Chapter 14: An Architectural

Solution for Health Information Exchange. Virtual and

Mobile Healthcare: Breakthroughs in Research and

Practice, Information Resources Management

Association, pp. 283-327, IGI.

ICSOFT 2021 - 16th International Conference on Software Technologies

176