User bio
404 bio not found
Member since Jan 15, 2024
Replies:

Thank you so much @Ashok Kumar 

According to the documentation, the recommended strategy for customizing a DTL transformation (used for converting SDA to FHIR and vice versa) is to:

  1. Create a copy of the standard DTL, and
  2. Modify it.

Once a custom DTL package is specified, the transformation automatically selects the custom DTL instead of the default one.

This approach does not cover a strategy of creating a new DTL from scratch.

And let's say I decided to try it, I have a few questions:

  1. After creating a custom DTL, how do I access it within the transformation logic?
    • I understand that we have the function GetDTL(), which calls a global ^HS.XF.Transform to retrieve the appropriate transformation.
  2. Should I manually add my custom DTL to the built-in global (^HS.XF.Transform) to ensure it's selected correctly?
  3. Is there any official documentation that covers this specific part—such as modifying the global, necessary configuration steps, or best practices—to avoid missing anything critical?

Thank you @Ashok Kumar 

Yes, I fully understand that SDA (Summary Document Architecture) is an intermediary format.
And yes, I am using the HTTP operation in my interoperability production.

When you say "You need to programmatically convert the response", do you mean:

  • Convert it into an object, or
  • Convert it into SDA?

If the goal is to convert it into an object, does that mean I should manually read the JSON entities/nodes, extract the relevant information, and transform it directly into an HL7 message—bypassing SDA entirely?

If the goal is to convert it into SDA, does that mean I must first transform the FHIR response into a FHIR request? If so, how? Because FHIR responses often contain additional fields that do not appear in FHIR requests, such as:

"type": "searchset",
"total": 1,
"search": {
    "mode": "match"
}

I’m asking these questions because, as you know, InterSystems provides built-in functionalities to automatically convert FHIR requests into SDA, such as:

  • Process: HS.FHIR.DTL.Util.HC.FHIR.SDA3.Process
  • Transform class: HS.FHIR.DTL.Util.API.Transform.FHIRToSDA3

These components accept FHIR requests and successfully transform them into SDA.

However, when handling FHIR responses, I tried extracting the payload, creating a new message, and sending it to HS.FHIR.DTL.Util.HC.FHIR.SDA3.Process. Unfortunately, the transformation failed—possibly because the FHIR response contains additional fields that the built-in functions don’t recognize.

It's worth noting that when I send a FHIR request to the exact same process, it transforms correctly into SDA (without these extra fields).

The problem was that the built in code was messing with the URL were using which was causing this error every time... Try to use a tool to capture the URL (in my case sometime it was sending "/" and sometimes it was removing the last part of the URL depending on the values in URL and path request )

I had to extend the process and the operation and slightly modify them to make this work:

Custom.NewProcess1 Extends HS.FHIR.DTL.Util.HC.SDA3.FHIR.Process

Custom.NewOperation1 Extends HS.FHIRServer.Interop.HTTPOperation

Certifications & Credly badges:
Ali has no Certifications & Credly badges yet.
Global Masters badges:
Ali has no Global Masters badges yet.
Followers:
Ali has no followers yet.
Following:
Ali has not followed anybody yet.