Andrew McIntyre wrote: > Hello Ian, > > I am not suggesting that the labs be all exactly the same, but that > the bar be AHML compliance, as it is built on the standard, it is > available now (in fact testing is free, compliance certification is > not expensive) and if all HL7 from path labs passed that test then > things would be a lot more standard than they are now.
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 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. > We actually make modifications to the format dynamically to suite > specific PMS, but life would be much easier if that was not necessary. > (An each new build has new bugs so you chase your tail) ... > I suspect that some labs worry about making the messages compliant > because it may upset fragile import routines in existing packages, so > its up to the end users to start insisting on standards. For ages > there have been rumors that NEHTA might try and insist on standards > but no one seems to have the guts to actually do it, so its up to end > users. > > Producers should be transmitting AHML compliant messages and consumers > should actually test that their packages import AHML compliant > messages in an error free way. If we get to that point then we can > work on improving the quality of the content. There is an old Internet saying with respect to email messaging standards: "Be strict with what you send and forgiving with what you receive." That has served interoperability on the Internet rather well, and medical software developers should take it to heart. Tim C > IC> At 7:35 am +1000 13/5/06, Ian Haywood wrote: >>> Andrew McIntyre wrote: >>> >>>> code sets that have been specified. Its the quality of implementation >>>> and not the standard. The labs have the ability to produce compliant >>>> messages, but given the current business model its the market that >>>> gives them the will to do it. >>> Agree with these points but would add that the standard is not as >>> well-drafted as it could be >>> and has multiple points of 'interpretion' where the programmer can >>> do X or Y and still be within the standard. >>> This is probably inevitable given the standard is a 'blue-sky' >>> document: it's not referring to a real implementation >>> >>> Again, as many others have, I make the call for a reference implementation >>> >>> Ian > > IC> The latest version of AS4700.2 is substantially based on real > IC> implementations, excepting that there are many places where real > IC> implementations differ from one another and one has to compromise > IC> somehow when trying to get towards less variance. > > IC> Every pathology lab does tests a little differently - so making them > IC> all report consistently is not a small cost-free task. > > IC> HB262 provides more guidance on implementation. The version for the > IC> latest AS4700.2 is still in the works. > > IC> Reference implementation is in the works - pending funding approval. > > IC> The radiology messaging standard is a "blue-sky" standard. It is > IC> actually easier to document "one way" in a blue sky environment where > IC> there are fewer toes to tread on. We are still waiting on > IC> implementations. > > IC> A "standard" *cannot* be written based on "one real implementation" > IC> without giving undue market power to the owner of said > IC> implementation. Hence it does *not* happen in a consensus environment. > > IC> The prospects of harmonisation of real different implementations are > IC> slim - EG beta/vhs; DVD standards. It can only happen through > IC> negotiation where both camps have to give ground - ie no real > IC> implementation can be the answer. > > > IC> Ian. > > > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
