It doesn’t look like OMOP includes a structure to store patient contact information like name and phone number to be used for recruitment. Is there another standard that others would recommend?
1 Like
Would you want store PHI in your system?
Yes, we’d like to store PHI in separate but secure structure to be used as a compliment to the OMOP data.
Colorado extends the Person table to include a name field. Since it is NOT proper OMOP, this field won’t ever be used in a network query or available for use in Atlas, but it is available for our Bi-devlopers to write SQL to retrieve the data.
We have extended OMOP to include a structure for this data. I will have my colleague post the structure here. (It really should be submitted formally - and we will do that as soon as we can).
I am curious, what is the use case for storing PHI?
The All of Us Research program has extended the OMOP CDM to include PHI tables. Since this includes a large number of institutions with an already done implementation, it would be great if it could be adopted as a blessed standard/extension. Maybe not part of the core CDM but a sanctioned plugin.
@cukarthik Let me know if it is OK to share the All of Us PHI DDL.
@dave.barman PHI could be used to generate a hash and link records across institutions or to contact patients to take a survey.
Friends:
Please bring it to the CDM Working Group and write a proposal here. Don’t forget the use cases!! 
OMOP CDM has the structure to store contact information. It should be stored in Observation table. The concept_id are following:
42869483 (Personnel Fax number)
42869484 (Personnel Email address)
42869482 (Personnel Business phone number)
42869479 (Personnel Cell phone number)
42869480 (Personnel Home phone number)
and there are more…
The actual phone number or email address are stored in the value_as_string field.
and patient name is stored in observation_concept_id: 4161172 (Patient name).
@mgurley any chance you are able to share that DDL? We are interested in moving to OMOP but see the lack of PHI tables as a barrier. Would likely create our own supplemental tables, but would love to see what’s already out there!
Can you share the DDL for PHI extension?
Where can I find the DDL extension for PHI
At Columbia we are most likely going to do what @MPhilofsky does at Colorado.
For the All of Us program, we created a set of PII (Participant Identifiable Information) files/tables for program reasons. The information can be found here. I’m not sure if they would be very helpful for others b/c we are actually used those tables for internal QA processes.
We have modeled PHI, source table identifiers, and other non-OHDSI used variables for adding to the CDM. The best solution for us has been to add “Site-Specific add-on” (aka extension) fields to CDM tables.
Eventhough, there are standard concept_ids to store PHI in the Observation table, we don’t do this. We don’t want PHI buried in our CDM, it’s too risky. Extra tables sounded like a good idea, but implementation and increased resource use to join tables proved a little bit more work than anticipated. So, we went with adding Site-Specific add-on fields to the CDM. These won’t be used by Atlas or other OHDSI tools, but the extra fields won’t break any of the other tools. Also, the field names all have ‘_x’ to signify the field is not an OMOP field.
I have a poster here explaining the how & why along with some points of caution for adding extra fields.