Quoting Tim Churches <[EMAIL PROTECTED]>: > > Who ensures that AHML is compliant, I wonder? About 6 months ago we > submitted a set of messages for communicable disease notification to > AHML. The messages were carefully designed to be compatible with HL7 2.3 > and with AS4700.2 and the Standards Australia path messaging companion > handbook to AS4700.2 (HB262). We got back a about a dozen error messages > from AHML. A few were due to mistakes that we had made in our example > messages, but several were due to errors in the ADHL testing facility > (we were right, it was definitely wrong), and the rest were due to grey > areas in the standards and specifications which are open to > interpretation - AHML had interpreted them differently from us, but it > was not clear that either party was categorically right or wrong and > none of the aforementioned documents gave guidance. > > > As for examples, we have made available the files that passed AHML > > accreditation and have been on the Australian HL7 Meeting CDs > > > > http://download.medical-objects.com.au/TrustedHL7.zip > > > > You can view what compliant HL7 looks like here > > > > http://download.medical-objects.com.au/trusted/index.html That's great, thanks heaps.
> Yes, sets of reference messages are very useful, and that is the > approach we are taking in our discussions with labs regarding > communicable disease notifications. IMHO they (reference examples) are absolutely essential, otherwise you run into exactly this problem: coding with your (poentially wrong) interpretions then have to go back and re-write when you find out you have guessed wrong. Maybe I'm just a concrete thinker, but I find I need to see an example to understand the standards docs. This is main use of the reference implementation: it's the "King Solomon" of HL7, and the interpretations of that programmer (who hopefully worked in close conjunction with Ian Cheong et al.) are by definition the correct ones. Alternatively, the developer can simply use the reference implementation, which will be nice portable code, we hope, as a third-party module in their application, and be compliant from the get-go. My point is: if you can't make it compulsory for developers, to comply, at least make it as easy as possible. Ian Haywood _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
