[EMAIL PROTECTED] wrote: > Currently there is no API which allows the clinical app to report problems > back to the messaging app: they are "over-separated". > Obviously it's that happy standards-based medium between the monolithic > super-app > and the > current scenario we are looking for.
It can send an error ack with an error message. They happen not infrequently eg: "EFCreateError:Cannot create file ""\\SERVER\MDW2\qhps03080909234.ORU"". The network path was not found" The Ideal thing would we to the same SOAP interface as the messaging client, but unencrypted, then the messaging client could not save the file but send it directly to the PMS and get an ack back (or not). Then if the PMS later supports encrypted messaging you can take the messaging client out of the loop transparently. In computer Science terms its called a decorator. The messaging client is put in the loop to decrypt the message and look after transport but calls the same interface on the PMS with unencrypted data. Then you have a situation where any number of decorators can be applied depending on the needs. This is the basis of our interface engine technology, we can add in modifiers as needed. Whats needed is the standard interface. In reality there are not many applications that handle Error acks out there, if there is a problem its usually the Telephony interface that gets called!. > This means each clinical application has to keep it's own record, and > creates havoc with defining ACKs: what if one clinical app accepts the > message, but the other rejects, what's the messaging app to do then? Generally each destination application gets its own message. You can have multiplexing decorators, and they then need to create a new message for each destination and handle the acks themselves. A failure on one of those destinations needs to be managed by the multiplexing application. This is whats available in the ACK Segment: 1 2 ID R 0008 00018 Acknowledgment Code 2 20 ST R 00010 Message Control ID 3 80 ST O 00020 Text Message 4 15 NM O 00021 Expected Sequence Number 5 1 ID B 0102 00022 Delayed Acknowledgment Type 6 100 CE O 00023 Error Condition Andrew McIntyre _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
