Designing a Framework of Technical Hospital Information Systems Requirements and Evaluating the Systems Implemented through this Framework

doi:10.21203/rs.2.14326/v1

Download PDF

Research article

Designing a Framework of Technical Hospital Information Systems Requirements and Evaluating the Systems Implemented through this Framework

https://doi.org/10.21203/rs.2.14326/v1

This work is licensed under a CC BY 4.0 License

Journal Publication

published 03 Apr, 2020

Read the published version in BMC Medical Informatics and Decision Making →

You are reading this older preprint version

Read the latest preprint version →

Background Hospital Information System (HIS) implementation is complex and costly compared to other information systems. Therefore, the present study was conducted with the aim of designing and evaluating technical HIS requirements.

Methods This study was conducted in 2016 in two parts: designing technical requirements and evaluating the HIS. The first part of the study was performed through the Delphi technique. In the second part of the study, evaluation of systems was done using a checklist based on the approved requirements.

Results In the first part of the study, the final list of technical HIS requirements was designed with 73 items in four domains including ‘communication service’, ‘system architecture’, ‘security service’, and ‘system response time’. In the second part, the results of the evaluation indicated that the approved requirements had been observed in 63.8%, 65.5%, 72.4%, and 76.3% of the HIS software programs in the dimensions of ‘communication service’, ‘system architecture’, ‘security service’, and ‘system response time’, respectively.

Conclusions The technical HIS evaluation tool was designed to be used in the evaluation and selection of the system. The evaluation results also indicated that the studied HISs were weaker in ‘communication service’ and ‘system architecture’ domains compared to the other two domains under study.

Medical Informatics

technical requirements

Hospital Information System (HIS)

communication service

system architecture

security service

system response time

Today, the advancement of Information Technology (IT) has changed the face of the world altogether and healthcare services are significantly supported through the emerging IT [1, 2]. Among those, HISs are one of the most commonly used health information systems [3]. Not only do these systems offer a tool for information management [4], but they also provide opportunities for rapid and precise processes, immediate access to information, economic savings, increased overall efficiency and even reduced clinical errors as well as improved treatment quality [5]. One of the problems arisen from HIS implementation is lack of proper identification of technical requirements and integrity of these systems [6]. Therefore, a framework of technical HIS requirements and assessing HISs based on this framework is of utmost importance.

Despite potential benefits, HISs are neither widely used within healthcare providers nor readily accepted by users where they are launched [7]. Polack (2009) reported the failure rate of Electronic Health Records (EHRs) as 30–50% [8]. Implementing and accepting information systems in hospitals is relatively more complicated and costly compared with other businesses. Thus, a number of countries spend at least 2–6 percent of their health budgets on information and communication technologies [6, 9]. Given the fact that HISs gain acceptability rather slowly and the significant rate of failure among these systems, efforts need to be made in order to understand how to overcome the challenges against HIS implementation [10]. A great deal of time and money may be wasted in healthcare systems unless these challenges are duly addressed [11].

Technical characteristics of information systems such as ‘system architecture’ type, ‘communication service’ of the system, and ‘system response time’ have a major role in determining the success or failure of a system [12]. A number of studies have addressed technical factors as the second major factor [1] and even the biggest barrier to effective HIS implementation [13]. According to another study, 35% of information system failures showed to be rooted in technical factors [14]. Technical obligations help users ensure that a system is capable of communicating with other systems and guarantees information security and confidentiality [15]. Technical aspects help network designers to identify technical features and the software version that supports these features; however, in some cases, these technical features may affect the choice of hardware platforms [16].

Given the strong link between technical factors and success rate of HISs[17], it is of great importance to establish appropriate evaluation criteria for solving technical barriers to the system implementation[18] inasmuch as accurate assessment of HISs is considered as an integral part the successful implementation of these systems[19]. In this regard, much care should be taken to choosing both HIS software programs and software suppliers. The selected software need to be capable of meeting organizational goals [20]. Therefore, the Request For Proposal (RFP), which forms the basic document for HIS implementation, must be prepared and approved by the executive team, end users and a number of system analysts [6]. A couple of studies conducted to rate HISs have evaluated some technical requirements in these systems [21, 22]. Some studies have referred hardware, software, networking and technical support as the technical challenges faced during development of health information systems [11, 23].

Regarding the program of Iran’s Ministry of Health and Medical Education for the application of IT services in the healthcare sector and development of EHRs[24] and considering HISs as good examples of EHRs[25], implementation principles and the technical requirements of these systems need to be continuously assessed and revised[26]. Therefore, the present study aimed at proposing a framework for the technical HIS requirements and assessment of HISs implemented based on these requirements. The requirements set out in this study can be employed by hospital executive teams and HIS developers.

The present study was conducted in two parts: designing technical HIS requirements and evaluating HISs based on these requirements.

First Part: Designing technical HIS requirements

The research was conducted using Delphi technique in three stages: Focus GroupDiscussion (FGD), Modified Delphi Technique, and Classic Delphi Technique. The details of each stage are as follows:

First Stage: Focus Group Discussion

At this stage, 10 experts holding master’s degrees or higher in software, networking, and IT with at least 7 years of work experience in hospital IT departments or the IT departments of medical universities were selected from among faculty members and the staff. FGD was utilized at this stage. During four 4-hours sessions, technical barriers and challenges of implementing HISs were discussed. The FGD pursued two goals: identifying the most important technical requirements desired by the experts and outlining all of the problems the experts had ever faced regarding technical HIS requirements during system implementation or execution. At this stage, the experts represented their ideas freely and addressed any technical HIS requirements through brainstorming. The experts’ comments were recorded and then transcribed during the meetings. Finally, a list of technical requirements was compiled and, based on their views, the requirements were grouped into four domains including ‘communication service’, ‘system architecture’, ‘security service’, and ‘system response time’ and then the primary questionnaire on the framework of technical HIS requirements was designed. The questionnaire included introduction of the study, objectives and a list of the technical HIS requirements with an open-ended question in order to add up experts’ comments to the list at a further stage.

Second Stage: Modified Delphi Technique

In the second stage, Modified Delphi Technique was employed to reach consensus on the requirements. Experts of this stage were the same experts participating in the first stage of the study. Modified Delphi Technique is generally used as a Group Delphi Technique to reach consensus based on experts’ opinions through structured questionnaires. This method was a multi-stage process, which continued until consensus was reached. The Modified Delphi Technique was an open-ended round Delphi guided by the focus group or one-to-one interviews [27]. At the end of the focus group, the initial technical requirements were formatted in the form of a five-point Likert questionnaire (Strongly Disagree = 0 to Strongly Agree = 4). Each technical HIS requirement was independently assessed by the experts and the assigned a score. The requirements with a final mean score of 3 and above were approved, and those with a final score of less than 2 were eliminated. Moreover, the requirements with an average score of 2–3 were reassessed by the experts to be either approved or removed from the questionnaire. The experts were encouraged to freely propose any new ideas about technical HIS requirements. They reached an agreement on the final list of technical HIS questionnaire after four focus group rounds. Finally, four groups of technical HIS requirements were accepted with 72 items and an average of 3.4 scores.

Third Stage: Classic Delphi Technique

In this stage, the questionnaire containing 72 items approved in the second stage was distributed among 40 IT experts and hospital and medical sciences university’s managers across the country holding master’s degrees or higher and at least 5 years of work experience in the field of HIS. The questionnaire included demographic information, 72 closed-ended questions and an open-ended question to explore the possibility of getting additional technical requirements. Participants were asked to express their opinion through a five-point Likert scale (from strongly disagree to strongly agree). At all rounds of the Delphi technique, feedback was anonymously provided to the participants. To ensure all Delphi characteristics (anonymity and feedback), research collaborators as another focal point were introduced to the hospitals under study across the country. They were responsible for familiarizing IT experts and managers with research goals and providing feedback on the data in each round. Out of the 40 distributed questionnaires, 38 were filled out. The mean score of each requirement was computed using SPSS software program (Version 18, SPSS Inc., Chicago, IL, USA) and then used for statistical purposes. This Classic Delphi Technique was done in two rounds. Finally, one item was added to the questionnaire and four groups of technical HIS requirements were approved with 73 items and an average of 3.6 scores.

Second Part: Evaluating HISs

Iran’s Ministry of Health and Medical Education was inquired about the number of companies providing HISs and it turned out that the software was being implemented by 19 software suppliers throughout the country. Then, 19 suppliers were contacted for permission to assess hospital information systems out of which 16 suppliers gave the permission. Finally, a list of the hospitals which had been implementing HISs bought from these suppliers since at least 5 years earlier was provided. For each software supplier, one hospital was randomly selected which was running the HIS software program. If not all software modules of the supplier company were operational in the selected hospital, the hospital was eliminated from the study and replaced by another hospital through random selection. Finally, 16 hospitals were selected to evaluate HIS software programs. Using the technical HIS checklist containing Yes/No questions designed in first part, IT users and experts working at the information technology units of the selected hospitals were interviewed in person and the checklists were filled out. Next, the data was analyzed using SPSS software program (Version 18, SPSS Inc., Chicago, IL, USA). If hospital HISs met the checklist criteria, they were given a score of 1. Otherwise, a score of zero was given to the HISs. To show system status, the percentage scores were calculated. The percentage scores obtained for each domain were considered as very weak, weak, average, good, and very good for percentages of 0–20%, 20–40%, 40–60%, 60–80%, and 80–100%, respectively.

Ethical Considerations

Before starting the FGD round, all participants signed an informed consent form in which study objectives, voluntary participation in the FGD, and information confidentiality had been explained. Furthermore, in the second part of the study, participants were informed of study objectives before filling out the questionnaire. The voluntary nature of participation was explained, and participants were assured of information confidentiality and anonymity.

In the Classic Delphi stage, 76.3% of experts were men and 23.7% were women. The mean age of participants was 34.7 ± 6.3 years, with a minimum and maximum age of 28 and 52 years, respectively. As for the level of education, 63.2% of participants held a bachelor’s degree at the time of the study. The mean work experience of participants was 9.9 ± 5.3 years and their mean HIS work experience was 6.6 ± 1.7 years.

In the first round of Classic Delphi Technique, all requirements related to the domains of ‘communication service’, ‘system architecture’, ‘security service’, and ‘system response time’ assessed by the experts were finally approved. Regarding ‘system architecture’ requirements, one of the requirements did not gain the minimum score in the first round; hence, it was reassessed along with the proposed new requirements in second round of the Classic Delphi Technique and was then approved.Eventually, the list of technical HIS requirements was confirmed for the four domains containing 73 items with a mean of 3.6. These requirements existed in 68.9% of HISs implemented in the hospitals under study. The results of the Delphi technique and evaluation of technical HISs requirements are presented in Tables 1 to 5.

Table1. Mean score of technical requirements and HIS evaluation

Requirements		Delphi results	Evaluation results
Requirements		Mean	Yes	No	Total	Status
1	Communication service	3.49	102(63.8)	58(36.2)	160(100)	Good
2	System architecture	3.53	283(65.5)	149(34.5)	432(100)	Good
3	Service security	3.5	359(72.4)	137(27.6)	496(100)	Good
4	System response time	3.82	61(76.3)	19(23.8)	80(100)	Good
Total		3.6	805(68.9)	363(31.1)	1168(100)	Good

‘Communication service’ requirements including 10 items are shown in Table 2. Delphi score regarding the importance of ‘communication service’ was 3.49±0.38, and the assessed HIS met 63.8% of the ‘communication service’ requirements.

Table2. Mean score of ‘communication service’ requirements and HIS evaluation

	Requirements	Delphi results	Evaluation results
	Requirements	Mean	Yes	No	Total
1	Ability to receive and send information electronically between different departments of an hospital	3.78	14(87.5)	2(12.5)	16(100)
2	Ability to send and receive information from/to other software systems	3.73	12(75)	4(25)	16(100)
3	Ability to transfer information between different software versions	3.71	12(75)	4(25)	16(100)
4	Ability to use the standard protocol approved by the country's competent authorities for the exchange of patient records and the exchange of financial information	3.6	8(50)	8(50)	16(100)
5	Capability of simultaneous viewing of a file by multiple users	3.5	15(93.8)	1(6.2)	16(100)
6	Ability to access information of other components from other locations according to the level of access	3.5	16(100)	-	16(100)
7	Ability to register and modify orders in different parts of the hospital and access these stations with regards to security and access level	3.34	14(87.5)	2(12.5)	16(100)
8	System capability for calling developed required services	3.28	2(12.5)	14(87.5)	16(100)
9	Support for communication with software via fax, WORD, spreadsheet, e-mail and the Internet	3.26	6(37.5)	10(62.5)	16(100)
10	Ability to consult and communicate with doctors and specialists outside the hospital (audio-visual communication	3.18	3(18.8)	13(81.2)	16(100)
Total		3.49±0.38	102(63.8)	58(36.2)	160(100)

As presented in Table 3, ‘system architecture’ with 27 requirements and the mean score of 3.53±0.37 were confirmed, which met 65.5% of implemented HISs.

Table3. Mean score of ‘system architecture’ requirements and HIS evaluation

	Requirements	Delphi results	Evaluation results
	Requirements	Mean	Yes	No	Total
1	Ability to use standard databases	3.86	16(100)	-	16(100)
2	Ability to cope with standard Persian language	3.84	16(100)	-	16(100)
3	Ability to handle an unlimited number of clients	3.78	14(87.5)	2(12.5)	16(100)
4	Availability of standard templates for output and input information	3.76	13(81.2)	3(18.8)	16(100)
5	Capability of easy and standard installation of client and server	3.73	16(100)	-	16(100)
6	Capability of easy and automatic upgrading through server	3.73	14(87.5)	2(12.5)	16(100)
7	Ability to use standard programming languages	3.71	15(93.8)	1(6.2)	16(100)
8	Compatibility with Worldwide Standards for Operating System Server and Clients	3.71	11(68.8)	5(31.2)	16(100)
9	Ability to export the information to various types of statistical software programs	3.71	11(68.8)	5(31.2)	16(100)
10	Ability to generate custom reports	3.68	9(56.2)	7(43.8)	16(100)
11	Usability of Server's date and time instead of Client's date and time in the software	3.63	13(81.2)	3(18.8)	16(100)
12	Ability to execute routines as services instead of manual execution	3.55	12(75)	4(25)	16(100)
13	Ability to run under the network by Client/Server method	3.52	13(81.2)	3(18.8)	16(100)
14	Ability to have predicted and routine reports	3.52	14(87.5)	2(12.5)	16(100)
15	Ability to adopt an appropriate solution for server connection among different units	3.5	11(68.8)	5(31.2)	16(100)
16	Ability to use external devices and other devices in the system	3.5	15(93.8)	1(6.2)	16(100)
17	Ability to give independence to clients of specific operating systems and platforms	3.47	7(43.8)	9(56.2)	16(100)
18	Ability to use supported standards	3.47	8(50)	8(50)	16(100)
19	Reporting capabilities through Web Service	3.44	7(43.8)	9(56.2)	16(100)
20	Ability to provide all technical specifications, relationships among tables, ERD, routines and relationships between software classes in the form of UML and other technical features of the database in writing and based on the RUP methodology for large projects or XP for small projects	3.44	4(25)	12(75)	16(100)
21	Ability to record all information and procedures that can be changed in the database and avoid storing them in the program code.	3.39	9(56.2)	7(43.8)	16(100)
22	Availability of multilayer enterprise architecture in software design	3.34	6(37.5)	10(62.5)	16(100)
23	Ability to run on the Web	3.28	6(37.5)	10(62.5)	16(100)
24	Ability to use Commit and Roll Back Standards in using procedures	3.28	5(31.2)	11(68.8)	16(100)
25	Ability to register and edit information through the Web	3.23	4(25)	12(75)	16(100)
26	Ability to use open source tools in system design and production	3.07	6(37.5)	10(62.5)	16(100)
27	Visibility of database contents and non-coding information	3.02	8(50)	8(50)	16(100)
Total		3.53±0.37	283(65.5)	149(34.5)	432(100)

According to Table 4, ‘service security’ with 31 requirements and the mean score of 3.5±0.39 were approved, which was observed in 72.4% of the implemented HISs.

Table4. Mean score of ‘security service’ requirements and HIS evaluation

	Requirements	Delphi results	Evaluation results
	Requirements	Mean	Yes	No	Total
1	Automatic and periodical backup options	3.89	15(93.8)	1(6.2)	16(100)
2	Observation of all protection and security considerations for accessing the database on the network	3.86	15(93.8)	1(6.2)	16(100)
3	Ability to provide user identity by placing username and password according to user access level	3.84	16(100)	-	16(100)
4	Ability to provide access level according to layering of information to maintain valuable information	3.78	16(100)	-	16(100)
5	Security in web applications	3.73	6(37.5)	10(62.5)	16(100)
6	Logging user performance and reporting it to the system administrator, log manager	3.71	12(75)	4(25)	16(100)
7	Automatic retrieval of information whenever necessary	3.71	14(87.5)	2(12.5)	16(100)
8	Ability to equip servers and clients for the antivirus used by users	3.68	15(93.8)	1(6.2)	16(100)
9	Ability to provide a program for storing and archiving information electronically at specified intervals	3.68	10(62.5)	6(37.5)	16(100)
10	Lack of encryption display in the form of text	3.65	16(100)	-	16(100)
11	Supporting standard locking mechanism to prevent updates by unauthorized individuals	3.63	9(56.2)	7(43.8)	16(100)
12	Setting the password as text/number	3.6	12(75)	4(25)	16(100)
13	Ability to create a personal information file including user characteristics required to determine the level of ‘security service’	3.6	13(81.2)	3(18.8)	16(100)
14	Ability to define functional roles and relationships with access levels	3.6	14(87.5)	2(12.5)	16(100)
15	Ability to register and report all logins and logouts from software, as well as access to all features suitable for registration such as username, workstation (IP) and MAC	3.6	12(75)	4(25)	16(100)
16	Manual retrieval of information whenever necessary	3.55	15(93.8)	1(6.2)	16(100)
17	Ability to define specific and confidential information sections	3.55	11(68.8)	5(31.2)	16(100)
18	Ability to reset the password when using a password	3.5	15(93.8)	1(6.2)	16(100)
19	Application functionality in workstations under domain	3.47	14(87.5)	2(12.5)	16(100)
20	Lack of access to the database except for the interface	3.42	11(68.8)	5(31.2)	16(100)
21	Presence of remote monitoring and control technology	3.36	6(37.5)	10(62.5)	16(100)
22	Compatibility with hardware firewalls	3.34	12(75)	4(25)	16(100)
23	Ability to restrict user access to other operating system resources	3.28	13(81.2)	3(18.8)	16(100)
24	Manual backup options	3.28	16(100)	-	16(100)
25	Ability to support digital signature	3.23	2(12.5)	14(87.5)	16(100)
26	Lack of random port use	3.23	5(31.2)	11(68.8)	16(100)
27	Lack of need for local admins	3.21	13(81.2)	3(18.8)	16(100)
28	Authentication via domain	3.18	11(68.8)	5(31.2)	16(100)
29	Accessible to the system with any particular IP range and routing capability	3.15	6(37.5)	10(62.5)	16(100)
30	Ability to use name (as defined in DNS) and lack of dependence on the IP and computer name	3.15	9(56.2)	7(43.8)	16(100)
31	Support for Biosensor technology to logon	3.02	5(31.2)	11(68.8)	16(100)
Total		3.5±0.39	359(72.4)	137(27.6)	496(100)

As shown in Table 5, ‘system response time’ with 5 requirements and the mean score of 3.82±0.29 were confirmed by the experts, which was observed in 76.2% of the assessed HISs.

Table5. Mean score of ‘system response time’ requirements and HIS evaluation

	Requirements	Delphi results	Evaluation results
	Requirements	Mean	Yes	No	Total
1	Fast search capability in sections with massive amounts of information	3.86	11(68.8)	5(31.2)	16(100)
2	Easy and quick reporting	3.84	13(81.2)	3(18.8)	16(100)
3	Ability to respond within acceptable ‘system response time’ to user requests for specific operations	3.81	9(56.2)	7(43.8)	16(100)
4	Ability to access the system 24 hours a day without any interruption	3.81	16(100)	-	16(100)
5	Capability of performing within acceptable processing time	3.78	12(75)	4(25)	16(100)
Total		3.82±0.29	61(76.2)	19(23.8)	80(100)

Technical HIS requirements including 73 items categorized in four domains including ‘communication service’ (10 items), ‘system architecture’ (27 items), ‘security service’ (31 items), and ‘system response time’ (5 items) were approved by experts. Compliance rate of the requirements in the hospitals under study was considered as ‘good’ (68.9%).

‘Communication service’ is one of the domains of technical requirements confirmed by the experts. Requirements related to ‘communication service’ showed a compliance rate of 63.8% in the evaluated HISs, which is considered to be at a good level. However, compared to the other domains under study, this compliance rate was lower. Additionally, the standard protocol approved by the national healthcare authorities for patient information exchange was only met in half of the information systems of the research community. The National Coordination Office of Health Information Technology of America, appreciates the need for standards, making incentives to use standards and a credible environment for interoperability, sharing and use of electronic health information due to the fact that such standards can prove useful in design stage of the development of a new system[28, 29]. Another study on the HIS implementation difficulties indicated that poor integration of various systems is a potential source of problems [30].

In his study, Feko stated that HISs in Hungary are capable of communicating within hospitals. Nevertheless, the ability to inter-communication outside the hospital is limited [31]. Surveying the acceptability of health information technology in 7 industrial countries suggested that, despite the high number of EHR, they still lag behind the health information exchange [25]. Several other studies have pointed out that the level of interoperability among HISs is disappointingly low, and they have scored low in the assessments [32–34]. The lack of interoperability restricts care provider organizations to use product portfolio of a software supplier in a way that their data is stored in the supplier’s specific format and cannot be easily transferred to another system [35]. Ultimately, lack of interoperability among HISs results in an increased load of paper [36]. In a study, users believed that working with integrated systems would reduce working hours and increase work speed [6]. Not only is the capability of system information exchange effective in indirect nursing care[37], but it also leads to reduced patients re-admission[38]. Failure to exchange information among various HISs imposes financial burdens on hospitals and causes failure to refunding the costs to Healthcare institutions[39]. Furthermore, information exchange among these systems helps to reduce the cost of transmitting laboratory reports, imaging and clinical communication among healthcare providers [40]. As Walker et al. (2005) stated, investing in Electronic Medical Records (EMR) interoperability and health information exchange could save $77 annually [41]. A unified and focused EHR approach for each patient means to have regional Electronic Patient Records(EPRs) that provides a degree of internal exchange capability[42], although the main features of the fourth and current HIS generation - integration of HISs—is known as integrity with other systems[6]. The specific framework for ‘communication service’ requirements of HISs including the standards of information exchange at system design phase need to be given serious attention. What follows can highlight this importance, a) considering the importance of information exchange capability in information systems, b) the need to develop interoperable systems, c) prevention of organizational dependence on the products of a particular company, d) the impact of lack of data integrity on treatment and cost addition, e) the heterogeneous software forests that does not meet the goal of creating and implementing an EHR.

‘System architecture’ is another important domain of technical requirements. Based on the findings, compliance with the requirements of ‘system architecture’ in the assessed HISs was proper (65.5%). However, it has achieved a third rank in comparison to the other domains of technical requirements. In software development, ‘system architecture’ determines system development model, environment development, and system development tools [43]. Multiple distributed systems, developed in various programming languages, demand more mechanisms for practical communication in engineering perspective [44]. In this regard, service-oriented architecture is a tool for defining IT infrastructures that allow various software programs to exchange data and cooperate in the process of business, regardless of the types of operating systems or programming languages through which software programs are designed. Moreover, the messaging standard enables diverse healthcare software programs to exchange office and clinical data and run it on the web [45]. Systems that are based on varied platforms and programming languages appear to create numerous heterogeneous systems in an organization, which makes it difficult to develop HIS projects. Hence, the possibility of using open source tools, web-based implementation, and supported standards is part of the framework of ‘system architecture’ requirements which are helpful in future software development.

‘Security service’ is also addressed as another domain of technical requirements, which has been well met in evaluating information systems of the research community and can be regarded as good (72.4%). Security issues are among the hindering factors of using and implementing information systems in the healthcare sector [46]. Furthermore, several studies have highlighted security concerns of EHRs [47–49]. In other studies, the level of technical security in some health centers was reported as strong and in some hospitals as moderate [50]. In yet other studies, more than half of respondents expressed their health security data at a good/moderate level [33, 51]. Previous research shows neither a specific policy for patient access to information nor punishment for unauthorized access to information. While each system user has a specific password, there is usually no expiration date for these passwords, and thus, system users can access them with no time limitation [50]. The system must have security mechanisms for controlling user access in terms of tasks or classified access [52]. An effective access control system ensures that system users cannot access system resources unless they are permitted to do so [7]. On the other hand, HISs should provide easy access to healthcare information at the caring institution [53]. A vast number of user-friendly techniques including setting passwords, biometric techniques, smart cards, and certifications are widely used to guarantee data confidentiality and user validation [54]. Typically, these systems attempt to prevent illegal operations before they occur [55]. In a study investigating the priority of nursing data security requirements in EHRs, making a backup was introduced as the highest priority of majority of IT experts [56]. Providing encrypted, incremental backups of information is one of the security measures for EHR protection [57]. Considering the fact that patient data security management using the HIS influences care quality, the rights of patients and healthcare professionals and their working practices[58], patients may conceal their information due to lack of trust in the security of HISs, which is health-damaging[59]. Thus, recognizing security features and privacy in HISs is of great importance and, in the event of facing such risks, some data protection measures need to be taken [60]. Hospitals should follow a standardized set of instructions to enhance information security [61, 62]. The level of security seems to vary from one study to another. Regarding the important role of data in providing patient care, data backups and data access control are known as the major security concerns of the systems. Therefore, a security framework which guarantees system security and makes information access easy by authorized individuals is required where HISs are being implemented.

Another domain of technical HIS requirements approved by the experts is ‘system response time’. Based on our findings, ‘system response time’ was at a good level (76.3%) in the HIS evaluation. ‘System response time’ is one of the major technical challenges of the HIS [30, 63]. Numerous studies have highlighted system response dissatisfaction, and referred to it as an obstacle for EHR application and the main reason for its abandonment by users [63–65]. In organizations which are heavily dependent on computerized systems in patient care, the downtime should be 0% or a little above 0. Yet, in these organizations, business continuity procedures should be in place to ensure safety and patient care continuity [66]. Therefore, one of the general technical aspects of the HIS is timely system access at a high speed, which is identified as an important factor in the efficiency of HISs [52, 53]. Low ‘system response time’ reduces the chances of system acceptance by users and successful implementation of the system [67]. Therefore, in order to increase system efficiency and consequently user satisfaction, it is recommended to highlight the importance of ‘system response time’ requirements while choosing a system.

Technical HIS requirements were designed with 73 items in four domains including ‘communication service’, ‘system architecture’, ‘security service’, and ‘system response time’. These requirements can be used in the lifecycle of information systems while customers attempt to choose systems so as to meet minimum user requirements for using HISs. These requirements can help designers and developers of HISs to adapt the software program to the user needs. Furthermore, HIS evaluation of the research community suggests that, in spite of a good score in the evaluation, in technical HIS requirements, the domains of ‘communication service’ and then ‘system architecture’ were weaker than the other ones. Hospitals are constantly developing their HISs, which leads to the emergence of many heterogeneous systems. Integration of these systems is also difficult to achieve since each one is designed and implemented in accordance with its own principles. In addition, patient data is stored in these systems and their transfer to new systems is not an easy task. Therefore, this can be a major challenge and obstacle in establishing interoperability between different systems for creating EHRs and developing systems in accordance with changes and needs of organizations and users.

IT: Information Technology

HIS: Hospital Information System

EHRs: Electronic Health Records

RFP: Request for Proposal

FGD: Focus Group Discussion

EPR: Electronic Patient Record

EMR: Electronic Medical Record

Ethics approval and consent to participate

Ethical approval was elicited from the 102th meeting of the Ethical Committee at the Kashan University of Medical Sciences (06 Feb 2013). All participants were invited verbally to take part in the study. For those who agreed to participate, a signed written informed consent form was obtained.

Consent for publication

Not applicable.

Availability of data and material

All data generated or analysed during this study are included in this article.

Competing interests

The authors declare that they have no competing interests.

Funding

This work was supported by Kashan University Medical Research Council [grant number 91120]. This funder paid for those who contributed to project management and data collection.This research did not receive any specific grant from funding agencies in the public, commercial, or not-for-profit sectors.

Authors’ contributions

MF made substantial contributions to the conception, design and acquisition of funding. MSJ and RDB participated in data collection and performed the statistical analysis. ZM and EN contributed to manuscript drafting, revision, and approval, and MF was responsible for the general supervision of the research group. All authors read and approved the final manuscript.

Acknowledgments

We sincerely appreciate the respected Vice-Chancellor of Kashan University of Medical Sciences and the cooperation of the management and personnel of the information technology unit of the hospitals and Medical Science universities where the study was conducted.

1.Farzandipur M. Factors affecting successful implementation of hospital information systems. Acta Inform Med. 2016; 24(1):51.

2.Negash S, Musa P, Vogel D, Sahay S. Healthcare information technology for development: improvements in people’s lives through innovations in the uses of technologies. Inform Thecnol Dev. 2018;24(2):189–197.

3.Haux R. Health information systems–past, present, future. Int J Med Inform. 2006;75(3–4):268–281.

4.Toromanovic S, Hasanovic E, Masic I. Nursing information systems. Mater sociomed. 2010; 22(3):168.

5.Bates DW, Cohen M, Leape LL, Overhage JM, Shabot MM, Sheridan T. Reducing the frequency of errors in medicine using information technology. J Am Med Inform Assoc 2001; 8(4):299–308.

6.Sagiroglu O, Ozturan M. Implementation difficulties of hospital information systems. Inform Tec J. 2006; 5(5):892–899.

7.Malliarou M, Zyga S. Advantages of information systems in health services. Choregia. 2009; 5(2):43–53.

8.Polack PJ. Why some EMR projects fail. Ophthalmology Management. 2009; 13(8):64.

9.Hillestad R, Bigelow J, Bower A, Girosi F, Meili R, Scoville R, Taylor R. Can electronic medical record systems transform health care? Potential health benefits, savings, and costs. Health Aff(Millwood). 2005; 24(5):1103–1117.

10.Zandieh SO, Yoon-Flannery K, Kuperman GJ, Langsam DJ, Hyman D, Kaushal R. Challenges to EHR implementation in electronic-versus paper-based office practices. J Gen Intern Med. 2008; 23(6):755–761.

11.Garavand A, Samadbeik M, Kafashi M, Abhari S. The Identification and Classification of Deployment Challenges Related to Electronic Health Records: A Review Article. Shiraz E-Med J. 2016; 17(2):e33304.

12.Hebda T, Czar P, Mascara C. Handbook of informatics for nurses and health care professionals.3rd ed. Pearson Prentice Hall; 2005.

13.Sequist TD, Cullen T, Hays H, Taualii MM, Simon SR, Bates DW. Implementation and use of an electronic health record within the Indian Health Service. J Am Med Inform Assoc. 2007; 14(2):191–197.

14.Kaplan B, Harris-Salamone KD. Health IT success and failure: recommendations from literature and an AMIA workshop. J Am Med Inform Assoc. 2009; 16(3):291–299.

15.Blumenthal D. Implementation of the federal health information technology initiative. N Engl J Med. 2011; 365(25):2426–2431.

16.Al-shawi M. CCDE Study Guide. Cisco Press; 2015.

17.Ojo AI, Popoola SO. Some correlates of electronic health information management system success in Nigerian teaching hospitals. Biomed Inform Insights. 2015; 7:1–9.

18.Mirani N, Ayatollahi H, Haghani H. A survey on barriers to the development and adoption of electronic health records in Iran. Journal of Health Administration (JHA) 2013, 15(50):65–75.

19.Farzandipour M, Meidani Z, Gilasi H, Dehghan R. Evaluation of key capabilities for hospital information system: A milestone for meaningful use of information technology. Ann Trop Med Public Health. 2017; 10(6):1579–1586.

20.Fadhil NFM, Jusop M, Abdullah AA. Hospital Information System (HIS) Implementation In A Public Hospital: A Case Study From Malaysia. Far East J Psychol Bus. 2012; 8(1):1–11.

21.Garavand A, Samadbeik M, Asadi H, Abhari S. Readiness of Shiraz teaching hospitals to implement Electronic Medical Record (EMR). Journal of Health Management and Informatics(JHMI). 2016; 3(3):82–88.

22.Safdari R, Ghazisaeidi M, Jebraeily M. Electronic health records: Critical success factors in implementation. Acta Inform Med. 2015; 23(2):102–104.

23.Amiresmaili M, Zarei L, Sheibani E, Arabpur A. Evaluation of the indicators of Hospital information system. Health Information Management. 2013;10(1):1–13.

24.Farzandipour M, Ahmadi M, Sadoughi F. Adopting confidentiality principles for electronic health records in Iran: a Delphi study. J Med Syst. 2011; 35(3):333–343.

25.Jha AK, Doolan D, Grandt D, Scott T, Bates DW. The use of health information technology in seven nations. Int J Med Inform. 2008; 77(12):848–854.

26.Farzandipour M, Meidani Z, Riazi H, Sadeqi Jabali M. Task-specific usability requirements of electronic medical records systems: Lessons learned from a national survey of end-users. Inform Health Soc Care. 2018;43(3);280–299.

27.Keeney S, McKenna H, Hasson F. The Delphi technique in nursing and health research. John Wiley & Sons; 2010.

28.Huang Q, Yin Q. Study on Electronic Health Record and its Implementation [Master Thesis]. Department Design and Computer Science, School of Health and Society,Kristianstad University; 2012.

29.Office of the National Coordinator for Health Information Technology. Report to Congress on Health Information Blocking. Department of Health and Human Services, Washington, DC; 2015.

30.Khalifa M. Technical and human challenges of implementing hospital information systems in Saudi Arabia. J Health Inform Dev Ctries. 2014; 8(1):12–25.

31.Aggod-Feko A. The Role of Hospital Information Systems in Successful Health and eHealth Services in Hungary and in International Dimension. LESIJ-Lex ET Scientia International Journal. 2010; 17(1):456–466.

32.Carr CD, Moore SM. IHE: a model for driving adoption of standards. Comput Med Imaging Graph. 2003; 27(2):137–146.

33.Kang’a S, Puttkammer N, Wanyee S, Kimanga D, Madrano J, Muthee V, et al. A national standards-based assessment on functionality of electronic medical records systems used in Kenyan public-Sector health facilities. Int J Med Inform. 2017; 97:68–75.

34.Shah GH, Leider JP, Luo H, Kaur R. Interoperability of information systems managed and used by the local health departments. J Public Health Manag Pract. 2016; 22 Suppl 6:S34-S43.

35.Handel DA, Wears RL, Nathanson LA, Pines JM. Using information technology to improve the quality and safety of emergency care. Acad Emerg Med. 2011;18(6):e45-e51.

36.Brailer DJ. Interoperability: The Key To The Future Health Care System. Health Aff (Millwood). 2005; 24 Suppl 1:W5–19-W15–21.

37.Farzandipour M, Meidani Z, Riazi H, Jabali MS. Nursing information systems requirements: a milestone for patient outcome and patient safety improvement.: Comput Inform Nurs. 2016; 34(12):601–612.

38.Estes SL, Kelemen A, Liang Y, Constanine DR. Electronic Health Record Vendors in Reducing Hospital Readmission Rates: Promoting Interoperability. Comput Inform Nurs; 2016, 1(2):6–14.

39.Khajouei R, Abbasi R, Mirzaee M. Errors and causes of communication failures from hospital information systems to electronic health record: A record-review study. Int J Med Inform. 2018; 119(2018):47–53.

40.Sprivulis P, Walker J, Johnston D, Pan E, Adler-Milstein J, Middleton B, Bates DW. The economic benefits of health information exchange interoperability for Australia. Aust Health Rev. 2007; 31(4):531–539.

41.Walker J, Pan E, Johnston D, Adler-Milstein J, Bates DW, Middleton B. The Value Of Health Care Information Exchange And Interoperability. Health Aff (Millwood). 2005;24 Suppl Web Exclusives:W5–10-W5–18.

42.Wainer J, Campos C, Salinas M, Sigulem D. Security requirements for a lifelong electronic health record system: An opinion. Open Med Inform J. 2008; 2:160–165.

43.Zhan X, Liu X. Design and Implementation of Clinic Appointment Registration System. Engineering. 2013; 5(10):527–529.

44.Kitsiou S, Manthou V, Vlachopoulou M. A framework for the evaluation of integration technology approaches in healthcare. Proceedings of the IEEE in Information and Communication Technologies in Bioinformatics. Ioannina, Greece; 2006:28–30.

45.Yang T-H, Sun YS, Lai F. A scalable healthcare information system based on a service-oriented architecture. J Med Syst. 2011; 35(3):391–407.

46.Tieu L, Sarkar U, Schillinger D, Ralston JD, Ratanawongsa N, Pasick R, Lyles CR.Barriers and facilitators to online portal use among patients and caregivers in a safety net health care system: a qualitative study. J Med Intern Res. 2015; 17(12):e275.

47.Chhanabhai P, Holt A. Consumers are ready to accept the transition to online and electronic records if they can be assured of the security measures. MedGenMed. 2007; 9(1):8.

48. Kirchner H, Prokosch H, Dudeck J, Jöckel K, Lehmacher W, Gesenhues S. Querschnittsbefragung von 8.000 BARMER-Versicherten zu Erwartungen und Einsatz einer elektronischen Gesundheitsakte [Survey on expectations and implementation of an electronic health record, in German]. Proceedings of the Annual Meeting of the GMDS, Essen, September 7–10, 2009.

49.Zurita L, Nøhr C. Patient opinion-EHR assessment from the users perspective. Stud Health Technol Inform. 2004; 107(Pt2):1333–1336.

50.Mehraeen E, Ayatollahi H, Ahmadi M. Health Information Security in Hospitals: the Application of Security Safeguards. Acta Inform Med. 2016; 24(1):47–50.

51.Yeboah ZS. The role of information and communication technology in health information system of the Afigya Sekyere District, Ghana [MSc Thesis]. Department of Community Health, School of Medical Sciences, College of Health Sciences, Kwame Nkrumah University of Science and Technology; 2008.

52.Heu, Centre For Health Economics. Technical Specifications, National Health Insurance Information System. The University of the West Indies; 2011.

53.Mohan J, Yaacob RRR. The Malaysian Telehealth Flagship Application: a national approach to health data protection and utilisation and consumer rights. Int J Med Inform. 2004; 73(3):217–227.

54.Chousiadis C, Mavridis I, Pangalos G. An authentication architecture for healthcare information systems. Health Informt J. 2002; 8(4):199–204.

55.Dekker MAC, Etalle S. Audit-based access control for electronic health records. Electronic Notes in Theoretical Computer Science (ENTCS). 2007; 168:221–236.

56.Samadbeik M, Gorzin Z, Khoshkam M, Roudbari M. Managing the security of nursing data in the electronic health record. Acta Inform Med. 2015; 23(1):39–43.

57.Sittig DF, Belmont E, Singh H. Improving the safety of health information technology requires shared responsibility: It is time we all step up. Healthc(Amst). 2018;6(1):7–12.

58.Harman LB, Flite CA, Bond K. Electronic health records: privacy, confidentiality, and security. Virtual Mentor. 2012; 14(9):712–9.

59.Ozair FF, Jamshed N, Sharma A, Aggarwal P. Ethical issues in electronic health records: a general overview. Perspec Clin Res. 2015; 6(2):73–6.

60.Fernández-Alemán JL, Señor IC, Lozoya PÁO, Toval A. Security and privacy in electronic health records: A systematic literature review. J Biomed Inform. 2013; 46(3):541–562.

61.Cavalli E, Mattasoglio A, Pinciroli F, Spaggiari P. Information security concepts and practices: the case of a provincial multi-specialty hospital. Int J Med Inform. 2004; 73(3):297–303.

62.Deshmukh P, Croasdell D. HIPAA: Privacy and security in health care networks. Information Ethics: Privacy and intellectual property. IGI Global; 2005: 219–238. DOI: 10.4018/978–1–59140–491–0.ch013

63.Hier DB, Rothschild A, LeMaistre A, Keeler J. Differing faculty and housestaff acceptance of an electronic health record. Int J Med Inform. 2005; 74(7):657–662.

64.Cohen JF, Coleman E, Kangethe MJ. An importance-performance analysis of hospital information system attributes: A nurses’ perspective. Int J Med Inform. 2016; 86:82–90.

65.Kim HH, Cho KW, Kim HS, Kim JS, Kim JH, Han SP, et al. New integrated information system for pusan national university hospital. Healthc Inform Res.2011; 17(1):67–75.

66.Wager KA, Lee FW, Glaser JP. Health care information systems: a practical approach for health care management.4rd ed. John Wiley & Sons; 2017.

67.Berg M. Implementing information systems in health care organizations: myths and challenges. Int J Med Inform. 2001; 64(2–3):143–156.

Download PDF

Journal Publication

published 03 Apr, 2020

Read the published version in BMC Medical Informatics and Decision Making →

Editorial decision: Major revision
05 Nov, 2019
Review #2 received at journal
04 Nov, 2019
Review #1 received at journal
10 Oct, 2019
Reviewer #2 agreed at journal
09 Oct, 2019
Reviewer #1 agreed at journal
24 Sep, 2019
Reviewers invited by journal
13 Sep, 2019
Submission checks completed at journal
09 Sep, 2019
Editor assigned by journal
06 Sep, 2019
Editor invited by journal
05 Sep, 2019
First submitted to journal
04 Sep, 2019

You are reading this older preprint version

Read the latest preprint version →

Designing a Framework of Technical Hospital Information Systems Requirements and Evaluating the Systems Implemented through this Framework

Status:

Journal Publication

Version 1

Abstract

Background

MEthods

First Part: Designing technical HIS requirements

First Stage: Focus Group Discussion

Second Stage: Modified Delphi Technique

Third Stage: Classic Delphi Technique

Second Part: Evaluating HISs

Ethical Considerations

REsults

Discussion

Conclusion

List of Abbreviations

Declarations

Ethics approval and consent to participate

Consent for publication

Availability of data and material

Competing interests

Funding

Authors’ contributions

Acknowledgments

References

Status:

Journal Publication

Version 1