Graph Database

Graph Database for Linked Health Data

A graph database is a database management system in which the links between records are stored as data in their own right, so a query reaches related records by following those links rather than by joining tables. Much health economic data is defined by its links, as patients have admissions, admissions carry diagnosis and procedure codes, codes sit in hierarchies and trials compare treatments. With the links stored that way, a question such as "which admissions carry any code below this condition" becomes a walk along edges. The tool changes how data are stored and queried and leaves the quality of the data and of the economic analysis unchanged.

Triple stores and property graph stores

Graph databases come in two main families, set by the data model they hold. Besta and colleagues, surveying 51 systems, separate native graph databases, built to hold and query graphs using either the RDF or the labelled property graph model, from systems that hold graphs on another backend such as a relational or key-value store.

The first family, often called triple stores or RDF stores, holds data as RDF triples. The W3C SPARQL 1.1 Update Recommendation describes the Graph Store behind such a system as a mutable container of RDF graphs managed by a single service, with one default graph and any number of named graphs, and such systems usually support SPARQL as their query language. HealthEconomics.wiki's own vocabulary, the Health Economics Ontology (HEO), is published on NCBO BioPortal in SKOS format, and SKOS data are expressed as RDF triples, so HEO is the kind of data a triple store holds.

The second family holds property graphs, in which nodes and edges each carry a label and a set of property-value pairs. Hogan and colleagues note that property graphs are most prominently used in graph databases such as Neo4j, and that property graphs translate to and from plain edge-labelled graphs without loss of information. Systems built on property graphs are usually queried with Cypher or Gremlin. ISO/IEC 39075 GQL, published in April 2024, is the ISO standard database language for property graphs.

How a graph database stores and finds connections

A relational database links tables through keys and assembles a connection at query time with a join. Timón-Reina and colleagues, reviewing graph databases in biomedicine, note that where most relationships are many-to-many, a query needs multiple expensive joins, and that path traversals over tables representing vertices and edges are hard to optimise without extra structures such as adjacency lists.

A native graph database stores adjacency directly. In Neo4j, as Besta and colleagues describe, each node record points to the physical location of its first edge and each edge record points to the next edges of both its end nodes, so a neighbourhood query or traversal follows pointers without an index. The cost of such a query then depends on the size of the part of the graph visited, not on the size of the whole graph, although Besta and colleagues add that a graph too large for main memory runs at a speed set by caching.

The OMOP Common Data Model used by the OHDSI community keeps its concept relationships in a relational table and builds a CONCEPT_ANCESTOR table automatically by traversing all concepts connected through hierarchical relationships, so a query for a concept and all its descendants reads a precomputed table. A graph database would answer the same question by walking the "is a" edges at query time. Both return the same codes for a cost-of-illness study and differ in when the traversal work is done.

Besta and colleagues separate small, interactive transactional queries that touch a few nodes and edges from complex analytical queries that span the whole graph. A query for one patient's pathway is of the first kind, and a count over every patient in a cohort is closer to the second.

Documented uses close to health economics

Published projects show graph databases holding the kinds of data that health economists draw on. They are named examples, and none shows the approach to be standard practice in economic evaluation.

Patient records

Stothers and Nguyen loaded a 100-patient subset of the MIMIC-III critical care data into Neo4j and into PostgreSQL and ran 22 queries in each. Cypher queries averaged 7.86 clauses against 10.33 for SQL, and average runtime was 48.86 ms in the first Neo4j build and 45.26 ms in a remodelled one, against 154.48 ms in PostgreSQL. Building the relationships was the slow part, since creating 3,432 relationships in an operation involving 16,457 nodes took about 2.5 hours, and the authors did not test large datasets. They proposed, without testing, linking claims data to such records through shared ICD-9 codes, a step of direct interest for costing studies that use real-world data.

Studies and trial registries

The BRAinS-Graph project at Greifswald loaded 1,319 ClinicalTrials.gov records for diabetes studies in Germany, 1,760 medical data models and the MeSH and UMLS vocabularies into a single Neo4j database of about 3 million nodes and 8 million relationships. The authors used Cypher queries to count study types, which they present as support for planning a meta-analysis. They state that results depend on the quality of the source data and must be checked by domain experts before use in practice, so a count from such a graph is only a starting point for the searches of a systematic review.

Biomedical knowledge networks

Himmelstein and colleagues built Hetionet as a public Neo4j database and chose a graph database because, for many biomedical uses, the connections between entities matter most and a rigid fixed structure is often a hindrance.

What the performance evidence shows

Timón-Reina and colleagues found the benchmark studies heterogeneous, with findings that disagree in some cases. Studies built around specific biological problems tended to favour graph databases, while more formal benchmarks found relational systems better at grouping, sorting and aggregation, and graph databases better at multi-table joins, pattern matching and path finding.

The same review notes that some benchmarks report problems on large graphs, and that for Neo4j the number of edges to evaluate and the size of the subgraph pattern being matched can slow queries. Its conclusion is that graph databases are not superior in every graph query and that the aims and operational context should drive the choice. The MIMIC-III comparison fits this reading, because a small dataset on one laptop says little about a national claims extract.

Worked example with admissions and procedure counts

All patients, procedures and tariffs here are illustrative. An analyst stores a small costing extract as a property graph, with nodes for two patients (X and Y), three admissions (A1 and A2 for X, A3 for Y) and two procedure types, P1 with a tariff of GBP 1,200 and P2 with a tariff of GBP 450. Admission A1 records P1 once and P2 twice, A2 records P2 once and A3 records P1 once.

Step 1. The loader writes one edge between each admission and each procedure type it records, and stores the number of times as a count property on the edge. The cost per patient sums over the two-step paths that run through each admission to its procedure types,

$$C_i = \sum_{a \in A_i} \sum_{k \in K_a} n_{ak} \, c_k$$

where $C_i$ is the cost for patient $i$ in GBP, $A_i$ is the set of admissions linked to patient $i$, $K_a$ is the set of procedure types linked to admission $a$, $n_{ak}$ is the count stored on the edge joining admission $a$ and procedure type $k$ and $c_k$ is the tariff of procedure type $k$ in GBP.

Step 2. For patient X the sum over A1 and A2 is

$$C_X = (1 \times 1200 + 2 \times 450) + 1 \times 450 = 2100 + 450 = 2550$$

where the bracket is admission A1 and the last term is admission A2. For patient Y, $C_Y = 1 \times 1200 = 1200$, so the extract costs GBP 2,550 plus GBP 1,200, or GBP 3,750.

Step 3. Suppose instead the loader merges repeated records into a single edge and drops the count. Admission A1 then shows P2 once, and its cost falls to

$$C_{A1} = 1200 + 450 = 1650$$

where $C_{A1}$ is the cost of admission A1 in GBP and each term is one procedure tariff. The total becomes GBP 1,650 plus GBP 450 plus GBP 1,200, or GBP 3,300, which understates the true GBP 3,750 by GBP 450, or 12.0%.

Step 4. In a triple store the count cannot sit on the edge itself, since the RDF specification states that relations among more than two things can only be expressed indirectly. An extra node for each admission and procedure pair would carry the count, or an extension of RDF that lets edges act as nodes would be used, options Hogan and colleagues describe. Either design gives GBP 3,750 when counts are kept, and the error in Step 3 lay in the loading step, as it would in a relational design.

Choices that change what a graph database returns

Several design decisions sit between the source data and the answers a graph database gives. Each one should be reported when a graph database supplies inputs to a model or a search.

• What becomes a node. Timón-Reina and colleagues name the main trade-off of a relaxed schema as deciding when a data item becomes a node or an attribute, while keeping model complexity and integrity under control. The worked example shows how that choice moves a cost total.
• Schema or no schema. The same review reports that all the benchmark studies it covered credit a schema-optional design with the flexibility to add new nodes and relations without restructuring, but the meaning of each node and edge type still has to be written down.
• Transactions. Besta and colleagues find support for ACID transactions widespread, though some systems offer only a subset or a weaker consistency model, which matters when records change while analyses run.
• Query language. Timón-Reina and colleagues describe a lack of standard query languages across graph databases at the time of their review, so queries written for one system may not run on another. SPARQL is a W3C standard for RDF, and GQL now serves property graphs.
• Build effort. The same review warns that redesigning a storage layer usually takes notable development effort, which may deter research teams that are short of people and money.

Graph databases beside related ideas

A knowledge graph is a body of data and a graph database is one kind of system that stores and queries such data, so a knowledge graph can also live in files or in a relational database. Property graphs and RDF, the two data models, and SPARQL, the query language for RDF, each have their own page. A vector database stores numerical embeddings and retrieves items by similarity, which answers a different question from following named links.

Graph databases also differ from the record systems they draw on. An electronic health record or a set of claims data is a source, and a graph database is one way of storing extracts from such sources for analysis, as relational databases do. Whatever the storage, data quality decides whether the answers can be trusted.

Misreadings that lead to wrong inputs

Most errors come from crediting the database with properties that belong to the data or the analysis. Three recur.

1. Treating a fast query as a correct one. A traversal returns exactly what was loaded, so missing, duplicated or merged edges pass straight into a cost or count, as Step 3 of the worked example shows.
2. Transferring benchmark results. Speed differences found on one dataset and machine need not carry over to another, and costing queries that mostly sum and group records are the aggregation work where formal benchmarks favoured relational systems.
3. Reading graph structure as evidence. A path between a drug and a disease in Hetionet, or a study count in BRAinS-Graph, describes stored records and supplies none of the effect estimates or uncertainty that a health technology assessment requires.

Sources

• Baines D, Ashley M. Health Economics Ontology (HEO). NCBO BioPortal, accessed 2 November 2026. https://bioportal.bioontology.org/ontologies/HEO
• Besta M, Gerstenberger R, Peter E, et al. Demystifying graph databases: analysis and taxonomy of data organization, system designs, and graph queries. ACM Computing Surveys. 2023;56(2):1-40. https://doi.org/10.1145/3604932
• Cyganiak R, Wood D, Lanthaler M, editors. RDF 1.1 Concepts and Abstract Syntax. W3C Recommendation, 25 February 2014. https://www.w3.org/TR/rdf11-concepts/
• Gearon P, Passant A, Polleres A, editors. SPARQL 1.1 Update. W3C Recommendation, 21 March 2013. https://www.w3.org/TR/sparql11-update/
• Gütebier L, Groß S, Winter B, et al. Enhanced health study discoverability: graph-based analysis approach. JMIR Medical Informatics. 2026;14:e86812. https://doi.org/10.2196/86812
• Himmelstein DS, Lizee A, Hessler C, et al. Systematic integration of biomedical knowledge prioritizes drugs for repurposing. eLife. 2017;6:e26726. https://doi.org/10.7554/eLife.26726
• Hogan A, Blomqvist E, Cochez M, et al. Knowledge graphs. ACM Computing Surveys. 2021;54(4):1-37. https://doi.org/10.1145/3447772
• ISO/IEC. ISO/IEC 39075:2024 Information technology, Database languages, GQL. Geneva: ISO; 2024. https://www.iso.org/standard/76120.html
• Miles A, Bechhofer S, editors. SKOS Simple Knowledge Organization System Reference. W3C Recommendation, 18 August 2009. https://www.w3.org/TR/skos-reference/
• Observational Health Data Sciences and Informatics. Chapter 5, Standardized Vocabularies. In: The Book of OHDSI. OHDSI; 2021. https://ohdsi.github.io/TheBookOfOhdsi/StandardizedVocabularies.html
• Stothers JAM, Nguyen A. Can Neo4j replace PostgreSQL in healthcare? AMIA Joint Summits on Translational Science Proceedings. 2020;2020:646-653. https://pmc.ncbi.nlm.nih.gov/articles/PMC7233060/
• Timón-Reina S, Rincón M, Martínez-Tomás R. An overview of graph databases and their applications in the biomedical domain. Database. 2021;2021:baab026. https://doi.org/10.1093/database/baab026