Background

Healthcare relies on health information systems (HISs) to support various care processes and receive reimbursement for the care provided. Examples of functionalities are financial management, daily reporting, and medication management [1,2,3]. Unfortunately, current HISs still have some drawbacks. For example, lack of interoperability resulting in care professionals having difficulty communicating files [4, 5]. Other studies on HISs reported problems with poor interface design [6, 7], poor security [8, 9], missing features [10, 11], lack of professional support [12, 13], limited use [6, 14], and low data quality [1, 15]. Most of these problems occur when relevant standards, procedures, and guidelines are not followed effectively.

Because HISs consist of many interrelated software modules that should communicate, coordinate, and evolve over time [16], the software architecture is critical in HIS design. Bass et al. [17] define the software architecture of a program or a computing system as: “The structure of the system, which comprises software elements, the externally visible properties of those elements, and the relationships among them.” The software architecture supports communication on the system, guides design decisions, informs maintenance, and facilitates architectural analysis of the overall system [18].

There are two main approaches for software architecture design: informal and formal. The back-draw of informal software architecture design relying on boxes-and-lines models, is that such a representation of the system is hard to understand because it is not standardized and does not follow a particular language. The formal approach follows the well-established ISO/ISEC/IEEE 42010 standard [19], which ensures unambiguous communication.

A particular type of architecture that is generic and can help design specific software architectures for multiple software systems is the Reference Architecture (RA). An RA is a generic design that can be used to derive specific Application Architecture (AAs) based on the identified stakeholders’ concerns, more quickly and with higher quality [20, 21]. The RA serves as an architecture blueprint for future software architects and should provide a standardized lexicon, taxonomy, and (architectural) vision [21, 22] . In the (grey) literature, several RA designs have been proposed for HISs [23,24,25,26,27,28,29,30]. More information on these RAs is available in the Related Work Section.

In practice, the derivation of the AAs from RAs is not trivial for two basic reasons. First of all, some of the proposed RAs do not focus on HIS in general, but only address the hospital sub-domain [29, 31]. Secondly, the proposed RAs do not seem to follow a proper architecture documentation guideline. [26,27,28, 30]. Furthermore, these RAs are far from complete, which hampers the design of the required AAs.

The problems stakeholders experience with HISs require more clarity in healthcare’s complex digital landscape, a clarity that RA provides. Therefore, the objective of this article is to develop an RA for HISs following well-established architecture design methods. The RA is dedicated to the healthcare domain and is represented using the software architecture viewpoints. To illustrate and evaluate the RA, an AA was derived in a case study on a Japanese hospital. The paper concludes with lessons learned and a discussion of the proposed RA.

Methods

Research questions

The following research questions were identified:

  • RQ1: What are the stakeholders and their concerns related to HISs?

  • RQ2: What is a feasible Reference Architecture for HISs?

  • RQ3: Does the Reference Architecture allow for the derivation of a specific Application Architecture?

Our approach to these questions is depicted in Fig. 1. Domain analysis is defined as the systematic activity for deriving and storing domain knowledge to support the engineering design process [32]. Domain analysis consists of domain scoping and domain modeling. Domain scoping identifies the domain’s scope and the necessary knowledge sources to derive the key concepts [33, 34]. Domain modeling aims at representing the domain knowledge in a reusable format.

Fig. 1
figure 1

The adopted approach for the RA design. Numbers inside tasks represent corresponding section numbers

Full size image

Based on the domain analysis, we choose the relevant viewpoints [35] for our architecture design step. We continued with a case study, to evaluate the RA’s suitability for deriving an AA.

Method for deriving and evaluating application architecture

The RA can be used as a starting point for creating an AA [20]. The AA is described in this study as the software model of a specific application displayed through a combination of architectural views. To begin, an RA was created.

Fig. 2
figure 2

Methods used for deriving the AA. Each view from the RA will lead to a view in the AA, Adopted from [36]

Full size image

The view of the RA was used to generate the corresponding view of the AA, as seen in Fig. 2. Figure 3 depicts the procedure followed for this derivation. For each view of the reference architecture, this approach was used; the application’s necessary entities were first listed; then entities from the corresponding RA view were chosen based on the entity from the application. The required entity is reused if it could be identified in the RA; otherwise, a new entity was introduced to the AA. If the entity is located in the RA, it was examined to see if it can be reused in its original state or whether it has to be changed. If the names of the modules were the same or if the modules were interchangeable (e.g., financial management vs. economic management [37]), the modules were considered entirely reusable. The module may be composed or decomposed if it is not reusable in its present state and thus had to be modified. In a composition, multiple RA modules were merged into a single AA module. As an example of a composition, a data transfer module and data collection module could be merged into a data processing module (see [38]). After the decomposition, an RA module is broken down into several smaller modules in the AA. Finally, the reusability of the RA’s entities was explored and the RA’s usability (to derive the AA) considered. Concluding, making an AA for a particular settings (i.e. case study), serves as validation for the RA [20, 36].

Fig. 3
figure 3

Approach followed in building AA from RA Adapted from Tummers et al. [36]

Full size image

This approach as described above and depicted in Fig. 3 , has been used in a variety of other domains such as agriculture [36], supply chains [39], and smart warehouses [33].

Results

Domain analysis

To scope and model the domain, we performed a systematic literature review [40] to identify papers in which HISs, their domains, stakeholders and, concerns and features were described. This resulted in a set of 11 papers [7, 10, 41,42,43,44,45,46,47,48,49].

Domain scoping

HISs cover a wide range of sub-domains within healthcare. Many HIS papers focus on the hospital sub-domain [7, 42, 47], others focus on the primary care [10], pediatrics [43], outpatient care [45, 47], and diabetes care [49]. The most common stakeholders and their concerns for HISs development are presented in Table 1. While some stakeholders are generic for HISs, such as the patient, other stakeholders are more domain-specific, such as the Laboratory.

Table 1 Key stakeholders (in alphabetical order) and their main concerns
Full size table

Domain modeling

To model the features of the HIS domain, feature modeling was adopted. A feature model represents the domain knowledge and desired system by distinguishing common, alternative, and optional(e.g., sub-domain specific) features of the system, and the interdependencies amongst these features [50]. The feature is defined as “a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or system” [51]. Sub-features of a more general feature are shown under the most general feature in a tree-shaped model [51]. Our feature model for the HIS is presented in Fig. 4 and is based on the features mentioned in the literature.

Fig. 4
figure 4

A downsized version of the Feature model for HISs. Numbers on the right-hand side of the features represent the number of sub-features not shown

Full size image

We split the full set of features into six main features (Middle column of Fig. 4). The Generic Management Information System (MIS) feature contains non-domain-specific features. The Data management feature contains features related to the management of data and data-driven decision-making by care professionals. Medication management and Patient monitoring are typical HIS features. Planning & scheduling is a feature mainly used by secretaries and administrative staff. Last, but certainly not least, the Security feature must ensure the system’s resilience and protection of its data.

Architecture design

In the next section, the selected viewpoints were used for designing the RA are described. In the subsequent sections, the HIS RA views were built from these four viewpoints.

Selection of views

Although the HIS’s main purpose is to assist in the current daily operations, it should also be flexible and adaptable to facilitate different long-term visions [16, 52]. To do so, the RA needs to cover all features of the feature diagram in Fig. 4. The RA should also cater to users in all different sub-domains of healthcare and facilitate tailoring to local needs. After all, a hospital HIS needs to meet different demands than a general practitioner’s HIS and thus, will have different architectural decompositions.

For modeling the RA, we adopted the Views & Beyond (V&B) approach [35]. This approach consists of selecting out of 17 predefined viewpoints the ones of interest to certain stakeholders. The four viewpoints of particular interest to key stakeholders in the healthcare domain selected for modeling the HIS RA are the context diagram, decomposition view, layered view, and deployment view.

Context diagram

The context view of a system contains the entities that are outside the system’s scope but have a direct relation with the system [53]. The context diagram represents the context view and shows the system boundaries, environment, and the entities it communicates with [54]. The reference context diagram for the HIS is presented in Fig. 5.

Fig. 5
figure 5

The reference context diagram. Only the interactions considered the most important are shown

Full size image

The external entities and their communications with the HIS were based on the stakeholders and their concerns from Table 1. Six external entities are considered obligatory: the HIS cannot function without them. The optional entities can be absent in simpler HISs such as automated data sources or are (sub)domain-specific, such as the laboratory. Besides, some (sub)domains may require specific entities that are not shown in the reference context diagram. Many entities have two-way communication with the HIS, meaning that the HIS communicates with the entity and vice versa. External entities with a one-way communication with the HIS, are rarer. For example, a governmental organization can receive reports from the HIS, but this organization has no authorization to access the HIS data. We only describe one type of communication per interaction due to space limitations, in practice, there are many more possibilities.

Decomposition view

The decomposition shows how a system can be decomposed into multiple (sub)modules and how they relate to one another (parent-child). This view often is the basis for HIS design, development, and system documentation [55]. The decomposition view helps to check for the presence of the required modules for all stakeholders. The HIS RA decomposition view consists of six modules with 34 sub-modules, see Fig. 6.

The first module is Medication management, containing sub-modules related to medication handling, distribution, and safety monitoring. The second module is Patient monitoring and contains sub-modules related to the assessment, admission, discharge, status, and referrals of patients, and is input for the electronic health record. The Patient monitoring module also contains a sub-module labeled Patient portal in which the patient can check his/her files. The Security module with the sub-modules Authentication, Authorization, and Security mechanisms must ensure the privacy and security of the HIS and its data. Module number four is Planning and scheduling, with sub-modules used by various stakeholders to ensure proper care coordination. The Generic MIS module is not healthcare specific. Its sub-modules are important to keep track of assets, such as staff and inventory, to provide means for organization-wide communication, quality control, and financial affairs. Often the features from the generic MIS module can be found in so-called enterprise resource planning (ERP) systems. These systems are business management system solutions which are used for managing, automating, and integrating all the business functions within an organization [56,57,58]. These five modules generate data, which needs management. This happens in the Data management module, which has sub-modules to ensure proper import, sharing, analysis, and data search.

Figure 6 shows all described modules and sub-modules of the RA for HIS. A specific Application Architecture (AA) consists of a selection of these modules tailored to the stakeholders’ requirements.

Fig. 6
figure 6

The reference decomposition view of the HIS

Full size image

Layered view

The layered view reflects the software modules’ allocation into different layers, based on a unidirectional “allowed to use” relationship between the layers Clements et al. [35]. We decided to base our layered view on the standard of enterprise software systems because of its flexibility (Fig. 7). Starting at the top, the layered view consists of a presentation layer with a User Interface (UI). The presentation layer relies on the business logic layer that determines how data are created, stored, and processed. The business logic layer contains the Planning and scheduling, Generic MIS, Patient monitoring, and Medication management modules from the decomposition view (Fig. 6). These four modules, the backbone of any HIS, generate and use data from the Data management layer. The Data management layer contains sub-modules to simplify access to the data. To provide overall HIS security, a vertical layer connected to all three horizontal layers was added. This Security layer contains the modules: Authentication, Security mechanisms, and Authorization for safety and security at all system layers.

Fig. 7
figure 7

The reference layered view for the HIS

Full size image

Deployment view

In the deployment view, software modules are allocated to the hardware entities on which they are executed. This view is useful for analyzing the performance, availability, reliability, and security aspects of the system [35]. Due to the vast diversity of HISs, we decided to develop a generic deployment view that can represent many of HISs across care domains

The deployment view (Fig. 8) shows one or more clients and zero or more servers. If there is a client only, and no server, the deployment is a standalone desktop application or a thick-client with all modules on the client-side. A client-server application consists of at least one server and multiple clients, for example, thin clients with modules located on one or multiple servers. Finally, a system with multiple clients and multiple servers that communicate using cloud computing technology is cloud-based.

A system will most likely have a back-up server in case the original server goes down, but a combination of other types of servers is also possible. These other types of servers could include load balancing servers to allow for big data analytics, as well as application servers, web servers, and database servers. The RA deployment view also provides space for a web-based application. In that case, only an internet browser is required on the client-side with which the end-user can use the HIS. The server is often provided by the software supplier, which contains the modules to host the web page and store the data.

Depending on the specific requirements the allocation of the modules as identified in the decomposition view can be allocated in various different ways over the selected nodes in the deployment view.

Fig. 8
figure 8

The reference deployment view of the HIS

Full size image

Case study Chiba University Hospital

This study’s primary objective was to propose and evaluate the RA. We decided to base the illustration and evaluation on a case study from the literature, as no site visits were possible due to the COVID-19 pandemic. For our case study, we used the well-detailed article by Jahn et al. [59] in which they compare a Japanese and German hospital HIS using the three-layer graph-based meta-model (\(3\hbox {LGM}^{2}\)) [31]. When presented and inspected visually, the \(3\hbox {LGM}^{2}\) model combines the UML decomposition view, uses view, and layered view.

Our case study was done by developing an AA. for the Japanese Chiba University Hospital (CUH) based on Jahn et al. [59]. Figure 3 shows the approach followed to build the AA.

Feature diagram

The 104 modules of the CUH model in Jahn et al. [59] (page 6 Fig. 5) were mapped onto the features from our feature module (Fig. 4). We added 47 sub-features to meet the level of detail presented in Jahn et al. [59]. Interestingly, Jahn et al. [59] listed more detailed Patient monitoring and Generic MISs features, which we included as sub-features in Additional file 1: Fig. 1. In contrast, our RA was more detailed concerning the other HIS features.

Context diagram

Although the stakeholders of the HISs are not explicitly mentioned in Jahn et al. [59], we were able to make the application context diagram based on mentioned systems such as a Laboratory Information Systems and a Pharmacy Department System. The stakeholders and other entities of such systems combined with the obligatory entities and interactions from Fig. 5, provided the application context diagram. There was no need to add extra external entities (see Fig. 2 in the Additional file 1). We used 12 out of 15 (80%) entities from the RA context diagram.

Decomposition view

The decomposition view extracted from Jahn et al. [59] is presented in Additional file 1: Fig. 3. Despite slightly different wording in the labels of (sub)modules, we could make the decomposition view, which listed 104 modules from the feature model. Seven sub-modules from our RA were not found in the Japanese HIS and removed from the application decomposition view. Therefore, we utilized 27 out of 34 modules from the RA decomposition view, resulting in a re-use of 79%.

Layered view

Although the authors used the term “layers” differently than we do, the provided information allowed us to derive the layered view using our own design choices. The result was the same as depicted in Fig. 7 above.

Deployment view

Jahn et al. [59] provide limited information about the CUH HIS deployment, but it does show the CUH databases. From this information, we inferred the deployment situation at the hospital. The deployment view is available in Fig. 9.

Fig. 9
figure 9

Deployment view for the Chiba University Hospital based on Jahn et al. [59]

Full size image

As discussed above and shown in the Additional file 1, we could successfully derive an AA for the CUH case from our RA. Making the views for the case study took us about two days (16 h). Based on this case study, we made some minor changes to our RA, which were already included in Figs. 4, 6, and 7.

Discussion

To the best of our knowledge, this is the first RA for the health care domain built using standard architecture design approaches from the software architecture community. In this discussion, we critically reflect on our results and compare this study with related work.

Critical reflection on the results

For the domain analysis, we relied on scientific articles. A more extended data collection from grey literature or expert interviews might have yielded different input for the viewpoint selection. We believe that the scientific articles provided a factual basis for the viewpoints because of their diversity across care domains, and, indeed, our case study did not suggest otherwise.

Based on the domain analysis, we identified 15 key stakeholders for HISs because of their relevance to almost all HISs. The domain was modeled with the feature diagram, which provided a broad overview of the different features demanded for HISs. The feature diagram included the most relevant features and, when needed could be extended with additional (sub)features, as illustrated in the case study section. This allows the feature model to evolve with the changing health care domain.

Based on the key stakeholders’ concerns and input from the domain analysis, four viewpoints were selected to model the RA. Together, these viewpoints gave a broad and solid overview of HISs. The Context Diagram and Decomposition View showed the architecture from the stakeholders’ perspective, the Layered and Deployment View provided a standardized technical representation of HISs. The Deployment View (Fig. 8) was modeled generically to allow for various deployment alternatives, as illustrated in the case study (Fig. 9).

In current practice, the modules described in the decomposition view are often implemented by a combination of systems. In a hospital, for example, a hospital information system, an order management system, a pharmacy information systems, and many more systems are used. At first sight, a fully integrated ERP system would be an option to align these processes and systems. However, there are several difficulties in using ERP systems in the healthcare sector. First of all, the alignment of business processes with the ERP system is not an easy task, and the success of the project, therefore, depends on the complexity of the processes in the environment. For this alignment, either the processes or the ERP system have to be adapted, but some ERP systems require a lot of effort to be adapted to the required processes. Another problem is related to the vendor lock-in problem [60]. When an ERP system is adapted for the healthcare provider, there is too much dependency on the vendor and the consultants who can provide the required services.

The case study was based on a peer-reviewed article due to the COVID-19 pandemic. Although Jahn et al. [59] did not explicitly name stakeholders, the paper contained sufficient detail to derive the context diagram and the decomposition view. Similarly, we were able to derive the layered and deployment view based on the detailed information Jahn et al. [59] provided. The use of four views to derive the AA was demonstrated. In theory, the same procedure can be used to generate other potential perspectives (e.g. use views, layered views etc.). To do so, the appropriate views must be defined based on the chosen system’s particular application requirements [35] . Till all the necessary views have been determined, the approach described above will be followed; that is, reference views will be established first, followed by application views. When using this reference architecture for the development of a new system, it is very important to make use of the different standards for HISs. In order to ensure interoperability with other systems, standards such as HL7 FHIR should be used [61] Furthermore, the diagnoses in the systems should also be standardized using codes such as ICPC-2 or ICD11 [62, 63].

Future work will expand towards cases in the long-term care domain to further demonstrate our RA’s applicability.

Related work

Several other RAs for HISs have been published. The pioneer RICHE RA from 1993 [23] has an open architecture with three layers: user applications, basic applications, and information systems. Despite its old age, the paper described many problems that have remained unsolved up until today. Wartena et al. [24] described in 2010 a RA for a personal telehealth ecosystem with a focus on networking and communication, ignoring other features.

More RAs for HISs are found in grey literature, such as white papers and technical reports. These RAs are often characterized by none [25] or some diagrams only [26,27,28], and do not apply any formal software architecture modeling technique, as defined in the computer science literature [64].

We found three papers that used diagrams systematically to describe their RA for hospitals [29, 31], and healthcare in general [30]. Nictiz [29] presented an RA for hospitals using an Archimate model [65]. Their RA showed similarities with ours: their domain ‘reference model’ contained many elements from our decomposition view and layered view. However, the Archimate Model is limited to the scope of enterprise modeling [66] and is based on the by now replaced IEEE 1471 standard [67]. In contrast, UML has a much broader scope and contains many more modeling concepts to choose from, 150 instead of 50. Winter et al. [31] based their RA for the hospital domain on the UML-based 3LGM2 model, which had also been used by Jahn et al. [59]. Winter and colleagues’ metamodel for modeling Hospital Information systems, shows similarities with our RA as explained in Section 5. An RA with a similar scope to ours is ATOS’ “IT Reference Architecture for Healthcare” [30]. They did not use UML models, but an informal approach to display the ICT services for HIS development. Their RA shows some overlap with our decomposition view but ignores a deployment view.

Compared to the other RAs, our RA is generic, uses UML models, and addresses the entire healthcare domain.

Conclusions

In this study, we showed that the methods of the software architecture design community could be used in the healthcare domain effectively: we proposed a generic RA for HISs. We have shown the suitability of the RA for deriving the AA for a University hospital in Japan. Our method of evaluating an RA was successful for one case study. In our future work, we will use this method to a greater extent and apply the reference architecture for designing the architecture of various other HISs.