Name: executing complexity-increasing queries in relational (mysql) and nosql (mongodb and exist) size-growing iso/en 13606 standardized ehr databases
Uploaded: 2018-03-19T14:30:00.000+00:00
Duration: 7 min 26 s
Description: Watch this Scientific Journal Video about Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases at JoVE.com

The authors would like to thank Dr Dipak Kalra, leader of the EHRCom task force that defined the ISO/EN 13606 standard and his team from University College London for their kind permission to use the ISO/EN 13606 W3C XML Schema.
This work was supported by Instituto de Salud Carlos III [grant numbers PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 and RD16CIII].

1. Build a Relational MySQL DBMS to Store Three Double Sized Standardized EHR Extracts Databases
<ol>
	<li>Import the W3C (World Wide Web Consortium) XML Schema corresponding to the ISO/EN13606 RM and the ISO21090 Data types into a &#39;Java IDE&#39; (Integrated Development Environment). 
	NOTE: ISO stands for International Standards Organization. EN stands for European Norm.</li>
	<li>Execute the JAXB (Java XML Binding) plug-in in the IDE; this produces Java classes corresponding to the structure of the elements of the EHR extracts XML files.</li>
	<li>Tag manually the Java classes produced with JPA labels. These labels refer to the cardinalities and other relations between the relational tables of the MySQL database.</li>
	<li>Import the libraries of the JPA (Java Persistence API) into the IDE and execute the method that builds a MySQL database out of the tagged Java classes.</li>
	<li>Create three directories with 5,000, 10,000 and 20,000 realistic EHR extracts XML files.</li>
	<li>Execute the JPA method to load an XML extract into the MySQL DBMS on all the extracts of the 5,000 extracts directory.</li>
	<li>Repeat step 1.6 twice, once with the 10,000 extracts directory and once with the 20,000 extracts directory.</li>
</ol>
2. Build a NoSQL MongoDB DBMS to Store Three Double Sized Standardized EHR Extracts Databases
<ol>
	<li>Process each of the three directories containing 5,000, 10,000 and 20,000 realistic EHR extracts XML files with a standard program to convert XML files to JSON files, such as json.org.XML. Three directories with 5,000, 10,000 and 20,000 JSON files should be produced.</li>
	<li>Launch a MongoDB GUI (Graphic User Interface, see Table of Materials).</li>
	<li>Launch the MongoDB 2.6 server executing the mongod program from a DOS (Disk Operating System) system window.</li>
	<li>Connect the MongoDB GUI to the localhost server using port 27017.
	<ol>
		<li>Select the &#34;Connect&#34; menu.</li>
		<li>Write a name for the connection (for instance &#39;first&#39;).</li>
		<li>Write localhost:27017 in the DB Server textbox.</li>
		<li>Press the &#34;Connect&#34; button ; a tree with the current databases should appear on the left.</li>
	</ol>
	</li>
	<li>Build a database containing 5,000 standardized EHR extracts.
	<ol>
		<li>Click on the name of the connection at the top of the tree on the left.</li>
		<li>Select the &#34;File&#34; menu.</li>
		<li>Choose &#34;Add Database&#34;.</li>
		<li>Enter the name of the database in the dialog that appears.</li>
		<li>Click OK.</li>
	</ol>
	</li>
	<li>Build a collection containing 5,000 standardized EHR extracts.
	<ol>
		<li>Click on the name of the database in the tree on the left.</li>
		<li>Select menu &#34;Database&#34;.</li>
		<li>Choose &#34;AddCollection&#34;.</li>
		<li>Enter the name of the collection in the dialog that appears.</li>
		<li>Click &#34; create&#34;.</li>
		<li>Click on the name of the collection.</li>
		<li>Select the &#34;Import&#34; menu.</li>
		<li>Choose radio button &#39;&#39;JSON - mongo shell / / mongoexport&#34;.</li>
		<li>Click &#34;next&#34;.</li>
		<li>Press the &#34;Add Source Files&#34; button.</li>
		<li>Navigate on the computer using the dialog.</li>
		<li>Open the directory containing 5,000 JSON extract files.</li>
		<li>Select all the files in the directory.</li>
		<li>Press &#34;Open&#34;. The list of JSON files should appear in the Import dialog.</li>
		<li>Press &#34;Next&#34;; a preview of the new collection in the database appears on the left.</li>
		<li>Press &#34;Next&#34;.</li>
		<li>Press &#34;Start Import&#34;. The progress of the import appears down on the left, indicating the number of files imported and the elapsed time.</li>
	</ol>
	</li>
	<li>Repeat steps 5 and 6 to build a collection of 10,000 standardized EHR extracts.</li>
	<li>Repeat steps 5 and 6 to build a collection of 20,000 standardized EHR extracts.</li>
</ol>
3. Build a NoSQL eXist DBMS to Store Three Double Sized Standardized EHR Extracts Databases
<ol>
	<li>Launch the eXist database.</li>
	<li>Using the database&#39;s icon, open the Java Admin Client.</li>
	<li>Enter the admin password.</li>
	<li>Press the &#34;Connect&#34; button.</li>
	<li>Build a collection containing 5,000 standardized EHR extracts.
	<ol>
		<li>In the toolbar, select the menu &#34;Create a new Collection&#34;.</li>
		<li>In the dialog that appears, type the name of the new collection.</li>
		<li>Click &#34;accept&#34;; the new collection will appear.</li>
		<li>Select the name of the collection.</li>
		<li>In the toolbar, select the menu &#34;Store files in the database&#34;.</li>
		<li>Navigate on the computer using the dialog box.</li>
		<li>Select the directory containing 5,000 standardized XML extract files.</li>
		<li>Click the button &#34;Select the files or directories to store&#34;. Note that a dialog box appears showing the progress, the files being stored, and the percentage of the database created.</li>
	</ol>
	</li>
	<li>Repeat step 5 to build a collection containing 10,000 standardized EHR extracts.</li>
	<li>Repeat step 5 to build a collection containing 20,000 standardized EHR extracts.</li>
</ol>
4. Design and Execute in the 3 Relational MySQL Databases 6 Complexity-Increasing Queries
<ol>
	<li>Design six complexity-increasing queries according to the archetypes used by the EHR extracts.</li>
	<li>Program an SQL script with the first query on the MySQL database. The SQL must adapt to the special structure of the MySQL database due to extracts standardization (archetypes). The database maps the whole structure of the extracts. As a result, the SQL query is rather complex.</li>
	<li>Identify the attributes of the databases that would speed up the response time of the queries if an index was built on them, then construct such indexes, though most indexes are built automatically by the DBMS.</li>
	<li>If a query needs a non-automatically built index, build it manually.
	<ol>
		<li>Connect to the MySQL server (Supplementary Figure 1).</li>
		<li>Select and click on the database name on the left.</li>
		<li>Select and click on the relational table where the indexed field resides.</li>
		<li>Click on the tab &#34;Structure&#34;.</li>
		<li>Select and click on the column where the index will be built.</li>
		<li>Click on &#34;index&#34;. Note that the SQL sentence building the index appears, and a message stating that the sentence has been built successfully appears.</li>
	</ol>
	</li>
	<li>Execute the first query.
	<ol>
		<li>Select and click on the database name on the left.</li>
		<li>Click on the tab &#34;SQL&#34;.</li>
		<li>Write or paste the SQL code of the first query (see Supplementary Figure 2).</li>
		<li>Press &#34;continue&#34;. Note that the first screen of the list of results appears, along with a message with the execution time of the query.</li>
		<li>Repeat the execution 5 times and compute the average response time.</li>
	</ol>
	</li>
	<li>Repeat step 5 with queries 2 through 6.</li>
	<li>Do the whole process three times, with the 5,000, 10,000 and 20,000 extracts databases.</li>
</ol>
5. Design and Execute in the 3 NoSQL MongoDB Databases 6 Complexity-Increasing Queries
<ol>
	<li>Launch the MongoDB GUI (see Table of Materials).</li>
	<li>Launch the MongoDB 2.6 server executing the mongod program from a DOS system window (see Supplementary Figure 3).</li>
	<li>Follow step 2.4 to connect the MongoDB GUI to the localhost server using port 27017.</li>
	<li>Select and expand the MongoDB database on the left side.</li>
	<li>Select the collection.</li>
	<li>Click on the &#34;Collection&#34; menu in the toolbar.</li>
	<li>Execute the first MongoDB query.
	<ol>
		<li>Double-click the &#34;Query Builder&#34; button.</li>
		<li>Double-click on the &#34;Query field&#34; of the Query Builder at the right.</li>
		<li>Write the field of the MongoDB query in the field textbox of the query panel (See Supplementary Figure 4).</li>
		<li>Write the value of the MongoDB query in the value textbox of the query panel. 
		NOTE: This query should be something like {&#34;ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. value&#34;: &#34;Descripcion&#34;}. The field and the value are quoted and separated by semicolon.</li>
		<li>Double-click on the Projection field of the Query Builder</li>
		<li>Write the first projection in the projection textbox (see Supplementary Figure 5).</li>
		<li>Double-click on the projection field to add a new projection textbox.</li>
		<li>Write the second projection in the projection textbox. 
		NOTE: A projection selects a part of the document retrieved by the query. These should be something like {&#34;ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value&#34;: 1} and {&#34;ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor&#34; : 1}</li>
		<li>Click on the blue play button to execute the query.</li>
		<li>Visualize the query code in the Query Code tab.</li>
		<li>View the details of the result in the Explain tab: number of results, execution time in milliseconds.</li>
		<li>View, expand, and examine the results in the Result tab.</li>
		<li>If further processing of the query is required, write a Java program with the MongoDB Java driver with the query and a method to process the results.</li>
		<li>Repeat the execution 5 times and compute the average response time.</li>
	</ol>
	</li>
	<li>Do step 5.7 for the remaining 2 through 6 queries.</li>
	<li>Repeat the whole process in the 5,000, 10,000 and 20,000 extracts MongoDB databases.</li>
</ol>
6. Design and Execute in the 3 NoSQL eXist Databases 6 Increasing-Complexity Queries
<ol>
	<li>Launch the eXist DBMS.</li>
	<li>Open the Java Admin Client.</li>
	<li>Press the button &#34;connect to the database&#34;.</li>
	<li>Select the database and click on it.</li>
	<li>Click on the menu &#34;Consult database using XPath&#34;; the consult dialog box appears.</li>
	<li>Execute the first XPath query (see Supplementary Figure 6).
	<ol>
		<li>Write or paste the XPath code of the first query in the upper part of the dialog box.</li>
		<li>Click on the menu &#34;Execute&#34; in the toolbar of the dialog box.</li>
		<li>View XML results using the &#34;XML&#34; tab in the lower part of the dialog box.</li>
		<li>View number of results and compilation and execution time at the bottom of the dialog box.</li>
		<li>Repeat the execution 5 times and compute the average response time.</li>
	</ol>
	</li>
	<li>Repeat step 6 for queries 2 through 6.</li>
	<li>Do the whole process three times, for the 5,000, 10,000 and 20,000 extracts eXist databases.</li>
</ol>
7. Design and Execute a Concurrency Experiment using the MySQL and MongoDB 5,000 Extracts Databases
NOTE: The eXist database has been removed from the experiment at this juncture due to worse performance in the previous experiments.
<ol>
	<li>Select the queries with the three shortest time responses in the previous experiments using the 5,000 extracts databases (typically under several seconds).</li>
	<li>Identify and manually build appropriate attribute indexes for those queries, if necessary.</li>
	<li>Program two Java multithread applications, one for MySQL and the other for MongoDB; each application will have three different priority threads, one for each query selected in step 1.</li>
	<li>Execute and compute the CPU (Central Processing Unit) use distribution for each thread (query).</li>
	<li>Execute each multithread application, clicking on the execute button five times during each 10-min span, and compute the most executed (highest priority) query average throughput and the average time response of the three queries.</li>
	<li>View the queries in execution, with priorities and execution time.</li>
	<li>Compute average throughput and average response time of each of the three queries.</li>
</ol>

<ol>
	<li>Codd, E. F. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=A+relational+model+for+large+shared+data+banks.">A relational model for large shared data banks.</a> Comm ACM. 13 (6), 377-387 (1970).</li><li>Kalra, D., Lloyd, D. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=.">.</a> ISO 13606 electronic health record communication part 1: reference model. , (2008).</li><li>Kalra, D., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=.">.</a> Electronic health record communication part 2: archetype interchange specification. , (2008).</li><li>Kalra, D., Beale, T., Heard, S. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=The+openEHR+foundation.">The openEHR foundation.</a> Stud. Health Technol. Inform. 115, 153-173 (2005).</li><li>Beale, T. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Archetypes:+constraint-based+domain+models+for+future+proof+information+systems.">Archetypes: constraint-based domain models for future proof information systems.</a> OOPSLA, Workshop Behav Semant. , (2002).</li><li>S&#225;nchez-de-Madariaga, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Examining+database+persistence+of+ISO/EN+13606+standardized+electronic+health+record+extracts:+relational+vs.+NoSQL+approaches.">Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches.</a> BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).</li><li>Ireland, C., Bowers, D., Newton, M., Waugh, K. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Understanding+object-relational+mapping:+a+framework+based+approach.">Understanding object-relational mapping: a framework based approach.</a> Int. J. Adv. Softw. 2, 202-216 (2009).</li><li>. Node+Path Persistence Available from: <a target="_blank" href="https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence">https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence</a> (2017)</li><li>Wang, L., Min, L., Wang, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Archetype+relational+mapping+-+a+practical+openEHR+persistence+solution.">Archetype relational mapping - a practical openEHR persistence solution.</a> BMC Medical Informatics and Decision Making. 15, 88 (2015).</li><li>Kaur, K., Rani, R. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=Managing+data+in+healthcare+information+systems:+many+models,+one+solution.">Managing data in healthcare information systems: many models, one solution.</a> Computer. March. , 52-59 (2015).</li><li>Sabo, C., Pop, P. C., Valean, H., Danciulescu, D. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed&cmd=Search&doptcmdl=Citation&defaultField=Title+Word&term=An+innovative+approach+to+manage+heterogeneous+information+using+relational+database+systems.">An innovative approach to manage heterogeneous information using relational database systems.</a> Advances in Intelligent Systems and Computing. 557, (2017).</li></ol>

The authors have nothing to disclose. The datasets used in these experiments were provided by several Spanish hospitals under license for these experiments and consequently are not publicly available. The ISO/EN 13606 RM XML schema was provided by the University College London Centre for Health Informatics &amp; Multiprofessional Education (CHIME).

This protocol shows that pure relational ORM systems do not seem practical for single-patient queries (Q1, Q3, and Q4) since response times are slower, probably due to a high number of relational tables performing many expensive join operations, and due to the storage system used by the specific kind of database. NoSQL databases store data in a document-based fashion, while relational systems use a table-based fashion that spreads each document throughout the whole database. NoSQL systems show a linear slope, with MongoDB performing considerably faster than eXist DBMS. In concurrency, MongoDB also behaves much better than relational MySQL ORM7.
This protocol presents a troubleshooting protocol for the results presented in7 regarding the ORM MySQL DBMS. The MySQL system has been updated to the latest version and the results have been slightly modified. In addition, a critical point in document-based NoSQL systems such as MongoDB is that they may preserve consistency when storing medical information7 because when an EHR extract is updated, it is not overwritten, but a whole new extract with the new data is generated and stored in the system, and the original extract is maintained. This is a strict requirement of medical information, because some medical practitioners may have made important medical decisions based on the original data.
The improved relational ARM system drastically diminishes the number of relational tables and improves relational performance. However, since it modifies the relational schema, medical information held by the extracts may be queried, but extracts cannot be recovered in their exact original forms.
For very big databases in secondary use (research), it is not clear which database system is more appropriate, since the all-patient queries (Q2 and Q5) behave better in ORM than in NoSQL systems, but these systems perform better than the simplified relational systems in 12. We consider Q6 a special query in between clinical practice and secondary use whose behavior cannot be determined by the results yielded by these experiments.
However, one limitation of the method is the inavailability of direct experiments comparing the improved relational ARM system with NoSQL MongoDB regarding single-patient, medical practice queries with exactly the same data used in the protocol. We maintained the results interpolating Table 3 and Table 5 regarding single-patient queries until the experiment including optimized ARM in the protocol was performed. We leave these experiments for future applications. One critical step within the protocol is the selection of free database, similar software versions from recent years, so that we may compare the exact state-of-the-art of the three technologies.
This is one of the first attempts to directly compare relational and NoSQL systems using actual, realistic, standardized medical information. However, the specific system to be used depends much on the actual scenario and problem to be solved8.

NoSQL (Not only SQL) DBMS have recently emerged as an alternative to traditional Relational DBMS (RDMBS). RDBMS have dominated the way data were stored in database systems for decades. Well-studied and understood relational algebra and calculus have guaranteed the efficiency and consistency of RDBMS1. NoSQL systems will not become substitutes for relational systems, but they could behave advantageously in certain scenarios and under several conditions.
Some of these particular scenarios and conditions would occur when designing the database persistence of Electronic Health Record (EHR) systems used to manage and store medical information. In order to be interoperable and sustainable in practice, several international standards such as ISO/EN 13606, openEHR, and HL72,3,4,5 have been used to standardize EHR extracts.
Several standards such as ISO/EN 13606 and openEHR have separated information and knowledge into two different levels of abstraction, represented by the Reference Model (RM) and special data structures called archetypes. This separation is often called the dual model and it permits EHR systems to be semantically interoperable and medical knowledge to evolve without reprogramming the whole EHR system and, consequently, to be maintainable and sustainable in practice6. However, the dual model implemented in standardized EHR systems requires that the organization of information follows a specific structure, and this has profound consequences in the way the database persistence level of the system is designed7.
Object Relational Mapping (ORM)8 is one methodology to implement an EHR system using the relational database paradigm. ORM exhaustively maps the structure of standardized EHR extracts XML (eXtensible Markup Language) files used by the system for a relational database. ORM constructs many relational tables exhaustively following the structure of the standardized EHR extracts XML files. These relational tables are related through many foreign keys and the resulting system may not be very efficient.
Several relational improvements to ORM have been proposed. openEHR&#39;s Node+Path9 reduces the number of relational tables by serializing subtrees of the whole extract XML file into BLOBs (binary large objects). However, this simplification causes complex retrieval logic, damaging complex queries. Archetype Relational Mapping (ARM)10 generates a database model driven by archetypes, building a new relational schema based on mappings between archetypes and relational tables. Consequently, some of the non-medical information of the EHR extract is lost.
Many document-based NoSQL databases store whole documents as entire BLOBs respecting an original XML or JSON (JavaScript Object Notation) format. This means that no relational tables are constructed. These NoSQL databases have no schema and they do not support either joins or (ACID) properties11, i.e.,atomicity, consistency, isolation, or durability. As a result, they may be very inefficient if an element of a document references elements of the same or other such documents utilizing an indirection link. This happens because, in order to maintain consistency, the entirety of the referenced documents have to be processed sequentially. However, a non-relational database may be still appropriate if the main task performed by the DBMS is a document-based task. This is because data may remain in a form more closely approximating its true representation using a document-based NoSQL database, though this is also due to the special persistence policies accomplished by EHR medical documents (see discussion section).
The purpose of these methods is to showcase several experiments to compare the implementation of the persistence layer of a standardized EHR system using three different DBMSs: one relational (MySQL) and two NoSQL (document-based MongoDB and native XML eXist). Their computational complexity has been computed and compared using three different increasing size databases and six different complexity-increasing queries. The three database servers have been installed and configured locally in the same computer where the queries have been executed. See the Table of Materials for technical details.
Concurrency experiments have also been conducted in order to compare the performance of relational MySQL and NoSQL MongoDB DBMSs. The described ORM improvements (Node+Path and ARM) have also been compared using relevant appropriate results from the literature10.
Database management systems are evolving continuously at an accelerating rate. No one would think about this exponential development when the only existing paradigm was the relational model. To take an example, see for instance12, where a model was proposed to implement response-time improved relational databases retaining the ACID properties.

<table><tbody><tr><td>MySQL 5.7.20</td><td></td><td></td><td>MySQL experiments</td></tr><tr><td>Red Hat Enterprise Linux Server release 7.4 (Maipo), 2.60GHz, RAM 16GB</td><td></td><td></td><td></td></tr><tr><td>MongoDB 2.6</td><td></td><td></td><td>MongoDB experiments</td></tr><tr><td>Windows 7, 2.66GHz, RAM 12GB&amp;nbsp;</td><td></td><td></td><td></td></tr><tr><td>eXist 3.0RC1</td><td></td><td></td><td>eXist experiments</td></tr><tr><td>Windows 7, 2.66GHz, RAM 12GB&amp;nbsp;</td><td></td><td></td><td></td></tr><tr><td>Studio 3T 5.5.1</td><td>3T Software Labs Gmbh</td><td></td><td>MongoDB GUI</td></tr></tbody></table>

executing complexity-increasing queries in relational (mysql) and nosql (mongodb and exist) size-growing iso/en 13606 standardized ehr databases

This research shows a protocol to assess the computational complexity of querying relational and non-relational (NoSQL (not only Structured Query Language)) standardized electronic health record (EHR) medical information database systems (DBMS). It uses a set of three doubling-sized databases, i.e. databases storing 5000, 10,000 and 20,000 realistic standardized EHR extracts, in three different database management systems (DBMS): relational MySQL object-relational mapping&#160;(ORM), document-based NoSQL MongoDB, and native extensible markup language (XML) NoSQL eXist.
The average response times to six complexity-increasing queries were computed, and the results showed a linear behavior in the NoSQL cases. In the NoSQL field, MongoDB presents a much flatter linear slope than eXist.
NoSQL systems may also be more appropriate to maintain standardized medical information systems due to the special nature of the updating policies of medical information, which should not affect the consistency and efficiency of the data stored in NoSQL databases.
One limitation of this protocol is the lack of direct results of improved relational systems such as archetype relational mapping (ARM) with the same data. However, the interpolation of doubling-size database results to those presented in the literature and other published results suggests that NoSQL systems might be more appropriate in many specific scenarios and problems to be solved. For example, NoSQL may be appropriate for document-based tasks such as EHR extracts used in clinical practice, or edition and visualization, or situations where the aim is not only to query medical information, but also to restore the EHR in exactly its original form.

Six different queries performed on realistic standardized EHR extracts containing information about the problems of patients, including their names, initial and final dates and severity, are shown in Table 1.
Average response times of the six queries in the three doubling-size databases in each DBMS are shown in Tables 2-4. Figures 1-6 show the same results graphically (notice that the vertical axes use very different scales throughout these figures).
The strong linear behavior of computational complexity is evident throughout all queries of the NoSQL databases, although with appropriate caution due to the relatively small size of the 3 datasets used. However, the relational ORM database shows an unclear linear behavior. The MongoDB database has a much flatter slope than the eXist database.
Results by the improved relational systems discussed in the introduction published in the literature may be found in Table 5. Interpolating MongoDB results from Table 3 with similar queries and database sizes of ARM results from Table 5 equals both database systems in Q1, but favors MongoDB in Q3.
The results of the concurrency experiments may be found in Table 5 and Table6. MongoDB beats MySQL both in throughput and response time. In fact, MongoDB behaves better in concurrency than in isolation, and stands as an impressive database in concurrent execution.
<img alt="Figure 1" class="xfigimg" src="/files/ftp_upload/57439/57439fig1.jpg" /> 
Figure 1: Algorithmic complexity of ORM MySQL, MongoDB, and eXist DBMS for queries Q1 and Q4. This figure has been modified from7 using Creative Commons license (http://creativecommons.org/ licenses/by/4.0/) and shows response times in seconds for 5,000, 10,000 and 20,000-sized EHR extracts databases for each DBMS and queries Q1 and Q4. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig1large.jpg" target="_blank">Please click here to view a larger version of this figure.</a>
<img alt="Figure 2" class="xfigimg" src="/files/ftp_upload/57439/57439fig2.jpg" /> 
Figure 2: Algorithmic complexity of ORM MySQL DBMS for query Q2. This figure shows response times in seconds for 5,000, 10,000 and 20,000-sized EHR extracts ORM MySQL database for query Q2. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig2large.jpg" target="_blank">Please click here to view a larger version of this figure.</a>
<img alt="Figure 3" class="xfigimg" src="/files/ftp_upload/57439/57439fig3.jpg" /> 
Figure 3: Algorithmic complexity of MongoDB and eXist DBMS for queries Q2 and Q5. This figure has been modified from7 using Creative Commons license (http://creativecommons.org/licenses/ by/4.0) and Shows response times in seconds for 5,000, 10,000, and 20,000-sized EHR extracts databases for each DBMS and queries Q2 and Q5. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig3large.jpg" target="_blank">Please click here to view a larger version of this figure.</a>
<img alt="Figure 4" class="xfigimg" src="/files/ftp_upload/57439/57439fig4.jpg" /> 
Figure 4: Algorithmic complexity of ORM MySQL DBMS for queries Q3 and Q5. Shows response times in seconds for 5,000, 10,000 and 20,000-sized EHR extracts databases for each DBMS and queries Q3 and Q5. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig4large.jpg" target="_blank">Please click here to view a larger version of this figure.</a>
<img alt="Figure 5" class="xfigimg" src="/files/ftp_upload/57439/57439fig5.jpg" /> 
Figure 5:&#160;Algorithmic complexity of eXist and MongoDB DBMS for query Q3. This figure has been modified from7 using Creative Commons license (http://creativecommons.org/licenses/ by/4.0/ ) and shows response times in seconds for 5,000, 10,000 and 20,000-sized EHR extracts databases for each DBMS and query Q3. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig5large.jpg" target="_blank">Please click here to view a larger version of this figure.</a>
<img alt="Figure 6" class="xfigimg" src="/files/ftp_upload/57439/57439fig6.jpg" /> 
Figure 6: Algorithmic complexity of ORM MySQL, eXist and MongoDB DBMS for query Q6. This figure has been modified from7 using Creative Commons license (http://creativecommons.org/licenses/ by/4.0/) and shows response times in seconds for 5,000, 10,000 and 20,000-sized EHR extracts databases for each DBMS and query Q6. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig6large.jpg" target="_blank">Please click here to view a larger version of this figure.</a>
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td></td>
			<td>Query</td>
		</tr>
		<tr>
			<td>Q1</td>
			<td>Find all problems of a single patient</td>
		</tr>
		<tr>
			<td>Q2</td>
			<td>Find all problems of all patients</td>
		</tr>
		<tr>
			<td>Q3</td>
			<td>Find initial date, resolution date and severity&#160;</td>
		</tr>
		<tr>
			<td></td>
			<td>of a single problem of a single patient</td>
		</tr>
		<tr>
			<td>Q4</td>
			<td>Find initial date, resolution date and severity&#160;</td>
		</tr>
		<tr>
			<td></td>
			<td>of all problems problem of a single patient</td>
		</tr>
		<tr>
			<td>Q5</td>
			<td>Find initial date, resolution date and severity</td>
		</tr>
		<tr>
			<td></td>
			<td>&#160;of all problems problem of all patients</td>
		</tr>
		<tr>
			<td>Q6</td>
			<td>Find all patients with problem &#39;pharyngitis&#39;,&#160;</td>
		</tr>
		<tr>
			<td></td>
			<td>initial date &#62;= &#39;16/10/2007&#39;, resolution date</td>
		</tr>
		<tr>
			<td></td>
			<td>&#160;&#60;= &#39;06/05/2008&#39; and severity &#39;high&#39;</td>
		</tr>
	</tbody>
</table>
Table 1: The six queries performed on the relational and NoSQL databases containing standardized EHR extracts about problems of patients. This table has been modified from7 using Creative Commons license (http://creativecommons.org/ licenses/by/4.0/) and shows the six complexity-growing queries performed on the three size-growing databases for each DBMS expressed in natural language.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>ORM/MySQL</td>
			<td>5000 docs</td>
			<td>10,000 docs</td>
			<td>20,000 docs</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>25.0474</td>
			<td>32.6868</td>
			<td>170.7342</td>
		</tr>
		<tr>
			<td>Q2 (s)</td>
			<td>0.0158</td>
			<td>0.0147</td>
			<td>0.0222</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>3.3849</td>
			<td>6.4225</td>
			<td>207.2348</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>33.5457</td>
			<td>114.6607</td>
			<td>115.4169</td>
		</tr>
		<tr>
			<td>Q5 (s)</td>
			<td>9.6393</td>
			<td>74.3767</td>
			<td>29.0993</td>
		</tr>
		<tr>
			<td>Q6 (s)</td>
			<td>1.4382</td>
			<td>2.4844</td>
			<td>183.4979</td>
		</tr>
		<tr>
			<td>Database size</td>
			<td>4.6GB</td>
			<td>9.4GB</td>
			<td>19.4GB</td>
		</tr>
		<tr>
			<td>Total extracts</td>
			<td>5000</td>
			<td>10,000</td>
			<td>20,000</td>
		</tr>
	</tbody>
</table>
Table 2: Average response times in seconds of the six queries on doubling-size databases of the ORM MySQL relational DBMS. This table shows six response times for each query for the three doubling-sized databases using the ORM MySQL relational DBMS and the in-memory size of the three databases.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>MongoDB</td>
			<td>5000 docs</td>
			<td>10,000 docs</td>
			<td>20,000 docs</td>
			<td>slope (*10exp(-6))</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>0.046</td>
			<td>0.057</td>
			<td>0.1221</td>
			<td>5.07</td>
		</tr>
		<tr>
			<td>Q2 (s)</td>
			<td>34.5181</td>
			<td>68.6945</td>
			<td>136.2329</td>
			<td>6,780.99</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>0.048</td>
			<td>0.058</td>
			<td>0.1201</td>
			<td>4.81</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>0.052</td>
			<td>0.061</td>
			<td>o.1241</td>
			<td>4.81</td>
		</tr>
		<tr>
			<td>Q5 (s)</td>
			<td>38.0202</td>
			<td>75.4376</td>
			<td>149.933</td>
			<td>7460.85</td>
		</tr>
		<tr>
			<td>Q6 (s)</td>
			<td>9.5153</td>
			<td>18.5566</td>
			<td>36.7805</td>
			<td>1,817.68</td>
		</tr>
		<tr>
			<td>Database size</td>
			<td>1.95GB</td>
			<td>3.95GB</td>
			<td>7.95GB</td>
			<td></td>
		</tr>
		<tr>
			<td>Total extracts</td>
			<td>5000</td>
			<td>10,000</td>
			<td>20,000</td>
			<td></td>
		</tr>
	</tbody>
</table>
Table 3: Average response times in seconds of the six queries on doubling-size databases of the MongoDB NoSQL DBMS. This table has been modified from7 using Creative Commons license (http://creativecommons.org/ licenses/by/4.0/) and shows the six response times of each query for the three doubling-sized databases using the NoSQL MongoDB DBMS and the in-memory size of the three databases. The linear slope of each query is also shown.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>eXist</td>
			<td>5000 docs</td>
			<td>10,000 docs</td>
			<td>20,000 docs</td>
			<td>slope (*10exp(-6))</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>0.6608</td>
			<td>3.7834</td>
			<td>7.3022</td>
			<td>442.76</td>
		</tr>
		<tr>
			<td>Q2 (s)</td>
			<td>60.7761</td>
			<td>129.3645</td>
			<td>287.362</td>
			<td>15,105.73</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>0.6976</td>
			<td>1.771</td>
			<td>4.1172</td>
			<td>227.96</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>0.6445</td>
			<td>3.7604</td>
			<td>7.3216</td>
			<td>445.17</td>
		</tr>
		<tr>
			<td>Q5 (s)</td>
			<td>145.3373</td>
			<td>291.2502</td>
			<td>597.7216</td>
			<td>30,158.93</td>
		</tr>
		<tr>
			<td>Q6 (s)</td>
			<td>68.3798</td>
			<td>138.9987</td>
			<td>475.2663</td>
			<td>27,125.82</td>
		</tr>
		<tr>
			<td>Database size</td>
			<td>1.25GB</td>
			<td>2.54GB</td>
			<td>5.12GB</td>
			<td></td>
		</tr>
		<tr>
			<td>Total extracts</td>
			<td>5000</td>
			<td>10,000</td>
			<td>20,000</td>
			<td></td>
		</tr>
	</tbody>
</table>
Table 4: Average response times in seconds of the six queries on doubling-size databases of the eXist NoSQL DBMS. This table has been modified from7 using Creative Commons license (http://creativecommons.org/ licenses/by/4.0/) and shows the six response times of each query for the three doubling-sized databases using the NoSQL eXist DBMS and the in-memory size of the three databases. The linear slope of each query is also shown.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td></td>
			<td>ARM paper</td>
			<td>ARM (s)</td>
			<td>Node+Path&#160; (s)</td>
		</tr>
		<tr>
			<td>Q1</td>
			<td>Query 2.1</td>
			<td>0.191</td>
			<td>24.866</td>
		</tr>
		<tr>
			<td>Q3</td>
			<td>Query 3.1</td>
			<td>0.27</td>
			<td>294.774</td>
		</tr>
		<tr>
			<td></td>
			<td>Database size</td>
			<td>2.90GB</td>
			<td>43.87GB</td>
		</tr>
		<tr>
			<td></td>
			<td>Total extracts</td>
			<td>29,743</td>
			<td>29,743</td>
		</tr>
	</tbody>
</table>
Table 5: Average response times in seconds of queries similar to Q1 and Q3 of the improved relational systems presented in10. This table has been modified from7 using Creative Commons license (http://creativecommons.org/ licenses/by/4.0/) and shows the two most-similar queries to Q1 and Q3 presented in10 corresponding to two improved relational database systems and their response times. The two database sizes are also shown.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>ORM/MySQL</td>
			<td>Throughput</td>
			<td>Response time</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>4,711.60</td>
			<td>0.0793</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>4,711.60</td>
			<td>0.1558</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>4,711.60</td>
			<td>0.9674</td>
		</tr>
	</tbody>
</table>
Table 6: Average throughput and response time in seconds of queries Q1, Q3 and Q4 of ORM MySQL relational DBMS in concurrent execution. This table has been modified from7 using Creative Commons license (http://creativecommons.org/ licenses/by/4.0/) and shows the highest average throughput of the three single-patient queries and their average response times in the concurrent execution experiment using the ORM MySQL relational system.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>MongoDB</td>
			<td>Throughput</td>
			<td>Response time</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>178,672.60</td>
			<td>0.003</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>178,672.60</td>
			<td>0.0026</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>178,672.60</td>
			<td>0.0034</td>
		</tr>
	</tbody>
</table>
Table 7: Average throughput and response time in seconds of queries Q1, Q3 and Q4 of MongoDB NoSQL DBMS in concurrent execution. This table has been modified from7 using Creative Commons license (http://creativecommons.org/ licenses/by/4.0/) and shows the highest average throughput of the three single-patient queries and their average response times in the concurrent execution experiment using the MongoDB NoSQL system.
Supplementary Figure 1: The screenshot shows the software screen to connect to the MySQL server. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_1.png" target="_blank">Please click here to download this figure.</a>
Supplementary Figure 2: The screenshot shows the SQL interface to the MySQL server where the first SQL query has been written. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_2.png" target="_blank">Please click here to download this figure.</a>
Supplementary Figure 3: The MongoDB 2.6 localhost server is launched using a DOS system window by executing the server mongod. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_3.png" target="_blank">Please click here to download this figure.</a>
Supplementary Figure 4: The screenshot shows the query written in the textboxes of the Query Builder as shown in steps 5.7.1 through 5.7.4. The screenshot illustrates step 5.7.3. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_4.png" target="_blank">Please click here to download this figure.</a>
Supplementary Figure 5:The screenshot shows the step 5.7.6. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_5.png" target="_blank">Please click here to download this figure.</a>
Supplementary Figure 6: The screenshot illustrates the writing of the XPath query in theupper part of the dialog. <a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_6.png" target="_blank">Please click here to download this figure.</a>

Watch this Scientific Journal Video about Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases at JoVE.com

Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases

This study compares relational and non-relational (NoSQL) standardized medical information systems. The computational complexity of the response times of querying such database management systems (DBMS) is computed using doubling-sized databases. These results help the discussion of the appropriateness of each database approach to different scenarios and problems.

Executing Complexity-Increasing Queries in Relational (MySQL) and NoSQL (MongoDB and EXist) Size-Growing ISO/EN 13606 Standardized EHR Databases

This research shows a protocol to assess the computational complexity of querying relational and non-relational (NoSQL (not only Structured Query ...

executing-complexity-increasing-queries-relational-mysql-nosql

Research

Education

JoVE Core

JoVE Journal

Nursing

Medicine

Unit 1

Documentation and Reporting

SCIENTISTS IN ACTION

9.2K Views.  Health Institute "Carlos III". This study compares relational and non-relational (NoSQL) standardized medical information systems. The computational complexity of the response times of querying such database management systems (DBMS) is computed using doubling-sized databases. These results help the discussion of the appropriateness of each database approach to different scenarios and problems.

Video: Executing Complexity-Increasing Queries in Relational MySQL and NoSQL MongoDB and EXist Size-Growing ISO/EN 13606 Standardized EHR Databases

Generation of Comprehensive Thoracic Oncology Database - Tool for Translational Research

The Thoracic Oncology Program Database Project was created to serve as a comprehensive, verified, and accessible repository for well-annotated cancer specimens and clinical data to be available to researchers within the Thoracic Oncology Research Program. This database also captures a large volume of genomic and proteomic data obtained from various tumor tissue studies. A team of clinical and basic science researchers, a biostatistician, and a bioinformatics expert was convened to design the database. Variables of interest were clearly defined and their descriptions were written within a standard operating manual to ensure consistency of data annotation. Using a protocol for prospective tissue banking and another protocol for retrospective banking, tumor and normal tissue samples from patients consented to these protocols were collected. Clinical information such as demographics, cancer characterization, and treatment plans for these patients were abstracted and entered into an Access database. Proteomic and genomic data have been included in the database and have been linked to clinical information for patients described within the database. The data from each table were linked using the relationships function in Microsoft Access to allow the database manager to connect clinical and laboratory information during a query. The queried data can then be exported for statistical analysis and hypothesis generation.

A thoracic oncology database was developed to serve as a comprehensive repository for clinical and laboratory data for the purposes of translational research. The database will serve translational cancer researchers within the Thoracic Oncology Research Program. This database is adaptable to other cancer models, as well as other human diseases.

The Thoracic Oncology Program Database Project was created to serve as a comprehensive, verified, and accessible repository for well-annotated cancer ...

A Data Integration Workflow to Identify Drug Combinations Targeting Synthetic Lethal Interactions

A synthetic lethal interaction between two genes is given when knock-out of either one of the two genes does not affect cell viability but knock-out of both synthetic lethal interactors leads to loss of cell viability or cell death. The best studied synthetic lethal interaction is between BRCA1/2 and PARP1, with PARP1 inhibitors being used in clinical practice to treat patients with BRCA1/2 mutated tumors. Large genetic screens in model organisms but also in haploid human cell lines have led to the identification of numerous additional synthetic lethal interaction pairs, all being potential targets of interest in the development of novel tumor therapies. One approach is to therapeutically target genes with a synthetic lethal interactor that is mutated or significantly downregulated in the tumor of interest. A second approach is to formulate drug combinations addressing synthetic lethal interactions. In this article, we outline a data integration workflow to evaluate and identify drug combinations targeting synthetic lethal interactions. We make use of available datasets on synthetic lethal interaction pairs, homology mapping resources, drug-target links from dedicated databases, as well as information on drugs being investigated in clinical trials in the disease area of interest. We further highlight key findings of two recent studies of our group on drug combination assessment in the context of ovarian and breast cancer.

Large genetic screens in model organisms have led to the identification of negative genetic interactions. Here, we describe a data integration workflow using data from genetic screens in model organisms to delineate drug combinations targeting synthetic lethal interactions in cancer.

A synthetic lethal interaction between two genes is given when knock-out of either one of the two genes does not affect cell viability but knock-out of ...

Cancer Research

Implementation of a Real-Time Psychosis Risk Detection and Alerting System Based on Electronic Health Records using CogStack

Recent studies have shown that an automated, lifespan-inclusive, transdiagnostic, and clinically based, individualized risk calculator provides a powerful system for supporting the early detection of individuals at-risk of psychosis at a large scale, by leveraging electronic health records (EHRs). This risk calculator has been externally validated twice and is undergoing feasibility testing for clinical implementation. Integration of this risk calculator in clinical routine should be facilitated by prospective feasibility studies, which are required to address pragmatic challenges, such as missing data, and the usability of this risk calculator in a real-world and routine clinical setting. Here, we present an approach for a prospective implementation of a real-time psychosis risk detection and alerting service in a real-world EHR system. This method leverages the CogStack platform, which is an open-source, lightweight, and distributed information retrieval and text extraction system. The CogStack platform incorporates a set of services that allow for full-text search of clinical data, lifespan-inclusive, real-time calculation of psychosis risk, early risk-alerting to clinicians, and the visual monitoring of patients over time. Our method includes: 1) ingestion and synchronization of data from multiple sources into the CogStack platform, 2) implementation of a risk calculator, whose algorithm was previously developed and validated, for timely computation of a patient&#39;s risk of psychosis, 3) creation of interactive visualizations and dashboards to monitor patients&#39; health status over time, and 4) building automated alerting systems to ensure that clinicians are notified of patients at-risk, so that appropriate actions can be pursued. This is the first ever study that has developed and implemented a similar detection and alerting system in clinical routine for early detection of psychosis.

We demonstrate how to deploy a real-time psychosis risk calculation and alerting system based on CogStack, an information retrieval and extraction platform for electronic health records.

Recent studies have shown that an automated, lifespan-inclusive, transdiagnostic, and clinically based, individualized risk calculator provides a powerful ...

Behavior

Databases to Efficiently Manage Medium Sized, Low Velocity, Multidimensional Data in Tissue Engineering

Science relies on increasingly complex data sets for progress, but common data management methods such as spreadsheet programs are inadequate for the growing scale and complexity of this information. While database management systems have the potential to rectify these issues, they are not commonly utilized outside of business and informatics fields. Yet, many research labs already generate "medium sized", low velocity, multi-dimensional data that could greatly benefit from implementing similar systems. In this article, we provide a conceptual overview explaining how databases function and the advantages they provide in tissue engineering applications. Structural fibroblast data from individuals with a lamin A/C mutation was used to illustrate examples within a specific experimental context. Examples include visualizing multidimensional data, linking tables in a relational database structure, mapping a semi-automated data pipeline to convert raw data into structured formats, and explaining the underlying syntax of a query. Outcomes from analyzing the data were used to create plots of various arrangements and significance was demonstrated in cell organization in aligned environments between the positive control of Hutchinson-Gilford progeria, a well-known laminopathy, and all other experimental groups. In comparison to spreadsheets, database methods were enormously time efficient, simple to use once set up, allowed for immediate access of original file locations, and increased data rigor. In response to the National Institutes of Health (NIH) emphasis on experimental rigor, it is likely that many scientific fields will eventually adopt databases as common practice due to their strong capability to effectively organize complex data.

Many researchers generate "medium-sized", low-velocity, and multi-dimensional data, which can be managed more efficiently with databases rather than spreadsheets. Here we provide a conceptual overview of databases including visualizing multi-dimensional data, linking tables in relational database structures, mapping semi-automated data pipelines, and using the database to elucidate data meaning.

Science relies on increasingly complex data sets for progress, but common data management methods such as spreadsheet programs are inadequate for the ...

Bioengineering

A Metadata Extraction Approach for Clinical Case Reports to Enable Advanced Understanding of Biomedical Concepts

Clinical case reports (CCRs) are a valuable means of sharing observations and insights in medicine. The form of these documents varies, and their content includes descriptions of numerous, novel disease presentations and treatments. Thus far, the text data within CCRs is largely unstructured, requiring significant human and computational effort to render these data useful for in-depth analysis. In this protocol, we describe methods for identifying metadata corresponding to specific biomedical concepts frequently observed within CCRs. We provide a metadata template as a guide for document annotation, recognizing that imposing structure on CCRs may be pursued by combinations of manual and automated effort. The approach presented here is appropriate for organization of concept-related text from a large literature corpus (e.g., thousands of CCRs) but may be easily adapted to facilitate more focused tasks or small sets of reports. The resulting structured text data includes sufficient semantic context to support a variety of subsequent text analysis workflows: meta-analyses to determine how to maximize CCR detail, epidemiological studies of rare diseases, and the development of models of medical language may all be made more realizable and manageable through the use of structured text data.

We present a protocol and associated metadata template for the extraction of text describing biomedical concepts in clinical case reports. The structured text values produced through this protocol can support deep analysis of thousands of clinical narratives.

Clinical case reports (CCRs) are a valuable means of sharing observations and insights in medicine. The form of these documents varies, and their content ...

Cloud-Based Phrase Mining and Analysis of User-Defined Phrase-Category Association in Biomedical Publications

The rapid accumulation of biomedical textual data has far exceeded the human capacity of manual curation and analysis, necessitating novel text-mining tools to extract biological insights from large volumes of scientific reports. The Context-aware Semantic Online Analytical Processing (CaseOLAP) pipeline, developed in 2016, successfully quantifies user-defined phrase-category relationships through the analysis of textual data. CaseOLAP has many biomedical applications.
We have developed a protocol for a cloud-based environment supporting the end-to-end phrase-mining and analyses platform. Our protocol includes data preprocessing (e.g., downloading, extraction, and parsing text documents), indexing and searching with Elasticsearch, creating a functional document structure called Text-Cube, and quantifying phrase-category relationships using the core CaseOLAP algorithm.
Our data preprocessing generates key-value mappings for all documents involved. The preprocessed data is indexed to carry out a search of documents including entities, which further facilitates the Text-Cube creation and CaseOLAP score calculation. The obtained raw CaseOLAP scores are interpreted using a series of integrative analyses, including dimensionality reduction, clustering, temporal, and geographical analyses. Additionally, the CaseOLAP scores are used to create a graphical database, which enables semantic mapping of the documents.
CaseOLAP defines phrase-category relationships in an accurate (identifies relationships), consistent (highly reproducible), and efficient manner (processes 100,000 words/sec). Following this protocol, users can access a cloud-computing environment to support their own configurations and applications of CaseOLAP. This platform offers enhanced accessibility and empowers the biomedical community with phrase-mining tools for widespread biomedical research applications.

We present a protocol and associated programming code as well as metadata samples to support a cloud-based automated identification of phrases-category association representing unique concepts in user selected knowledge domain in biomedical literature. The phrase-category association quantified by this protocol can facilitate in depth analysis in the selected knowledge domain.

The rapid accumulation of biomedical textual data has far exceeded the human capacity of manual curation and analysis, necessitating novel text-mining ...

TBase - an Integrated Electronic Health Record and Research Database for Kidney Transplant Recipients

TBase is an electronic health record (EHR) for kidney transplant recipients (KTR) combining automated data entry of key clinical data (e.g., laboratory values, medical reports, radiology and pathology data) via standardized interfaces with manual data entry during routine treatment (e.g., clinical notes, medication list, and transplantation data). By this means, a comprehensive database for KTR is created with benefits for routine clinical care and research. It enables both easy everyday clinical use and quick access for research questions with highest data quality. This is achieved by the concept of data validation in clinical routine in which clinical users and patients have to rely on correct data for treatment and medication plans and thereby validate and correct the clinical data in their daily practice. This EHR is tailored for the needs of transplant outpatient care and proved its clinical utility for more than 20 years at Charit&#233; - Universit&#228;tsmedizin Berlin. It facilitates efficient routine work with well-structured, comprehensive long-term data and allows their easy use for clinical research. To this point, its functionality covers automated transmission of routine data via standardized interfaces from different hospital information systems, availability of transplant-specific data, a medication list with an integrated check for drug-drug interactions, and semi-automated generation of medical reports among others. Key elements of the latest reengineering are a robust privacy-by-design concept, modularity, and hence portability into other clinical contexts as well as usability and platform independence enabled by HTML5 (Hypertext Markup Language) based responsive web design. This allows fast and easy scalability into other disease areas and other university hospitals. The comprehensive long-term datasets are the basis for the investigation of Machine Learning algorithms, and the modular structure allows to rapidly implement these into clinical care. Patient reported data and telemedicine services are integrated into TBase in order to meet future needs of the patients. These novel features aim to improve clinical care as well as to create new research options and therapeutic interventions.

TBase combines an electronic health record with an innovative research database for kidney transplant recipients. TBase is built upon an in-memory database platform, connected to different hospital systems, and used for regular outpatient care. It automatically integrates all relevant clinical data including transplantation-specific data creating a unique research database.

TBase is an electronic health record (EHR) for kidney transplant recipients (KTR) combining automated data entry of key clinical data (e.g., laboratory ...

Clinical Application of Artificial Intelligence Preoperative Planning System Combined with Expert Database Retrieval in Complex Revision Hip Surgery

Accurate preoperative planning in revision hip arthroplasty is crucial for achieving successful outcomes. To enhance the intuitive evaluation of acetabular bone defect severity and leverage previous successful experience in revision hip arthroplasty, this study proposes a novel approach based on expert surgical case database retrieval and is initially implemented in clinical application.&#160;In this study, five patients who required revision hip arthroplasty were preoperatively planned to employ the expert case database surgical planning system.The patient&#39;s imaging data was entered into the system and matched with cases in the expert case database. Based on the expert&#39;s surgical experience, a revision surgery plan was recommended. If no suitable case was found, the model and position of the prosthesis were planned based on patient-specific reconstruction results. A total of five patients were enrolled in this study, four males and one female, with a mean age of 50.6 years. The diagnosis was aseptic prosthesis loosening after hip arthroplasty. The mean operative time was 123.2 min, and the mean intraoperative hemorrhage was 672 mL. No intraoperative complications, such as vascular or nerve injury, were observed. In Case 2, for instance, the application of this innovative planning scheme enabled the surgeon to delineate the revision surgery plan for this patient in the preoperative period, thereby reducing the operative time and intraoperative hemorrhage. Furthermore, patients could be apprised of the outcomes of analogous cases in advance. Leveraging a big data analysis approach through our comprehensive case database enables automated identification of matching expert treatment plans throughout the entire process. This particularly benefits inexperienced orthopedic surgeons by providing accurate guidance on surgical strategies to assist them in selecting appropriate prosthetic sizes and mounting positions. Additionally, the matching results can offer patients visualizations depicting predicted postoperative outcomes.

This study proposes a novel artificial intelligence preoperative planning approach based on expert surgical case database retrieval in revision hip arthroplasty. Additionally, the technique was initially employed in five patients, exhibiting a reduction in operative time and intraoperative hemorrhage.

Accurate preoperative planning in revision hip arthroplasty is crucial for achieving successful outcomes. To enhance the intuitive evaluation of ...

Methods of Documentation VII: EMR

Electronic Medical Records (EMRs) primarily center around electronically documenting patients&#39; health information within a single healthcare organization or practice. They contain essential clinical data related to a patient&#39;s medical history, diagnoses, medications, treatment plans, lab results, and other pertinent information relevant to the specific encounter or episode of care. EMRs are designed to streamline documentation and workflow processes within individual healthcare settings, facilitating the delivery of patient care within that organization.
Electronic Health Records (EHRs)&#160; encompass a broader scope of patient health information, extending beyond the confines of a single healthcare organization or encounter. They integrate data from multiple sources and care settings, including medical histories from various providers, lab results from different laboratories, imaging reports, pharmacy records, insurance claims data, and patient-generated health information. EHRs provide a longitudinal view of a patient&#39;s health history, facilitating continuity of care, care coordination across different providers and settings, and comprehensive clinical decision-making.
Characteristics of EMR or EHRs:
<ul>
	<li>&#8226; They consist of structured collections of patients&#39; digital medical records originating from electronic formats or converted from paper records.</li>
	<li>&#8226;&#160;The information is digitally stored in electronic records. It can be easily distributed to healthcare providers in standardized formats, enabling efficient comparison and assessment of patient progress.</li>
	<li>&#8226;&#160;Healthcare facilities use standardized assessment tools like the minimal data set to systematically organize and document patient information.</li>
	<li>&#8226;&#160;The minimal data set typically includes nursing care components (e.g., diagnoses, interventions), patient demographic information (e.g., gender, date of birth), and service components (e.g., admission, discharge dates).</li>
</ul>
Critical Benefits of EMRs to Nurses:
<ul>
	<li>&#8226;&#160;EMRs offer several benefits to nurses, including the ability to compare ongoing clinical data with baseline data, maintain detailed patient logs, and quickly access patient records.</li>
	<li>&#8226;&#160;They facilitate legible, accurate, up-to-date, and complete documentation about patients, improving efficiency and quality of care delivery.</li>
</ul>

Electronic Medical Records (EMRs) primarily center around electronically documenting patients&#39; health information within a single healthcare ...

KEY TERMS AND CONCEPTS

Issues And Trends In Healthcare Delivery System

The issues and trends in healthcare delivery are constantly changing. The COVID-19 pandemic is one recent issue that wreaked havoc on healthcare systems, causing a shortage of healthcare workers, high demand for medicines and supplies, and increased medical expenditure due to a lack of insurance. Other issues include rising healthcare costs and care fragmentation.
Cost Containment
Payment for healthcare services has historically promoted adoption of costly and often unnecessary or inefficient services. Because health insurance did not cover preventative measures in the past, healthcare primarily focused on treating illnesses rather than prevention. The third-party reimbursement structure effectively shielded patients from learning the actual cost of their treatment. Competition among hospitals has pushed the rise in healthcare expenses even more. Hospitals have spent a lot of money on technologically advanced equipment to attract patients. As new technology and more complex treatments have been created and employed, patients&#39; expectations regarding the availability and utilization of such resources have risen. Cost-cutting support encourages hospitals to collaborate and share resources rather than compete. Other cost-cutting initiatives include reorganizing and consolidating many hospitals into a single system.
Care Fragmentation
Expanded healthcare research resulted in an upward cycle of new technologies and knowledge. Because many healthcare professionals can no longer keep up with the breakthroughs in all fields, specialization in fewer areas has become the norm rather than the exception. A general practitioner diagnoses and treats a wide range of common health conditions; however, a patient who requires diagnosis and treatment for a more difficult illness is typically referred to a specialist physician. This fragmentation of treatment can result in a loss of continuity of care, contradictory care plans, too much or too little medicine, and increased healthcare expenses.
Present trends in healthcare systems include demographic shifts, technological advancements, globalization of healthcare, educated consumers, and the effects of health policies and regulations.
Artificial Intelligence (AI)
AI is replacing traditional labor-intensive and time-consuming procedures in healthcare with quick, remotely accessible, and real-time solutions for diagnosis, treatment, and disease prevention. Health technology firms provide software platforms, application programming interfaces (APIs), and other digital goods to expand the benefits of AI. Improved surgery support, clinical workflow management, and medical diagnostics are just a few uses of artificial intelligence in healthcare.
Internet of Medical Things (IoMT)
IoMT helps create products that require little or no human involvement to offer healthcare services. Connected medical devices, equipment, and infrastructure allow various applications, including automated disinfection, smart diagnostics, and remote patient care. Cognitive IoMT (CIoMT) is a recent subtrend that merges sensory data, automated processing, and network connectivity for real-time diagnosis, monitoring, tracking, and illness management.
Telemedicine
Many governments, healthcare institutions, professionals, and patients have expedited their use of telemedicine due to the COVID-19 epidemic. To counteract the pandemic, governments devised telemedicine suggestions to decongest healthcare institutions. Telemedicine relieves the strain on facilities and reduces the need for personal protective equipment (PPE) by allowing doctors to contact their patients via telecommunication. Health technology businesses are developing telehealth services to aid public health mitigation initiatives by improving social distancing. Telemedicine also aids in the remote assistance of the elderly, decreases bed utilization, and conserves clinical resources.
3D Printing
3D printing is gaining popularity in healthcare for various applications, such as producing lightweight prostheses, bionics, and casts used to immobilize body parts to heal fractures. Utilizing low-cost, lightweight biomaterials and innovative materials improves care delivery and production time while lowering expenses. 3D printing technologies produce patient-specific organ models and surgical equipment using the patient&#39;s specific dimensions measured by medical imaging. 3D printing can also produce individualized surgical tools, which improve a surgeon&#39;s dexterity and promote better surgical results while permitting faster and less stressful treatments.
Blockchain
Blockchain&#39;s security and traceability make it suited for a wide range of applications in the healthcare business. Electronic medical records, remote patient monitoring, tracking of pharmaceutical supply chains, and processing health insurance claims are just a few examples of applications of blockchain technology. Blockchain technology also assists with EHR administration and FHIRChain (Fast Health Interoperability Records) for clinical data exchange. It is also utilized in smart contracts, combating medicine counterfeiting, storing, distributing, and retrieving remotely obtained biological data.
Genomics
In recent years, significant efforts have been made to create genomics tools for various applications. Integrating both genomic knowledge and procedures into existing clinical workflows will guarantee that clinicians follow established communication and actionable recommendations to patients through a genetic test. Because of advances in genomics, a new era of individualized medicine is now feasible. For various unmet clinical requirements, gene therapy and gene-based therapeutic options have changed clinical treatment and specialist care.

The issues and trends in healthcare delivery are constantly changing. The COVID-19 pandemic is one recent issue that wreaked havoc on healthcare systems, ...