RE: [ohf-dev] Re: HL7 Messaging Plan for OHF

["Hamm, Russell A." <Hamm.Russell@xxxxxxxx>]

As it happens I heard of an open source HL7 V2 messaging service while at HIMSS this week.  I'll dig up the details...

-russ 

-----Original Message-----
From: ohf-dev-bounces@xxxxxxxxxxx [mailto:ohf-dev-bounces@xxxxxxxxxxx] On Behalf Of Grahame Grieve
Sent: Wednesday, February 15, 2006 5:39 AM
To: Sarah E Knoop
Cc: Open Healthcare Framework Mailing list
Subject: Re: [ohf-dev] Re: HL7 Messaging Plan for OHF

ok, so I think we should have one, and I have one in development.

committers, I'm going to propose a HL7 V2 component when we have our face to face at the eclipse conference (thurs afternoon)

Grahame


Sarah E Knoop wrote:
> Hi Grahame,
> 
> ok. So this is our model for part of what we need to represent HL7 
> messages. The other portion is proprietary that we will need to convert.
> Additionally, there are several things that make working with the 
> current model difficult, that could be improved. So I am looking to 
> OHF for a consistent representation ... and possibly an improved one.
> 
> Sarah Knoop
> 
> IBM Almaden Research Center
> 650 Harry Rd.
> San Jose, CA 95120-6099
> email: seknoop@xxxxxxxxxx
> phone: (408) 927-2622  (tie 457-2622)
> 
> 
> 
> 
> Grahame Grieve <grahame@xxxxxxxxxxxxxx>
> 02/11/2006 08:38 PM
> Please respond to
> grahame@xxxxxxxxxxxxxxx
> 
> 
> To
> Sarah E Knoop/Almaden/IBM@IBMUS
> cc
> grahame@xxxxxxxxxxxxxxx, Open Healthcare Framework Mailing list 
> <ohf-dev@xxxxxxxxxxx> Subject
> Re: [ohf-dev] Re: HL7 Messaging Plan for OHF
> 
> 
> 
> 
> 
> 
> Hi Sarah.
> 
> OK, all that made sense - so, now, what is it that you want? (given 
> that you already have all this)?
> 
> You want an OHF replacement that has this type of functionality?
> 
> Grahame
> 
> 
> Sarah E Knoop wrote:
>> Hi Grahame,
>>
>> The way XDS uses HL7 v2.5 is in pieces, not in full messages. So we 
>> have
> 
>> generated/implemented the necessary subset HL7 data strucures and
> segments
>> for XDS using the HL7 v2.5 XML Schemas published. So we have a java
> object
>> for every level of granularity. 
>>
>> For example, XDS requires patientID's to take the format of a CX data
> type
>> that minimally specifies CX.1, CX.4.2 and CX.4.3. So we have a CX 
>> data structure that maintains all 10 subcomponents. We fill these 
>> components
> in
>> the data structure then render the message fragment (ex. 
>> 1234^^^&2.16.123.444.01&ISO). Regarding your "tables" question, 
>> CX.4.3
> is
>> to be a universal ID type to be taken from HL7 Table 0301. We have 
>> implemeted this table as a java class composed of literal constants 
>> for each table value. This is so we can maintain some sort of 
>> integrity when
> 
>> forming the pieces of the messages we need.
>>
>> The reason for such a data structure representation is that we also 
>> do
> XDS
>> metadata extraction in which, for example, we parse a CDA R2 
>> document, extract corresponding XDS metadata values, and form the 
>> metadata pieces
> as
>> we go along. An example here is the mapping of 
>> ClinicalDocument/recordTarget/patientRole/id@extension --> CX.1 
>> ClinicalDocument/recordTarget/patientRole/id@root --> CX.4.2 So, a 
>> very fine level of granularity is needed.
>>
>> Hope this clarifies,
>> Sarah Knoop
>>
>> IBM Almaden Research Center
>> 650 Harry Rd.
>> San Jose, CA 95120-6099
>> email: seknoop@xxxxxxxxxx
>> phone: (408) 927-2622  (tie 457-2622)
>>
>>
>>
>>
>> Grahame Grieve <grahame@xxxxxxxxxxxxxx> Sent by: 
>> ohf-dev-bounces@xxxxxxxxxxx
>> 02/09/2006 04:18 PM
>> Please respond to
>> grahame@xxxxxxxxxxxxxxx; Please respond to Open Healthcare Framework 
>> Mailing list <ohf-dev@xxxxxxxxxxx>
>>
>>
>> To
>> Open Healthcare Framework Mailing list <ohf-dev@xxxxxxxxxxx> cc
>>
>> Subject
>> Re: [ohf-dev] Re: HL7 Messaging Plan for OHF
>>
>>
>>
>>
>>
>>
>>
>> Sarah E Knoop wrote:
>>> Hi Grahame,
>>> Just to clarify, "run-time library with validation" will include 
>>> java
>> data
>>> structures for HL7 messages? 
>> yes
>>
>>> If so, to what granularity? Will we be able to create, say, a CX 
>>> data
>> type
>>> instance outside the context of a message? 
>> sort of. Actually, you can create a Component and make it like a CX 
>> data type; the trouble with HL7 V2 is that these things aren't 
>> actually quite types. The way my library works (which is what I am 
>> proposing for the OHF v2 library) is that you have an underlying 
>> library which reads and writes messages and provides version and 
>> definition support, and then you write a conformance profile, an use 
>> that to code generate wrapper classes that present a clean wrapper 
>> around the underlying library.
>>
>>> Will there be representation of all the HL7 Tables?
>> maybe; depends what you mean by "representation". The contents of the 
>> table will be available for each version. But do you want a java 
>> representation to the compiler? what would that mean?
>>
>>> Additionally, I have re-read the PIX/PDQ enhancement proposal. You 
>>> are correct in their intent to make v3 a supported option. This will 
>>> mostly
> 
>>> affect PIX-PDQ server side ... so it seems all we need to be 
>>> concerned with (from an XDS/ PIX-PDQ client) is representation for v2.5.
>> yes, I think for the moment we can keep the v3 work and the PIX/PDQ 
>> work
> 
>> apart.
>>
>> Grahame
>>
>> _______________________________________________
>> ohf-dev mailing list
>> ohf-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ohf-dev
>>
>>
> 

--
Grahame Grieve
CTO, Jiva Medical       Software Integration Tools
CTO, Kestral Computing  Healthcare Applications