View source for RQD Segment Fields and Promotion of IS

Joann Larson 2-26-08 

I am submitting the following issue to the FM list Server at the request of Kathleen Connor and on behalf of Hans Buitendijk, OO co-chair. 

In the course of preparing HL7 v2 chapters 4 and 4a for the upcoming ballot, the editor, Greg Thomas, was applying proposal 522 to the fields assigned data type IS. The question arose as to whether or not it was logical to promote the following fields in the RQD Requisition Detail segment to CWE. 

RQD-7 Cost Center Account Number (IS) Definition: This field contains the general ledger cost center account number associated with a department that may issue or charge for this item. Refer to HL7 Table 0319 – Department Cost Center for valid values. RQD-8 Item Natural Account Code (IS) Definition: This field contains the accounting code that identifies this item in order to charge for this item. User-Defined Table 0320 - Item Natural Account Code is used as the HL7 identifier for the user-defined table of values for this field. 

Both tables have no suggested values. 

I checked chapter 6 to see if there were any analogous fields there, but was unsuccessful. Many of the segment fields in chapter 6 are tied to NUBC codes which does not seem to be the case with the RQD Requisition Detail segment fields. 

I am wondering if there would ever be any circumstance under which there would be more than one coding system applied to an organization's general ledger? I am thinking that perhaps a promotion to an HD data type might be more sensible. This question was discussed in InM yesterday. The conclusion was that the solution depended on whether or not these were instances or concepts. InM agreed that FM would have the expertise to determine this. Perhaps RQD-7 is an instance and RQD-8 is a concept? 

Here is the context for the fields: RQD - Requisition Detail Segment : contains the detail for each requisitioned item. The segment appears in the following messages: OMS - stock requisition order message (event O05) and its Ack (event O06) OMN - non-stock requisition order message and its Ack (event O08) 

Please see HL7 v2.6 chapter 4, section 4.11.1 to view the segment attribute table. It did not paste satisfactorily into this message.

Joann Larson


'''Hans J. Buitendijk 2-25-08'''

Tough question.  For RQD-7 I would lean as well more towards HD rather then CWE, but could be pursuaded to CWE by financial experts.  For RQD-8 I would be leaning more towards CWE rather then HD. 
  
For neither one I would go with CNE or ID. 
  
I would run it by FM to make sure what exactly these fields would equate to in the accounting space to be sure. 

'''Joann Larson 2-25-08:'''  InM is looking at is situations where the IS should not be promoted to CWE, CNE or ID. 
I am thinking that there might be situations where promoting an IS to an HD might be more appropriate. This would be backward compatible because the first component in an HD data type has an assigned IS data type. 

I am thinking that the following may be in question: 
RQD-7 Cost Center Account Number (IS) 
Definition:  This field contains the general ledger cost center account number associated with a department that may issue or charge for this item.  Refer to HL7 Table 0319 – Department Cost Center for valid values. 


RQD-8 Item Natural Account Code   (IS) 
Definition:  This field contains the accounting code that identifies this item in order to charge for this item. User-Defined Table 0320 - Item Natural Account Code is used as the HL7 identifier for the user-defined table of values for this field. 

Both tables have no suggested values. 

I checked chapter 6 to see if there were any analogous fields there, but was unsuccessful. Many of the segment fields in chapter 6 are tied to NUBC codes which does not seem to be the case with the RQD Requisition Detail segment fields. 

I am wondering if there would ever be any circumstance under which there would be more than one coding system applied to an organization's general ledger? I am thinking that perhaps a promotion to an HD data type might be more sensible.