RPS: Additional Model Constraints

1. Background

The formal model represented by the RPS model (as diagram, document or hierarchical message format) can be turned programmatically into an XML schema. An RPS message instance that does not parse as valid according to the schema would be rejected and the relevant information could be communicated back to the submitter in a standard HL7 acknowledgement message.

However there are business rules that can be applied as additional constraints on the model, that cannot be expressed in the model or the schema. Such constraints need to be identified explicitly. We have not yet specified how violations of these constraints are to be identified and communicated to the sender of an RPS message.

2. Additional Model Constraints

There are already two additional constraints attached to the RPS model:

(1) No keyword object may have both its id and code attributes populated;

(2) No document object may have both a populated text attribute and any associated component(s);

Other possible additional constraints of interest are:

(3) Each content file accompanying an RPS message must be referenced by exactly one document object in the message;

(4) A document object that references a file must reference a file actually accompanying the message;

(5) Only one copy of a file as identified by SHA-1 or similar algorithm may be submitted to a single recipient;

(6) The id of a component of a document object must refer to a document object defined in the current message or in a message previously sent to the same recipient.

(7) The id of the document associated with a context of use object must refer to a document object defined in the current message or in a message previously sent to the same recipient.

(8) The id in a keyword object must refer to a keyword definition object defined in the current message or in a message previously sent to the same recipient and applicable for all applications to which the keyword might be applied by the distribution of a CoU or its associated documents to all of the pertinent applications.

(9) The codes system and value given in any object must exist and be applicable to the object class and usage context by local business rules.

(10) The sequence number used in association with each submission (or reviewable unit) pertaining to a submission unit must be different from any sequence number supplied with any previous submission unit pertaining to that submission (or reviewable unit). Does it also have to be greater?

There is a subsidiary question here: how does the regulator assign sequence numbers in their response submission units? There seems to be no practical way within the existing framework to coordinate the numbers, so the easiest way might be to treat the submitter’s and the regulator’s sequences as independent, each starting from one in a given application-submission.

(11) State transitions as defined for each class must be observed; any improper state transition must be rejected in its entirety.

3. Questions For RPS

(1) When a recipient detects constraint violations how is that to be communicated back to the sender? Do we need a class in which violations of these constraints (errors) can be carried in a submission unit?

For example, we might define an error class of type observation in a “subject of” relationship with submission unit, with the following attributes:

• id of the error instance
• code identifying the specific constraint violation
• value which can carry the id of the offending object or the file name
• interpretation code to indicate the disposition of the object in error

Since constraint violations are detected in the initial processing of a single submission unit, these error responses could be returned as a copy of the submission unit with the status set to “active” to indicate that only the items in error were processed abnormally or set to “cancelled” of “nullified” to show that the entire submission unit was rejected. In this case only the submission unit, its subject of and error class instances need be returned.

(2) How should individual objects in violation of a constraint be treated?

Since there are no states defined for HL7 objects that specifically represent a correctable error condition on an individual basis, the easiest course would be to delete offending objects and allow the sender to resubmit them in a corrected form.

(3) Under what conditions should constraint violations lead to rejection of an entire submission unit?

(4) Should we have a “positive acknowledgement” to indicate no constraint violations in a submission unit, or can that be conveyed in the standard acknowledgement message?

(5) Would it be useful to have a class analogous to error, called issue, in which coded messages concerning procedural problems with individual document objects, document filings (i.e. context of use objects) or other RPS objects could be returned to the submitter? For example, an issue object might identify an improperly structured study or flag an incorrectly filed document; it would not be used to carry comment on the context of a document, though it could allow for short comments for a reviewer to suggest a correction. These would be returned as general responses.