[Top][All Lists]

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

Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the G

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message
Date: Sun, 29 Aug 2010 22:08:29 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Aug 13, 2010 at 02:11:51PM -0700, Jim Busser wrote:

> because despite that some other human-interactive encounter (doctor visit) 
> could have been recently created, we are making assumptions here whether the 
> results even:
> 1) relate semantically to the most recent encounter
> 2) relate operationally (workflow wise) to the most recent encounter

I don't think that question exists because those results
came into existance (as far as the praxis is concerned)
during said encounter. It is not so much whether they
semantically relate to that encounter - they define it.

After all, if there wasn't any such thing as electronic
results import you'd be physically shuffling around those
very results during that very encounter.

But, again, by using a dedicated account for import and
suitable defining encounter recency limits you can effect
whatever policy is deemed appropriate.

> Let us suppose the results would cause me to change our
> plan. but that you had already left. Say I needed to phone
> you after-the-fact. I might easily rather make a new
> encounter of type "voice call to patient".

So, why not ?

> Alternatively, I might decide to not deal with them until the *next* 
> encounter.

Which does not make a difference as to the encounter at
which they became known to the praxis. *When* they become
known their encounter *takes place*. Either it's an already
ongoing encounter or it is not. The limits of which are

> Accordingly, I think any results that are imported by
> script ought to be linked to a single in-common (or
> optionally different) encounter type that is distinct from
> human-interactive encounters. Re-categorization
> (re-association) is to my view too prone to mal-prediction. 

If that policy is deemed appropriate - enact it. There is
nothing holding anyone back.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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