This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "DetectedIssue when using multiple payloads"

From HL7Wiki
Jump to navigation Jump to search
Line 16: Line 16:
  
 
(Rene) That's even less granular than my intention. How doesn one express "I reject slot #3 for reason Y", and "I reject slot #17 for reason Z", and "I accept slot #25, but with the following warning W associated to its acceptance" ? But for sure, just stating that half of them are "acceptable" whereas the other half is not is already problematic.
 
(Rene) That's even less granular than my intention. How doesn one express "I reject slot #3 for reason Y", and "I reject slot #17 for reason Z", and "I accept slot #25, but with the following warning W associated to its acceptance" ? But for sure, just stating that half of them are "acceptable" whereas the other half is not is already problematic.
 +
 +
(Lloyd) I'm not terribly comfortable with an interaction that isn't being treated as a single unit of work.  I.e. Either accept the entire interaction or accept none of it, but don't accept bits and pieces.  If you need to, reject the whole thing, and then indicate which pieces you actually had problems with.  I had proposed turning DetectedIssue into a physical class complete with a 'location' pointer so you could refer to which specific element in the request you weren't happy with.  E.g. address repetition 5 or component 3 or whatever.  However, it got voted down because of need for greater discussion within INM.

Revision as of 23:52, 3 August 2006

Issue

If one sends 1 interaction containing mutiple requests, and some of those are rejected, and others accepted, how does the reciever communicate the reasons for rejecting some of them ?

There's a detectedIssue for the ControlAct, but that's for the entire order, not for parts of it. Do we need detectedIssue classes related to fulfillment objects in the application response ?

Currently we have deferred the entire issue to a future cycle by constraining an order interaction to 1 request object.

Discussion

(Gaby Jewell, Feb 2005) This is an issue today. In the UK, we're receiving a list of appointment slots available for referrals. As we process the list, we may have issues with none, one, many or all of the slots. We process he slots that are valid and return an error for each slot that had an issue. We send one acknowledgement message with a list of errors--could be a long list of errors! No matter what we do, it's wrong (other than "AA" for no slots with issues and "AE" for all slots with issues).

(Rene) That's even less granular than my intention. How doesn one express "I reject slot #3 for reason Y", and "I reject slot #17 for reason Z", and "I accept slot #25, but with the following warning W associated to its acceptance" ? But for sure, just stating that half of them are "acceptable" whereas the other half is not is already problematic.

(Lloyd) I'm not terribly comfortable with an interaction that isn't being treated as a single unit of work. I.e. Either accept the entire interaction or accept none of it, but don't accept bits and pieces. If you need to, reject the whole thing, and then indicate which pieces you actually had problems with. I had proposed turning DetectedIssue into a physical class complete with a 'location' pointer so you could refer to which specific element in the request you weren't happy with. E.g. address repetition 5 or component 3 or whatever. However, it got voted down because of need for greater discussion within INM.