OHDSI Home | Forums | Wiki | Github

Howto Build an OMOP compliant EPIC Smartform - Advice?

Implementers
#1

There has been much discussion that I have been trying to amalgamate regarding how to ingest survey data and other forms of data that are usually gathered outside of the EHR. Generally, these data are messy and difficult to transform into the OMOP CDM. This ties into the recent thread discussing the fate/future of CDM 6.0, which had survey tables implemented.

Thankfully the work by @clairblacketer and others has provided some guidance, but a vast array of data gathering efforts (REDCap, etc.) could actually be performed in the EHR with some thoughtful development.

We have been asked by a potential client to assist in building an EPIC SmartForm that would gather data for both quality improvement and research opportunities.

Attached is an ‘alpha’ for discussion. Please let me know if we are on the right track?

UMass - Sample IBD EPIC SmartForm v0.pdf (133.6 KB)

#2

I LOVE this idea! In my experience, most researchers using the OMOP CDM don’t get to influence how data are added to an EHR. So, this is fantastic!

In order for these data to be used by OMOP, they need to be coded in OHDSI supported vocabularies and codes for the ETL to easily incorporate them into the CDM. I took a quick look at your attached pdf and analyzed this small segment:

"10. Physician’s Treatment Plan (select all that apply): a. Continue current medication [SNOMED: 16024541000119100] "

Unfortunately, SNOMED code = 16024541000119100 is not in Athena. So, this particular SNOMED code would need to be custom mapped to a standard concept_id. Also, “Physician’s Treatment Plan” is not in Athena.

My suggestion is to take ensure all questions, statements, answers, codes, and ideas of interest are present in OHDSI supported Vocabularies and code lists. This will eliminate the burden of custom semantic mapping and also alleviate the concern of data loss. Regarding the technical implementation, you should ensure all data entered in the UI flow uninterrupted to the backend of your EHR. Many times, there are transformations to the data between the UI and the database storing these data.

Also, once you implement and use the solution, I would like to have you present your work in the Healthcare Systems Interest Group. I think this is an excellent topic for the group.

1 Like
#3

Hi Melanie,

Thank you for your thoughtful response and encouragement. As far as your correction, it is noted, and anticipated that we will come across codes that aren’t in Athena, nor a ‘standard’ for OMOP.

What I would like further guidance on is how to map the actual question being asked. We indeed want to avoid custom semantic mapping entirely, but we aren’t sure that will always be an option. Luckily, we have extensive experience with EPIC Clarity and how to derive data from SmartElements and SmartForms so that there is 1:1 capture from the UI to the RDBMS.

We would appreciate the opportunity to present to the Healthcare Systems Interest Group, once we have this effort underway, and garner feedback and insights from the community!

-S

#4

Hello Sanjay,

If you are unable to map the question or statement to a standard concept_id, then you will create a 2 billionaire for the source concept_id. WARNING: You will not be able to participate in network or collaborative studies with these custom, 2 billion concepts. And the OHDSI tools will not recognize or use these concepts. See the poster here for more information on custom mapping.

If you have the ability to convince others, I strongly suggest you help the powers that be chose standard concepts to represent their ideas of interest. Semantics might not be an exact match, but don’t let perfect be the enemy of great. And interoperability between different OMOP CDMs is great!

Awesome! It would be a shame to create custom forms & elements only for them to be transformed to an unusable or difficult to ETL format.

Also Awesome! Please keep us posted.

1 Like
t