FactEngine and Health Care
Making the OMOP easier to work with…
OMOP is the Observational Medical Outcomes Partnership which works on a Common Data Model (CDM) used to store and retrieve information about providers, people, conditions, visits, specimens, measurements, devices, drugs and other related data within the health care sector. The idea is that by having a standardised vocabulary for such things as drugs, conditions, observation types etc efficiency can be gained when transposing information from one computer system to another. In an era of digital medical records this effort aims to provide a reliable bedrock of standardised information.
The Common Data Model itself works with about 60 entity types, or tables/views if you think of a relational database, with some of those entity types/tables storing information for more than one type of concept. For instance, a central entity of the CDM called Concept provides a common repository for such things as conditions, drugs and devices amongst other entity types.
As an exercise the I put an extrapolation of the CDM into Boston and the FactEngine (www.factengine.ai), Fact-Based Modelling conceptual modelling tools.
The challenge of creating an enterprise schema with 60 entity types is one thing. Writing queries over a large health care model is another thing again.
With data warehouses or applications with large data schemas, when writing queries over the underlying database, the problems are manyfold. The first is remembering where you are within a query as you write it. The second is remembering the relationships between the entities of your schema.
A schema of 60 entity types, for instance, may have hundreds or thousands of relationships to remember. The OMOP CDM has over 300 relationships. Keeping all those in your head is almost impossible.
This is something the FactEngine was specifically designed to help manage.
A typical query in the FactEngine looks like the following:
Natural language queries are readily made possible by using Fact-Based Modelling to describe your schema. Contrast the query above to how you would write the same query in the Structured Query Language (SQL) of a typical relational database:
An advantage of FactEngine is that it helps you write the query, as it remembers the relationships for you. A typical query writing experience in the FactEngine looks like the following:
Database query examples, as per our SQL example, generally have an accompanying natural language explanation of what the query actually asks. There is a lot of time wasted in that exercise, when you may as well write the query in natural language in the first instance.
At a time when the pressures on medical staff are high, as in when performing contact tracing for Covid19 infections, the quicker and easier queries can be written to find critical information the better.
FactEngine is working hard to make it as easy as possible to query databases such as those that conform to the OMOP CDM to bring critical information to light in the shortest possible time.
More information about the OMOP CDM can be found at: https://www.ohdsi.org/ and https://github.com/OHDSI/CommonDataModel/wiki
Thank you for reading. I hope this has been helpful in painting a picture of the future of database query languages. As time permits I will write more on Fact-Based Modelling and natural language queries.
— — — — — — — — — — — — — — — — — — — —
NB The model used in this article is free from copyright with the OMOP initiative being open source. Please refer to https://www.ohdsi.org/web/wiki/doku.php?id=documentation:cdm:license and https://github.com/OHDSI/CommonDataModel/wiki for more information.
