Unless I misunderstand you, you are referring to the same thing (ie transport ACK).
Ok - from reading Tom's document (and along the lines of what Tim is saying), I don't understand how the ACK's that healthlink is talking about in their "code of practice" are semantically any stronger than the acks that could be generated by the transport layer when it receives msgs, or indeed by the clinical application when it purports to save data into a record. All of these involve a _computer_ system taking responsibility for the message. Now I hope we are getting competent computer programmers to write our programs so I don't know where all these missing messages are going - it's not like Healthlink is the only company with the magic formula for using a transactional database. So if all the ACK is saying is that computer system X has persisted the message to disk, frankly that is no stronger than doing it at the transport level boundary. Now, if instead the ACK is a real acknowledgement that this path report has been reviewed by a human being and a clinical judgement formed about the next action to take, that for me is a real acknowledgement - and that is something that is for me is best done inside the clinical application. I don't see much value in pathology review being done in the 'messaging app' because access to notes, recalls etc are one step away. In summary, if the ACK they are talking about is a real human ACK, then I am all for that - but would think it should be done inside a real clinical application, not inside a glorified ftp client.
Can you indicate what you mean by "integrate fully" and give an example where the functionality of such "full integration" couldn't be achieved using the "uncoupled" architecture present in the market?
The current uncoupled architecture gives way too much importance to 'messaging vendors'. Messaging vendors should be living in the world of 'database vendors', 'graph component vendors'. Clinical software companies should pay messaging vendors for components if they can't be bothered writing their own component to meet the public standard (identically to the way a vendor would license an SMTP component if it wanted to enable email sending in a program). GP's should be purchasing systems based on the messaging standards they support (not whether it has Healthlink or Medical-objects as its engine - though the quality of the licensed messaging engine could be a competition point much the same way as people currently grumble about vendors who use SQL server..)
Not any time soon, at least for the transmission of messages between competing clinical packages. For obvious reasons, clinical vendors "A" and "B" are more likely to deal with messaging vendor "Z" than each other.
I don't want A and B ever to have met each other - I want them both to commit to 3rd party approved standard X. I want X to be well defined enough that it doesn't take a month of developer meetings for A and B to communicate with each other. If A or B fails to work with a particular message (say a difference of opinion in the spec) - I want a third party arbitrer (AHML) who tells them what the correct behaviour is. IMHO this is how technical (loosly coupled messaging) standards are meant to work. Andrew _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
