Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
SURVEY data in OMOP CDM - updated #137
Adding Patient Reported Outcome data to CDM
ICON plc is currently engaged in a project with [[http://www.ichom.org/|ICHOM (International Consortium for Health Outcomes Measurement]].
ICON plc is developing a platform to ingest, store and analyse the patient 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:
The SURVEY table is used to store an instance of a completed survey or questionnaire. It captures details of the individual questionnaire such as who completed it, when it was completed and to which patient treatment or visit it relates to (if any). Each SURVEY has a SURVEY_CONCEPT_ID, a concept in the CONCEPT table identifying the questionnaire e.g. EQ5D, VR12, SF12. Each questionnaire should exist in the CONCEPT table. Each SURVEY can be optionally related to a specific patient visit in order to link it to a specific patient assessment or treatment.
Patient responses to survey questions are stored in the OBSERVATION table. Each record in the OBSERVATION table represents a single question/response pair and is linked to a specific SURVEY / questionnaire in the SURVEY_OCCURRENCE_ID. Each response record is the response to a specific question identified by the OBSERVATION_CONCEPT_ID. This concept ID is a unique question contained in the CONCEPT table. An individual survey question can have multiple responses to a question (e.g. which of these items relate to you, a, b, c ,…?). Each response is stored as a separate record in the OBSERVATION table.
Amendments required to the OBSERVATION table are as follows
The example below describes the data to be stored for a question on the HOOSPS (Hip Disability and Osteoarthritis Outcome Score) patient questionnaire.
CONCEPT table – example
The patient response is captured as a code 2 (in this instance) in the questionnaire. The CONCEPT_ID is determined by finding a match in the concept table for the code (2) for the specific question (identified by HPS1) in column DOMAIN_ID and the response value (2) in the column CONCEPT_CODE.
SURVEY table - example
OBSERVATION table - example
The proposal argues for:
This will needed maintenance !
Whether the CMD should or should not include Health Outcome Measures is a different question from should this proposal be accepted. I plan to say the proposal should not be accepted, based upon the implementation. The proposal tries to fit Outcome Measures into the existing CDM, but the CDM does not handle it very well.
@don-torok , thanks for that input. Just to set the context a little further here, the thinking behind the design here is to keep it to the same level of normalization as the other OMOP domains and minimize the number of new entities or domains. This approach is consistent with the overall OMOP philosophy?Taking each point in turn;
I would be interested to get your view on what use-cases that the current proposal does not support. Are there specific scenarios that you are dealing with or have considered that cannot be supported using the proposed model.