Question
· Sep 8

Custom Operation VS production

#InterSystems IRIS for Health #Global Masters #HealthShare

Hi Everyone,

So after @Ariel Glikman posted a custom operation example, I'm stuck on another dilemma, and here it is:

  1. I might have different patients with the same business identifier
  2. Each patient (logical) might have several resources like Observations, Conditions and Tasks (there are other type but they are not part of the issue)
  3. Tasks are a representation of something called "Morbidity", it's a presumed illness but not a validated condition
    1. Tasks are created according to observations and/or conditions and the task hold a reference to those resources
    2. A resource such as Observation / Condition may be connected to only one task
    3. A patient might have several tasks

my requirements:

  1. Allow queries according to task id / patient id / patient business identifier
  2. Allow date filtering (different date for each resource)
  3. for each Observation / Condition I need to add the task ID it is part of (if so)

my dilemma: will it be better to do all that logic within the custom operation, or should I create a production with a listener that will do all that logic?

Thanks,

Eyal

Product version: IRIS 2024.1
Discussion (2)2
Log in or sign up to continue
DC AI Bot · Sep 8

Based on the scenarios related to logical patients, resource associations, filtering, and business identifiers, there are two approaches available:

  1. Custom Operations:

    • A custom operation in InterSystems IRIS enables you to design tailored logic that can filter data, manage tasks, and connect observations or conditions dynamically. This ensures that specific business rules are implemented and executed exactly as intended. Attributes like task ID, patient ID, filtering by date, and associations between tasks and resources can be programmed directly within this operation [1][2].

  2. Production Listener:

    • A listener in production is designed to automate and continuously handle incoming data based on established rules. A listener enables asynchronous processing as data arrives and can be used to create tasks, link resources, and apply filters as per the workflow. This is commonly used for applications needing real-time resource management [1][2].

Both methods have merits depending on the workload and business needs:
- Custom operations allow greater control over conditional application logic and interactions with data, especially for complex requirements.
- Listeners are better for production environments requiring automated and continuous data handling and integration with multiple systems.

Based on your scenario, if many transformations and checks are needed per interaction—custom operations might be preferable. Whereas, for scalable, real-time processing, opting for a listener in production is more suitable.

Sources:
[1][2]

Sources:

0 0
Keren Skubach · Sep 9

Hi Eyal,

The main difference really comes down to time and storage. You can put the logic either in a custom operation or in a production—both work—but each has its trade-offs.

With a production, you get the nice benefit of being able to visually trace what’s happening. It lets you monitor the flow and easily see what happened with your request. The flip side is that this visibility comes at a cost:

  • It’ll run a bit slower, since you’re adding another component in the middle.
  • It’ll use more storage, because every message in the trace is stored in the database until it’s purged.

So, productions are great for monitoring and transparency, but they do take up more resources compared to a custom operation.

0 0