[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] HL7 Importing Lab Results/Contacts
From: |
richard terry |
Subject: |
Re: [Gnumed-devel] HL7 Importing Lab Results/Contacts |
Date: |
Wed, 6 Jul 2011 19:25:58 +1000 |
User-agent: |
KMail/1.12.4 (Linux/2.6.31-23-generic-pae; KDE/4.3.5; i686; ; ) |
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
>