Skip to main content
Advertisement
Browse Subject Areas
?

Click through the PLOS taxonomy to find articles in your field.

For more information about PLOS Subject Areas, click here.

< Back to Article

Fig 1.

Example of slides acquired for digital pathology.

From left to right: a tissue sample extracted from a patient is divided into multiple specimens; these are fixed into containers, blocks of formalin or paraffin; in turn the blocks are sliced. The produced slides can have one specimen per container, multiple items from the same block or items from different parts in the same block. For Figure credits see the Section Acknowledgments.

More »

Fig 1 Expand

Fig 2.

Number of common variants produced by different pipelines given identical input.

In the Figure, the underlined text indicates the versions of: the Burrows-Wheeler Aligner(BWA), the Broad Institute’s Genome Analysis Toolkit (GATK) Unified Genotyper(UG) and human genome reference(Hg). For Figure credits see the Section Acknowledgments.

More »

Fig 2 Expand

Fig 3.

Mind map of a set of annotations produced by a variant calling procedure.

Dashed lines highlight recurrent blocks.

More »

Fig 3 Expand

Fig 4.

The openEHR two-level separation.

Relationship between the Reference Model, on the left, and the Archetype Model, on the right.

More »

Fig 4 Expand

Fig 5.

Example of an archetype expressed in ADL.

The archetype defines a generic sports racket.

More »

Fig 5 Expand

Fig 6.

Example of an archetype query in AQL.

More »

Fig 6 Expand

Fig 7.

Example of an archetype, composed of other archetypes, shown as a tree structure.

Different shapes/capital letters mean different archetypes. The text “0..*” shows the cardinality of the relation (i.e., from 0 to any number of the related archetypes).

More »

Fig 7 Expand

Fig 8.

Some possible instances of the archetype illustrated in Fig 7.

The number after the capital letter denotes a particular instance of the given archetype.

More »

Fig 8 Expand

Fig 9.

Tree view of an archetype data structure with multiple nested archetypes.

More »

Fig 9 Expand

Fig 10.

AQL query for the data structure in Fig 9.

More »

Fig 10 Expand

Fig 11.

PyEHR architecture: main modules, databases and their interactions.

More »

Fig 11 Expand

Fig 12.

PyEHR architecture: Data Management System.

More »

Fig 12 Expand

Fig 13.

Code snippet from the Driver Factory Class.

The actual driver factory class; the lines at the bottom refer to the drivers for the MongoDB and Elasticsearch databases.

More »

Fig 13 Expand

Fig 14.

Main driver API tasks.

More »

Fig 14 Expand

Fig 15.

PyEHR: Query flow.

The query evaluation process starts from nine o’ clock and proceeds clockwise.

More »

Fig 15 Expand

Fig 16.

JSON view of a generic EHR structure.

The part on the left is the magnified view of the small region of the whole structure, shown on the top right.

More »

Fig 16 Expand

Fig 17.

Graph representation of some EHR structures generated.

Archetypes are shown as circles in a tree structure.

More »

Fig 17 Expand

Fig 18.

Structures relative depth distribution on the created EHRs.

On the right the archetype maximum depth vs the relative structure frequency. On the left the overall maximum depth vs the relative structure frequency.

More »

Fig 18 Expand

Fig 19.

Structures “max width” distribution on the created EHRs.

More »

Fig 19 Expand

Fig 20.

Type 3 query example with two levels of containment.

The number of CONTAINS clauses gives away the query level.

More »

Fig 20 Expand

Fig 21.

Apache Hadoop MapReduce, CNR. Query time vs number of nodes for a type 1 count query at different levels.

Each point is the mean query time, while the bar shows the standard deviation of the measurements. At the scale shown the points and the bars are almost indistinguishable.

More »

Fig 21 Expand

Fig 22.

Apache Hadoop MapReduce, CNR. “Spread” curves for a type 1 count query at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements. At the scale shown the points and the bars are almost indistinguishable.

More »

Fig 22 Expand

Fig 23.

PyEHR with MongoDB, CNR. Query time vs number of nodes for a type 1 count query at different levels.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 23 Expand

Fig 24.

PyEHR with MongoDB, CNR. Query time vs number of nodes for different types of count query at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 24 Expand

Fig 25.

PyEHR with MongoDB, CNR. Query time spent in the index lookup, count and fetch phases while performing a type 3 query at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 25 Expand

Fig 26.

PyEHR with MongoDB, CNR. “Spread” curves for a type 2 count query at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 26 Expand

Fig 27.

PyEHR with Elasticsearch, CNR. Query time vs number of nodes for a type 1 count query at different levels.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 27 Expand

Fig 28.

PyEHR with Elasticsearch, CNR. Query time vs number of nodes for different types of count query at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 28 Expand

Fig 29.

PyEHR with Elasticsearch, CNR. Query time spent in the index lookup, count and fetch phases in a type 3 query at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 29 Expand

Fig 30.

PyEHR with Elasticsearch, CNR. “Spread” curves for a type 2 count query at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 30 Expand

Fig 31.

Apache Hadoop MapReduce, CL. Query time for type 1 count query at different levels.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 31 Expand

Fig 32.

PyEHR with MongoDB, CL. Query time for type 1 count query at different levels.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 32 Expand

Fig 33.

PyEHR with MongoDB, CL. Query time for different type of count queries at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 33 Expand

Fig 34.

PyEHR with MongoDB, CL. Query time spent in the index lookup, count and fetch phases in a type 3 query at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 34 Expand

Fig 35.

PyEHR with Elasticsearch, CL. Query time for type 1 count query at different levels.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 35 Expand

Fig 36.

PyEHR with Elasticsearch, CL. Query time for different type of count queries at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 36 Expand

Fig 37.

PyEHR with Elasticsearch, CL. Query time spent in the index lookup, count and fetch phases in a type 3 query at level 5.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 37 Expand

Fig 38.

CNR. Results comparing performance for a type 1 query at level 3.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 38 Expand

Fig 39.

CL. Results comparing performance for a type 1 query at level 3.

Each point is the mean query time, while the bar shows the standard deviation of the measurements.

More »

Fig 39 Expand