A Framework to Evaluate Architectural Solutions for Ubiquitous

Patient Identification in Health Information Systems

Zuhaib Memon

, Ovidiu Noran

and Peter Bernus

IIIS Centre for Enterprise Architecture Research and Management, Griffith University, Brisbane, Australia

Keywords: Enterprise Architecture, Architecture Principles, Patient Identification, Architecture Evaluation.

Abstract: The lack of accurate, reliable and consistent patient information is a major issue in healthcare, despite a

relatively high Health Information System (HIS) adoption level worldwide. The main reason for this appears

to be patient records lacking accurate particulars, including links to associated care programs, disease

classification and treatment plans. The causes for this are multiple, including incompatibility of healthcare

standards between version releases, inconsistent HIS implementation, lack of effective data input / validation,

and the rapid evolution of and absence of a single ‘universal’ technological solution. Sustainable, stable and

long-term architectural solutions are required. This research builds on previous work identifying major

challenges and root causes of the problem and proposing essential non-functional requirements for HIS

architectures. The paper elaborates on non-functional requirements and proposes an evaluation framework

(based on a new international standard) that can be used to assess aspiring HIS architectures for long term

stability and self-evolution and thus to support strategic decision making from within the evolving HIS.

1 INTRODUCTION

Having accurate, reliable and consistent patient

information is still a major issue in healthcare despite

a high Health Information System (HIS) penetration

worldwide (Fernandes and O'Connor 2015). The root

cause of this appears to be a lack of accurate records

of patient particulars, associated care programs,

disease classification and treatment plans. While the

effect on HIS efficacy and patient medical security is

obvious, there exist important flow-on effects on

healthcare management and policy-making.

A plethora of triggers result in erroneous patient

records – see. Arts et al. (2002). In previous work, the

authors elaborated on a selection of causes deemed to

be some of the most important and difficult to address

(Memon et al. 2017). For example, the

incompatibility of healthcare standards themselves,

the inconsistent manner that HISs are implemented,

episodic unavailability of HIS leading to duplication

and inconsistency of information, lack of effective

data input and validation, patients spoofing or hiding

information from the system for various reasons, etc.

https://orcid.org/0000-0003-0043-1209

https://orcid.org/0000-0002-2135-8533

https://orcid.org/0000-0001-5371-8743

Previous research identified four main categories

of challenges in implementing portable patient

identification in HIS (technical, cultural, social and

ethical), and spelled out architecturally significant

requirements (Chen 2013), or so-called ‘ilities’ that

should feature in sustainable HIS architectures such

as promoted by the World Health Organisation. The

paper builds on previous work and findings from

literature on use cases and case studies (Aller 2016;

Lowry et al. 2015) using a conceptual-analytical

method to demonstrate how the significant ‘ilities’

can be structured and built into a sustainable long-

term HIS architectural solution. This is then taken one

step forward by proposing a healthcare architectural

evaluation framework usable to underpin strategic

decision making in a sustainable manner, i.e. from

within the evolving HIS itself.

580

Memon, Z., Noran, O. and Bernus, P.

A Framework to Evaluate Architectural Solutions for Ubiquitous Patient Identiﬁcation in Health Information Systems.

DOI: 10.5220/0007696305800587

In Proceedings of the 21st International Conference on Enterprise Information Systems (ICEIS 2019), pages 580-587

ISBN: 978-989-758-372-8

2 PATIENT IDENTIFICATION

CHALLENGES

Beyond conceptual problems, e.g., incompatibility of

healthcare standards and inconsistent HIS of

implementation around the world, (Anderson 2007;

LO 2006; Memon et al. 2017; Rinehart-Thompson

and Harman 2006) identified several categories of

challenges as explained below.

2.1 Cultural and Social Barriers

In some (often developing) countries, directly sharing

personal information outside family or larger group is

forbidden. Instead, the family or tribe ‘head’ is to pass

on information, which can result in incompleteness

and inaccuracy (misinterpretation originating due to

lack of proper background, fear of stigma, ‘shame’,

etc.). People outside of the group may not be allowed

contact with members of health care providers; thus,

patient identification may be subject to errors but also

pose a threat to the health workers’ security

(Almutairi and Moradi 2012).

In addition, language barriers and lack of ‘cultural

competence’ (Georgetown University 2011;

Sulaiman 2017) may impair communication and

cooperation at the core of patient information

management (Schyve 2007), so training may need to

be provided and techniques used carefully chosen to

match the cultural environment and afferent degree of

EHR acceptance (Brown 2012; Zoonen 2013).

2.2 Ethical Issues

An essential advantage of HISs is making Electronic

Health Records (EHRs) universally available (when

they are indeed usable and interoperable, as argued by

Reisman (2017)). However, this intrinsically

generates privacy and security concerns – ‘hacking’,

identity theft, unauthorized access or data alteration

(Devon et al. 2010; Ngafeeson 2014). Improper use

of data for serious diseases has the potential to create

significant preconceptions and inequity in workplace

and society (Harman et al. 2012; Ozair et al. 2015;

Sharona 2012). Therefore, ‘information ethics’ as

espoused by Fessler and Grémy (2001) must be

thoroughly observed. This is no trivial task,

considering the effort and costs (Noble et al. 2009) in

the socio-economic and cultural context present in

some geographical areas, especially in developing

countries.

2.3 Technical Problems

Ubiquitous patient identification typically relies on

electrical power availability, local or worldwide

networking capability, possibly aiming towards

Internet of Things (IoT)-based pervasive healthcare

(Arnrich et al. 2010; Zdravković et al. 2014), and

based on Wireless Sensor Networks (Ko et al. 2010).

These requirements may present significant barriers

in developing countries or remote areas in general.

Data may require local storage (avoid information

loss or duplication on power loss), and processing/

conditioning (reduce transmission bandwidth need).

Traditionally patient identification has been text-

based, but it is fraught with numerous pitfalls, such as

duplication or unavailability of essential data (e.g.

unique identifiers (names, dates of birth) due to

geographical and cultural factors (Aller 2016), or the

possibility to intentionally provide false information

(e.g. for doctor- and/or drug ‘shopping’).

Alternative technologies proposed are based on

barcodes and/or radiofrequency identification (RFID)

tags, both often used with wristbands, or biometric

identification using body features unique to

individuals (Alyssa 2012; Doll Martin Associates

2008; García-Betances and Huerta 2012). In the latter

category, among the most used are iris pattern, palm

vein and fingerprint (Aller 2016).

Iris pattern can be sensed from a distance

(important if physical contact is a problem due to e.g.

cultural or fomite (infectious transmission)

perceptions, and can be done in infrared (hence less

conspicuous). However it requires a good image, may

be confused with facial recognition (which may be

feared by some members of the public) and may fail

due to rare but existing pigment dispersion conditions

(Pillai et al. 2011; Ross 2010)

Fingerprint technology has been used for decades

and evolved to be able to identify fake or dead prints

and improved reliability by using 3D. While it is an

accepted method in many areas and countries, it does

require good quality readers, may imply a negative

social perception (Wickins 2007) (e.g. due to being

associated with Police work), and may lack accuracy

for young patients or those who practice specific

manual trades affecting finger ridges (Aller 2016).

Palm vein identification is more recent (Zhang et

al. 2007), uses separate templates in each patient

network and is more secure, but this hinders data

consolidation. It can also be affected by ambient light

and palm position, must be refreshed yearly for young

patients and can constitute a fomite (Aller 2016; Patil

and Ajmire 2018).

As can be seen, biometric technologies exhibit a

A Framework to Evaluate Architectural Solutions for Ubiquitous Patient Identiﬁcation in Health Information Systems

581

large variety and are in constant evolution. Each

technique is useful in specific conditions and appears

to have its weaknesses; therefore, a combination is

perhaps the solution. Also, in order to triangulate and

to verify results and thereby minimise patient

misidentification, text-based identification may also

be used, but only as a back-up measure and to

facilitate interoperability (e.g., with legacy systems).

Note that ‘blockchain’ technology is also being

considered for compliance, information integrity

preservation, privacy and interoperability, although

the technology is in its infancy (Krawiec 2016).

In view of the above, a question remains: how to

prepare for a long-term ubiquitous solution in view of

the continuous evolution and heterogeneity of

solutions and different levels of technology adoption

worldwide? The solutions must meet patient

identification functional requirements as well as

essential non-functional requirements (HIMSS 2015)

due to the special role of patient identification in the

lives of patients in health services management.

In conclusion, a stable, long-term solution must

specify architectures, rather than specific solutions or

technologies. This creates a problem: how do we

know that such architectures are in fact of ‘good

quality’? The authors argue that there is also a need

for an evaluation framework for assessing the quality

of such architectures. The remainder of this paper

addresses the above two essential questions.

3 DESIRED SYSTEMIC

PROPERTIES OF A SOLUTION

There is an extensive literature of non-functional

requirements (the system ‘ilities’), in the software

engineering (Chung et al. 2000; Jan et al. 2016;

Penzenstadler et al. 2014) and systems engineering

literature (INCOSE 2011; ISO/IEC/IEEE 2011).

However, the authors were unable to find a

comprehensive list that applies to enterprises.

Many ilities known from the systems engineering

literature apply to enterprises including health care

(public health, health care provision & management

(Anyanwu et al. 2003)), but the relevance and

priorities of these properties are expected to be

different from those that apply to a software system

(including an HIS). This is expected, as the health

enterprise is a complex evolving system of systems

(SoS) both on national- and global scales - and the

time horizon on which the long-term viability of this

enterprise needs to be secured is very long (in fact,

open ended).

In recent years, evidence accumulated (at least in

the HIS area) pointing to the need to pay increasing

attention to non-functional requirements. E.g., Lowry

et al. (2015) list as a top priority to “... consistently

display information critical to patient identification in

a reserved area to avoid wrong patient errors”.

Establishing a framework for an open-ended long

term solution to patient identification is facing a

problem that has been documented in the systems

engineering literature (Jain et al. 2009; Warren 2018)

namely that stakeholders are not a good (or reliable)

single source of information when it comes to

determining non-functional requirements of a system.

Accordingly, system ilities are usually not on the

radar of stakeholders (or only trivial ones are

considered): the architects must become protagonists

and educate stakeholders about what they should be

requiring. E.g., maintainability is not in the focus of

typical HIS stakeholders, even though when a system

becomes too expensive to maintain a costly redesign

and re-development will be necessary.

As described by Bellomo et al. (2015), the

software architecture community identified a list of

systemic (non-functional) requirements that dominate

the landscape of software systems architecture.

However, the patient identification problem context

is provided by a ‘system’ that is not software, but

rather an evolving socio technical system of systems

(SoS). This SoS consists of a combination of policies,

laws and processes performed by humans, supported

by a various technologies, and involve independently

managed and evolving services. So, while lessons

learnt from the systems and software engineering

must be considered, we must make adaptations and

look at experiences from other domains.

3.1 Quality Attributes of Systems of

Systems

The international Standard ISO 25010 - Quality

Model (2011) provides guidance on quality attributes

of systems (such as: functional suitability, reliability,

performance efficiency, usability, security,

compatibility, maintainability and portability), and

additional attributes relevant when the system is in

use (effectiveness, efficiency, satisfaction, freedom

from risk and context coverage). Section 4.1 of this

standard includes a finer-grained and comprehensive

list of sub-categories (see Table 1).

Despite these quality characteristics being

important, these concentrate on a shorter time scale /

horizon than a patient identification system would

require, because traditional architectural decisions for

software and other technical systems are made

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

582

assuming that the systems will be designed, built and

used, without necessarily considering very long term

changes (abrupt or evolutionary) in the domains of

technology, or in the socio-economic environment.

Table 1: Categories of quality attributes, with sub-

categories in italics. (Source: the publicly available

informative section of ISO25010 (2011)).

 Functional suitability: Functional completeness,

Functional correctness, Functional

appropriateness,

 Performance efficiency: Time behaviour, Resource

utilization, Capacity;

 Compatibility: Co-existence, Interoperability,

 Usability (defined by ISO9241 as “the extent to

which a product can be used by specified users to

achieve specified goals with effectiveness,

efficiency and satisfaction in a specified context of

use”): Appropriateness, Recognisability,

Learnability, Operability, User error protection,

User interface aesthetics, Accessibility;

 Reliability: Maturity, Availability, Fault tolerance,

Recoverability;

 Security: Confidentiality, Integrity, Non-

repudiation, Accountability, Authenticity;

 Maintainability: Modularity, Reusability,

Analysability, Modifiability, Testability,

Portability, Adaptability, Installability,

Replaceability;

 Effectiveness;

 Efficiency;

 Satisfaction: Usefulness, Trust, Pleasure, Comfort,

 Freedom from risk: Economic risk mitigation,

Health and safety risk mitigation, Environmental

risk mitigation;

 Context coverage: Context completeness,

Flexibility.

Therefore, as demonstrated in previous work by

two of the authors (Noran and Bernus 2017; Turner et

al. 2018) the solution must be approached as a long-

term infrastructure building endeavour, where during

the lifetime of this infrastructure many changes are to

be expected while preserving continuity. For this

reason the authors propose a working list of ilities

(See Table 2) that adds viability (which is in fact the

ultimate long-term system survival capability) to

Boehm’s (2014) set.

We argue that to decide on the introduction of

sustained use of biometrics in patient identification it

would be impractical to assess all of the ilities of HISs

impacted by the relevant technology choice(s).

Section 4 below proposes reducing the size of the

decision tree to arrive at an evaluation regime that

prunes the options so meaningful comparisons and

associated implementation decisions can be made.

Such a reduced list would contain mandatory

criteria for very long term HIS infrastructure

decisions to eliminate solution options possibly

attractive to some stakeholders (given a shorter term

investment horizon) but which do not satisfy essential

non-functional requirements and go against the

achievement of long term strategic goals.

4 A GENERIC ARCHITECTURE

EVALUATION FRAMEWORK

STANDARD

ISO42030 ‘Architecture Evaluation Framework’

((ISO/IEC 2018) contributes to the maturity of

architecture governance because it systematises the

elements to be considered by a process that supports

architectural decision making. The standard builds on

the concepts of previous work on architecture

evaluation, but generalises these. Such previously

published methods include Architecture Trade-off

Analysis Method – ATAM (Kazman et al. 2000), the

Method Framework for Engineering System

Architectures (QASAR) (Firesmith 2010) and

Analysis of Alternatives (U.S. Air Force 2008).

Accordingly, the evaluation of alternatives should

be performed in two passes: i) eliminate proposals

that do not satisfy mandatory non-functional

requirements, and ii) compare candidate solutions

using and appropriate decision-making method. ISO

42030 (ISO/IEC 2018) requires that based on

business goals architecture governance derive the

evaluation objectives, i.e., what kind of answers do

we expect from the architecture evaluation?

Objectives may include the desire to determine

whether the solution will reduce the total cost of

ownership, to what extent, or if it will improve current

capability/service quality.

Comparing alternative solutions would be

performed by defining factors that influence the

answers, and selecting methods known to deliver

these answers. Evaluation factors (derived from

business drivers) may include cost, schedule, quality,

risk etc., whereupon evaluation methods on this level

would not be very formal (referring to existing

analysis reports, or using expert panels are typical

examples). This is important, because in practical

situations there are too many objectives and factors

and it is necessary to eliminate many of these using

fast and affordable methods.

A Framework to Evaluate Architectural Solutions for Ubiquitous Patient Identiﬁcation in Health Information Systems

583

Table 2: Categories of ilities (based on (Boehm 2014)).

Individual ilities

 Quality of Service: Performance, Accuracy,

Usability, Scalability, Versatility

 Resource Utilization: Cost, Duration, Personnel,

Scarce Quantities (size, weight, energy, …)

 Protection: Safety, Security, Privacy

 Robustness: Reliability, Availability,

Maintainability

 Flexibility: Modifiability, Tailorability /

Extendability, Adaptability

 Composability: Interoperability/Portability,

Openness/Standards Compliance, Service-

Orientation

Composite ilities

 Comprehensiveness/Suitability: all of the above

 Dependability: Quality of Service, Protection,

Robustness

 Resilience: Protection, Robustness, Flexibility

 Affordability: Quality of Service, Resource

Utilization

 Viability

Often though, the answers are unclear, and to

compare architectural solutions one also needs to

assess the architecture by asking what is the value of

this architecture (the quality requirement may not be

met? is there a trade-off or opportunity to optimise?,

how do architectural decisions contribute to the

expected quality attributes?).

As part of this value assessment process, one must

determine how/to what extent the chosen architecture

contributes to achieving the business goals? The

value of the chosen approach may be demonstrated

using suitably selected metrics (value factors that

have measurable characteristics), such as speed,

throughput, cost, etc. Given the value assessment

factors, value assessment methods are needed to

compile the findings of architecture evaluation.

Often the desired measures are not readily

available by inspecting the proposed architecture, so

further architectural analysis is needed, and this may

require models to be developed.

Analytical models may be suitable for sensitivity

analyses, e.g., perform quantitative statistical analysis

using simulation models that can be put to test and

provide evidence of the extent the architectural

solution meets the desired quality attributes. Some

systemic properties (availability, changeability,

robustness, evolvability, complexity) may be

expressed using graph properties of the system, or by

entropy calculations, and so on. Architecture analysis

exercises are for the above reason the most costly and

time consuming; therefore it is prudent to eliminate

the need for such analytic work if possible.

5 A FRAMEWORK TO

EVALUATE PROPOSED

UBIQUITOUS PATIENT

IDENTIFICATION SOLUTIONS

Solutions advocated at any one time by protagonists

(namely to use biometrics for patient identification)

must be able to be evaluated against the desired

criteria discussed in Section 3. While the generic

framework of ISO 42030 (ibid.) draft international

standard gives guidance, a practical application

requires the identification of domain-specific

objectives, evaluation factors and methods.

A first-cut version of a specific evaluation

framework can be developed based on the systemic

properties discussed and found desirable for any

proposed solution. Note that in real application the

proposed artefacts must be re-visited, validated with

stakeholders and possibly expanded using the end

user’s architecture governance processes.

As shown in Section 2.3, biometric identification

techniques are useful to various degrees in different

circumstances and have their own characteristics,

requirements, weaknesses and strengths. Thus, given

the uncertainties and the need to adopt future-proof

systems, it is important to have an evaluation

framework at hand that can assess proposed solutions

both in terms of a) the long term sustained

performance of technical systems (such as those using

biometrics) that provide patient identification

services, and b) in terms of how these contribute to

the viability of seamless use of patient identification

functions within relevant processes of the complex

healthcare SoS (the ‘healthcare ecosystem’). Thus,

from patient identification point of view, both the

healthcare ecosystem and the system(s) providing

patient identification service need be considered.

5.1 Evaluation Objectives

In discussing the relevant evaluation objectives for

the architecture of the healthcare SoS, the first

difficulty encountered is that in the healthcare

ecosystem there is no central decision making

authority that has complete control over the system as

a whole (not even on the country or region level).

However, there exist significant players that can

develop and disseminate policies, principles and

standards that influence decision makers in desirable

directions. Accordingly, an evaluation must answer

the following fundamental questions:

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

584

i) Does the architecture of the healthcare SoS

display a structure enabling continuous long-term

change and improvement (viability)?

ii) Is there a guarantee that the above can happen

without the need for reinventing the way this

essential function is provided by the patient

identification services available at any one time,

now and in the future? Thus, the authors propose

to also investigate evolvability.

iii) Is there a guarantee that system changes satisfy

the end user quality of service requirements (such

as usability)? The reason for usability to make the

mandatory list of ilities is the recurrent reports

about lack of usability and / or good user

experience design result in poor adoption and a

number of adverse effects that prevent the full

benefits from being realised (Lowry et al. 2015).

iv) Other evaluation objectives could be defined and

used (based on the ilities listed in Tables 1 and 2),

but the focus here is on the viability aspects.

Given that the evaluation concerns an SoS, these

objectives are relevant for each level and constituent

of the healthcare ecosystem, according to the theory

of the Viable Systems Model (Beer 1972). Although

the architectural measures taken to ensure viability,

evolvability and usability may not be the same on

every system level, government level measures (laws,

policies, principles and mandatory compliance

processes) must be traced to corresponding decision

making instruments on lower levels of the ecosystem

(e.g. various and allied health care providers).

5.2 Evaluation Factors

Architecture evaluation factors are often categorised

as Political, Economic, Social, Technological,

Environmental and Legal (PESTLE) (Law 2009),

which helps the designer of the evaluation to find

relevant factors and determine what methods to use.

For example, an economic factor of viability is that

the system is affordable to operate, while an

economic factor for evolvability is that changing the

system by adding a new technology is affordable (e.g.

by modularising the system architecture to separate

technology choice from the service user, thus

localising the change effects). When evaluating

systems for usability, one must include economic

factors: it needs to be understood whether the use of

patient identification system requires extra work or

otherwise slows down the medical service.

5.3 Evaluation Method(s)

Depending on the evaluation factors at hand, there

can be a number of options to use, including expert

reviews, references to existing strategic analysis from

respectable sources, etc. If the identified methods

cannot give a conclusive answer, then architecture

evaluation needs to evaluate each relevant factor of

the solution from the point of view of the value it

contributes to business goals. The result is a synthesis

report identifying the extent the architecture satisfies

business goals, as well as identifying risks due to

uncertainty or lack of available information.

5.4 Value Analysis

Value analysis has its own objectives, factors, and

methods, and reports are created that can be

incorporated into the eventual architecture evaluation

synthesis report. Space and scope limitations do not

allow a factors and methods listing, albeit it must be

noted that value assessment should try to use existing

sources of information, such as historical records of

past projects. However, in case the outcomes of value

assessment methods are inconclusive, a third layer of

architecture evaluation 'architecture analysis’ is

necessary.

5.5 Architecture Analysis

Architecture analysis also has its own objectives,

factors and methods, and the results incorporated into

an eventually produced ‘synthesis report’.

The main difference between this layer and the

first two is that the factors considered are such that

the analysis methods require the use of modelling

and/or experimentation; therefore, the cost and time

involved may be significant. For example, if the value

of a new process cannot be ascertained, business

process modelling and simulation may be required to

model the economic impact of the architectural

change.

Experimentation may involve the creation of a

proof of concept of a pilot implementation, which

then will be used to conduct usability experiments.

6 CONCLUSIONS AND FURTHER

WORK

This paper proposes an architectural solution for the

currently unsolved patient identification problem,

based on an International Standard for Architectural

Evaluation (ISO 42030) and should be considered as

an example demonstrating the use of this standard.

The difficulty of the problem lies in the following:

A Framework to Evaluate Architectural Solutions for Ubiquitous Patient Identiﬁcation in Health Information Systems

585

i) The Healthcare Ecosystem is an SoS without an

ultimate central authority to control its evolution;

ii) A patient identification infrastructure must be

viable on a very long term, and there is only scarce

experience with successful long term IT

infrastructure building, with significant social and

political factors influencing its success;

iii) The technologies of today will change at an

accelerated rate; therefore, a long term solution

must incorporate the ability of the system to

evolve without causing unacceptable disruption.

The proposed framework is a tool that may be

used to assess patient identification improvement

proposals in view of addressing the most significant

stakeholder concerns, which are not always explicitly

espoused in essential non-functional requirements.

End users of this framework may include government

agencies (e.g. health departments, health district

management), NGOs (such as the WHO, standards

bodies, etc.) and even HIS vendors.

Further work will include development of the

details of the evaluation framework and its validation

by selected experts from stakeholder groups.

REFERENCES

Aller, R. D. 2016. "Patient Identification: Biometric or

Botched?," HIMSS16, I.M.i. Assn (ed.), Las vegas, US.

Almutairi, D., and Moradi, E. 2012. "Factors Influencing

Turnover among Saudi Nurses: A Literature Review."

Retrieved 2018, https: //www.academia.edu/795094/

Alyssa, I. 2012. "Health Care Information Technology:

Securing the Electronic Health Record with Biometric

Technology," The Review: A Journal of Undergraduate

Student Research (15), pp. 4-8.

Anderson, J. G. 2007. "Social, Ethical and Legal Barriers to

E-Health," Int J Med Inform. (76:5-6), pp. 480-483.

Anyanwu, K., Sheth, A., Cardoso, J., Miller, J., and Kochut,

K. 2003. "Healthcare Enterprise Process Development

and Integration " Journal of Research and Practice in

Information Technology (35:2).

Arnrich, B., Mayora, O., Bardram, J., and Tröster, G. 2010.

"Pervasive Healthcare – Paving the Way for a

Pervasive,User-Centered & Preventive Healthcare

Model," Methods Inf Med (49:1), pp. 67-73.

Arts, D., de Keizer, N., and Scheffer, G.-J. 2002. "Defining

and Improving Data Quality in Medical Registries" J

Am Med Inform Assn. (9:6), pp. 600-611.

Beer, S. 1972. Brain of the Firm. London: Penguin Press.

Bellomo, A., Gorton, I., and Kazman, R. 2015. "Toward

Agile Architecture: Insights from 15 Years of Atam

Data " IEEE Software (32:5), pp. 38-45.

Boehm, B. e. a. 2014. " -Ilities Tradespace and

Affordability Project" Technical Report SERC-2014-

TR-039-3, https://archive.sercuarc.org/publications-

papers/technical-report-tradespace-and-affordability/

Brown, C. 2012. "Health ‐ Care Data Protection and

Biometric Authentication Policies: Comparative

Culture and Technology Acceptance in China and in the

United States," Rev Pol Res (29:1), pp. 141-159.

Chen, L. 2013. "Characterizing Architecturally Significant

Requirements," IEEE Software (30:2), pp. 38-45.

Chung, L., Nixon, B. A., Yu, E., and Mylopoulos, J. 2000.

Non-Functional Requirements in Software Engineering.

Dordrecht Kluwer.

Devon, M. H., Gorman, L., and Goodman, J. C. 2010.

"Health Information Technology: Benefits and

Problems-Report 327." www.ncpa.org/pdfs/st327.pdf

Doll Martin Associates. 2008. "Technology Solutions to

Patient Misidentification." Australian Commission on

Safety and Quality in Healthcare.

Fernandes, L. M., and O'Connor, M. 2015. "Accurate

Patient Identification: A Global Challenge," in:

Perspectives in Health Information Management

Fessler, J. M., and Grémy, F. 2001. "Ethical Problems in

HIS.," Methods Inf Med. (40:4), pp. 359-361.

Firesmith, D. 2010. "Quasar: Quality Assessment of

Software-Intensive System Architectures."

https://resources.sei.cmu.edu/library/asset-view.cfm

García-Betances, R., and Huerta, M. 2012. "A Review of

Automatic Patient Identification Options for Public

Health Care Centers with Restricted Budgets," Online J

Public Health Inform.

(4:1).

Georgetown University. 2011. "Center for Child and

Human Development. National Center for Cultural

Competence." http: //gucchd.georgetown.edu/67212.

Harman, L., Flite, C., and Bond, K. 2012. "Electronic

Health Records: Privacy, Confidentiality, and

Security," Virtual Mentor. (14:9), pp. 712-719.

HIMSS. 2015. "Promoting Usability in Health

Organizations: Steps toward a Healthcare Usability

Maturity Model." Health IT User Experience

Committee, https://www.himss.org/file/1323535/

INCOSE. 2011. Systems Engineering Handbook: A Guide

for System Life Cycle Processes and Activities (V.3.2.1).

San Diego, CA, USA.

ISO/IEC. 2011. "Iso/Iec 25010: Systems and Software

Engineering — Systems and Software Quality

Requirements and Evaluation (Square)." ISO/IEC.

ISO/IEC. 2018. "Iso/Iec 42030: Draft Standard for Systems

and Software Engineering - Architecture Evaluation."

ISO/IEC.

ISO/IEC/IEEE. 2011. "Iso/Iec/Ieee 29148. Systems and

Software Engineering - Reqs Engineering.." ISO/IEC.

Jain, R., Chandrasekaran, A., and Elias, G. M. 2009.

"System Architecture Concerns: A Stakeholders ’

Perspective."

Jan, S. R., Khan, F., Tahir, M., Khan.S, and Ullah, F. 2016.

"Survey: Dealing Non-Functional Requirements at

Architecture Level. Vfast Transactions on Software

Engineering," (9:2), pp. 7-13.

Kazman, R., Klein, M. H., and Clements, P. C. 2000.

"Atam: Method for Architecture Evaluation (Cmu/Sei-

2000-Tr-004)." https://resources.sei.cmu.edu/library/

asset-view.cfm?assetid=5177

ICEIS 2019 - 21st International Conference on Enterprise Information Systems

586

Ko, J., Lu, C., Srivastava, M. B., Stankovic, J. A., Terzis,

A., and Welsh, M. 2010. "Wireless Sensor Networks for

Healthcare," Proceedings of the IEEE (98:11).

Krawiec, R. J., et. al. 2016. "Blockchain: Opportunities for

Health Care." deLoitte.

Law, J. E. 2009. A Dictionary of Business and Management,

(5th ed.). Oxford University Press.

LO, B. 2006. "Professionalism in the Age of Computerised

Medical Records.," Singapore Med J. (47:12), pp.

1018-1022.

Lowry, S. Z., Ramaiah, M., Taylor, S., Patterson, E. S.,

Prettyman, S. S., Simmons, D., Brick, D., Latkany, P.,

and Gibbons, M. C. 2015. "Technical Evaluation,

Testing, and Validation of the Usability of Electronic

Health Records.." NISTIR 7804-1 Retrieved Dec.,

2018, from http://dx.doi.org/10.6028/NIST.IR.7804-1

Memon, Z., Bernus, P., and Noran, O. 2017. " Challenges

in Implementing a Portable Patient Identification

System for Ubiquitous Healthcare in Developing

Countries" in Information Systems Development:

Advances in Methods, Tools and Management, N.

Paspallis, M. Raspopoulos, M. Barry, M. Lang, H.

Linger and C. Schneider (eds.). Larnaca, Cyprus.

Ngafeeson, M. 2014. "Healthcare Information Systems:

Opportunities and Challenges (Paper 14)," in

Encyclopedia of Information Science and Technology,

M. Khosrow-Pour (ed.). IGI Global.

Noble, S., Donovan, J., Turner, E., Metcalfe, C., Lane, A.,

Rowlands, M., Neal, D., Hamdy, F., Ben-Shlomo, Y.,

and Martin, R. 2009. "Feasibility and Cost of Obtaining

Informed Consent.," J Health Serv Res Policy (14:2),

pp. 77-81.

Noran, O., and Bernus, P. 2017. "Business Cloudification:

An Enterprise Architecture Perspective.," in

Proceedings of the 19th International Conference on

Enterprise Information Systems, S. Hammoudi et al.

(ed.). Porto, Portugal: ScitePress, pp. 353-360.

Ozair, F., Jamshed, N., Sharma, A., and Aggarwal, P. 2015.

"Ethical Issues in Electronic Health Records: A General

Overview," Perspect Clin Res (6:2), pp. 73-76.

Patil, P. A., and Ajmire, P. 2018. "Survey: Human

Identification Using Palm Vein Images," Int J

Emerging Technologies in Engineering Research (6:3).

Penzenstadler, B., Raturi, A., Richardson, D., and Tomlison,

B. S., "Safety, Security, Now Sustainability: The

Nonfunctional Requirement for the 21

Century," IEEE

Software (31:3), pp. 40-47.

Pillai, J. K., Patel, V. M., Chellappa, R., and Ratha, N. K.

2011. "Secure, Robust Iris Recognition Using Random

Projections and Sparse Representations," IEEE Trans.

Pattern Anal. Mach. Intell. (33:9), pp. 1877-1893.

Reisman, M. 2017. "Ehrs: The Challenge of Making

Electronic Data Usable and Interoperable," Pharmacy

and Therapeutics (42:9), pp. 572-575.

Rinehart-Thompson, L., and Harman, L. 2006. "Ethical

Challenges in the Management of Health Information,"

in Privacy and Confidentiality;. Sudbury, MA: Jones

and Bartlett, p. 54.

Ross, A. 2010. "Iris Recognition: The Path Forward," IEEE

Computer (43:2), pp. 30-35.

Schyve, P. M. 2007. "Language Differences as a Barrier to

Quality and Safety in Health Care: The Joint

Commission Perspective," J Gen Intern Med. (22:Suppl.

2), pp. 360-361.

Sharona, H. 2012. "Employing E-Health: The Impact of

Electronic Health Records on Workplace (Paper 10)

Http://Scholarlycommons.Law.Case.Edu/Faculty_Publicat

ions/10." Faculty Publications.

Sulaiman, A. 2017. "The Impact of Language & Cultural

Barriers on Patient Safety & Health Equity."

http://www.wapatientsafety.org/impact-of-language-

cultural-barriers-on-patient-safety-health-equity

Turner, P., Bernus, P., and Noran, O. 2018. "Enterprise

Thinking for Self-Aware Systems," IFAC Papers

OnLine (51:11), pp. 782-289.

U.S. Air Force. 2008. "Analysis of Alternative (Aoa)

Handbook: A Practical Guide to Analysis of

Alternatives." Kirtland AFB, NM: Air Force Materiel

Command Office of Aerospace Studies (OAS).

Warren, T. 2018. "Non Functional Requirements & It's

Importance across the Sdlc." Retrieved Dec, 2018,

https://tangowhisky37.github.io/PracticalPerformance

Analyst/spe_fundamentals

Wickins, J. 2007. "The Ethics of Biometrics: The Risk of

Social Exclusion from the Widespread Use of

Electronic Identification," Science and Engineering

Ethics (13:1), pp. 45-54.

Zdravković, M., Noran, O., and Trajanović, M. 2014.

"Towards Sensing Information Systems," in

Proceedings of 23

International Conference on

Information Systems. Berlin: Springer Verlag.

Zhang, Y. B., Li, Q., You, J., and Bhattacharya, P. 2007.

"Palm Vein Extraction and Matching for Personal

Authentication," in Procs of Visual '07. pp. 154-164.

Zoonen, L. 2013. "From Identity to Identification: Fixating

the Fragmented Self " Media, Culture & Society (35:1),

pp. 44-51.

A Framework to Evaluate Architectural Solutions for Ubiquitous Patient Identiﬁcation in Health Information Systems

587