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