gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] HL7 Importing Lab Results/Contacts


From: richard terry
Subject: [Gnumed-devel] HL7 Importing Lab Results/Contacts
Date: Mon, 4 Jul 2011 09:32:03 +1000
User-agent: KMail/1.12.4 (Linux/2.6.31-23-generic-pae; KDE/4.3.5; i686; ; )

Hi List/Karsten

Firstly the caveat that I've not really read most of the posts - skimmed them 
-- and I'm not up to date with your schema ---  but as I've probably  spent 
mega-hours dealing with similar problems and gone up blind allies  -- and I do 
have a functioning solution being used in day-to-day practice,  I thought I'd 
post this information.

If this post is 'way off topic' then just ignore it, but for what it is worth 
here is my 2c worth as to how I've implemented the lab import/ordering stuff - 
which has been working in my practice for well over 2 years now. I'd assume 
you have come up with a similar solution but would be interested in hearing in 
summary what they are.

Here in Australia there are two main sorts of data import into medical records

1) Those you control  - eg your scanned documents/legacy records which have to 
be scanned.
2) Those you receive via HL7.

The quality of HL7 is so variable there is only one thing you can guarentee - 
and that is that there is no uniform way of identifying the sender that exists 
across all messages - some even have a 'numerical' ID as in NATA labs, and 
also that as time drifts by, some senders use  different sender id's. (for 
example company take-overs, or seemingly at the whim of a practice manager). 
Examples

MSH|^~\&|APOLLO|NATA^2178^N| (= Douglas Hany Moir Pathology)
MSH|^~\&|HAPSDLOAD|HAPS (= Hunter Area Pathology Services)
MSH|^~\&|LRS|Healthscope Pathology|( = Healthscope Pathology)

Also, this often also does not reflect the sender, as when  a practice sends 
the letters of all doctors under a uniform practice header where of course you 
extract the sender from other HL7 message fields.

I did notice some debate about 'contacts categories' for labs - I may have  
mis-interpreted this. Yes of course, organisations in my system have 
categories. 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") . 

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. 

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.

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.

Regards

Richard












reply via email to

[Prev in Thread] Current Thread [Next in Thread]