To model the heart

The nomenclature…

Currently, the EACTS Congenital Database uses so-called nomenclature. It’s a list of all the diagnoses and all the surgical procedures that the database recognizes. In other words, it’s the database ontology.

…and its flaws

Talking with doctors about my analysis, every now and then, I hear a sentence which begins with: “But you don’t know that…”, followed by some additional facts that are not contained in the database. Why is that? Having the data, I know everything that doctors wanted me to know, so I don’t need to be told that I’m missing something. If one can’t make an analysis based on the data alone, the database doesn’t do it’s job. The job of the database is to provide all the information needed to do the analysis.

I already have it in for the Aristotle Score. Now I’m targeting the nomenclature.

The list was probably created by surgeons, who don’t have knowledge about data structures and mathematical modeling. So they created a list of procedures, with a possibility to assign many procedures to one operation. Unfortunately, they didn’t know that they have had must keep one procedure per entry. For example, they created two procedures:

  • VSD repair
  • Arterial Switch Operation (ASO)

That’s fine. If a patient had one of them, you assign one of them. If a patient had both, you assign both. But then, suddenly…

  • Arterial Switch Operation (ASO) and VSD repair

Why? I can already assign both VSD repair and ASO to a patient. Why would I need a third entry, containing both of them? This violates the integrity of the data.

Let’s say, I ask the system: “Please tell me about patients who had VSD repair, what else did they have?”. Being asked such question, the system will look at the “VSD repair” procedure, and show other procedures attached to those patients. Since “ASO + VSD” is a different procedure, it will not be shown. This is a data model integrity violation.

Clearly, making my analysis, I need to repair those flaws, by removing “ASO+VSD” procedure and replacing it with two procedures: “ASO” and “VSD”.

New ontology

The database is bound to the given ontology. When given a list of procedures, it can talk using the procedures’ names.

I learned that the original list of diagnoses had thousands of them. It was shortened down to 200 entries. So there potentially are thousands of distinguishable possibilities.

A heart is an object which consists of parts. Each part can suffer a number of defects. It should be possible to describe a diagnosis by specifying one or more defects in specific heart parts. This would be a creation of a new ontology: instead of a plain list of diagnoses, the database would speak the language of anatomical parts of the heart, their features and procedures performed. This would be much more powerful than current list.

The same with procedures. Instead of having a list of procedures, a doctor would have a set of heart parts with possibility to describe what was done against each of them.

Data integrity

Current nomenclature allows entering inconsistent data. For example, there are procedures that can not go together, for example variants of one procedure. If one of the variants was performed, it can’t be done again in another variant, because it was done already.

It it really a problem? In my opinion, yes. Current data set does contain inconsistencies, so it’s really happening. You don’t see it in the general, aggregated reports on-line, it’s visible only in the source data.

Trying to fix this problem by applying validation rules like “Procedure X can’t go together with procedure Y” would be both time consuming (to design and implement) and ineffective. There would be too many rules to think of them all.

A heart model would naturally ensure the data integrity. On other words, all the “validation rules” would be embedded in the data model, without need to specify them explicitly.


Database would use names of anatomical parts of heart. Old diagnoses names would be still useful and would refer to specific predefined heart descriptions. Data analysis would improve significantly, because it would be aware of the relations of the heart parts. Now, there are several VSD procedures. Current list considers them be totally unrelated. Anatomical ontology would know that all of them are variations of one procedure.

  • It’s a generalization of the current Nomenclature and it would be backwards compatible.
  • Database reports and data analysis would talk the language of anatomy of heart.
  • Related procedures would be represented as related (Now, the related procedures are represented as unrelated).
  • Integrity of procedures and diagnoses would be ensured.
  • Detailed, accurate heart description would result in detailed, accurate analysis and better understanding of the surgical results.

Author: automatthias

You won't believe what a skeptic I am.