OHDSI Home | Forums | Wiki | Github

Utilizing the CDM for Clinical Applications with Second-Level Response Times

General
#1

Hello OMOP Community,

As a first-time poster, I’m seeking advice on using the Common Data Model (CDM) for operational clinical applications with response times in the order of seconds.

Our team is developing applications for in-hospital use by clinical staff (primarily doctors and nurses), leveraging EHR data. These applications are intended for online, point-of-care use rather than analytics or research purposes. When we refer to “near real-time” or “real-time,” we’re aiming for response times in the range of seconds, not milliseconds or microseconds.

We’re considering adopting the CDM as our primary schema for medical data, with the possibility of adding columns if necessary. Our main focus is on utilizing the CDM’s approach to modeling health data.

Key points:

  1. Target: Clinical applications with second-level response times
  2. Users: Hospital clinical staff
  3. Data source: EHR
  4. Proposed schema: CDM (potentially with minor modifications)
  5. Out of scope: App-specific data (users, permissions, etc.)

Questions for the community:

  1. Has anyone implemented CDM for similar use cases requiring second-level response times?
  2. What challenges or limitations did you encounter in achieving these response times with CDM?
  3. Are there any best practices or recommendations for optimizing CDM for this level of performance?
  4. How well does CDM perform in an environment requiring second-level response times?
  5. Are there other considerations you’d recommend we take into account?

I’m happy to provide any additional information or clarification as needed.

Thank you in advance for your insights!

#2

Hi @Aviad:

Welcome to the family.

This is a very interesting use case, that few people in the community have attempted, it seems. The problem is that the OMOP CDM is not geared towards it, and you will probably have to do your own Expansion of the Model (what you call minor modifications). For example, right now there is no support of orders (issue, follow up, fulfillment, cancellation etc.), no support for scheduling, and no support for identifiable information of patients, providers and organizations (names, phone numbers etc.). The other problem is that the model isn’t transactional, or semi-transactional. All entities tend to have start and end dates, stretching over time. So, when a patient undergoes a treatment or has a condition, you will have to go back to the same record and change the end date until it is over. While that is happening there is no indication that something is still ongoing (see the debate about this problem for visits here, but it also got debated later). Also, often the end date is not available, even when this is technically not possible (see the debate about this problem also for visits here). But so far this has been discussed as a day by day problem, rather than second by second.

Let’s see if somebody wakes up from vacation time who has more experience. Good luck to you.

#3

Thank you @Christian_Reich for this detailed and insightful reply, and for the warm welcome!

Could you elaborate a bit more on what you meant by saying that

? I’m particularly interested in understanding how this might impact real-time or near-real-time operations in a clinical setting.

I’ll also take your advice and wait a bit longer to see if others with experience in this kind of usage chime in.

Much appreciated,
Aviad

#4

@Aviad

I understand your goal is to obtain real-time data in a clinical application, correct? I wouldn’t recommend using the OHDSI Common Data Model for operational clinical applications.

The OHDSI CDM is primarily designed for analytics and research, while operational clinical applications require many additional data elements for clinical operations. Modifying the CDM schema to fit your use case might not be a wise approach, as it would involve significant changes and might not meet your clinical application objectives.

Instead, consider modifying your EHR system architecture and implementing a data streaming process to achieve real-time data for your clinical applications.

#5

Thank you very much, @mityung, for your thoughtful and informative response. Your insights are truly valuable, and I appreciate the time you’ve taken to address our situation.

I hope you don’t mind if I ask for a bit more clarification on a few points:

  1. Regarding data streaming from our EHR, I’m curious about your thoughts on the data model we’d need to effectively store and utilize this streamed data for our clinical applications. We were initially drawn to OMOP due to its robust approach to modeling medical information, especially considering our goal of creating multiple apps that can share data efficiently. Would you have any recommendations for alternatives that might better suit our operational needs?

  2. I’m particularly interested in your perspective on why modifying the CDM schema might not meet our clinical application objectives. Could you perhaps elaborate a bit more on this point? Your expertise here would be incredibly helpful as we navigate these decisions.

  3. I apologize for not providing enough context initially. Unfortunately, we don’t have direct control over the EHR system or its architecture. Our primary objective is to build clinical applications that can utilize the existing hospital data, which is currently stored across various system databases that we cannot directly modify.

  4. Given these constraints, do you have any suggestions for approaches we might consider? We’re very open to exploring different strategies that could help us achieve our goals within these limitations.

Thank you again for your patience and expertise. Any help you might offer is immensely appreciated as we work through these challenges.

Best regards,
Aviad

#6

Hi @Aviad. I’ll elaborate on both @Christian_Reich and @mityung’s comments:

  1. The OMOP CDM represents more than a decade of design decisions and consensus conventions that are aimed at OMOP’s core use case: retrospective analysis. As you develop your project you will encounter numerous situations where those designs and conventions are incompatible with your use case. It’s in the name: Observational Medical Outcomes Partnership. You will be on your own to resolve those incompatibilities, as no one else in the community is addressing those issues.
  2. You will make so many modifications to the OMOP CDM that your model will no longer be an OMOP CDM. I posit your model will likely become incompatible with OHDSI tools, and also will likely become incompatible with CDM updates. You may decide OMOP is your best option as a starting point for a data model that can accommodate data from your various systems but I would embark on that journey with acknowledgment that you are not building an OMOP CDM - you are just using the CDM schema as a starting pattern.
  3. Your usage pattern is quite different from the rest of the community. Most CDM holders update their CDM by performing a complete truncation and reload, and they do that on a weekly, monthly, or quarterly period. There are a small number of CDM holders I’m aware of who perform incremental updates. That’s what Christian means by semi-transactional, I think. I’d be willing to bet there are no CDM holders performing near-real-time incremental updates. So again, you’d be on your own to solve any problems that difference reveals.

That may sound “unwelcoming” but it’s not meant to. It’s just that the community is focused on the core use case so you won’t have compatriots in the community trying to address your very different use case.

#7

Thank you @jmethot !

I think you understood our use case wonderfully, and your clear, profound and detailed feedback is very helpful to us. I see your message as very welcoming, and caring.

We are considering OMOP as the starting point. The fact that that adding new kinds of data to it will make us incompatible to some degree with the standard and tooling is not a surprise, you comment making this explicit is valuable and brings clarity.

Knowing such a mode of operation is completely uncharted territory in CDM usage is another great input for us, and one which we will definitely consider seriously.

Just for future readers (and maybe curious current ones), here are our planned next steps:

  1. Benchmark a synthetic workload (mostly writes, but also reads) using the CDM in a “transactional” manner, simulating our future usage. This should give us some indication about the usability of the CDM our applications.
  2. Consider other existing medical data schemas, evaluating them for this usecase.
  3. Evaluate using a custom (small) data model for each application. This sidesteps the need for a single, “all-encompasing” data model, making its schema easier to create.

In case someone has any feedback regarding our plan, or the original question - that would be great!

1 Like
#8

@Aviad
Point#2 has been addressed by @jmethot very precisely.

Statements from your message:

“……Unfortunately, we don’t have direct control over the EHR system or its architecture. Our primary objective is to build clinical applications that can utilize the existing hospital data, which is currently stored across various system databases that we cannot directly modify.”

“……especially considering our goal of creating multiple apps that can share data efficiently?”

I understand the following:

  1. You are developing a new system that will accommodate your multiple clinical applications and analytics needs.
  2. The new system is intended to integrate with your existing EHR, which involves data stored across various databases and facilitates bidirectional data exchange.
  3. The new system is expected to support real-time data exchange.

If this understanding is accurate, you’ll need to detail your interoperability strategies so I can assist in designing a robust solution that aligns with your business requirements. You also mentioned that you cannot modify the data within the EHR databases.

What options do you have for exchanging data with the existing EHR?

#9

@Aviad I’m also available for a quick Zoom call to discuss this further, if that would be helpful. You can contact me via email at nsg@mityung.com to coordinate a convenient time.

#10

Thank you @mityung. We’ll be doing other things during the remainder of August, but will be happy to be in touch in the future, as we come back to this issue, with more data.

Just to answer your question, the data digestion is from the various databases, which is why we cannot have the EHR emit events.

t