Web interface for medical image repository

(1)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2015

FREDERICO JOS´

E

SOARES DA SILVA

WEB INTERFACE FOR MEDICAL IMAGE

REPOSITORY

INTERFACE WEB PARA REPOSIT ´

ORIO DE

(2)

(3)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2015

FREDERICO JOS´

E

SOARES DA SILVA

WEB INTERFACE FOR MEDICAL IMAGE

REPOSITORY

INTERFACE WEB PARA REPOSIT ´

ORIO DE

IMAGEM M´

EDICA

Disserta¸cão apresentada à Universidade de Aveiro para cumprimento dos requesitos necessários à obten¸cão do grau de Mestre em Engenharia de Computadores e Telemática, realizada sob a orienta¸cão cient´ıfica do Dr. Carlos Manuel Azevedo Costa, Professor do Departamento de Electrónica, Telecomunica¸cões e Informática da Universidade de Aveiro

(4)

(5)

o j´uri / the jury

presidente / president Prof. Dr. Augusto Marques Ferreira da Silva

Professor Auxiliar da Universidade de Aveiro

vogais / examiners committee Prof. Dr. Jos´e Paulo Ferreira Lousado

Professor Adjunto do Dep. de Informática, Comunica¸cões e Ciências Funda-mentais, da Escola Superior de Tecnologia e Gestão de Lamego do Instituto Politécnico de Viseu

Prof. Dr. Carlos Manuel Azevedo Costa

(6)

(7)

agradecimentos / acknowledgements

Quero agradecer à minha fam´ılia por todo o apoio incondicional e à minha namorada por toda a paciência.

Um enorme obrigado aos meu amigos por me acompanharem em toda esta jornada. Uma nota de apre¸co também para a ”fam´ılia” Meshapp por me disponibilizarem o tempo necessário para a realiza¸cão desta disserta¸cão.

Quero também agradecer ao grupo de bioinformática, com uma nota especial para o Luis Bastião por toda a ajuda prestada e ao professor Carlos Costa por orientar esta Disserta¸cão.

Para finalizar, quero deixar um muito obrigado ao Duarte Corvelo e ao Vitor Silva pelas preciosas dicas que me deram.

I want to thank my family for their unconditional support and my girlfriend for the patience.

A big thanks to my friends who have always been present on this journey. I want to make a note of appreciation to Meshapp ”family”, for providing the necessary time to accomplish this thesis.

I would also want to thank the whole bioinformatics group, special note to Luis Basti˜ao for all the help provided and to professor Carlos Costa for guiding this thesis.

Finally I want to make a big thanks to Duarte Corvelo and Vitor Silva for the precious tips they gave me.

(8)

(9)

Resumo A imagem médica em formato digital é hoje em dia um instrumento fundamental para suporte ao diagnóstico e tratamento cl´ınico. Exis-tem vários repositórios que dispõem já de um acesso Web integrado aos estudos imagiológicos e informa¸cão associada. O Dicoogle PACS é um software código aberto que oferece um conjunto de funcionalidades inovadoras para uma audiência mais alargada como, por exemplo, in-vestigadores. No entanto, esta plataforma não dispõe de uma interface compat´ıvel com os modernos ambientes Web, incluindo dispositivos móveis. Esta disserta¸cão conceptualizou e desenvolveu uma interface Web inovadora para o Dicoogle que separa claramente as componentes cliente e servidor, suportando simultaneamente a extensibilidade da plataforma através de plugins. A plataforma foi desenvolvida com o estado da arte de tecnologias Web, assegurando assim uma grande capacidade de desenvolvimento no futuro. Finalmente, a arquitetura da solu¸cão proposta teve em considera¸cão as especificidades da norma DICOM.

(10)

(11)

Abstract Digital medical imaging is nowadays a fundamental tool for supporting clinical diagnosis and treatment. There are already repositories with web interfaces that provide integrated access to imagiologic studies and associated information. Dicoogle PACS is an Open Source plat-form that provides a set of innovator functionalities for a more broad audience like, for instance, researchers. Nevertheless, its graphical user interface was not compliant with modern web environments, including mobile devices. This thesis proposes a web application for Dicoogle that offers a complete separation of client and server components, and supports extensibility through plugins. Moreover, the platform was developed with state-of-the-art technologies that provide a great de-velopment potential for future. Finally, the solution architecture took into account the specificities of DICOM standard.

(12)

(13)

List of Figures

2.1 PACS: Major components[1] . . . 6

2.2 Example of DICOM Information Object Definitions[1] . . . 8

2.3 DICOM File Format . . . 10

2.4 WADO request example [1] . . . 10

2.5 Dicoogle Architecture [1] . . . 15

2.6 Related work: comparation . . . 17

2.7 Ember: component interaction . . . 21

2.8 Layered Architecture [2] . . . 24

2.9 Microkernel Architecture [2] . . . 25

3.1 Proposed Architecture . . . 30

3.2 Dicoogle: Structure . . . 35

3.3 Flux: User interaction [3] . . . 37

3.4 Reflux: architecture . . . 37 3.5 Login Diagram . . . 40 3.6 Indexer Diagram . . . 42 3.7 Search Diagram . . . 43 3.8 Management Diagram . . . 44 4.1 Dicoogle: Login . . . 48 4.2 Dicoogle: Search . . . 49

(18)

4.4 Dicoogle: Results . . . 50

4.5 Dicoogle: Image informations . . . 51

4.6 Dicoogle: Management Index Options . . . 52

4.7 Dicoogle: Management Transference Options . . . 53

4.8 Dicoogle: Management services . . . 54

4.9 Dicoogle: Storage Servers . . . 55

4.10 Dicoogle: Management Logs . . . 55

4.11 Dicoogle: Indexer . . . 56

(19)

List of Tables

2.1 DICOM Message Services . . . 9

2.2 QIDO-RS Study attribute matching . . . 12

2.3 QIDO-RS Series attribute matching . . . 13

2.4 QIDO-RS Instance attribute matching . . . 13

2.5 QIDO-RS Common to all query levels . . . 14

2.6 Frameworks: GitHub and StackOverflow popularity . . . 23

3.1 User Access . . . 31

3.2 Search methods . . . 32

3.3 Management Application Settings . . . 33

3.4 Management - Application Services . . . 34

3.5 Management - Application Tasks . . . 34

(20)

(21)

Listings

3.1 Dicoogle Webapp: SearchAction . . . 38

3.2 Dicoogle Webapp: SearchStore . . . 38

3.3 Dicoogle Webapp: SearchView . . . 38

(22)

(23)

Chapter 1 Intoduction

This chapter will present an overview, goals and outline of the document.

1.1 Overview

With the evolution of the Information Technologies (IT) many professional areas have adopted computer systems to assist in various tasks, thus optimizing their time and in-creasing the reliability of results.

These new technologies makes possible for healthcare providers to better manage pa-tient health information and share it with other institutions on a secure and reliable way. In recent years medical imaging was becoming a critical tool in the diagnosis and treat-ment of patients. Research and industry efforts to develop medical imaging equiptreat-ment, which evolved gradually to a panoply of imaging resources, have been the major driv-ing forces towards wide acceptance of the Picture Archivdriv-ing and Communication System (PACS) concept [4].

The PACS concept refers to systems used in laboratories of medical imaging and cover transport, storage and visualization of images and associated data. The interoperability of distinct PACS equipment is guaranteed by the DICOM (Digital Imaging and Communi-cations in Medicine) that standard contemplates the communiCommuni-cations, data structures and

(24)

encoding of images.

Dicoogle [5] is a PACS Open Source solution supported by an indexing system and by peer-to-peer (P2P) protocols. It was developed by the Bioinformatics group at Aveiro Uni-versity. Beyond the research and education scope, Dicoogle is also used in real production scenarios and there is a scientific community using it to extract knowledge and search for medical images.

Dicoogle has a graphical desktop version based on Java Swing and RMI. However there have been an effort to migrate it to a web environment, the tendency is that applications and services will work, whenever possible, through the web, increasing the portability and facilitating the use as it removes the need of software installation.

1.2 Goals

This thesis is proposed under the Dicoogle Project and the main goal is to create a web platform that ensure the operability with standards and features already implemented by Dicoogle desktop version.

Following the trend of web technologies, it is intended to separate completely the Web client from the server.

However, we are dealing with a platform that supports a large repository data, then performance issues will have to be taken into account, ensuring a fast and efficient search over big-data repositories.

1.3 Outline of thesis

This thesis is divided in 5 chapters. Here is a brief description of the content of the document:

Chapter 2: It describes the medical context in which this thesis is inserted. DICOM Standards is presented. A comparison is made between Dicoogle and related work. Finally Web Technologies are presented.

(25)

Chapter 3: Presents the problem to solve and the conceptual requirements, functional and non-functional. Describes the architecture and implementation of Webapp.

Chapter 4: Presents the work results, mainly focused on user experience and validation of the Webapp.

Chapter 5: It contains the conclusions of the work and points directions for future work.

(26)

(27)

Chapter 2 State of the Art

This chapter serves as a state of the art survey in the topic of Digital Medical Imaging Laboratories. It will be presented the relevant protocols, standards and related work.

2.1 Digital Medical Imaging Laboratories

The medical imaging is one of the areas with strong growth in healthcare, in both hospitals and research unities[6]. The development of treatments and discovery of new cures is often dependent on technology.

When a patient came to an Health Institution the HIS(Hospital Information System) is critical and should have a fast and efficient access to all patient data. Only in this way it will be possible for doctors to diagnose and treat the patient in useful time. [7]

2.1.1 PACS (Picture Archive and Communication System)

The amount of images generated every day makes healthcare institutions search for IT solutions that ensure scalability, security, performance and reduced maintenance costs. It is also important to support redundancy of medical records.

In the past twenty five years, the practice of radiology has being revolutionized by PACS (picture archiving and communication system). The main goal of PACS is to provide an

(28)

easy way of acquire, store and distribute medical images information, leaving behind all the need for human intervention through analogical systems[8].

Figure 2.1: PACS: Major components[1]

As shown in Figure 2.1 there are three major PACS components[1]:

• Acquisition: The modalities units responsible by the capture of image.

• Storage: The archive servers responsible by the storage of digital images.

• Visualization: Workstations that allow users to visualize and operate the images.

Acquisition can be a hard task. Nowadays, images can be directly produced by digital equipment, but older equipment that may only produce analogical films require the use of scanners to produce the digital image. The acquisition computers perform three main tasks: Acquires the studies image data, codify that data in standards data structures and send them to PACS Archive Server.

Beyond storage, PACS system also include a mechanism to distributes images among the different PACS nodes using, for instance, the DICOM Query/Retrieve service.

Visualization is the only part of PACS that users really see. This component should provide a user-friendly interface for searching and manipulates studies.

(29)

All the communication between the three elements relies in DICOM standard protocol to ensure the interoperability of the various PACS equipment, regarding the communica-tions, data structures and image encoding.

As [8] state, there are three basic PACS architectures: Stand-alone, client-server and web-based.

• Stand-alone: In this model the images are sent automatically to workstations from archive server. This approach reduce the risk of losing imaging data because multiple copies will be available on the system.

• Client-server: The images are uploaded to a central repository at the PACS Server. No prefetching is needed and workstations retrieve studies only when they need. This approach has disadvantage associated to the eventual unavailability of the server that compromises all entire PACS system.

• Web-based: This solution is similar to Client-server, differs on the client side that is a Web-based application. Portability is the great advantage of this model.

2.1.2 DICOM Standard

Back to 80’s, it is impossible to open and transfer medical images from one vendor to another because no standard was followed at the time. The institutions were attached to a manufacturer solutions if they want to keep their image acquisitions. American College of Radiology (ACR) and the National Electrical Manufactures Association (NEMA) realized the need of a standard protocol for transfer images between devices manufactured by various vendors.

In 1983, ACR and NEMA formed a committee with the objective of creating a protocol for supporting communications and formats used in digital medicine imaging processes. The efforts resulted in the first version of DICOM published in 1985. Since then, the standard won a great relevance to the development of PACS systems. Between 1985 and

(30)

1988, two revisions were done and only in 1993 that the full version was presented, having been improved up to the present day. [9]

DICOM Data Model

The data model defines four information Entities: Patient, Study, Series and Images. Each Entity is identified by an unique identifier.

Beyond the information about the image, a DICOM file contain meta-data with ad-ditional information, that aims to represent the real world, like institutions or patient attributes. The DICOM objects are represented using IODs (Information Object Defini-tions) and one DICOM file could contain several IODs.

Figure 2.2: Example of DICOM Information Object Definitions[1]

DICOM Services

To perform the transmission of data over the network, DICOM provides a set of ser-vices that allow the exchange of information. Applications are identified by an AETi-tle(Application Entity Title), each AETitle has associated a par of IP and PORT that allows Application Entities to be addressed in a network.

The communication between DICOM devices requires an association between them. This process is divided into several stages. Firstly the client application sends an associa-tion request to the server applicaassocia-tion that want to be connected with, specifying the desired services. The receiver verifies if the requested services are supported and if everything is in accordance, it responds with the list of accepted services. When the response is received, the requester application can now proceed with the effective services.

(31)

There are two main DICOM Service classes:

• DICOM Storage: allows sending images to a remote destination.

• DICOM Query / Retriever: allows us to search and retrieve images from a server.

In the process o transfer files the most important operations data is the C-STORE and C-MOVE. The C-STORE sent the file to the target application and the C-MOVE transmit the file to located on the target to another application identified on the request, that transmission is made through the C-STORE command [10]. All DICOM Services are described in table 2.1

Command Function

C-ECHO Check DICOM status C-STORE Push image to PACS C-FIND Search repository C-GET Get Image

C-MOVE Move Image

Table 2.1: DICOM Message Services

DICOM File Format

The DICOM file consist on an header and a data set following a IOD (a set of data elements). The header must contain a 128 byte preamble and a 4 byte prefix. Each data element is organized in a TLV format: Tag, Length and Value as shown on figure ahead.

The Tag is present in every DICOM element and it define that element in an unique way. As Figure 2.3 shown the Value Representation(VR) defines the data type: UI for Unique Identifier, CS for Coded String, etc. As DICOM is a binary protocol, the length of element is mandatory.

(32)

Figure 2.3: DICOM File Format

DICOM WADO

WADO(Web Access to DICOM Objects)[11] is not a communication protocol, it is a extension to DICOM protocol. WADO defines a normalized way to access objects through the web. It uses the HTTP protocol which is particularly valuable because it allows access to DICOM content from any network.

Wado proposes a URL syntax for Web Requests, being the equivalent of DICOM query and retrieve request. Figure 2.4 exemplify a URL syntax of an WADO request.

(33)

DICOM QIDO

QIDO(Query based on ID for DICOM Objects) is also a DICOM Standard extension for web, providing support for queries: Studies, Series and Instances.

In the context of EMR(Electronic Medical Record) imaging information is an impor-tant input allowing a better performance in many situations. As basis for the QIDO-RS requirements, some clinical scenarios were used:

• Search from EMR

• Population FHIR(Fast Healthcare Interoperability Resources) resources

• Worklist in Viewer

• Study import duplication check

• Multiple system query

• Clinical reconstruction

• Mobile Device Access

Tables 2.2, 2.3, 2.4, 2.5 describes the attribute matching of QIDO-RS Levels. The meaning for types of matching is:

• ”S” - Single matching

• ”L” - UID List matching

• ”U” - Universal matching

• ”*” - Wildcard matching

• ”R” - Range matching

(34)

• ”NONE” - No matching is supported, the value will be returned in all requests. • ”UNIQUE” - Unique key

Keyword Types of Matching

StudyDate S,*,U,R

StudyTime S,*,U,R

Accession Number S,*,U ModalitiesInStudy S,*,U ReferringPhysiciansName S,*,U StudyDescription S,*,U PhysicianOfRecord U PatientsName S,*,U PatientID S,*,U PatientBirthDate NONE PatientSex NONE StudyInstanceUID UNIQUE StudyID S,*,U NumberOfStudyRelatedSeries NONE NumberOfStudyRelatedInstance NONE RetrieveURL NONE

(35)

Keyword Types of Matching Modality S,*,U SeriesDescription NONE SeriesInstanceUID UNIQUE SeriesNumber S,*,U NumberOfSeriesRelatedInstances NONE PerformedProcedureStepStartData S,*,U,R PerformeedProcedureStepStartTime S,*,U,R RequestAttributeSequence SEQUENCE >ScheduledProcedureStepID S,*,U >RequestedProcedureID S,*,U

Table 2.3: QIDO-RS Series attribute matching

Keyword Types of Matching **All attributes of Series level **

SOPClassUID L SOPInstanceUID UNIQUE InstanceNumber S,*,U Rows NONE Columns NONE BitsAllocated NONE NumberOfFrames NONE

(36)

Keyword Types of Matching InstanceAvailability S,*,U

SpecificCharacterSet NONE RetrieveURL NONE

Table 2.5: QIDO-RS Common to all query levels

Examples of the three queries:

1 h t t p :// l o c a l h o s t / s t u d i e s ? P a t i e n t I D = 2 3 4 5 6 2 3

2 h t t p :// l o c a l h o s t / s e r i e s ? S t u d y D a t e = 2 0 1 5 0 1 3 1

3 h t t p :// l o c a l h o s t / i n s t a n c e s ? M o d a l i t i e s I n S t u d y = CR

The web request header should include the type ”application/dicom+xml” or ”ap-plication/json”. About the response DICOM JSON Model is composed by an array of objects, identified by DICOM TAG, and each object contains a string encoding the DI-COM Value Representation(VR), vr attribure, and at most one of three attributes: Value, BulkDataURI and InlineBinary.

Example of DICOM JSON MODEL:

1 [ 2 { 3 " 0 0 2 0 0 0 0 D ":{ 4 " vr ": " UI ", 5 " V a l u e ": [" 1 . 2 . 4 5 6 . 7 . 2 . 2 3 . 4 . 6 . 7 . 3 2 1 4 5 "] 6 } 7 } , 8 { 9 " 0 0 2 0 0 0 0 D ":{ 10 " vr ": " UI ", 11 " V a l u e ": [" 1 . 2 . 4 5 6 . 7 . 2 . 2 3 . 4 . 6 . 7 . 3 2 1 8 7 "] 12 } 13 } 14 15 ]

(37)

2.1.3 Dicoogle

Dicoogle [5] is an open source application developed by Bioinformatics group at Univer-sity of Aveiro. It is a PACS Archive Software supported by an indexing system(Figure 2.5), called Lucene [12], that allows meta-data queries to all attributes contained in a DICOM object data set. This open up new horizons since with Dicoogle it is possible to extract more information compared with the queries that traditional PACS support. Also provide a retrieve engine through a distributed environment. It has also a folder watcher that allow us to index local files outside the normal DICOM workflow [4].

(38)

Dicoogle is fully compliant with DICOM standards to ensure interoperability with systems. Up to 20 millions of DICOM Objects were already indexed with Dicoogle, what proves its scalability. Currently, Dicoogle offers a SDK for development of new plugins or modules and, in addiction to client/server, also supports P2P environments [4].

(39)

2.1.4 Related Work

Due to the relevance of the medical images to health, many solutions have appeared. The most important applications besides Dicoogle that implements the DICOM Standard are: Orthanc [13], Osirix [14], dcm4che [15], OpenSourcePACS [16], K-PACS [17], Conquest PACS [18] and MRIdb [19]. The figure 2.6 shows a detailed comparison between the Dicoogle and other systems.

(40)

2.2 Web Technologies

Internet has changed a lot over the years and several technologies have emerged. In the 90’s, the pages were basically static. The system evolved to the called “web 2.0” that take advantage of JavaScript and background data download(through AJAX and WebSockets).

The Web 1.0 system were characterized by two aspects:

• Static Sites: Content is not changed over time, the were merely informational without reason to come back later.

• No interactive: User could see but had no way to contribute or modify content. The Web 2.0 was officially defined by Dale Dougherly [20] but was popularized in Tim O’Reilly site describing it as:

”Web 2.0 is the business revolution in the computer industry caused by the move to the internet as platform, and an attempt to understand the rules for success on that new platform. Chief among those rules is this: Build applications that harness network effects to get better the more people use them”

2.2.1 SPA

A single page application(SPA), also called webapp, is a single webpage that load all the resources required for the app on the first load but all subsequent content is load dynamically. A clear definition that describes an SPA is stated by Ali Meshab and Arie van Deursen in their paper [21]:

”The single-page web interface is composed of individual components which can be updated/replaced independently, so that the entire page does not need to be reloaded on each user action.”

2.2.2 JavaScript

JavaScript is a programming language created in 1995 by Netscape. It is nowadays the main language used in web client-side but can be used on server-side too, as is the case of

(41)

Node.js [22]

As a cross-platform, JavaScript is a run-time evaluated programming language, making it a very flexible language. It is a dynamically typed language, that means that variables are bound to objects at run-time, so it is possible to bind a different type to an existing variable during the execution.

Example:

1 var n a m e = " F r e d e r i c o ";

2 n a m e = 3;

2.2.3 CSS

On a website developing, the best approach to deal with questions related with accessi-bility, performance and maintenance, is to separate content. CSS(Cascading Style Sheets) has an important role here.

The correct way of publish a web document is following a semantic structure. CSS gave all the information about layout: colors, positions, lengths, etc. While HTML only define the content structure.

CSS is a simple style sheet language and, for this reason, appeared also some CSS preprocessor. A CSS preprocessor aims to help write CSS files, allowing the use o variables, providing helpfull functions and other specific features inherent to the preprocessor. Of all possible alternatives, the most popular are SASS[23] and LESS[24].

2.2.4 Responsive Web Design

Today, more than ever, new devices appear with different screen characteristics, espe-cially mobile devices. Because of the limitations that small screens have, it is necessary to adjust layouts sizes but also rethink the approach on how the elements are arranged in the screen [25]. Therefore Responsive Web Design(RWD) is the practice of developing a website or webapp to suit any device, of any screen size adapting the needs of each one.

(42)

The most common way of making the layout responsive is through CSS media queries, defining different styles according the device screen characteristics.

2.2.5 Frameworks

When we are creating a webpage, as well as other necessities in the programming area, we feels the need to create something structured, easy to maintain and with a reasonable time of implementation. With the growth of web technologies, the world of JavaScript frameworks is constantly changing, so it is very important to choose the most appropriate framework.

AngularJS

AngularJS [26] is an open-source web application framework released in 2009. It follows the Model-View-Controller(MVC) pattern for implementing user interfaces.

This frameworks extends traditional HTML with two-way data binding that allows au-tomatic synchronization between models and views. All the control layer is isolated from the models and views.

We can say that angularJS consists of:

• Directives: Used to abstract the manipulation of the Document Object Model(DOM).

• Controllers: Controllers are used to set up and add behavior to the $scope object, $scope is an object that ties a view to the controller.

• Modules: A module is a container for a part of the app.

• Routes: Routes allow the creation of different URLs for each part of the app.

(43)

Backbone

Backbone [27] is a JavaScript framework released in 2009 that provides building blocks required to develop SPAs.

Classified as MVC but, in reality, is a MV* because C is for Collections instead of Controller. Collections are ordered sets of models. It also offers an Event Module that gives objects the capacity of event triggering and listening.

Ember

Ember [28] is also an open-source and MVC web application framework that was created in 2011.

Main concepts of Ember are Routes, Controllers, Views, Templates, Models and Com-ponents. Figure 2.7 illustrates how this classes interact.

Figure 2.7: Ember: component interaction

• Templates: Describes the user interface of the app, some addition to HTML are provided, like: expressions, outlets and components.

(44)

• Router: Makes the correspondence between models and URLs • Models: The object representation that store data.

• Controllers: Connect models and templates.

• View: Encapsulate templates, combine them with data to render and register events. • Component: Isolated view with the purpose of being reused.

ReactJS

ReactJS [29] is the most newer JavaScript framework. It was released in 2013 and is mantained by Facebook and Instagram.

Unlike the others frameworks already presented in this document, ReactJS does not follow the MVC pattern, it is just the V in the MVC because it only take care of UI. As it does not include model or controler components it can be used in conjunction with another framework, like AngularJS, Backbone or Ember. For example, in Backbone, ReactJS can easily replace the View component.

ReactJS requires everything to be separated into small modules, thus helps in the maintenance and ease of code reading.

But is ”under the wood” that the most important thing about ReactJS lives, the Virtual DOM. Virtual DOM is a copy of original DOM that will be comparated with original and only changed components will be re-rendered, resulting in a fastest and optimized way of changing DOM content.

Community

An important factor when we have to choose a framework is the community behind it. When a problem appear it is fundamental a good community to support and help solving problems/bugs. In addition, a larger community means more tutorial, more libraries and more knowledge around the web. So Table 2.6 illustrate the current state of previous mentioned frameworks on GitHub and StackOverflow.

(45)

Metric AngularJS Backbone Ember ReactJS GitHub Stars 34.7k 20k 12.5k 14.4k StackOverFlow

Questions

75.3k 17.2k 13.7k 1.2k

Table 2.6: Frameworks: GitHub and StackOverflow popularity

Summary

At the time this project was started, AngularJS underwent a complete restructuring from v1.x to v2.0, not making sense to start a project that in few months would probably be deprecated.

JS community has moved away from Backbone because it does not provide a clean architecture, there is no guidance on how develop and structure a project, due to this careless architecture it is very easy to disrupt a project hurting productivity.

ReactJS has had a lot of hype from the JS community. It is a well structured framework, a triangle between Views, Actions and Stores where actions update the store which in turn make the view update. Due to Virtual DOM, ReactJS has proven to be the fastest in terms of performance. The performance was an important factor to take in account, since Dicoogle need to handle large data sets and ReactJS can handle the modification and display of large tables of contents with great performance.

2.3 Software Architectures

2.3.1 Layered

Layered is one of the most common architecture pattern [2]. Its Architecture is focused on multi-layerd grouping of distinct features. As shown in the Figure 2.8, layers are stacked vertically and each one is responsible for itself. Moreover, the changes made in one layer can not affect the behaviour of others layer. It is not supposed that one layer have knowledge

(46)

about core working flow of another layer. The loosely coupled is one of the principles of this pattern, each layer only communicates with the adjacent layer and all communication should be done through abstractions between them.

Figure 2.8: Layered Architecture [2]

Since there is total separation of the layers, this pattern facilitates comprehension, maintenance and independent development.

2.3.2 Microservices

Software build as microservices presupposes the division into multiple component ser-vices. So, each service can be deployed individually and work independently without affecting the overall flow of the application. Scalability is highly increased by this pattern, because it is a distributed architecture.

(47)

2.3.3 Microkernel

Also referred as the plugin architecture pattern, Microkernel aims to facilitate the addition of new features as plugins to the core. To achieve that, a minimal functional core have to be separated from the overall feature, the plugins. Extensibility, flexibility and isolation of application features are the best characteristics of microkernel pattern.

Figure 2.9: Microkernel Architecture [2]

The plugins works as standalone, they are independent components with additional features that extend the core system. That behavior is illustrated in Figure 2.9.

(48)

(49)

Chapter 3 Dicoogle Web Application

In this chapter, the proposal of Dicoogle Web Application is presented. We describe the requirements, architecture and methods used to implement the solution.

3.1 Requirements Analysis

3.1.1 The Problem

Dicoogle has currently an main user interface based in Java Swing and RMI. However, the necessity of having a multi-platform web client interface was identified as a critical issue. So the main objective of this work is to replace completely the desktop version by a web one. The trend is that applications will work whenever possible through the Web, increasing the portability and making the installation easily. However, the Web browsers have limitations and the concerns about real time content are raised.

This thesis aims to develop a web platform with state-of-the-art technologies that must be interoperable with current features and standards available on desktop version of Di-coogle. It is also required to do a refactoring of the REST API that must respecting the compliance with the medical imaging standards (DICOM, QIDO-RS, STOW-RS and WADO-RS).

(50)

3.1.2 Functional Requirements

Search

Users should be able to search studies in three ways: free text, free text with advanced query and advanced mode. Simple free text will return results of any kind. Advanced query allow user to construct a query that fit the purpose, for example: ”Modality: CT AND PatientSex: M”. The last option provide an interface with all available options.

The search result should be divided into four sections: Patient, Study, Serie and Image. The user should be able to export the searched data.

Index

The user should have the possibility to launch a new index task, see what tasks are running and stop a running task.

Manage

In the management area the user should be able to: • Edit index options

• Edit transference options

• Start/Stop services and edit the server ports • Edit Storage Servers

• View Logs about the system

3.1.3 Non-Functional Requirements

Responsiveness

With the relevance that mobile devices have nowadays, Responsive Web Design will be a mandatory issue for Dicoogle Webapp that should behave reasonably well on all screen

(51)

sizes, adjusting its layout to fit on them.

Performance

Given the number of studies that Dicoogle must be able to handle, it is necessary to pay attention to the performance of the web page. Concepts of ”Big data” should be take into consideration.

Extensibility

Once the Dicoogle is a relatively large project and several people are involved, it is required an easy integration of new features.

Follow the evolution

Being a project in the long term, trying to predict the path of Web technologies can be a real asset. Newer don’t mean necessarily better but it can help in the project maintenance.

3.2 Architecture

The main objective of proposed architecture for Dicoogle Webapp is to separate the client component from the server as Figure 3.1 presents.

The architecture selected to solve this problem was the Layered, the most common and traditional pattern used among software engineers [2]. With that approach, it is possible to run server and Webapp in two distinct servers and locations because each layer has his specific role and responsibility that can be deployed separately.

All the existing functionalities from old desktop interface were ported to RESTful services. In addition to divide responsibilities, it is important to have a separate API. A well structured and documented API will bring the possibility of external applications take advantage of it.

(52)

Figure 3.1: Proposed Architecture

The Webapp was developed in ReactJS, taking advantage of the modularity that this provides. Each view was divided in small components, allowing easy replacement in the future. The entire structure is designed for a long-term project, the code is well separated and organized allowing an easy understanding of it by outsiders. In respect of styles, it was adopted a CSS framework named SASS that allows the creation of variable that can be reused, in addition that framework provide some function utilities of great value for the project.

As stated above, the use of state-of-the-art tools was an main objective, so beyond the use of ReactJS which is relatively new, all the code in JavaScript was developed on top of the new ECMAScript 6 (ES6). ES6 is the next-generation of JavaScript.

3.3 RESTful API

The applicational server Jetty was chosen because of its ability to work both as stan-dalone or embeddable. Two main components of proposed solution rely on Jetty, the web

(53)

services(which are presented below) and the Dicoogle Webapp itself.

There are other solutions but one of the preoccupations to this project was to follow the innovation path. As such, compatibility with the newest version of Java EE is an important factor. Only two of main application servers support Java 7, Jetty and Glassfish. Jetty proved to be the easiest solution to embedding jetty inside the server and it has also a small footprint.

The API was designed for providing consistency and flexibility. This new API is di-vided in five groups: User Access, Search, Management Application Settings, Management Application Tasks and Management Services. Only JSON responses were considered. The next sub section will detail the proposed API.

3.3.1 User Access

The User Access web service has methods to login, logout and manage users. All these service methods are described in the table 3.1.

Method HTTP Operation Description /account/login POST Login /account/logout POST Logout

/account/user CRUD User accounts, create, remove Table 3.1: User Access

3.3.2 Search

This is the most important web service of Dicoogle. There are two types of queries supported by index engine. A simple text query that can be made for a general search. For refined results, it is possible to do a advanced query with predefined keywords.

Apart from the main search method, there are other three methods. The /dump method returns all indexed values for a SOPInstanceID, the /export method allows to export a

(54)

query results to CSV and /providers method that returns a list of all providers available for research, the table 3.2 presents more details of those search methods.

Method HTTP Operation Description /search

- keyword: Boolean - query: String - provider: String<>

GET Search the DICOM meta-data.

/dump - uid: String

GET Dump of DICOM meta-data

/export

- format: String - keyword: Boolean - query: String - provider: String<>

GET Export search in various formats

/providers - type: String - enable: Boolean

GET Return provider list.

(55)

3.3.3 Management Settings

Table 3.3 lists all methods available for management settings. Method HTTP Operation Description /management/settings/

index/path

CRUD Dicoogle directory to index

/management/settings/ index/zip

CRUD Storage/Index Files compressed

/management/settings/ index/effort

CRUD Effort of index (0-100)

/management/settings/ index/thumbnails

CRUD Thumbnails indexing

/management/settings/ index/thumbnails/size

CRUD Size of Thumbnails indexing

/management/settings/dicom CRUD AETitle /management/settings/

storage/dicom

CRUD AETitles for Storage

/management/settings/ dicom/storage

CRUD DICOM Storage Settings

/management/settings/ dicom/query

CRUD DICOM Query Settings

(56)

3.3.4 Management Services

There are three methods to get status, start and stop services and plugins as table 3.4 show.

Method HTTP Operation Description /management/dicom/

storage

GET/POST Manage Storage Service

/management/dicom/ query

GET/POST Manage Query Service

/management/ plugins

GET/POST Manage Plugins

Table 3.4: Management - Application Services

3.3.5 Management Tasks

Manage the indexer tasks is one of the most important web-services of Dicoogle. It was possible to start a indexing task and stop it. In support, especially for visual representation, it was released a method to return the status of course tasks. The methods are discribed in the table 3.5.

Method HTTP Operation Description /management/tasks/index

- uri: String

POST/GET Start/Stop task

/management/tasks - uid: String

CRUD Manage running tasks

(57)

3.4 Webapp - Client Application

3.4.1 Interface Design

Having regard to the proper functioning of the Webapp not only on desktop but also on mobile devices, the base structure of the interface is composed by a Topbar, a Sidebar and a Content zone as figure 3.2 show.

Figure 3.2: Dicoogle: Structure

The choice of the sidebar was necessary to have an application ready for mobile devices. Due to the lack of display area on these devices, the use of a sidebar helps in accessing different features, besides it being a standard widely used in native mobile applications. While in desktop screens the sidebar is always visible, in mobile devices it is hidden and can be accessed on topbar with just one click.

3.4.2 Developent tools

(58)

• NPM • Browserify • Watchify • 6to5ify • Sass

NPM [30] is the package manager chosen to manage dependencies of Dicoogle Webapp. Browserify [31] allow us to load modules imported by npm (like Node.js does) just by call a simple require function. Together with Browserify we are using Watchify to watch all file changes in real time and recompile the Browserify bundle. In order to use the new EcmaScript 6(ES6) since must of the current browsers does not support ES6 yet, a plugin for Browserify named 6to5ify is used. To compile the preprocessed CSS (see Sass section), sass files is being watched to compile all SASS files to a normal CSS bundle.

At the end the result is two unique files, the JavaScript and the CSS bundle. Only these two files need to be included in our HTML file in order to run the Webapp.

The main frameworks used were: ReactJS, Reflux and Bootstrap.

3.4.3 Data flow

Flux [3] is an application architecture for building complex client-side web interface. Flux avoid MVC pattern and follow a unidirectional data flow. As Figure 3.3 illustrates, when a user triggers a action, a message will be propagated to the dispatcher, to the stores and finally the view will update due to store changes. This will keep the data structure linear and all the data manipulation will be done in the Store.

(59)

Figure 3.3: Flux: User interaction [3]

Dicoogle Webapp uses a library based in Flux, named Reflux [32]. Reflux get together the Flux Dispatcher and Actions, this simplify a lot the Flux architecture setup, reducing the process to two steps: create actions and listen to that actions. In our webapp, all views are follow by their Action and Store, and is in that Store that all communication with the outside world (i.e. Dicoogle API), is made. Store, as the name implies, is responsible for store all the data between client and server. Views are listening for Store changes and re-render when that happens. Figure 3.4 presents an example that shows how search action flow is done on our Webapp.

(60)

The base implementation for the search view is present in the code blocks 3.1, 3.2 and 3.3 for SearchAction, SearchStore and SearchView respectively.

1 // S e a r c h A c t i o n s . js 2 var R e f l u x = r e q u i r e (’ r e f l u x ’) ; 3 var S e a r c h A c t i o n s = e x p o r t s ; 4 S e a r c h A c t i o n s . s e a r c h = R e f l u x . c r e a t e A c t i o n () ; 5 6 e x p o r t { S e a r c h A c t i o n s };

Listing 3.1: Dicoogle Webapp: SearchAction

1 // S e a r c h S t o r e . js 2 var S e a r c h S t o r e = R e f l u x . c r e a t e S t o r e ({ 3 l i s t e n a b l e s : S e a r c h A c t i o n s , 4 i n i t : f u n c t i o n () { 5 t h i s. _ c o n t e n t s = {}; 6 } , 7 o n S e a r c h : f u n c t i o n( d a t a ) { 8 // F e t c h d a t a f r o m s e r v e r 9 ... 10 11 // n o t i f y d a t a c h a n g e s 12 t h i s. t r i g g e r () ; 13 } 14 }) ; 15 16 e x p o r t { S e a r c h S t o r e };

Listing 3.2: Dicoogle Webapp: SearchStore

1 // S e a r c h V i e w . js 2 var S e a r c h V i e w = R e a c t . c r e a t e C l a s s ({ 3 g e t I n i t i a l S t a t e : f u n c t i o n() { 4 r e t u r n { d a t a : [] , 5 s t a t u s : " l o a d i n g ", 6 c u r r e n t : 0};

(61)

7 } , 8 c o m p o n e n t D i d M o u n t : f u n c t i o n() { 9 t h i s. i n i t S e a r c h () ; 10 } , 11 c o m p o n e n t W i l l M o u n t : f u n c t i o n() { 12 // S u b s c r i b e to the s t o r e . 13 S e a r c h S t o r e . l i s t e n (t h i s. _ o n C h a n g e ) ; 14 } , 15 i n i t S e a r c h : f u n c t i o n() { 16 S e a r c h A c t i o n s . s e a r c h (t h i s. p r o p s . i t e m s ) ; 17 } , 18 _ o n C h a n g e : f u n c t i o n( d a t a ) { 19 t h i s. s e t S t a t e ({ d a t a : d a t a }) ; 20 } , 21 r e n d e r : f u n c t i o n() { 22 ... 23 } 24 }) ;

(62)

3.4.4 Architecture

There was an effort to segment Dicoogle Webapp into small components. The main module were broken in small pieces, what allows better enforcement, facilitates the debug and ensures ease of maintenance and future work on the project.

JavaScript files are organized according ReactJS and Flux propose, there are three main packages, the stores, the actions and the components. Component contains the views of our app, they are divided in the main sections: login, search, management, indexer, about. There is also another component package called mixins, here is where all the reusable code should stand.

Login

There is nothing new to say about a login operation, see Picture 3.5. Session is managed on server side, every call to server implicitly creates a new session if there is no session yet. This validation on the server is done using a HttpSession object to track whether the session is active or not.

(63)

All ReactJS components of Dicoogle Webapp use a mixin, see code block 3.4, that check if current user session is valid, if not webapp is redirected to login page.

1 // U s e r M i x i n . js 2 var R o u t e r = r e q u i r e (’ react - r o u t e r ’) ; 3 i m p o r t { U s e r S t o r e } f r o m ’ . . / . . / s t o r e s / u s e r S t o r e ’; 4 var U s e r M i x i n = { 5 m i x i n s : [ R o u t e r . N a v i g a t i o n ] , 6 c o m p o n e n t W i l l M o u n t : f u n c t i o n() { 7 if( U s e r S t o r e . g e t L o g g i n S t a t e () == f a l s e) 8 { 9 // U s e r is not l o g g e d in , go to l o g i n p a g e 10 t h i s. t r a n s i t i o n T o (’ l o g i n ’) ; 11 } 12 e l s e{ 13 // U s e r is l o g g e d in . P r o c e e d ! 14 } 15 } 16 }; 17 e x p o r t { U s e r M i x i n };

(64)

Indexer

The mechanic shown in Picture 3.6 is simple. There are three main methods that interact with servers. To keep the view up to date, the are a timeout loop calling the update method. The other two methods have the responsibility to start and stop tasks.

A finished task is being held in the user interface, and is only removed by action of the user. To achieve that, a java singleton holding all running tasks is created on server keeping track of all tasks that UI should show.

Figure 3.6: Indexer Diagram

Search

Figure 3.7 shows the flow and interaction diagram from search to results. Search view contains two components: SimpleView.js and AdvancedView.js, each one will jump to the same destination, the ResultsView.js.

ResultsView is composed by 4 main views (PatientView.js, StudyView.js, SerieView and ImageView.js), each view is fully dependent of the previous one (except the first). The Store are being listened in parent view and affect all children views. This parent view has always present a button that leads to another view, the ExportView.js. It is in ImageView.js that it is possible to interact with the image itself: Show the image indexed fields and show the image.

(65)

(66)

Management

Figure 3.8 presents the management section, there are a parent view (ManagementView.js) that contain a TabView switching between each child component.

Figure 3.8: Management Diagram

As Figure 3.7 and 3.8 shows, all views that interact with the server have they own Store and Action. All stores have the same behaviour, fetch data from server if needed and notify all components listening them that there are changes and it is needed to render the affected components. Stores are an important piece of our Webapp, allow information to be persisted during the session and share all states between components.

(67)

3.4.5 Styles

The use of CSS preprocessors allows to extend the basic CSS functionalities, such as the use of variables that could be reused or nested css selectors that follow the same visual hierarchy of HTML.

The CSS preprocessor chosen for our Webapp was SASS [23], with files organized in three main folders: core, components and modules. Core folder contains all global variables, like colors, fonts, dimensions and all global styles. This global variable are used in individual styles present into components and modules folder. SASS files are compiled to one unique style file that is imported by Dicoogle Webapp.

3.4.6 Responsiveness

In order to make Webapp responsive to all device sizes, some techniques were used. The first one is the use of media queries, that consists of a media type and an expression that limit the scope of the style. The other technique was the use of Bootstrap [33] Grid System that consists in 12 columns per row that are distributed according with the specified for each screen size. The Grid System is used always when possible mainly on sections containers. For the tables, we used Datatables library. It was introduced a extension for responsive purposes, optimizing tables’s layout for different screen sizes, not only by resizing but removing and wrap columns on mobile devices.

3.4.7 Routes

In order to create a flexibility of integrate the interface with third-party modules, we have created three endpoints that give direct access to Dicoogle user interface. The end-points available are described in table 3.6.

This will allow, for instance, a third-party Webapp has a direct link to results on Dicoogle Webapp.

(68)

Endpoint Description URL query parameters /search Direct access to query results query, provider, keyword

/dump Direct access to dump of image info SOPInstanceID /image Direct access to image SOPInstanceID

Table 3.6: Endpoints for specific UI features

3.4.8 Other components

To facilitate HTML manipulation, it was used jQuery [34]. JQuery also provides a way to communicate with our servers through Ajax requests, it was taken advantage of this ability and all requests are made through this library.

Build on top of jQuery, jQuery UI [35], is a library that provide some widget, effects and interface interactions, it was used in Dicoogle Webapp on several occasions.

All tables presented on Dicoogle make use of Datatables library [36]. It allows to create tables with a build in set of features, such as paging, ordering, filtering, among others.

Finally, Dicoogle Webapp was build with Bootstrap [33] framework, it helps build user interface components. Besides forms, buttons, navigation and other components, it also provide a great grid system that was used mainly to give responsive capabilities to our Webapp.

(69)

Chapter 4 Results and discussion

This chapter shows the results of the work done in this thesis.

4.1 Overall Solution

Dicoogle Webapp is an web application developed to adopting the web oriented archi-tecture. This brand new Webapp allows users to search DICOM files, dump all DICOM object meta-data and visualize the image with a simple integrated viewer. The user have also the ability to manage all Dicoogle related options, such as: index and tranference options, manage services status, edit storage servers and view all logs about the system. Moreover, the user have now the ability to fully manage index tasks.

Compared to the old desktop version, Dicoogle now have the capacity of being used on any web-enabled device.

4.2 User Experience

The new Dicoogle Webapp presents now a clean and organized interface. It contains all the features that old desktop interface had. However, there were some modifications that improve the user experience.

(70)

4.2.1 User Account

When a user tries to access any page of webapp, and there is no valid session available, the user is redirected to the login page as figure 4.1 presents. After correctly authentication, the Webapp page will be displayed.

Figure 4.1: Dicoogle: Login

4.2.2 Search

There are available two search modes. Simple and Advanced. Figure 4.2 shows the simple search page.

The search queries are more intuitive when compared to the old interface. On the same input, the system detects if it is a simple or keyword query. This detection is done by regex expressions.

Example of query with keywords:

(71)

Figure 4.2: Dicoogle: Search

The advanced query mode shown in figure 4.3 allows the user to build queries with the help of graphical controls available in the interface. It is allowed to specify name, id and gender of a patient. It is also possible to detail institution name, physician, operator name, modality and date of a study.

(72)

4.2.3 Visualization

Figure 4.4 presents an example of query results that were divided into four parts: patients, studies, series and images. Navigation is doing by steps, select the patient then select the study then serie and finally image.

The button ”Export” present in figure 4.4 is to export the results to CSV, giving the hypothesis to choose which fields to export.

Figure 4.4: Dicoogle: Results

First step of results presents the patients for a query search. This step contains a table with patient id, name, gender and number of studies. After selecting a patient, the user is taken to step 2. Step 2 displays all studies for the chosen patient and the informations about the study are: date, description, institution name and modality. Third step show all series of a study, allowing user to see number, modality, description and number of images. The last step is the visualization of all the images that match the choices made in previous steps.

In the image step, the user have the ability to view the image in a simple viewer, see an example in figure 4.5(a).

(73)

The user also has the ability to dump all indexed fields (i.e. DICOM object meta-data) as figure 4.5(b) shows.

(a) Image View _{(b) Image Dump}

Figure 4.5: Dicoogle: Image informations

The result page can be accessed directly by third-party apps as mentioned in 3.4.7. The informations shown in figure 4.5 also can be directly accessed through endpoint but instead of an popup, the same info will be present on a new page.

(74)

4.2.4 Management

The Webapp have a section with all management options.

Index Options

In figure 4.6 we can see all index options available. The main option is the ability of Dicoogle to monitoring a directory, this option enables automatic indexing of all DICOM files present in it and directory monitorization path can be edited. Beyond directory watch, the user is able to do some other configurations, such as: enable the indexing of zip files, save thumbnail and set thumbnail size.

All changes made in this section were only active after saved with the displayed button for this purpose.

(75)

Transfer Options

Figure 4.7 presents transfer storage options. It allows to select the supported encoding rules for each SOP class. As there is no text input on that options all changes made are sent in real time to Dicoogle server.

(76)

Services

It is possible to start and stop services as well as to define server ports and auto start options. Figure 4.8 illustrates the user interface to manage services on Dicoogle. The available services are Storage and Query Retrieve Service. Additionally, Query Retrieve have some advanced settings.

Figure 4.8: Dicoogle: Management services

Storage Servers

The Fourth tab of management section is Storage Servers (Figura 4.9). That view presents a list of storage servers. For add a new storage server the user must enter the AETitle, IP address and Port of the desired server.

(77)

Figure 4.9: Dicoogle: Storage Servers

Logs

Monitorize the server is also an important feature. So as Figure 4.10 shown the user have the ability to consult the server logs that are being updated automatically.

(78)

4.2.5 Indexer

The feature that obligated to more refactoring was the indexing section, that was moved from the management section to the main menu. Beyond location, it is now more complete, allowing to index more than one URI and monitorize the progress of each one (Figure 4.11).

Figure 4.11: Dicoogle: Indexer

The interface provide all info about a task. It is shown identification of the task: name and UID. The user is also informed of all metrics for a task, the percentage of progress, elapsed time and the number of objects indexed and non-indexed. By providing a URI to the location, the user can start a index task.

(79)

4.3 Validation

The validation of Dicoogle Webapp was done through tests performed in the following devices: desktop, Android devices, iPhone, iPad. In all devices the behavior was the expected. In relation to browser, was tested in Chrome, Firefox and Safari. Figure 4.12 shows a example of Dicoogle on a mobile device.

Once the decision was made to use new technologies, it was not taken into account the compatibility with older browser versions, so there is the possibility of lack of support for some features.

(80)

4.4 Discussion

At a time that web technologies are in constant evolution the project presented here was fully developed with free state-of-the-art technologies that make it independent of platform.

The results presented will in accordance with the objectives set at the begin, we can conclude that the objective was reached.

Comparing with the previous developed interface, we now have a more complete and coherent interface, benefiting the user experience. With the results, now it’s possible to abandon the old GUI. The base created here allows a flexible way to add new features and plugins, allowing the easy expansion of the Dicoogle Webapp.

Of the eight PACS analyzed in section 2.1.4 only three have Web Client. The impor-tance of Dicoogle having a platform with a complete, scalable and very flexible Webapp is an asset to relevance of this PACS platform for the medical imaging sector.

Finally, the chosen tools allowed a modeling of the entire application according what is defined by the framework (i.e. ReactJS). The result of following a pattern, and so structure the code as it should, is a code with high quality in terms of maintenance. Not counting the time of learning, the speed of development was favored by doing use of generic modules, taking advantage of code reuse.

(81)

Chapter 5 Conclusions and Future Work

In this chapter we summarize the work developed. We mention the accomplishments, issues and point direction for future work.

5.1 Accomplishments

The work developed in this thesis has several contributions to the continuity and growth of the project Dicoogle. Moreover, the health professionals who are now able to make use of the platform it was important.

The main goals have been achieved, such as:

• All features are now supported by RESTful services.

• The Webapp became fully independent of the server.

• The Webapp can now be deployed on another machine and location of server.

• Webapp is developed based on state-of-the-art technologies with huge potential of growing.

(82)

5.2 Issues

The first problem encountered was the size of the project, there was some difficulty understanding the entire architecture and existing infrastructure. During implementation, it was difficult to build a setup for the Webapp development. The application is based on various new technologies and it took some time to get everything ready to work.

Throughout the project, it was necessary to handle large amounts of data, that imposed several difficulties when it comes to render such data.

5.3 Future Work

Despite the main goals have been achieved, there is still much work that can be done. Below are summarized the main points that must be followed to improve and expand this solution.

• Explore React-Native: an extension of react to mobile devices which will allow to have a better performance on mobile enviroments [37].

• Integrate Plugin Systems in the Graphical Environment: it will allow to extend the search interface to Content-Base-Image-Retrieval (CBIR) [38].

• Capability to integrate third-party web viewer in embedded enviroment.

• Integrate Dicoogle Statistics. A platform to show aggregated data regard to dose and productivity metrics [39].

(83)

Bibliography

[1] O. S. Pianykh, Digital Imaging and Communications in Medicine, 2010.

[2] M. Richards, Software Architecture Patterns, 2015.

[3] “Flux — Application Architecture for Building User Interfaces.” [Online]. Available: https://facebook.github.io/flux/docs/overview.html [Accessed: 2015-05-27]

[4] C. Costa, C. Ferreira, L. Basti˜ao, L. Ribeiro, A. Silva, and J. L. Oliveira, “Dicoogle - An open source peer-to-peer PACS,” Journal of Digital Imaging, vol. 24, no. 5, pp. 848–856, Oct. 2011.

[5] “DICoogle.” [Online]. Available: http://www.dicoogle.com/ [Accessed: 2015-01-30]

[6] J. Marks, “Medical Imaging for Improved Patient Care Contents,” pp. 1–8, 2007.

[7] R. Haux, “Health information systems - Past, present, future,” International Journal of Medical Informatics, vol. 75, pp. 268–281, 2006.

[8] H. Huang, PACS and Imaging Informatics - Basic Principles and Applications, vol. 24.

[9] “DICOM PS3.1 2014c - Introduction and Overview.” [Online]. Available: http: //dicom.nema.org/medical/dicom/current/output/pdf/part01.pdf [Accessed: 2015-01-28]

[10] L. Jr, R. Copetti, E. Comunello, and A. Wangenheim, “Um Modelo para Comunica¸c˜ao de Dados DICOM em Redes de Telemedicina de Baixa Velocidade.”

(84)

[11] N. E. M. Association, “Digital imaging and communications in medicine (DICOM) Part 3: Information object definitions,” p. 46, 2011. [Online]. Available: http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle: Digital+Imaging+and+Communications+in+Medicine+(DICOM)+Part+3:

+Information+Object+Definitions#4

[12] Apache Software Foundation, “Apache Lucene Core,” 2014. [Online]. Available: http://lucene.apache.org/core/ [Accessed: 2015-01-30]

[13] “Orthanc - DICOM Server.” [Online]. Available: http://www.orthanc-server.com/ about.php [Accessed: 2015-01-30]

[14] Rosset A., “OsiriX - DICOM Viewer,” 2003. [Online]. Available: http: //www.osirix-viewer.com/index-m.html [Accessed: 2015-01-30]

[15] G. Zeilinger, “dcm4che: Open Source Clinical Image and Object Management.” [Online]. Available: http://www.dcm4che.org/ [Accessed: 2015-01-30]

[16] “UCLA Medical Imaging Informatics Medical Imaging Informatics.” [Online]. Available: http://www.mii.ucla.edu/opensourcepacs [Accessed: 2015-01-30]

[17] “K-PACS.” [Online]. Available: http://www.k-pacs.net/ [Accessed: 2015-01-30] [18] Marcel van Herk, “Conquest DICOM software.” [Online]. Available: http:

//ingenium.home.xs4all.nl/dicom.html [Accessed: 2015-01-30]

[19] “MRIdb.” [Online]. Available: http://www3.imperial.ac.uk/bioinfsupport/resources/ software/mridb [Accessed: 2015-01-30]

[20] S. Aghaei, “Evolution of the World Wide Web : From Web 1.0 to Web 4.0,” Interna-tional journal of Web & Semantic Technology, vol. 3, no. 1, pp. 1–10, 2012.

[21] A. Mesbah and A. Van Deursen, “Migrating multi-page web applications to single-page AJAX interfaces,” pp. 181–190, 2007. [Online]. Available: http://www.st.ewi.tudelft.nl/∼_{arie/papers/spci/csmr2007.pdf [Accessed: 2015-01-17]}

(85)

[22] “Node.js.” [Online]. Available: http://nodejs.org/ [Accessed: 2015-01-31]

[23] “Sass: Syntactically Awesome Style Sheets.” [Online]. Available: http://sass-lang. com/ [Accessed: 2015-02-01]

[24] “Getting started — Less.js.” [Online]. Available: http://lesscss.org/ [Accessed: 2015-02-01]

[25] “Responsive Web Design Basics Web Fundamentals.” [Online]. Avail-able: https://developers.google.com/web/fundamentals/layouts/rwd-fundamentals/ [Accessed: 2015-05-26]

[26] Google, “AngularJS Superheroic JavaScript MVW Framework,” 2014. [Online]. Available: http://angularjs.org/ [Accessed: 2015-01-31]

[27] “Backbone.js.” [Online]. Available: http://backbonejs.org/ [Accessed: 2015-01-31] [28] Ember, “Ember.js - A framework for creating ambitious web applications,” 2014.

[Online]. Available: http://emberjs.com/ [Accessed: 2015-01-31]

[29] “React: a Javascript Library for Building User Interfaces.” [Online]. Available: http://facebook.github.io/react/ [Accessed: 2015-01-31]

[30] “NPM.” [Online]. Available: www.npmjs.com [Accessed: 2015-02-10]

[31] “Browserify.” [Online]. Available: http://browserify.org/ [Accessed: 2015-05-29] [32] “Getting Started with Flux ReactJS News.” [Online]. Available: http:

//reactjsnews.com/getting-started-with-flux/ [Accessed: 2015-05-27]

[33] “Bootstrap The world’s most popular mobile-first and responsive front-end framework.” [Online]. Available: http://getbootstrap.com/ [Accessed: 2015-05-28] [34] “jQuery.” [Online]. Available: http://jquery.com/ [Accessed: 2015-05-28]