Question
· Mar 21

Transforms in COS over DTL

Hi All,

  After doing IRIS/Ensemble etc for 20 years I've come across a company who have very odd view, especially about DTL's and routers.

  They have convinced themselves to use COS for transforms (including HL7) and for routers (and one of their 3rd party providers agree!)

  Their reasons are; efficiency, compatibility, flexibility, power and re-usability.

 

  Of course these reasons are wrong!

  • Efficiency, difference between 1-2 lines compared to a DTL/XML going to 3-4 lines (This also assumes the COS code is well written)
  • Compatibility, surely less with COS as its subject to developer style?
  • Flexibility, you can add <code> blocks in DTL anyway
  • Power, no idea what they are saying here?
  • Re-Usability,?

 

  My counter arguments are;

  • Non technical users can see the DTL in a GUI
  • You don't have to remember PID:5 is patient name for example
  • You get auto complete on using schema's
  • You will miss out on DTL specific functions (example lookups), albeit you could call the look up code in COS
  • Its bloody insane not to use DTL's for HL7!

 

  Anyway I could do with some other peoples opinions or examples I can present to convince them DTL's and routers (using rules) is the best way.

 

  Please help!

Discussion (3)3
Log in or sign up to continue

A couple of thoughts ...

  1. In my experience, the pool of resources that can build complex integrations using the Health Connect GUI is an order of magnitude larger than those that can do the same in pure ObjectScript. The rarer the resource, the more it costs.
  2. I've also found that some of those that have used ObjectScript as a method to enhance/alter the behavior of production components have implemented "private" methods or relied on undocumented behavior that has the potential to change or become deprecated, requiring extensive testing and possibly re-coding when upgrading.

Maybe someone is looking for job security.  

Regarding 

You will miss out on DTL specific functions (example lookups), albeit you could call the look up code in COS

some might think that using classes with COS code is better as it allows you to call any funtion you like. I think that's demonstrating a lack of knowledge.  If you created a class that extends Ens.Rule.FunctionSet , the functions then become available to anyone using the DTL or Rule Editor.

Additionally the new Rule Editor allows for ForEach whch otherwise might have been difficult to implement in the past.

I'd much rather be spending my time working on more advanced parts of an implementation instead of DTLs and Rules.

The only odd thing about DTLs and Rules is when you ask a business analyst to be involved they might not feel as strongly about following a rigorous CI/CD process. In my experience, some folks like to make changes to the DTLs and Rule and not commit to a feature branch and promote up thru the different environment(TEST,STAGE,PROD) as would normally be done if one was striclty in a class, even thought DTLs and Rules are in fact classes.