[Gnumed-devel] Re: A few questions

[Jim Busser]

On 2010-01-25, at 5:24 AM, David Mackenzie wrote:

> Hi Jim,
> 
> I was just having a chat to dad about a couple of things relating to HLF 
> messaging and I have a few questions.
> 
> 1) In Australia, messaging between health organisations (including HL7 
> messages) are sent by encrypted email. There is a program called Argus in 
> australia that is used to encrypt/decrypt the messages using keys given out 
> by the Australian government (HIC). The keys don't have to be issued by the 
> HIC and can be generated using PGP or other means. Do Canada or the US have 
> such regulations? Does GNUMed already have a way to handle incoming messages, 
> and, either pass them to Mirth or Mirth poll a database/directory for them? 
> Or does this functionality have to be either built/borrowed?

In Canada, some policy is set at the national level but a lot (in health) is 
set at the level of provinces. Each province has a medical College (despite 
that other entities are also named Colleges) which oversee the quality and 
accountability of medical care on behalf of the public. The Colleges all 
stipulate that email should not carry patient information unless the email is 
secure/encrypted but says nothing of the specific approaches. The government 
people would presumably also find that satisfactory but did not yet get around 
to getting anything to happen. They have been (pressured into) pursuing a dream 
of patient data into giant databases as part of a national project that offers 
the provinces money to do this -- the bureaucrats' "vision". I believe they are 
trying to model after the UK without acknowledging that approach's serious 
problems. I am unaware of anything in the US that does what Argus does.

> 2) The current medical software programs dad uses have the concept of a 
> "message holding bay", whereby doctors can view all messages that have 
> arrived at the surgery and chose to import them into the database. There is a 
> screen which lists all the doctors names as found in the incoming messages 
> with some details about the message. Is this a feature you are familiar with 
> and desire? This would be a feature of GNUMed and not Mirth. Mirth would 
> simply put the messages into the "message holding bay" in the database. This 
> may need to be thought through a bit further, as the messages may require 
> further parsing once the import to database function is selected.

Karsten can clarify but what GNUmed can and does already do is to poll indexed 
values from tables each corresponding to different clinical / administrative 
data types and present these numbers in a "virtual" inbox which is one of the 
GNUmed plugins, such as can be seen in the demo Kirk inbox. These are shown to 
the clinician (doctor) in question based on these results not having yet been 
"reviewed" (i.e. no-one has yet "acknowledged" them with the review function). 
Double-clicking on an inbox row (each corresponds to a patient - type of 
clinical information combo e.g. lab results or documents or messages from 
staff) activates both the patient and the plugin.

All that therefore needs to be done is to get the messages-to-be-imported to be 
imported into the right tables and the inbox should function automagically. (?)

> 3) Value based mappings: Dad mentioned that a type of observation result, may 
> need to be placed into different tables to another type of observation 
> result. For example, a blood pressure result, may go into a blood pressure 
> table, whereas, something else may go into another table. Mirth does not 
> really provide this capability of drilling down to the field value level and 
> a more detailed knowledge of the HL7 message field values would need to be 
> understood to implement this functionality. Is this desired behaviour for 
> GNUMed?

That's a good question. I am familiar with labs sending lab data (which is 
granular) and which should all go into the measurements table and blood 
pressure is also granular and despite that one would normally measure it within 
the clinical visit physical exam and document it in the "O" of a SOAP note, it 
is nonetheless a measurement and it too would go into measurements.

I do understand however that HL7 may be usable to transport documents (like 
text documents) so I am not yet sure of the best way to pick that out. But you 
are right some level of abstraction that would allow to differentiate which 
Mirth-to-GNUmed channel to take (if such would be better split into a separate 
channel) sounds like a good idea. 

> I will be implementing a working vertical tomorrow. It won't have all the 
> fields/values mapped to the database, but it should be a good start.

You just made my day :-)

-- Jim