Having analytical capabilities inside clinics is an obeyed step forward since most diagnosing data is currently created in a format suitable to computer processing. The advantages of having the machines working on the extraction of numbers benefit all parts of the healthcare pipeline, fastening verdict generation, broadening the use of stored data, cross-correlating the multiple sources of information, and profiting from theoretically unlimited quantifications, which are the core for creating evidencebased verdicts, fast population analysis, more accurate diagnosis, enforcement of patients' adherence to treatment and interinstitutional cooperation envisaging the use of big data and artificial intelligence. Nevertheless, such a platform requires integrating several subsystems that developers still need to conceive to interact with each other. Additionally, the automation must comply with confidentiality regulations; therefore, security breaches are open while processing the data. The presented work involves the development of an architecture capable of allocating an unlimited number of algorithms inside healthcare facilities, which provides quantifications without perturbing the operation of the transport utilities that are already working. Moreover, the presented design can return numbers to a centralizer that keeps a simple yet robust protocol to assert inter-institutional cooperation around big data and artificial intelligence implementations.
With the advent of artificial intelligence, the data stored in healthcare facilities suddenly gained
unexpected relevance. Hospitals, clinics, and healthcare administrators initially obeyed to save
patient records by law [
Recent Artificial Intelligence (AI) implementations in medicine and other high-impact fields
have created an optimistic atmosphere around many possibilities that might emerge when
machines execute tasks [
Once these dificulties are solved, developers might want to share numbers among several
institutions, a task that requires administration and management input. Interinstitutional
integration is desirable because it spreads the usability of AI to more extensive geographical
regions [
This manuscript presents the design and implementation of a data architecture integrating access to standard transport managers and algorithms to share the resulting quantifications with a data centralizer. The architecture automates the extraction of numbers that describe pathologies’ verdicts and treatment-tracking responses inside the institutions and shares labeled numbers with the centralizer, where a higher hierarchy implementation runs population analysis to provide a myriad of new AI-based services to society.
This document is organized as follows: the materials and methods sections present the technicals behind the solution implemented to assert querying flexibility and, thus, enable the capability to retrieve data from any repository. Then, we explain how the final users can program jobs using smartphones or web interfaces by perfecting their querying interfaces and defining the algorithms for the programmed jobs. Finally, we present the schematics for the architecture capable of reading and executing the jobs while complying with confidentiality regulations. The materials and methods section ends with two detailed proofs of concepts where we produce analytics using the proposed architecture. In the results section, we display interface prototypes of the syncing utility since those views are the highest-level component of a solution for the problems that motivated this work. The results section also provides evidence for the two proofs of concept listed in the materials and methods section. Finally, we discuss the inclusion of analytics into medical pipelines and further work. In the conclusion, we concisely resume the more striking contributions of this work.
The synchronizing interface will serve as a referee by signaling the functionalities required to
provide analytics and automatic reporting inside clinics and hospitals. The proposed architecture
should comply with protocols of specific appliances and be flexible enough to keep operative
regardless of infrastructure size or running applications. Moreover, the design should consider
adding new data sources, new sharing numerical data schemes, and new reporting templates
without afecting the operation of the already established services. The syncing interface should
provide redundant security mechanisms since this device is physically visible and accessible
within hospital premises. Access to the configuration methods of this device would represent a
security breach that might render void its usability under HIPAA terms [
The presented architecture allows healthcare providers to schedule data processing tasks easily.
The pipeline starts when a user’s smartphone synchronizes with the Evalu@ service (E@) [
Since the E@-Med – the local interface – initiates the communication with the E@ service, there is no space for security breaches, and keeping the link alive with distinct institutions remains under local control.
Regardless of network security and complexity, hospitals and clinics rely upon TCP/IP for data transport. Applications such as File Transfer Protocol (FTP), its secure version SFTP, Pop3 or IMAP for emailing, or the specialized PACS are extensions of the platforms supporting the
Institutional querying instruments
Load once Forms filling Acq date (0008,0032)? Acc number (0008,0050) ? Modality (0008,0060)? ...
Specfic fields for specific repository ...
Form for repository A (cid, eitid, eid, aid)
Form for repository B (cid, eitid, eid. aid)
Institution B
internet. Therefore, accessing a local or remote repository can be generalized as shown in
Figure 2. In general, a user willing to retrieve data – human or robot – will need to provide
the IP address of the machine where the information resides, namely the "host," a username,
and a password. The host is an IP address or a human-readable name that will be translated to
its correspondent IP address in networks with active domain name servers (DNS); otherwise,
the IP address will be enough to activate the Address Resolution Protocol (ARP) that completes
the TCP/IP requirements to establish a communication between computers in share media. At
this moment, the syncing interface (E@+Med) will deliver the user and passwords through the
recently established channel, and, in case access is granted, the syncing interface will need to
provide the querying string that varies in extent and complexity depending on the repository
or a path inside the host in less complex transport applications [
The aid variable holds a unique identifier for tested and approved algorithms, in which docked
executables are uploaded to E@ as in an application repository such as Android or Apple stores.
Then, E@ shares those docked codes with every registered E@-Med, making the software
solutions available to all users with accounts in at least one of the collaborating institutions.
The architecture warrants data processing inside the institutions within a protected domain.
When users define the querying string to filter data, they also select the algorithm(s) for
processing. The algorithm developer defines the deliverables of each solution, and users accept
the implementation as it is. With the querying string, the E@-Med brings the data, decrypts it,
anonymizes it, and makes it available in a temporal directory, as we presented in [
Only moving the data and making it available for research endeavors is one of the most solicited applications. The data should be anonymized and converted to a format that is easy to transport. The most critical case happens when DICOM data are required after screening for a specific pathology, patient’s age, gender, or treatment. The user can also set aspects such as the number of studies and the range of creation dates. As explained in Section 2.2, each repository defines the fields needed to create an order. For this purpose, a user employs the string query creation functionality to filter the data. What follows for this particular application does not need data processing; instead, it will request an action from an IRB member, which consists in authorizing the IRB study to be delivered to the requesting user. The system will provide emails to inform process flagging and availability.
One common problem in radiology and neurosurgery units is monitoring the correct operation of installed CSF draining valves. Young hydrocephalus patients often receive an MRI before and after surgically placing the device. The medical images are taken at diferent moments, and the MRI technician defines imaging parameters to proceed with the critical constraint of favoring the patient’s comfort, thus producing the images in the shortest possible time. This proof of concept shows the results of an algorithm that reports the diferences in ventricular volumes between studies. The Querying string is specific about grabbing FLAIR T2 images produced in a range of rates over one patient id; therefore, the algorithm will try to segment the lateral ventricles in all found volumes and report them with the study acquisition date. Additionally, the final report displays a 3D reconstruction of the segmented structures with the read volumes in mm3.
The syncing interface displays eight environments to all authenticated users, except for the super-administrator, who will see the ambient to manage users. The signing-in process includes a tokenized key sent to the institutional email and a fingerprint reading, such as security robustness to respond to HIPAA regulations. The interfaces shown in Figure 4 correspond to diferent displays where the administrators control the available repositories.
The add repository interface allows the administrator to define unlimited databases. There is no fixed template to explain the connection parameters. Instead, the administrator is encouraged to provide suficient information in the form key:value to have successful connections, and this lfexibility also supports further changes to repositories’ security. The E@-Med interface will use both keys and values to connect the storage as shown in Figure 2.
In Figure 5, panel A shows the superficial functionality for repositories. From here, an administrator can turn the access to algorithms on and of, and this action will be reflected system-wide. To add an algorithm, the administrator should use the add algorithm function (screenshot not shown).
Panel B of Figure 5, presents the only screen for the exclusive use of super-administrators. From here, the authorized user can give access to the critical functions of E@-Med to secondlevel administrators after registering their fingerprints; therefore, someone will always be available in the hospital’s facilities to control the system’s behavior in local environments.
After the IRB has authorized the use of clinical data, the files are delivered without encryption, anonymized, and in Nifti format. The new container concatenates the individual DICOM files and deletes the DICOM headers; therefore, the new files occupy less space in the disk and are easier to transport. Figure 6 displays a query run on the command line as the E@-Med would do with the configured Cron job. The presented connection involves a PACS system, and a video of this interaction is available at www.fernandoyepesc.com..
An algorithm based on the Automatic Ventricular Volume Estimator AVVE runs on MRI volumes of the same subject. The querying string used a patient number and study creation date constraints. Therefore, for the specific case, two volumes are compared. The Data gathering process occurs in the same manner presented in Section 3.2. After that, the system calls the modified version of the AVVE and provides the gathered volumes – two volumes due to the date constraint – for processing. The system creates the report shown in Figure 7, which can be dicomized and sent back to PACS. The processing also includes returning Evalu@ the patient’s age in days and the ventricular volumes before and after the shunt procedure.
Authors producing thousands of methods developed year by year in research units will not have
the opportunity to implement their creations in a production environment. Such a situation
precludes the use of technology to benefit many aspects of current healthcare methods. The
transport utilities inside hospitals – as specialized as PACS or simple FTP-based ones – could be
adjusted to move the data to temporal storages where algorithms perform diverse quantifications.
With such a level of Generalization, proposals such as integrating the Radiology Information
Systems (RIS) and PACS to complement the storing and data-sharing capabilities and provide
this new platform with image processing capabilities [
Instead, the proposed architecture covers the need for analytics in hospitals and clinics where
algorithms are used globally. The authors can test their creations in real arenas and gain prestige.
When an algorithm is valuable and infallible, healthcare institutions will use it to obtain all the
benefits that several authors have agreed on regarding the need for analytics within hospitals
[
The presented architecture integrates several communication systems and is flexible to incorporate new repositories with cutting-edge security strategies of today and further ones. The presented protocol assures that external communication does not propagate confidential information and algorithm execution happens in local facilities using local resources. Additionally, the system facilitates job programming by integrating smartphone technology.
Further developments involve the creation of a testing environment where authors can check feasibility while the platform assures the rightness of the presented codes. Also, we envisage the creation of new algorithms and the possibility of connecting them in compounded pipelines.
The presented interface is a flexible system that enables analytics inside hospitals, respecting HIPAA and implementing a protocol that allows interinstitutional collaboration to support artificial intelligence implementations. Confidentiality compliance is accomplished when the system only allows human interaction in the tasks’ programming and when receiving the reports. Additionally, the proposed architecture gives local administrators the faculty to turn of the components of the system at will.