Middle East Respiratory Syndrome Coronavirus (MERS-CoV) was first discovered in September 2012 in Saudi Arabia. Since then, it caused more than 1600 laboratory-confirmed cases and more than 580 deaths among them. The clinical course of the disease ranges from asymptomatic infection to severe lower respiratory tract illness with multiorgan involvement and death. The disease can cause pulmonary, renal, hematological, and gastrointestinal complications. In this paper, we report neurological complications of MERS-CoV in two adult patients, and we hypothesize the pathophysiology. The first patient had an intracerebral hemorrhage as a result of thrombocytopenia, disseminated intravascular coagulation, and platelet dysfunction. The second case was a case of critical illness polyneuropathy complicating a long ICU stay. In these cases, the neurological complications were secondary to systemic complications and long ICU stay. Autopsy studies are needed to further understand the pathological mechanism.

No abstract

The Kingdom of Saudi Arabia is known for its extreme climate where temperatures can exceed 50 °C, especially in summer. Improving agricultural production can only be achieved using innovative environmentally suitable solutions and modern agricultural technologies. Using Internet of Things (IoT) technologies in greenhouse farming allows reduction of the immediate impact of external climatic conditions. In this paper, a highly scalable intelligent system controlling, and monitoring greenhouse temperature using IoT technologies is introduced. The first objective of this system is to monitor the greenhouse environment and control the internal temperature to reduce consumed energy while maintaining good conditions that improve productivity. A Petri Nets (PN) model is used to achieve both monitoring of the greenhouse environment and generating the suitable reference temperature which is sent later to a temperature regulation block. The second objective is to provide an Energy-Efficient (EE) scalable system design that handles massive amounts of IoT big data captured from sensors using a dynamic graph data model to be used for future analysis and prediction of production, crop growth rate, energy consumption and other related issues. The design tries to organize various possible unstructured formats of raw data, collected from different kinds of IoT devices, unified and technology-independent fashion using the benefit of model transformations and model-driven architecture to transform data in structured form.

This paper presents a conceptual architecture, design, and recommendation for the IoT Edgebased healthcare management system. The suggested architecture aims at distributing the workload of system performance (electronic healthcare services), including monitoring, diagnosis, prediction, as well as managing and archiving medical data of patients across different points of the system (at the edge and on the cloud). The proposed system design consists of two main subsystems (one for monitoring tasks and another one for medical record management activities). Both subsystems interact with multiple kinds of database systems (SQL and NoSQL). Transformational-based system for data migration is presented as a contribution of this paper. Two styles of transformation compositions are considered in the architectural design of transformation agents. INDEX TERMSIoT healthcare application, edge-based, system architecture, composition of model transformation, database migration, database design.

PurposeThis paper aims to introduce the goal-oriented requirements extraction approach (GOREA). It is an elicitation approach that uses, specifically, healthcare business goals to derive the requirements of e-health system to be developed.Design/methodology/approachGOREA consists of two major phases: (1) modelling e-health business requirements phase and (2) modelling e-health information technology (IT) and systems requirements phase. The modelling e-health business requirements phase is divided into two main stages: (1) model e-health business strategy stage and (2) model e-health business environment stage. The modelling e-health IT and systems requirements phase illustrates the process of obtaining requirements of e-health system from the organizational goals that are determined in the previous phase. It consists of four main steps that deal with business goals of e-health system: (1) modelling e-health business process (BP) step; (2) modelling e-health business goals step; (3) analysing e-health business goals step; and (4) eliciting e-health system requirements step. A case study based on the basic operations and services in hospital emergency unit for checking patient against COVID-19 virus and taking its diagnostic testing has been set and used to examine the validity of the proposed approach by achieving the conformance of the developed system to the business goals.FindingsThe results indicate that (1) the proposed GOREA has a positive influence on the system implementation according to e-health business expectations; and (2) it can successfully fulfil the need of e-health business in order to save the citizens life by checking them against COVID-19 virus.Research limitations/implicationsThe proposed approach has some limitations. For example, it is only validated using one e-health business goal and thus it has to be authenticated with different e-health business goals in order to address different e-health problems.Originality/valueMany e-health projects and innovations are not established based on robust system requirements engineering phase. In order to ensure the success delivery of e-health services, all characteristics of e-health systems and applications must be understood in terms of technological perspectives as well as the all system requirements.

Purpose: To review breast magnetic resonance imaging (MRI) features of radial scar (RS) with and without associated atypia/malignancy. Methods: Twenty-eight (mean age 56.8) patients diagnosed with 30 biopsy-proven RS (n = 25, ultrasound-guided 14-gauge, n = 5, stereotactically guided 9-gauge) subsequently underwent breast MRI followed by surgery. Magnetic resonance imaging protocol included axial T1, axial fat sat T2, and postgadolinium in axial and sagittal planes. Two radiologists reviewed the mammographic and MRI findings in consensus according to the Breast Imaging Reporting and Data System lexicon. Results: Of the 30 RSs excised surgically, 14 (14/30, 47.7%) were not associated with atypia/malignancy while atypia/malignancy was found in 16 (16/30, 53.3%) RSs. Three (3/30, 10%) RS lesions did not enhance on dynamic MR. Mean lesion size on MRI was 1.4 cm (range, 0.5-5 cm). Seventeen (17/30, 56.7%) lesions presented as nonmass enhancement and 9 (9/30, 30%) as masses. Nonmass lesions showed focal distribution (13/17, 76.5%) and heterogeneous enhancement (15/17, 88.2%). Masses showed irregular shape and margins (6/9, 67%) and heterogeneous enhancement (8/9, 89%). Multivariate analysis did not show any significant difference in MRI presentation between RS only and RS associated with atypia/malignancy. Conclusion: Breast MRI does not help differentiate between RS with or without associated atypia/malignancy.

No abstract

The comparative survey shows that there are many Domain Specific Languages (DSMLs) adopted in various Model-Driven Engineering (MDE) approaches for information systems engineering. Choosing the appropriate DSML depends on the type of the target information system (IS), as well as the technical and modelling skills of the developing team. Adopting the right DSML is considered a difficult issue for casual designers, domain experts with limited modelling skills. Therefore, introducing a simplified DSML that describes IS in a higher-level of abstraction way than existing DSML approaches supports business users to contribute more in the development process. In this work, a classification framework is introduced to categorise thirteen DSMLs, based on the target type of IS, into four major categories, namely, (1) DSMLs for n-tier web application development, (2) DSMLs for cloud-based applications development, (3) DSMLs for mobile-based applications development and (4) DSMLs for tier-specific enterprise applications development. Feature modelling technique was adopted to compare and categorise modelling languages. Sharing a common similarity are clustered together into higher-level categories in the hierarchy as the main characteristics from different modelling languages. At the end, the resulting framework is documented using a multiple-level feature diagram to support domain expert decisions of choosing a DSML that suits their needs; And provide common DSML features to be adopted in constructing a simplified DSML that supports Lightweight MDE development.