Quality of care evaluation parameters

There are no really precise and good parameters that could be used to evaluate the quality of care in hospitals, which submit the data to the EACTS Congenital Database or similar databases. The databases don’t contain detailed information about patients’ health. Let’s quickly review possible QoC parameters.

Remapping finally convenient

Preparing the materials is a major part of my thesis work. The database I’m analyzing uses a list of diagnoses which in fact should be called diseases. The diagnoses list is tangled, the entries do not describe single properties of the patient. I can’t analyze the data in this form, because all the statistical methods assume that the variables describe single properties. Multiple regression, for instance, will find combinations of factors that have an effect on the response variable, but the factors themselves need to describe single properties.

What I need to do, is remapping.

Tetralogy of Fallot database representation

Tetralogy of Fallot is a significant and complex congenital heart disease. It consists of four heart malformations. So if a patient is described to have TOF, it means that she/he has all those four malformations together.

However, the separate malformations are already present on the diagnoses list, as separate entities. From a data-modeling perspective, it’s a redundancy on the factors (malformations, diseases) list. This leads to problems with interpretation. As the VSD is one of TOF’s components, is already present on the diseases list, and users are allowed to enter both VSD and TOF diagnoses, there are patients with all four combinations in the database.

Size and color

This is what the current “related factors” view looks like. I am using advantage of the two presentation techniques: size and color. The size represents the number of patients that represent the association. Color represents the mortality, from blue and green (low mortality) to orange and red (high mortality).

This representation allows to quickly scan the table and find interesting points: red and big rows. Size and color work independently, it’s kind of two-dimensionality of the report representation.

Normalizing the data representation

I’ve spend many days working on the database browser and normalization of the data structure. The original problem was that the so called nomenclature, which is a flat list of diseases that couples factors that should be independent for the analysis.

The plan is to decouple the factors and create alternative nomenclature. The new, as I call it, normalized factors will carry the same information as the original nomenclature.

Given, treatment, result

The data structure refactoring will never end. At least it feels like it never will.

While normalizing the factors, I decided to add a new class, a factor type. I hate word “type” but I don’t have any better word now. The types will be:

• Given: not influenced by the hospital, mostly diseases and their properties.
• Treatment: the elements of the treatment. The hospital’s choice.
• Result: influenced by both given and treatment factors. They’ll be the dependent variables.

Having the factor types, it’ll be possible to compare the hospitals against the way of treating the patients. For example, what percent of patients will have palliative operations?

Four age groups in the EACTS Database reports

I just changed the EACTS Congenital Database reports to show four age groups instead of three. Old age groups were:

• Neonate (0-30 days)
• Infant (31-365 days)
• Other (366 days and more)

New age groups are:

• Neonate (0-30 days)
• Infant (31-365 days)
• Child (1-18 years)
• Adult (18 years and more)

I’ve changed six reports:

• Basic Score report
• Quality of Care
• Complications
• Outcome prognosis
• Primary reports
• Gold Standards

The linked reports are publicly available, so if you’re interested in congenital heart surgery, you can check the reports yourself.

Database browsing with Django

After few days of building a database browsing tool with Django, I must say: Django is brilliant!

I have set up browsing for all the major database entities: hospitals, surgeons, patients, operations and factors (a factor is a disease, procedure, etc). The database browsing website is intensively interlinked. Every hospital, surgeon, factor, etc is linked, so you can click it and follow to information about it.

Almost everything was done using the generic views, which means that I didn’t have to write the views myself. I decided to migrate the data instead of using the legacy tables directly. It required a bit of work with migrating the data, but I wanted to have pure Django-generated tables. Besides reading the Django documentation, what I have done was:

• Write models for my data: Hospital, Surgeon, Patient, Operation, Factor
• Move the data from the old tables to Django tables
• Generate slugs for nice URLs (slug-is-this-king-of-string)
• Design URLs (/hospitals/, /hospital/CODE/, etc)
• Write templates (hospital_list.html, hospital_detail.html, etc)

The next major task will be creating the “related factors” view. It seems like I’ll have to write a custom SQL query for that. The question is: having a given factor (tag), what else factors are associated with patients with my given factor?

What’s a diagnosis?

The EACTS Congenital Database website states:

The resulting the International Nomenclature for Congenital Heart Surgery including the Minimum Data Set of 21 items and the lists of 150 Diagnoses, 200 Procedures, 32 Complications, as well as 28 extra cardiac anomalies and 17 preoperative risk factors.

What’s a diagnosis, anyway? Is VSD a diagnosis? No, it’s a disease. So are Tetralogy of Fallot and Hypoplastic Left Heart Syndrome. We can talk about a diagnosis, when certain disease is identified within a patient.

Diagnosis can be also referred to as a set of identified diseases. This is unfortunate, because the nomenclature contains now sets of diseases, for example TGA+VSD. The dictionary of disases should contain single diseases only, and the diagnosis should be defined as a set of previously defined diseases, identified within a patient.

Tool for the database exploration

I decided to revive my idea of the database exploration tool. It won’t be static HTML files generator, it’ll be a mod_python based web service. Sometimes I wonder, why such tool wasn’t developed before. Now, since I’m starting to make the analysis, I’m becoming a real database user, not an administrator.

Despite I try to create a general tool for the data analysis, I can’t avoid looking at the data directly. I need to examine the data in many ways, and it’s often necessary to look at the specific patient histories to find out, if a special combination of factors was an data entry error, special case or a kind of case that wasn’t considered before.

I want to have trendy URLs, like:

http://server/patients/some-patient-id/

http://server/diagnosis/tof/

http://server/diagnosis/tof/male/

First thought was the mod_python and all custom code, but after some research, I decided to try Django. Its homepage says:

Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.

The tutorial showed how to get a simple poll service in no time. It deals with the database structure as well. I’ll need to build a Django model for my database and port the data, and then I’ll be able to build a browsing interface very fast. And I’ll have my trendy URLs.