New post
AllAccepted answers
Enrico Parisi · Feb 21, 2024

I'm not sure what "HL7 Reference Guide" exactly means for you, however, within "health enabled products" (IRIS for Health, Healthhare Connect, Healthshare UCR etc.) there are "HL7 Schemas" for all HL7 v2 variants up to 2.8.2.

Can be accessed from Management Portal Interoperability -> Interoperate -> HL7 v2.x -> HL7 v2.x Schema Structures.

There, for each version you can browse in detail the HL7 message structure, segments, field, subfields etc down to code tables associated to coded entries/fields.

If you don't have IRIS for Health, you can download IRIS for Health community edition that is free for non commercial/production use (check license for details).

Enrico Parisi · Feb 19, 2024

Well Julius, in general I would agree with you under that circumstances, BUT, in this particular case, the code he has implemented correspond exactly to the "Defining a Computed Property" documentation sample.

This is not a case of using %Library.PropertyHelper in random code, it's a case of using it according to documentation.

Granted that he is trying to use a variable instead of a string constant and (for good reasons IMO) does not work due of implementation constraints.

I agree that understanding the actual requirements and what needs to be implemented (the real problem), a viable solution can be suggested.

Enrico Parisi · Feb 19, 2024

This is interesting.

It is evident that when the class is compiled IRIS parse the <PropertyName>Computation() method(s) to find out what properties are actually used/referenced/passed to the cols.getfield() method(s), then it use this information to set the "fields" multidimensional property of %Library.PropertyHelper class before calling the <PropertyName>Computation() method.
This way only the used properties are set in the "fields" multidimensional property of %Library.PropertyHelper class.
This optimization improves performance in case of a class with many properties, possibly "complex" properties (calculated, references etc.) and I believe this is why has been implemented.

The "parser" is...simple, very simple.

To prove this assumption I wrote a little sample:

Class Community.Computation Extends %Persistent
{

Property FirstName As %String;
Property LastName As %String;
Property FullName As %String [ SqlComputed ];
ClassMethod FullNameComputation(cols As %Library.PropertyHelper) As %String
{
    ; cols.getfield("FirstName")
    ; cols.getfield("LastName")
    return ..FullNameComputationSub(cols,"FirstName","LastName")
}

ClassMethod FullNameComputationSub(cols As %Library.PropertyHelper, p1 As %String, p2 As %String) As %String
{
    return cols.getfield(p1)_" "_cols.getfield(p2)
}

/// do ##class(Community.Computation).test()
ClassMethod test()
{
    set obj=..%New()
    set obj.FirstName="Enrico"
    set obj.LastName="Parisi"
    write obj.FullName,!
}

}

If I run test() I get:
 

do ##class(Community.Computation).test()
Enrico Parisi

If I remove the commented line "; cols.getfield("FirstName")" and run test() again:

do ##class(Community.Computation).test()
 Parisi

If you look at your error:

"set cols.fields("ropert")={ropert}'"

That's the parser that found "cols.getfield(property)" and assuming a string was passed removed the first and last characters (assuming were double quotes), so it got "ropert".

Bottom line, cols.fields() can only be used passing a string constant with a property name.

Enrico Parisi · Feb 18, 2024

If you using IRIS prebuilt HL7 Business Service components, like EnsLib.HL7.Service.TCPService, it is not possible.

There is no place where you can call Transform() method.

If you have implemented your own BS, then you have full control.

Having said that, I ask again, what's the problem of implementing a simple HL7 Routing Business Process with a simple rule and transformation between BS and BO??
It can be done in few mouse clicks...

Enrico Parisi · Feb 18, 2024

Within setter and getter method you need to use Instance Variable to set/get the actual property value:

Property NewProperty1 As %String;
Method NewProperty1Get() As %String [ ServerOnly = 1 ]
{
    Quit i%NewProperty1
}

Method NewProperty1Set(Arg As %String) As %Status [ ServerOnly = 1 ]
{
    Set i%NewProperty1=123
    Quit $$$OK
}

To implement it in datatype class try using a method generator.

Maybe if you explain what you are trying to achieve there can be a different solution.

Enrico Parisi · Feb 9, 2024

My guess (I may be wrong!) is that you did not configure IIS existingResponse PassThrough option.

In IIS, if you don't configure that options, application errors (like IRIS REST errors) are not sent back to the client, instead a "standard IIS error" (my definition) is sent back to the client (i.e. browser).

Check this IRIS documentation on Configuring IIS to Return SOAP Fault Details, although it refers to soap, the same apply to REST.
You may want to google "IIS existingResponse PassThrough" for more info.

Again, I may be wrong...but I bet on this being the issue here.

Enrico Parisi · Feb 5, 2024

Nice write up, I agree to most of your comments.

Nowadays I personally try to avoid $Select() and $Case() because I realized that it's often difficult to read, particularly for new comers.

I fully agree on using full command keywords, in my case including for most common ones although I admit that sometime I almost automatically type a single letter Quit with postcondition to exit a loop (Q:key="")! 😁

As for "Use all lowercase for command keywords"..well, this is really a matter of taste, I like commands with capital first letter, I find it increase readability, but, again, it a subjective opinion.
One thing for sure, whatever you choose, stick with it! Be consistent.
In fact when I happen to modify existing code, I try to adapt new code to the existing style (if any 😱 ).

About using full function names for intrinsic functions....well, I agree but meanwhile I have to admit I'm not THAT consistent, I sometime use abbreviated/single letter for some functions like $d, $zdth, $i. Maybe I need to improve on this. 😊

I have mixed feelings about the (relatively) new Return command.
While I understand the usefulness in some circumstances (i.e. error processing) I really (really, really) don't like its usage "in the middle of code".
To me good code should have one, and only one, "exit point" at the end, I consider trowing Return commands here and there in the middle of code (like a method) the same of using a Goto.
That's why I still don't use it that much even now, last line is the only exit point and I use Quit, changing it to Return makes very little difference.

Enrico Parisi · Feb 4, 2024

Hi 

I found the rules here.

I understand that at the moment only some of the rules are applied to Open Exchange projects, but as you said, some customer may use the other rules to measure code quality or maybe simply to learn how to write good quality code.

Having published "wrong rules", whatever is the use, I don't think is a good thing. Fix the rule or remove it, before someone think they are good practice or useful info.