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

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