Re: [Gnumed-devel] HL7 Importing Lab Results/Contacts

[Jim Busser]

On 2011-07-03, at 4:32 PM, richard terry wrote:

> I initially in development had 'reserved categories' for say 
> pathologists, radiologists etc, and then used this category ID in conjunction 
> with the HL7 for ordering/receipt.
> 
> After some months I found this unmanageable, for the simple and in retrospect 
> expected  reason that unless you rigidly enforce all categories in your 
> contacts, which  is inflexible for the user, you can't guarentee a user will 
> allocate a  pathology company to the category pathology company, nor should 
> you try and enforce this, plus obvious problems with spelling errors.
> 
> My solution which you probably already have implemented was to have a lookup 
> table of hl7 senders.
> 
> The hl7 parser reads the MSH segment and attempts to match the sending entity 
> with the lookup table, if it fails, the new entity is added to the table, but 
> is obviously not linked to contacts at this point.
> 
> In the Staff Inbox - the resultant hl7 document is still viewable, but cannot 
> be filed until the underlying sender is dealt with by Admin.
> 
> In the admin section for HL7 Management - the admin must allocate this 
> currently unmatched hl7 sender with a name in contacts **WHOSE CONTACTS 
> CATEGORY IS  IRRELEVANT** due to reasons stated above - (this is of course 
> independant of the fact that your system my want to use its contacts 
> categories at some point to display "all pathology companies") . 


The above is the well-known scenario of "unmatched" items needing 
reconciliation.


> It is at this point  that the category of HL7 sender is allocated - and this 
> category **IS NOT FROM THE CONTACTS CATEGORY LOOKUUP TABLE **, but from a 
> different lookup table in whatever schema you are using from your 
> document/hl7 
> import. 


IOW we might refer to this as the "lookup table as supplied by the data broker"

> Also set here is whether the hl7 message has a default of a 'result' or a 
> 'document/letter', with a fallback position so that a sender who usually 
> sends 
> documents, can also be allocated a result category  should the user change 
> the 
> type of hl7 message from document to result in the  inbox - so that it 
> appears 
> on the appropriate list in the clinical record.


This is partly auto-resolvable from the OBX segment, seq 2 (Value Type), the 
two-character codes may be

        • For atomic numeric results: ‘NM’ or ‘SN’
        • For atomic text results: ‘ST’ (‘TX’ is not recommended)
        • For full text reports: ‘FT’ or ‘ED’.
                • TIFF, FAX, JPEG, MSWORD etc. :‘ED’
                • HTML, PIT, RTF, and other ASCII formats: ‘FT’

according to which I would intend to send

        {'NM', 'SN', ‘ST’, ‘TX’}
        --> into the table test_result

        {‘FT’ or ‘ED’}
        --> into the table blobs.doc_obj

but I agree it would be further helpful to associate, with each sender, the

        blobs.doc_type.pk

        semantic type of document (not type of file or mime type)
        such as "referral letter", "discharge summary", etc.

http://wiki.gnumed.de/bin/view/Gnumed/HealthLevel7#Delimiters_and_more
http://publicdb.gnumed.de/~ncq/gnumed/schema/gnumed_v15/gnumed-schema.html#blobs.table.doc-med

> In regards to Ordering, a user cannot order any request unless admin 
> allocates 
> a contacts entry to a type of request (whose categories correspond to those 
> allocated to the hl7 senders - not to contacts), eg, Douglaas Hanly Moir is 
> equated to a company we allow users to send pathology requests etc.
> 
> Seems to work well in practice.

Sounds good!

-- Jim