[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ohf-dev] Re: HL7 Messaging Plan for OHF

Thanks Grahame, sounds like a good place to start.

A few other thoughts were lingering in the back of my mind about this this evening. One point I ought to mention is that the (non-porprietary) model we used for HL7 v2 message pieces was generated by EMF using the HL7 v2 schemas. EMF provides the XMLResources to produce XML given an .ecore model. This may be a way to go ... and then just provide a "Message"Resources that would generate messages (or fragments thereof)?

Just thinking aloud,
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/15/2006 03:39 AM

Please respond to
grahame@xxxxxxxxxxxxxxx
To
Sarah E Knoop/Almaden/IBM@IBMUS
cc
Open Healthcare Framework Mailing list <ohf-dev@xxxxxxxxxxx>
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