New Conformance Flag for Don't Ignore

Background

In CDA R2, there is a rule:

 "A recipient of a CDA document must be able to parse and interpret the complete CDA header.

The CDA specification is completely silent on what this actually means. Interpret how? Is the whole header actually conformance >= required?

After much discussion, we realised that some portions of the header are mandatory, some are required, and some are optional. But these existing options do not get at the heart of our concern.

Part of the CDA framework is that CDA documents may be stored/exchanged/process in the absence of a specific trading partner agreement. The author and recipient responsibilities (from where the above rule comes) are intended to make this safe. And we know that there are some fields in the header that it is not safe to ignore. It's not that they have to be populated (mandatory) or even that they have to be supported in an application, but that if they are populated with a value that it is inappropriate for an application, the application must take notice of this, and act accordingly

We don't know what exact circumstances would make it inappropriate to ignore a field for a particular use case. Some typical examples might be:

• the document appends to another document you don't have
• the document concerns a patient type you don't handle (i.e. non-human)
• the document contains a participation type that invalidates your use

Some of these aren't very plausible in CDA R2, but will be much more important in CDA R3, which will have a much bigger header, with much more scope and many more truly optional things in it.

So what we want to do in CDA R3 is indicate specifically, which fields are mandatory|required|optional, and also to identify a few important fields (mainly non-mandatory ones) and say that you cannot ignore the contents of this field.

MnM proposal

We could do that in CDA specification narrative, but it seems to us that this is a useful additional notion that arises in other places, including messaging. Generally, having a specific trading partner agreement makes the use of flag like this somewhat superfluous, but there are use cases for messages (and probably services) where there are no trading partner agreements, and where it would be useful to indicate certain portions of the content as "must not ignore"

So we propose adding a specific extra flag to the methodology to indicate this status. It's not a new conformance status in the list mandatory|required|optional|prohibited, but it does seem to pertain to conformance, hence "new conformance flag". The flag would specify that implementers are not to ignore a field. Once specified, it cannot be unchecked in a derived model.

One implication of this flag would be that when it's true, both trading partners (when they are specifically identified) must have conformance at least Required for the attributes/associations so flagged. Primarily this would allow committees to indicate that some aspects of the design are unsafe to ignore.

The proposal doesn't specify what actions a recipient should or shall take for particular values of a field, only that they must take some appropriate action.

Discussion

Most of the fields that you'd do this for are "navigational" type fields - they are pretty much key decision points on how to process the content. But this is not a formal property of the proposal

Lloyd:

• To say that something must be present and not null, you set "isMandatory"= true
• To say that a given element must always be present in an instance (though it might be null), you set minimum cardinality to at least 1
• To say that a given element must be supported and understood if it appears, you set conformance="required"
• If an element is not marked as required, the sender can choose to not support it and the receiver can choose to ignore or even raise an error if the element is populated.

We don't have an ability to say "you don't have to support but you can't ignore it". What does it mean to "not ignore but not support"? If you're not ignoring an element, then by definition you're supporting it - you're displaying it, processing it and doing whatever might reasonably be expected of an application of your type that "supports" the element. (The specific behavior of course depends on the nature of the application and may include rendering on-screen, persisting, printing, analyzing, etc.)

Grahame:

From RCL:

"In all cases, if a required element is present in a message received by an application 
claiming conformance, then it shall be correctly processed by the receiving application.
A receiving application shall not raise an error due to the absence of a required element
with a cardinality of 0, although it may issue a warning that required information is missing."

Yes, that's what we want.

More:

"Receiving applications must demonstrate their ability to receive and process 
(eg. Store, display to users) not null values for required elements."

No. That's not what we want. The application does not need to demonstrate this, only to that it will not erroneously process information it shouldn't.

More More:

"Note: If an application adheres to an implementation profile declaring that 
the application supports an attribute or association, the application must be
able to send or receive that attribute or association if the application has
a value for it."

Slightly different space now, but this is also additional stuff we don't want. Though this might just need clarification

We want to draw apart required to be known and required to be displayed.