HL7 format for FT1;11-Total Price – Data Type CP

[Siew Choo Lim]

Hello,

I came across a field in HL7 2.4 message.  The field is FT1;11 ( Total Price ).  The variant is defining this field as data type = CP ( Composite Price ) but I don’t see this defined in the QDX Reference Guid online.

I am trying to find out what format should our vendor send in this field ? Whether to send the total price with decimal or implied decimal.

Example  – The Total price = $27.33

Should we get 2733 or 27.33 in FT1;11  if we are using CP as the data format in the hl7 configurator ?

Please advise.

Thank you

Topic

[Jim Kosloskey]

Quantity&Denomination^price type^from value (Numeric)^to value (Numeric)^range units (Coded Entry)^range type (ID)

The only required component is the Quantity/Denomination set. Quantity usually containing a decimal point.

So if US Dollars:

27.33&USD

Chapter 2 – section 2.8.9 of the HL/7 standard should have the specifics (at least that is where it is in 2.3.1) and advice for other components.

But if the vendor claims to know HL/7 they should know how to populate a CP type field.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Siew Choo Lim]

Now I understand that CP data type can contain decimal point.  What if the decimal point is not included ?  

Example:

If FT1;11 (Total Price) = 28530 without any decimal point

Does that mean that this field is actually $28530.00 or $285.30 ?

I just need to confirm this.

Thank you

SiewChoo

[Jim Kosloskey]

That needs to be negotiated with the sending system.

Some systems send numeric data with an assumed decimal point. Some actually place the decimal point. Other systems only send rounded to the dollar.

All are valid since the quantity CAN but does not have to contain a decimal point.

As an example, if if the sending system uses an assumed decimal point (let’s say last two bytes) and a receiving system requires a physical decimal point (Sending = 2300&USD, Receiving wants 23.00&USD), then you will need to convert the assumed decimal point to an actual decimal point.

Likewise if there is a mismatch between the sending and receiving systems on any of the above (or others I may not thought of) structures, it would be the responsibility of the Integration Engine to adapt.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Siew Choo Lim]

Thanks Jim !

I was thinking of telling the receiving system what to expect in FT1;11 based on the CP data type.  I guess I can’t do that now.

All I need is to have them agree on a format and then I’ll send whatever format we agree on.

[Jim Kosloskey]

What I would do is:

Find out from the Sending system what structure they are sending

Then relay that to the Receiving system.

If there are any differences, make adaptations in the engine.

Of course, I would expect that to be done for every field in the entire message so that everyone knows what can be sent and what needs to be received.

In other words, a full integration specification.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Siew Choo Lim]

Thanks.

What I’m doing is actually find out what the receiving system accounting system is expecting because I have 3 vendors sending charges in different formats in the FT1;11 price field !

[Author]

Replies