link to github

• Requestor: Colin Orr and Catherine Kerr, ICON plc
• Revising party: Joshua Ransom, Anna Corning, Emelly Rusli, Rayhnuma Ahmed, Aaron Stern; SHYFT Analytics
• Discussion: here

ICON plc is currently engaged in a project with ICHOM (International Consortium for Health Outcomes Measurement.

“ICHOM's mission is to unlock the potential of value-based healthcare by defining global Standard Sets of outcome measures that really matter to patients for the most relevant medical conditions and by driving adoption and reporting of these measures worldwide.”

ICHOM brings together patient representatives, clinician leaders, and registry leaders from all over the world to develop Standard Sets, comprehensive yet parsimonious sets of outcomes and case-mix variables for specific medical conditions that ICHOM recommends all providers track.

Each Standard Set focuses on patient-centered results, and provides an internationally-agreed upon method for measuring each of these outcomes. ICHOM believes that standardized outcomes measurement will open up new possibilities to compare performance globally, allow clinicians to learn from each other, and rapidly improve the care provided to patients.

ICHOM Standard Sets include baseline conditions and risk factors to enable meaningful case-mix adjustment globally, ensuring that comparisons of outcomes will take into account the differences in patient populations across not just providers, but also countries and regions. They also include high-level treatment variables to allow stratification of outcomes by major treatment types. A comprehensive data dictionary, as well as scoring guides for patient-reported outcomes is provided for each Standard Set.

ICON plc is developing a platform to ingest, store and analyse the outcome measures and is using the OMOP Common Data Model to store the data. The current CDM satisfies many of the requirements, but there are some gaps, specifically:

• We need to store data relating to each PROM (Patient_reported Outcome Measure) questionnaire that is completed by a patient. We propose introducing a new SURVEY table. Each row in the table represents an instance of a completed survey and serves to link a number of observations together in the RESPONSE table as well as providing additional information about the survey itself.
• The patient responses are stored as key-value pairs in the RESPONSE table, but we need to be able to group responses together according to the survey they belong to. We also need to know the timing of the observation in relation to the treatment the patient received - for example, 'baseline', or 'six month followup', so that we can compare outcomes. We propose adding the SURVEY and RESPONSE tables to fit these requirements.
• Patient responses will be stored in the RESPONSE table as either:
  RESPONSE_AS_CONCEPT_ID, RESPONSE_AS_NUMBER, RESPONSE_AS_STRING, and/or RESPONSE_AS_DATETIME. We require an extension to the concept table to include the following domain/vocabulary additions:

• QUESTION_CONCEPT_ID and QUESTION_SOURCE_VALUE may be used to record individual questions or groupings of questions that represent a survey Section (these relationships could be managed within the FACT_RELATIONSHIP table as well)
• Extensions to the concept table will include the ICHOM Data Dictionaries for each Standard Set. This requires new concepts for each data point in each Standard Set AND a concept for each allowable value for each data point. The ICHOM vocabulary will grow with each Standard Set that is defined by ICHOM. Each Standard Set is likely to generate 500 to 1,000 concepts and the objective is for 50 Standard Sets, thus requiring in the order of 50,000 new concepts.

(other potential table name options: PRO, PATIENT_REPORTED_OUTCOME, PROM, others?)

Example is for observation made through Question 1 (HPS1) on the HOOSPS survey (Hip Disability and Osteoarthritis Outcome Score). The question asks the degree of difficulty in descending stairs due to the patient's hip problem. The patient answers “Moderate”.

The patient response is captured as a code 0..4 and the CONCEPT_ID is determined by finding a match for the question Variable ID (HPS1) in DOMAIN_ID and the response in the CONCEPT_CODE.