=Paper=
{{Paper
|id=Vol-2408/paper2
|storemode=property
|title=Leveraging Blockchain to Improve Clinical Decision Support Systems
|pdfUrl=https://ceur-ws.org/Vol-2408/paper2.pdf
|volume=Vol-2408
|authors=Vidya Soundararajan,Bonnie McDaniel,Jiyo Shin,Sweta Sneha,Vijayaraghavan Soundararajan
|dblpUrl=https://dblp.org/rec/conf/eewc/SoundararajanMS19
}}
==Leveraging Blockchain to Improve Clinical Decision Support Systems==
https://ceur-ws.org/Vol-2408/paper2.pdf
Leveraging Blockchain to Improve Clinical Decision
Support Systems
Vidya Soundararajan MD, FACOG, MSHMI 1 Bonnie McDaniel 1 Jiyo Shin MD,
FAAFP, MSHMI 1 Sweta Sneha, PhD 2 Vijayaraghavan Soundararajan, PhD 3
1 WellStar Health System, Marietta. GA 30062
2 Kennesaw State University, Kennesaw, GA 30144
3 Vmware, Palo Alto, CA 94304
Soundararajan917@gmail.com
Abstract: Clinical decision support systems (CDSS) fail to reduce medical errors
because they are unable to interact actively with various sections of the electronic
health records (EHR) and provide context-appropriate alerts. The shortcomings
of the CDSS increase the cognitive burden to clinicians, worsen alert fatigue, and
increases the duplication of tests and health care costs without improving patient
outcomes. An architectural framework that leverages together CDSS with a
blockchain platform and smart contracts can provide a convenient abstraction
that has the potential to solve this problem. We performed a literature search
using the keywords CDSS, EHRs, blockchain technology. We manually and
electronically looked at papers that were published from 2000-2018. We used
CDSS, blockchain, EHR as keywords using the PubMed and Medline databases.
The search returned 2338 articles which we narrowed down to 73 manuscripts
that were relevant to our research identifying the gaps in the current EHR and
CDSS environment. This paper identifies the shortcomings of the current CDSS
and propose an architectural framework of a CDSS that utilize blockchain
technology with smart contracts that interacts well with clinical workflow,
reduces the cognitive burden to the clinician, eliminates irrelevant alerts,
duplicate tests, and improves patient outcomes. The proposed architectural
framework is designed with the goal of provisioning holistic information at the
point of care thereby empowering the physicians with an integrated CDSS which
holds the potential to reduce physician burnout, reduce healthcare costs, and
improve patient outcomes. We use the STARR format for this research study.
Keywords: Clinical decision support system (CDSS), Electronic health records
(EHR), Architectural, Framework, Blockchain.
1 Introduction
Clinical decision support systems (CDSS) are defined as knowledge systems integrated
with EHRs that use two or more items of patient data in conjunction with evidence
2
based clinical guidelines to generate case-specific advice[1]. CDSS also alert providers
to potential problems such as medication interactions and can provide streamlined
follow up instructions for patient care. The goal of a CDSS is to deliver the right
information to the care team in a timely manner through a channel that conforms with
clinical workflows and in a format that assists the provider with reaching the proper
diagnosis.[2] In their current state, clinical decision support systems exist in a closed
loop system and rely on historical events rather than evidence-based data[3]. The output
from these systems follow an IF-THEN framework for triggering alerts and in creating
the diagnostic report for the provider. The programs perform their function in an
ordered, systemic manner of collecting inputs, analyzing the data and creating outputs
[4].
The current design of clinical decision support systems has fallen short of the
intended goals of improved medical outcomes due to a lack of efficacy [5]. Although
integrated with the EHR, CDSS systems are not patient or context specific which leads
to the increased firing of irrelevant and inappropriate alerts [6]. The CDSS can only use
the structured patient data that is siloed in the individual providers’ EHR that may not
interact with other EHRs. The patient medical record is incomplete; therefore, the
CDSS cannot take advantage of large data sets to provide physicians with the
probability of an adverse condition or medication reaction [7]. Providers
independently must search various areas of a patient chart to obtain the information
they need and to assimilate the information: a time-consuming task. Current CDSS
inundate the physician with big data without context specific filters. Physicians must
expend cognitive energy to review and decipher unnecessary information which leads
to an increase in cognitive burden [5]. This overload leads to inefficiencies and gaps
in clinical workflows and increases the rate of provider burnout [8]. An interface
between a CDSS and a patient medical record that includes a patient-specific and
diagnosis-specific history would allow the CDSS to provide appropriate diagnostic
recommendations that are specific to the patient’s medical history [9]. Furthermore,
the transaction of information is instantaneous and provides real time guidance for the
clinician in a nonobtrusive fashion. This real time, instantaneous information that is
context relevant and patient specific, allows the physician to evaluate a patient, and
make appropriate decisions in a quick and efficient manner [10].
For example, a provider prescribes a blood pressure medication for a 90-year-old
woman with diabetes and a serum creatinine level of .8 and the CDSS generates an alert
stating the medication is contraindicated during pregnancy. Clearly the individual is
not pregnant; thus, the alert is irrelevant and considered a nuisance by the physician and
is ignored. However, along with an alert regarding pregnancy, there may be an alert
that emerges that suggests that the medication is contraindicated in a patient with renal
disease. This alert may be relevant and critical, however, because a nuisance alert had
popped up at the same time, both alerts may be ignored, and patient harm can occur
[11]. Some CDSS software allow adjustments to reduce some of the nuisance alerts;
however, the fundamental problem is the alert is triggered by the medication. The
CDSS scans its information on the medication and lists the various interactions (which
are not context based) for the medication alerts [12]. This routine leads to alert fatigue
which leads to clinical error. Ideally, the clinical decision support system should be
3
able to extract not only the name of the medication prescribed, but relevant information
about the patient (labs, gender, age and medical problems/surgeries) and refine the
number of alerts generated [13]. In the example stated, the CDSS should be able to
extract the patient age, 90, her medical problems (hypertension and diabetes), important
labs (creatinine .8), to use this clinical context to scan its database of interactions and
conclude that no alerts should be triggered. A context-based CDSS reduces alert fatigue
and also reduces the cognitive burden to the physician by only producing appropriate
alerts.
Currently, EHRs are not designed to store the patient information and allow the
CDSS to utilize it actively and simultaneously. Rather, both systems function in a
dyssynchronous fashion and create delays in patient care [14]. Additionally, because
of the lack of interoperability, the partial patient information is siloed in a provider’s
EHR and the provider cannot access critical information from other hospital systems.
This lack of interoperability leads to the duplication of tests and efforts and places
additional cognitive burden on the physicians to assimilate information from various
sources [10].
Various departments (pharmacies, nurses, providers) and clinical settings utilize the
CDSS simultaneously; it is imperative that the source of the clinical information from
which the CDSS pulls its information is immutable, portable, and irreversible in order
to provide clinical consistency and prevent errors [16]. However, for the CDSS to
function in this manner, it needs to be interoperable with multiple EHR systems,
laboratory systems and pharmacy systems. When the CDSS is embedded separately in
each of these entities, multiple interfaces are needed to be maintained or the CDSS can
malfunction [15,16].
Therefore, if a platform existed that could store the patient’s clinical information as
a base layer coupled with an interface between this base layer and a nonintegrated
clinical decision support software system, EHRs and outside sources would only need
one interface to the CDSS.
Blockchain technology together with smart contracts hold the promise of providing
a secure platform where once validated, irreversible patient data can be shared and
aggregated amongst providers [17]. Blockchain allows for secure and scalable data
sharing to enhance clinical decision making [18].
A CDSS linked to a medical record blockchain could alleviate cognitive burden for
the physicians by utilizing patient specific information, prevent the duplication of
diagnostic studies, and eliminate inappropriate alerts. By alleviating these problems,
we would reduce patient errors and consequently improve patient outcomes. If the
complete patient record were stored on a blockchain and an interface existed between
the blockchain and the CDSS, the CDSS could use the data in its algorithms. The
algorithm results would be sent real-time to the provider via an interface between the
CDSS and the EHR. Any alerts or suggestions triggered by this workflow would be
context-driven and clinically accurate.
The research question that we address is: How can relevant holistic patient
information be made available to the healthcare providers at the point of care with the
goal to enable well informed clinical decision making thereby improving patient
outcomes and reducing inefficiencies in healthcare delivery and practice. Our research
4
objective is to provide an architectural framework of a CDSS that interacts with EHRs
by leveraging a blockchain platform where patient data is stored as connected blocks.
The proposed CDSS has the potential to provide an integrated holistic view of all
patient information at the point of care thereby enabling the provider team to make well
informed clinical decision in a patient centered environment while addressing current
issues of inefficiency and interoperability. We utilize the STARR format in our research
as described below:
Situation: Clinical decision support systems (CDSS) fail to reduce medical errors
because they have been passively embedded into Electronic Health Records (EHRs).
Furthermore, each entity that interacts with EHRs (pharmacies, labs, radiology) have
their own embedded CDSS. Each CDSS utilizes the siloed information to trigger alerts.
This passive incorporation leads to the massive triggering of inappropriate alerts that
increase the cognitive burden to clinicians and leads to provider burnout, alert fatigue,
duplication of tests, and rising health care costs without improving patient outcomes.
Task: To keep the CDSS independent of the EHRs and to create a digital platform that
can contain a complete set of patient records with which the EHRs and the CDSS can
interact. With access to the complete patient records, the CDSS can create context-
driven appropriate alerts and that actively assist health care providers with timely
clinical decisions. More appropriate alerts that are context-driven can reduce alert
fatigue, reduce provider burnout, reduce health care costs and improve patient
outcomes. Blockchain technology provides a potential solution as a digital platform
that contains a complete set of patient records.
Approach: We design an architectural framework that leverages blockchain
technology to improve existing Clinical Decision Support Systems (CDSS).
Result: We design an architectural framework that leverages blockchain with CDSS to
produces context-driven alerts which results in fewer inappropriate alerts, reduces
physician burnout, reduces duplicate test ordering, decreases health care costs and
improves health care outcomes. The design is not yet implemented at a healthcare
facility. We provide details of a case scenario to test the validity of the proposed
architecture.
Reflection: In this paper, we provide an architectural framework that leverages
blockchain technology with CDSS. Future research will focus on implementation and
validation of the proof of concept. The current limitations of the architectural
framework include but are not limited to the following: the scalability of the CDSS;
the security of the patient data once it is in the blockchain format; the last mile issues
of converting the off chain patient data to on chain structured patient data.
2 Background CDSS, Blockchain and MedRec
A CDSS links patient data with a knowledge base to generate information and
suggestions that help providers improve the health care they deliver [3]. At a high level,
blockchain technology is a platform for directly and securely sharing audited,
permanent data based on permissions granted by the owner of the data [17].
5
2.1 CDSS
Clinical decision support systems (CDSS) are defined as knowledge systems integrated
with EHRs that use two or more items of patient data in conjunction with evidence
based clinical guidelines to generate case-specific advice [1]. According to Berner et
al., CDSS software incorporates the generic steps in input, processing and output: (i.)
The patient-specific data is entered by health professionals involved in the care, (ii.)
processed and linked to knowledge stored in a database, and (iii.) notifications are
communicated back to clinicians [19]. According to this concept, if the patient
knowledge is stored in the same database, the CDSS can be effective in reducing
clinical errors. However, when patient knowledge database is heterogenous and siloed
in various databases, the CDSS becomes ineffective in reducing clinical errors and
increases the cognitive burden for clinicians and increases the number of inappropriate
alerts and does not reduce the duplications of tests [15]. Huang et al describe a CDSS
based on heterogenous data sources that can assist inexperienced physicians with the
diagnoses of complex illnesses [20]; however, without the interoperability of databases,
it is difficult to create a common consistent patient knowledge base from which a CDSS
can receive its input and provide accurate clinical outputs [21]. Goldberg et al describe
an enterprise clinical rules service that utilize a single, logical service that can replace
innumerable discrete decision support modules that uses API to connect to the EHRs
[22]. The system utilizes numerous patient databases with a single CDSS. One of the
limitations of the ECRS is the caching of patient data is not available beyond the
boundary of a single decision support transaction [21]. The diagram and summary table
below show the current state of information flows in an EHR based clinical decision
support system When all of the patient data is in a single database or a single
prevention is evaluated, this model works well [15].
Fig. 1. An illustration of the current state of data flow in a clinical decision support system.
6
Figure 1 is an illustration of the current state of data flow in a clinical decision
support system. The inference engine, which is embedded in the EHR utilizes
structured patient data entered by the provider with evidenced based guidelines and
triggers alerts when key words are identified. The CDSS is passive, can only act upon
a single decision support transaction, and does not actively interact with the patient data
source. Ideally, the alerts are context based. However, the inference engine is limited
by the data entered by the provider and cannot abstract patient information from sources
outside the EHR unless an interface exists with the outside source. Figure 1 shows the
current workflow of a CDSS. The data inputs interface into the CDSS in a unilateral
direction. The unidirectional flow of data creates a passive rather than active CDSS
[17].
Table 1. Current state of CDSS.
Properties Purpose Problem
Software Embedded CDSS is integrated CDSS assessment guidelines provide generic
in HER with EHR system to and unnecessary information that inundates
assist with decision providers with too much unfiltered data and
making increases physician burnout.
Dataset siloed in EHR Provides triggers for •CDS can only recognize structured data
CDS entered by providers and cannot assimilate
unstructured data from outside sources. This
leads to incomplete patient records which limits
the efficacy of the CDS. Providers need to
manually assimilate the information. The
process disrupts the provider workflow and
increases cognitive burden for the provider.
•Critical time is wasted with manual transfer of
records.
•Patient is required to sign multiple forms to
authorize the release of records.
•Lack of access to outside records leads to
duplicate testing and inefficient utilization of
resources.
Alerts Warns providers of Alerts not context based. Alerts tend to be
possible interactions intrusive. Noncritical alerts fire frequently and
create alert fatigue.
Passive Cannot pull relevant information from EHR.
Results in duplicate testing.
CDSS software is embedded in the EHR systems and uses the passive steps of
input, processing and output to provide alerts and recommendations. It uses the patient
data knowledge source stored in a structured format to generate alerts when triggered.
Since the data source is restricted to the database in the EHR, the CDSS’s ability to
provide appropriate recommendations is limited (please see table 1).
7
Current clinical decision support systems are vendor specific. The inputs are
controlled by the vendor and the patient data is local to the specific provider’s EHR
[23]. It cannot interface with labs, pharmacies or data obtained from other medical
providers who utilize a different EHR. The inference engine which utilizes the medical
knowledge and the patient data for recommendations is limited by the inputs it receives
[15]. It is also programmed to fire specific alerts based on criteria programmed in the
EHR [19]. Therefore, alerts are not context aware and may not be clinically relevant.
While the end result is case-specific, the report is not complete. Figure 1 shows the
current workflow of a CDSS. The data flows in one direction from the information
sources into the CDSS. The unidirectional flow of data creates a passive rather than
active CDSS [17].
Ekblaw introduces a novel concept of a single patient database that is portable in the
form of the blockchain platform [24]. There is now the potential to combine a portable
complete patient data knowledge source with an interactive CDSS and produce
numerous decision support transactions.
2.2 Blockchain and Medrec
In a blockchain network the chain of transactions is decentralized and shared amongst
all members based on their granted level of permission. Transactions submitted to the
chain must be validated as authentic by a consensus of experts who are compensated
for validation [25]. Once consensus is reached, the new transaction in the chain is
linked to previous transactions by a cryptographic hashtag and cannot be reversed
except through a new transaction [26]. Information added is available immediately and
becomes a single source of truth for the information being recorded [26]. Permissions
to and use of data are executed through code stored on the blockchain platform knows
as smart contracts [16].
Briefly, smart contracts can be thought of as code that is executed in response to
accesses to the blockchain. It is called a smart contract because the action can be
automated and it can access data on the blockchain and can therefore enforce the terms
of the contract in an automated way [31,32].
For example, suppose a piece of data is stored on the permissioned blockchain. If the
physician tries to access the blockchain via an app, the smart contract looks at the access and the
physician access rights and determines if the physician is capable to access code. The smart
contract either allows access or denies access as a result. The same process can be held for the
CDSS and other third parties participating in the patient care.
8
Fig. 2. MedRec system architecture 30
Figure 2 describes the MedRec architecture. MedRec is a decentralized medical record
management system designed using blockchain technology [26]. MedRec uses smart
contracts built on an Ethereum blockchain and a backend API library to manage the
EHR interface. The APIs illustrated above in MedRec is manage access and
permissions to data recorded on the blockchain [3]. The physician registers with the
MedRec App. When a provider needs access to a patient’s records, they request access
to the records. The Gatekeeper runs a server listening to query requests from clients.
The request is cryptographically signed by the patient and allows the gatekeeper to
confirm if the provider is allowed access to the query.
9
It is this interface that allows for the interoperability of diverse EHR systems and
which would provide the data for the CDSS in a standardized format across systems.
MedRec does not store the records on the blockchain, but instead points to where the
record is located at the various points of service, also known as nodes [24,30]. These
nodes agree to run the smart contracts as requested by the MedRec blockchain. With
patient permission, the physician can access medical information across all records
linked to the MedRec ledger. By utilizing an API and storing the data off chain,
MedRec can simultaneously address the interoperability issue of EHRs and the
scalability issue of blockchain technology [18,26,29].
The MedRec blockchain has built in capabilities for a public blockchain. The
validation necessary to make the records immutable is a consortium of miners with
medical backgrounds who receive incentives for agreeing that the records to be added
to the blockchain are authentic [27]. On a MedRec blockchain network, the miners are
incentivized by gaining access to anonymized healthcare data. This same anonymized
data that is granted to the miners could also be accessed by the CDSS through additional
code in the smart contract [30].
These features provide an ideal vehicle to provide accurate information that a
clinical decision support system can use to assist providers and improve the delivery of
health care [30].
3 Methods
A review of the literature on clinical decision support systems in Medline and Pub Med
was performed utilizing the search terms “clinical decision support”, “alert fatigue”,
“EHR and clinical decision support”, “physician burnout”, and “interoperability”. The
purpose of these search terms was to get a consensus on current issues in clinical
decision support and why these issues occur. The searched revealed over 2,338
articles. We refined the search to “EHR and physician burnout” which isolated 16
articles. We discovered that many of the burnout issues were related to functionality
and disrupted workflows programmed into the EHR. A literature review was also
performed on “blockchain technology and healthcare” which produced 57 articles. The
initial search was for terms related to blockchain in order to obtain an understanding of
the functionality and current developments. We used the search terms, “blockchain”,
“ethereum”, “smart contract”, and “Hyperledger” “blockchain miners”, and “nodes”.
After gaining an understanding of blockchain technology we focused our search on
blockchain opportunities in healthcare.
4 Architectural Framework
We combined the concepts of a MedRec blockchain, which is a portable and complete
patient record, with an independent, non-integrated clinical decision support system.
The purpose is to provide clinically consistent output along with context specific
alerts that fire appropriately. The goal of this combination is to reduce cognitive
burden to physicians, provide clinical consistency with the independent CDSS
10
thereby reducing duplicity in tests, healthcare costs and improving patient outcomes.
The architectural framework is illustrated in figure 3 and the high level conceptual
workflow is provided below:
1. The Medrec blockchain is accessed through the APIs built into the MedRec platform.
2. Data needed for the current clinical diagnosis follows the code built into the smart
contract that retrieves the data stored “off chain” in the databases of the providers
who have treated the patient.
3. The CDSS is able to assess actively this data by using the CDSS knowledgebase,
algorithms and data mining techniques and to create context-based and patient
specific alerts, diagnostic tests, and clinical recommendations.
4. The diagnosis, orders and tests from this encounter are then routed back to the
provider database where they will feed back into the blockchain.
Fig. 3. An illustration of the architecture of our proposed blockchain solution to improve the
CDSS.
11
Table 2. –Proposed Changes to CDSS
Properties Purpose Advantages
CDSS software is separate CDSS interacts with a CDSS able to retrieve
from the EHR. The CDSS consistent source of patient relevant patient information
interfaces with the specific information. to reduce duplicate tests.
blockchain platform
Patient medical record is Immutable portable source •Patient records are portable.
accessible via a blockchain of patient records that is Reduced time wasted trying
interface. independent of the EHR to collate patient records.
system used. •Patient authorization is
stored electronically.
Alerts context based CDSS retrieves relevant •Alerts are context based.
information from the •Fewer alerts fired.
medical records and fires •Reduces alert fatigue.
alerts.
CDSS actively interacts with CDSS retrieves relevant •Improved clinical care
the EHR information from the entered through the development of
information to assist algorithms in a neural
provider with decision network that can assimilate
making. data within seconds.
•improved clinical
workflow.
•Reduces medical errors.
•Facilitates precision
medicine.
Figure 3 provides an illustration of the architecture of our proposed blockchain
solution to improve the CDSS. Rather than the single transaction of input, process,
output, the CDSS/blockchain framework will allow for multiple transactions operate
on a continuous loop system that follows the steps of input, process, output, input to
blockchain and store in the patient database. Information flows in a bidirectional
fashion from the clinician and the patient datasource to the CDSS. This framework
allows for an actively interactive CDSS that can then create context specific alerts and
clinical recommendations.
4.1 Scenario for conceptual Validation of the Proposed Framework
With the proposed architectural framework, a clinical encounter would proceed as
follows. A 90-year-old women with a medical history significant for hypertension and
diabetes, who has been on numerous medications in the past, and a serum creatinine of
2.0 presents to the primary care provider for blood pressure management. The patient
signs a consent which allows the provider to engage in the permissioned blockchain
that stores her records. The physician orders an ace inhibitor for the patient. The CDSS
would receive the input from the clinician and scan the blockchain datasource,
recognize that the patient is 90 (not of reproductive age), identify the medical problems
of diabetes and hypertension, review previous prescriptions for the patient, and
recognize the serum creatinine of 2.0. A context specific alert would arise regarding
12
the elevated creatinine and a potential contraindication for this medication with possible
alternative medications. After the clinician acknowledges the alert, the information
will be validated and added to the blockchain. In this situation the alert is context
specific and the CDSS actively interacts with the patient knowledge source to assist the
physician.
5 Barriers and conclusion
5.1 Barriers
There are potential barriers to creating this architectural framework: the scalability of
the CDSS, the security of the patient data once it is in blockchain format, the last mile
issues of conversion of off chain patient data to on chain structured patient data.
The MedRec blockchain points to the data in the provider EHR rather than
trying to store the data in the blockchain. By pointing to the location, the speed of
CDSS transactions increases and allows for scalability [28,29]. The blockchain would
have to have permissioned access via the API’s [26]. The potential vulnerabilities in
the API’s need to be tested and validated. The last mile issues of the conversion of
unstructured patient data in various media formats into structured data would require
further development of natural language processing (NLP). With each of these barriers
comes the potential for the advancement of complimentary technological advances.
5.2 Conclusion
The current state of CDSS is ineffective as it produces irrelevant alerts that are not
context based and consequently increase the cognitive burden to physicians while
increasing health care costs and not improving patient outcomes. We suggest an
architectural framework that leverages blockchain technology with a CDSS that is not
embedded in the EHRs. This framework provides a CDSS that actively interacts with
EHRs and a complete patient knowledge database and is able to produce context
relevant, patient specific alerts. This architectural framework reduces the cognitive
burden to the clinician, provides context relevant alerts and eliminates the duplication
of tests. These attributes can reduce physician burnout, reduce healthcare costs and
improve patient outcomes.
13
Competing Interests
The authors certify that they have no affiliations with or involvement in any
organization or entity with any financial interest, or nonfinancial interest in the subject
matter or materials discussed in this manuscript.
References
1. Buchman, B.: Precision Diagnosis: a view of the clinical decision support systems
(CDSS)landscape through the lens of critical care. Journal Of Clinical Monitoring And
Computing 31(2), 261–271 (2017).
2. Khairat S.: Reasons For Physicians Not Adopting Clinical Decision Support Systems:
Critical Analysis. JMIR Med Inform, 6(2), (2018).
3. Sim I.: Clinical decision support systems for the practice of evidence-based medicine.
Journal of the American Medical Informatics Association: JAMIA8(6),527–34, (2001).
4. Sittig D.: Grand challenges in Clinical Decision Support. Journal of Biomedical Informatics,
41(2),387-392, (2008).
5. Miller K.: Interface, information interaction: a narrative review of design and functional
requirements for clinical decision support. JAMIA, 25(5), 585-592, (2018).
6. Ancker J.: Effects of workload, work complexity, and repeated alerts on alert fatigue in a
clinical decision support system. BMC Medical Informatics And Decision Making, 17(1),
36, (2017).
7. Shortliffe E.:Clinical Decision Support in the Era of Artificial
Intelligence. JAMA. Published online November 05, 2018.
8. Procop, G.: Duplicate Laboratory Test Reduction Using a Clinical Decision Support Tool.
American Journal Of Clinical Pathology, 141 (5), 718–23, (2014).
9. Engelhardt M.: Hitching healthcare to the chain: An introduction to blockchain technology
in the healthcare sector. Technology Innovation Management Review, 7(10),22-34, (2017).
10. Kamel B.: Geospatial blockchain: promises, challenges, and scenarios in health and
healthcare. International Journal Of Health Geographics. 17(1),25, (2018).
11. Phansalkar, S.: Drug—drug interactions that should be non-interruptive in order to reduce
alert fatigue in electronic health records. Journal of the American Medical Informatics
Association,20(3), 489-493, (2012).
12. Phansalkar S.: Criteria for assessing high-priority drug-drug interactions for clinical decision
support in electronic health records. BMC Medical Informatics and Decision Making,13(1),
(2013).
13. Duke J.: A Successful model and visual design for creating context-aware drug-drug
interaction alerts. AMIA Annual Symposium Proceedings Archive, 2011:339–348, 2011.
www.ncbi-nlm-nih-gov/pubmed/22195086 (accessed 4 Oct 2018).
14. Zikos D.: CDSS-RM: a Clinical Decision Support System Reference Model. BMC Medical
Research Methodology, 18(1),2018.
15. Kawamoto K.: A. Key principles for a national clinical decision support knowledge sharing
framework: Synthesis of insights from leading subject matter experts. Journal of the
American Medical Informatics Association, 20(1), 199-207, (2011).
16. Kassakian S.: Clinical decisions support malfunctions in a commercial electronic health
record. Applied Clinical Informatics, 8(3), 910–923, (2017).
14
17. Gordon W.: Blockchain Technology for Healthcare: Facilitating the Transition to Patient-
Driven Interoperability. Computational and Structural Biotechnology Journal, 16(6), 224-
230, (2018).
18. Zhang P.: FHIRChain: Applying Blockchain to Securely and Scalably Share Clinical Data.
Computational and Structural Biotechnology Journal, 7(4), 267-278, (2018).
19. Berner,E.:Clinical Decision Support Systems: State of the Art.
www.healthit.ahrq.gov/sites/default/files/doc/page 09-0069-EF_1.pdf, last accessed
2018/10/4.
20. Huang M.: A Clinical Decision Support Framework for Heterogeneous Data Sources. IEEE
Journal of Biomedical and Health Informatics.
21. Beeler, P.: Clinical decision support systems. Swiss Medical Weekly,144(10), 2014.
22. Goldberg, H.: A highly scalable, interoperable clinical decision support service. Journal of
the American Medical Informatics Association, 21(E1), 2014.
23. Kuo T.: Blockchain distributed ledger technologies for biomedical and health care
applications, Journal of the American Medical Informatics Association, 24(6), 1211–1220,
(2017).
24. Ekblaw A.: “A Case Study for Blockchain in Healthcare:“MedRec” prototype for electronic
health records and medical research data“., 2016. healthit.gov … of IEEE Open & Big Data,
last accessed 2018/10/4.
25. Leventhal, R. Blockchain’s promise has Healthcare Innovators Eager
Healthcare Informatics, 34(2), 29-31, (2017).
26. Halamka J.: The Potential for Blockchain to Transform Electronic Health Records. Harvard
Business Review Digital Articles. 2-5, last accessed 2018/9/27.
27. Pirtle, Claude.: “Blockchain for Healthcare: The Next Generation of Medical Records?”
Journal of Medical Systems, 42(9), 171-173, (2018).
28. Cyran, M.: “Blockchain as a Foundation for Sharing Healthcare Data.” Blockchain in
Healthcare Today, www.doi.org/10.30953/bhty.v1.13, last accessed 2018/9/27.
29. Bell, L.: Applications of Blockchain within Healthcare. Blockchain In Healthcare
Today. 1(8), (2018).
30. Ekblaw, A.: MedRec: Medical Data Management on the Blockchain. Viral
Communications. www.viral.media.mit.edu/pub/medrec. last accessed 2018/10/4.
31. Idleberger, F: Evaluation of Logic-Based Smart Contracts for Blockchain Systems. Rule
Technologies. Research, Tools, and Applications. RuleML 2016. LNCS, vol. 9718, 167-
183, (2016).
32. Azaria,A: MedRec: Using Blockchain for Medical Data Access and Permission
Management. 2nd International Conference on Open and Big Data (OBD), 25-30, (2016).