Models for Query Health

One of the big topics of discussion early on in Query Health was what the model of clinical data was for executing the query against.  I've now done two different implementations and am working on a third and have some thoughts about how simple or complex the model needs to be.

For the most part, the model that I've needed has been very simple for the queries that have been given to us to work on.  The basic data elements (Tables) are shown below, along with their components (columns).

• Patient
• Age/Birthdate
• Gender
• Race
• Ethnicity
• Identifier
• Encounter
• Identifier
• Service Type (CPT Codes)
• Start Date
• End Date
• Provider
• Specialty
• Problem
• Identifier
• Start Date
• End Date
• Status
• Code (ICD or SNOMED)
• Allergy
• Identifier
• Start Date
• End Date
• Code (NDC or RxNORM for medications)
• Medication
• Identifier
• Start Date
• End Date
• Medication (NDC or RxNORM Code)
• Dose
• Route
• Frequency
• Result
• Date
• Code (LOINC)
• Value
• Unit

Each of these need to be linked back to the patient, and ideally, would also be linked back to the encounter.  For the queries I've looked at implementing, the values shown in bold are the critical ones that have been used.  The other ones are simply ones I think should be in the simplified model.  All of these components already exist in the TOC Clinical Information Model.

I've been able to map the simplified model elements to appropriate JavaScript functions in hQuery, and to XQuery functions against the CCD model in the most recent work.  For the SQL implementation I'm working on now, I'm simply going to use these six as the basic tables, with simple definitions for the columns.  I'll assume a simplified model for identifiers and vocabulary where the "namespaces" are fixed in the SQL representation for identifiers and codes.  That is to say, if you know what table the code or identifier is in, the namespace (OID in HL7 Version 3) is fixed to a particular value for an implementation.  That's just a simplification to make demonstration that EQMF can be used to declaratively represent the queries simpler for me.  In the real world, this might be reasonable for a single practice, if data from multiple practices is being managed, it might not be, but that's a refinement.

I think the next step after I do the SQL Table implementation is to look at either a risk stratification query (describe the population of a practice stratified with respect to some disease risk), or a study showing correlations between two particular items such as the use of particular medications with a particular disease conditions [e.g., Vioxx/ heart attack, Influenza Vaccination/Flu].