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

[richard terry]

On Wednesday 06 July 2011 19:13:10 you wrote:

see comments below

> 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’

I wish. No such luck in this neck of the woods. In an ideal world everyone 
would adhere/interpret standards, but they don't. Major hospitals here send 
what should be NM results in FT fields as a 'report, akin to getting a biro and 
writing the result in the middle of a page of blank paper'. Good luck if you 
choose to be purist. Unfortunately HL7 parsing is about 'exception' 
programming in the real world.

Regards

richard

> 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
>