Property Graph

Property Graph Data Model for Health Data

A property graph is a way of organising data as a graph, with records held as nodes and the links between them held as edges, in which an edge can hold attributes of its own as readily as a node can. A hospital admission can therefore sit on the edge between a patient and a hospital, carrying its date, length of stay and cost, without being redrawn as a separate record. For health economists the model matters because much of the evidence behind a cost study or a decision model is relational, and the property graph stores each link with its context attached. It is one of the two graph models most often found in graph database systems, beside the W3C Resource Description Framework, and it is the model that the ISO standard query language GQL is written for.

Nodes, edges, labels and properties

Angles and colleagues, in their survey of graph query languages, describe property graphs as graphs in which nodes and edges can further have attributes, and they give a formal definition. Each node and each edge has a unique identifier, which they describe as a hook for attaching meta-information in the form of property-value pairs. The definition can be written as a tuple.

$$G = (V, E, \rho, \lambda, \sigma)$$

where $V$ is a finite set of nodes, $E$ is a finite set of edges with no element in common with $V$, $\rho$ is a function that gives each edge its pair of start and end nodes, so every edge is directed, $\lambda$ is a function that gives each node and edge a label, and $\sigma$ is a partial function that gives the value of a named property for a node or edge, where one has been recorded.

A label says what kind of thing a node is, such as Patient or Study, or what kind of relationship an edge records, such as ADMITTED_TO. Properties hold the facts about one node or edge, such as an admission's cost. The Angles definition allows one label and one value per property, while Hogan and colleagues, in their survey of knowledge graphs, allow sets of labels and several values and treat such variations as syntactic. Angles and colleagues reported that Neo4j allowed one label on each edge, several on a node and one value per property, which may be a list.

Because each edge has its own identifier, two edges with the same label can join the same pair of nodes, so two admissions of one patient to one hospital are two edges with their own dates and costs.

Why attributes on edges matter for health economic data

The design answers a specific modelling problem. In a directed edge-labelled graph such as RDF, an edge is a bare statement, and the RDF 1.1 Concepts specification states that relations involving more than two entities can only be expressed indirectly. Hogan and colleagues show this with flights between two cities, where recording the company running a route turns each flight into a new node, a significant change to the graph. In a property graph the company is a property on the flight edge.

Angles and colleagues make the same point about provenance. Adding the source of each relation to an edge-labelled graph means remodelling the relation as a new kind of node, which may require a major change to the graph's structure, while a property graph is annotated directly without changing its overall structure. They call the property graph the most general and widely adopted alternative where new kinds of meta-information regularly need adding.

That situation is common in health economics. A micro-costing dataset built from linked electronic health records and claims data records admissions between patients and providers, with dates and costs. A decision model's parameter is linked to the study it came from, and the link can carry the table and price year a reviewer needs when checking model inputs against their sources. Each is a relationship with attributes, held as one edge.

Querying a property graph with Cypher, GQL and SQL

A property graph query is a pattern of nodes and edges to be found in the data. Cypher, released by the Neo4j development team, writes patterns pictorially, with nodes in round brackets, edges in square brackets and arrows for direction, as Angles and colleagues describe, and a dot gives a property's value, so a.cost is the cost on edge a. The Neo4j Cypher Manual documents aggregating functions such as count and sum, grouped by the non-aggregated expressions.

ISO and IEC published ISO/IEC 39075 GQL in April 2024, and its abstract says it defines data structures and basic operations on property graphs and provides a vehicle for portability of data definitions and manipulation among implementations. Ten months earlier ISO/IEC 9075-16 (SQL/PGQ, June 2023) defined ways for SQL to represent property graphs and interact with them, which matters for analysts whose hospital and claims extracts already sit in relational tables. The ISO page for GQL lists a corrigendum (Cor 1, 2026) and a revision under development.

Languages also differ in how a pattern is matched. Hogan and colleagues explain that SPARQL, the RDF query language, uses homomorphism-based semantics, letting several variables map to the same term, while Cypher uses isomorphism-based semantics on edges, so one match cannot use the same edge twice. The same question can therefore return different counts.

Worked example with hospital admissions for a cost study

All numbers in this example are illustrative. A cost study links three patients (P1, P2, P3) to two hospitals (H1, H2) through five admissions in 2025. Each patient node has two properties, age band and sex, each hospital node has one property, its name, and each ADMITTED_TO edge has three properties, admission date, length of stay in days and cost in GBP.

1. Count the parts of the property graph. There are 3 + 2 = 5 nodes and 5 edges, each with one label, so 10 labels in all. The property-value pairs number 3 × 2 = 6 on patients, 2 × 1 = 2 on hospitals and 5 × 3 = 15 on admissions, a total of 6 + 2 + 15 = 23.

2. Count the same data as RDF triples. Following the Hogan flight example, each admission becomes a node of its own. Each admission node needs a type triple, a triple from the patient, a triple to the hospital and three property triples, so 6 × 5 = 30 triples. Each patient needs a type triple and two property triples, 3 × 3 = 9, and each hospital a type triple and a name, 2 × 2 = 4. The total is 30 + 9 + 4 = 43 triples over 3 + 2 + 5 = 10 resource nodes. Neither form loses information, and the difference lies in where the admission's attributes live.

3. Run the cost query. The query in the table above returns, for H1, 3 admissions, 3 + 5 + 2 = 10 bed days and 2,400 + 4,100 + 1,600 = GBP 8,100, and for H2, 2 admissions, 1 + 4 = 5 bed days and 900 + 3,200 = GBP 4,100. The overall total is 8,100 + 4,100 = GBP 12,200 over 15 bed days, or 12,200 / 15 = GBP 813.33 per bed day, and the mean cost per admission is 12,200 / 5 = GBP 2,440.

4. Summarise by patient. P1 costs 2,400 + 900 = GBP 3,300, P2 costs GBP 4,100 and P3 costs 1,600 + 3,200 = GBP 4,800, so the mean cost per patient is 12,200 / 3 = GBP 4,066.67. The two means differ because P1 and P3 were each admitted twice.

5. Add a new attribute. The analyst later records the price year of each cost. In the property graph this is one new property per edge, 5 new pairs, with the structure unchanged. An RDF version that had used one direct admittedTo triple per admission would first have to replace each triple with an admission node, the remodelling cost Angles and colleagues describe.

6. Check how the matching rule changes a count. A pattern asking for pairs of admissions at the same hospital matches 3 × 3 = 9 pairs at H1 and 2 × 2 = 4 at H2 under homomorphism-based semantics, 13 in all, because each admission can pair with itself. Under Cypher's rule that an edge is used once per match, the counts are 3 × 2 = 6 and 2 × 1 = 2, 8 in all. A readmission analysis written without knowing the rule would overstate or understate pairs.

7. Interpretation. The graph holds the admissions as attributed links and absorbs new attributes without restructuring. The totals are only as good as the linked records, and nothing in the graph checks that two patient nodes are not the same person.

Health research uses of property graphs

Himmelstein and colleagues built Hetionet v1.0 for drug repurposing, integrating 29 public resources into 47,031 nodes of 11 types and 2,250,197 relationships of 24 types. They queried it in Neo4j and recommended the formats that include node and edge properties, such as source and licence information and confidence scores, so each relationship keeps its own provenance.

Gütebier and colleagues built the BRAinS-Graph, a labelled property graph in Neo4j integrating ClinicalTrials.gov, the Portal for Medical Data Models, the Unified Medical Language System and MeSH. In a diabetes demonstration with 1,319 study records they counted study types for meta-analyses, finding 1,140 interventional and 179 observational studies, a query relevant to the study-finding stage of a systematic review. They note that the graph relies on the quality of data from the external resources and that results must be validated by domain experts before real-world use.

Property graphs beside RDF and knowledge graphs

Hogan and colleagues state that property graphs can be translated to and from directed edge-labelled graphs without loss of information. They add that the edge-labelled model is more minimal and the property graph more flexible, and that the choice of model will often be secondary to practical factors such as the implementations available.

The two models differ in identity and meaning. RDF names things with IRIs, which by design have global scope, and the ontology standards built on RDF give its terms shared definitions. HealthEconomics.wiki's own ontology family is published in OWL and SKOS. Neither the Angles nor the Hogan property graph definition requires identifiers of that kind, so merging two property graphs depends on matching records, the task of entity resolution, and on agreed codes, the work of digital interoperability. The RDF 1.2 Concepts draft, a W3C Candidate Recommendation Snapshot of 7 April 2026, adds triple terms, so that a triple can appear inside another triple and a reifier can carry statements about it, such as who made a claim.

A knowledge graph can be built in either model, and a graph database is the software that stores and queries one, so the property graph is the data model that those products implement.

Modelling choices and limits

The flexibility leaves design decisions to the analyst. Timón-Reina and colleagues note that with relaxed schemas the main trade-offs are deciding when a data item becomes a node or an attribute, and keeping model complexity and integrity under control. A procedure stored as a property on an admission edge cannot easily be linked to a tariff or a clinical code list, while the same procedure as a node can. Hogan and colleagues add that analytical results may change drastically with the strategy used to prepare a graph, so the model design should be reported with any figures drawn from it.

The model carries no meaning beyond its labels. A label such as Hospital is a tag, not a defined class, and nothing in the property graph model deduces new facts or checks that values are plausible. Hogan and colleagues cite a schema proposal by Angles, and the GQL abstract covers specifying the structure of property graphs, but the checks that SHACL gives RDF must otherwise be written into the loading process. Data quality problems in the source records pass straight into the graph, as the BRAinS-Graph authors note.

Sources

• Angles R, Arenas M, Barceló P, Hogan A, Reutter J, Vrgoč D. Foundations of modern query languages for graph databases. ACM Computing Surveys. 2017;50(5):1-40. https://doi.org/10.1145/3104031 (preprint https://arxiv.org/abs/1610.06264)
• Cyganiak R, Wood D, Lanthaler M, eds. RDF 1.1 Concepts and Abstract Syntax. W3C Recommendation, 25 February 2014. https://www.w3.org/TR/rdf11-concepts/
• 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
• Hartig O, Champin PA, Seaborne A, Kellogg G, eds. RDF 1.2 Concepts and Abstract Data Model. W3C Candidate Recommendation Snapshot, 7 April 2026. https://www.w3.org/TR/rdf12-concepts/
• 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 39075:2024. Information technology, Database languages, GQL. Edition 1, April 2024. https://www.iso.org/standard/76120.html
• ISO/IEC 9075-16:2023. Information technology, Database languages SQL, Part 16, Property Graph Queries (SQL/PGQ). Edition 1, June 2023. https://www.iso.org/standard/79473.html
• Neo4j. Cypher Manual, Aggregating functions. Accessed 2 November 2026. https://neo4j.com/docs/cypher-manual/current/functions/aggregating/
• 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