Re: [HAPI-devel] handling of HL7-null

[Bryan T. <bp...@gm...>]

Hi Ronald,

Thanks very much for this helpful review.

I'm still not sure how to interpret this. The v2.6 text seems to
address "what can go in a field". If there's no corresponding text for
"what can go in a component/subcomponent" (is there? I don't have
access to this spec) then I think this would have to be interpreted as
an omission. Likewise the 2.5 text doesn't prohibit using nulls in
components, it just doesn't talk about the issue.

I were an application developer reading these specs, and I wanted to
tell other apps to delete an invalid subcomponent, I can imagine that
I would interpret the specs broadly and use |...""...|, rather than
sending two messages (with |""| and "...").

In the face of this ambiguity, and possible established practices, my
inclination as an API developer would be not to enforce the narrow
interpretation in this case.

James, do you have any comments?

Bryan

On 9/19/07, Life is hard, and then you die <ro...@in...> wrote:
>
> [sorry for the slow reply - was offline for bit]
>
> On Thu, Sep 13, 2007 at 11:29:09AM -0400, Bryan Tripp wrote:
> > Hi Ronald,
> >
> > > I think there's a slight confusion regarding HL7 Null's: only a field
> > > as a whole may be Null, not individual components. So, |""| says the
> >
> > Yes, I might be confused about that. Can you give me a section reference?
>
> Unfortunately the spec is not very explicit on this. However, there
> are a couple implicit places (note that various other places in the
> spec they talk about "null" when they actually mean "empty"):
>
>  - v2.5, Chapter 2, Section 2.5.3 says:
>
>     HL7 does not care how systems actually store data within an
>     application. When fields are transmitted, they are sent as
>     character strings. Except where noted, HL7 data fields may take
>     on the null value. Sending the null value, which is transmitted
>     as two double quote marks (""), is different from omitting an
>     optional data field. The difference appears when the contents of
>     a message will be used to update a record in a database rather
>     than create a new one. If no value is sent, (i.e., it is omitted)
>     the old value should remain unchanged.  If the null value is
>     sent, the old value should be changed to null.  For further
>     details, see Section 2.6, "Message construction rules".
>
>   (Section 2.6 however does not have anything further to say about
>   Nulls). Note that this is basically the only place that talks about
>   Nulls, apart from the update modes for repeating segments (2.10.4),
>   i.e. there's no mention anywhere that components or subcomponents
>   may be Null, only here that fields may be Null.
>
>  - v2.6, Jan/07 ballot spec, Chapter 2 (Control) is a bit more
>   explicit here (page 24):
>
>     A field may exist in one of three population states in an HL7 message
>
>     Populated. (Synonyms: valued, non-blank, not blank, not empty) [snip]
>
>     Not populated.  (Synonyms:  unpopulated, not valued, unvalued, blank,
>     empty, not present, missing.) [snip]
>
>     Null. Any existing value for the corresponding data base element
>     in the receiving application should be deleted. This is
>     symbolically communicated as two double-quotes between the
>     delimiters (i.e., |""|).Employing consecutive double quote
>     characters as the only content of a field for other purposes is
>     prohibited.
>
>   Further down on Page 56 (under repeating fields) it says:
>
>     With repeating fields, the segment action codes are not relevant.
>     Action codes cannot be applied to individual field repetitions,
>     because they cannot be uniquely identified. Therefore, they must
>     all be there. i.e., send a full list for each transaction. If the
>     intent is to delete an element, it is left off the list. This is
>     analogous to the snapshot mode for repeating segments and segment
>     groups. If the intent is to delete the whole list, the field is
>     transmitted once with a Null in the first component. In effect,
>     the Sender must make a statement about what action the receiver
>     is expected to take: omitting, or not populating, the field is
>     not a clear signal according to field state definition as
>     described in section 2.5.3.
>
>     At the same time, it is not incorrect to be precise about
>     specific information that is to be deleted if the data type
>     supports this capability. Note, however, that data types without
>     components, e.g. IS or ST do not support this capability. There
>     is no way to tie the Null value to an actual element instance in
>     the persistent data store. See example 2.
>
>   And in example 2 we find
>
>     The data type for PD1-1 is a data types without components. There
>     is no way to tie the Null value to an actual element instance in
>     the persistent data store. Therefore the following is ambiguous
>     and not good practice.
>
>      MSH|||||||||ADT^A31^ADT_A31|<cr>
>      EVN|...<cr>
>      PID|||1234567^^^^MRN|<cr>
>      PV1|...<cr>
>      PD1|S~""||||||||||||||||||||||
>
>
>  Cheers,
>
>  Ronald
>
>