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

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