LAst November I was at a SNOMED confernce in Copenhagen and it was announced the SSDO would be incorporated in Denmark under Danish law. I think there were some tax advantages, plus they were an early active member of the proposal. jon -- Jon Patrick Chair of Language Technology Australian R&D Centre for Health Informatics School of Information Technologies University of Sydney
Quoting David More <[EMAIL PROTECTED]>: > Hi Tim, > > Just three comments.. > > 1. The original SNOMED CT business case for NEHTA strongly recommended a > separate entity > to look after the terminology area going forward - possibly to > incorporate both the U Syd > Centre and others into a real terms powerhouse for Australia. I still > think that would be > the best way to go. > > 2. Its a pity NEHTA rushed this out, or so it seems, just before > Christmas when its not > ready - as they say in the covering document. > > 3. > > But Australia has the necessary expertise and capacity to carry out > > that R&D, all that is needed are some funding bodies with the vision > to fund it. If it > is left to "the market", I fear the results will be disappointing and > > expensive, and will need to be paid for in US$ and Euros. > > Amen to that - I am not holding my breath however. > > Cheers > > David > > ps - isn't the SDO planned to be in Denmark? > > D. > > > > ---- > Dr David G More MB, PhD, FACHI > Phone +61-2-9438-2851 Fax +61-2-9906-7038 > Skype Username : davidgmore > E-mail: [EMAIL PROTECTED] > HealthIT Blog - www.aushealthit.blogspot.com > > > On Sat, 23 Dec 2006 08:39:07 +1100, Tim Churches wrote: > > Ian Cheong wrote: > >> At 6:38 am +1100 22/12/06, Tim Churches wrote: > >>> See > >>> > >>> > http://www.nehta.gov.au/component/option,com_docman/task,cat_view/gid,122/Itemid,139/ > >>> > >>> > >>> Worth scrutinising and commenting upon, in writing, to NEHTA (but > perhaps comments can > be CCed to this list to promote discussion firts?). But don't only > >>> send comments to this list, send them to NEHTA as well as formal > responses, for > goodness sake. > >>> > >>> and > >>> > >>> > http://www.nehta.gov.au/component/option,com_docman/task,cat_view/gid,151/Itemid,139/ > >>> > >>> > >>> For path test and result codes, it seems like SNOMED CT is where it > is going to be at, > and the Auspath codes (see ), which are based on LOINC codes, are > >>> deprecated, which makes sense to me since LOINC, although freely > available, doesn't > adequately cover all of health and health care, and ultimately it > >>> doesn't make sense to have to build decision support and other > information systems > which have to deal with one terminology and corresponding set of codes > >>> for pathology, another for procedures, another for more general > diagnoses, yet another > for disabilities and so on. > >>> > >>> Usual grumbles about the use of Microsoft Excel files as the format > used to distribute > the draft code sets, when three more clicks by the > >>> relevant NEHTA functionary could have rendered the lists as CSV text > files, acceptable > to everyone. > >>> > >>> Tim C > >>> > >> > >> The Auspath codes are here: > >> http://www.austpath.uow.edu.au/index.cgi > >> > > Thanks, forgot to include that URL in my post. > > > >> lack of revision could mean one of two things: > >> 1. lack of use - which probably applies to request codes > >> 2. good fitness for purpose - which probably applies to report codes > sent routinely in > HL7 messages daily. > >> > > > > Over the last 18 months we have been talking to a lot of labs with a > NSW presence, both > public and private sector, regarding electronic > > communicable disease reporting, and the take-up of and enthusiasm for > LOINC request and > result codes seems very low. One large lab that we have dealt with > > seems to use them, the rest don't. > > > > We also found large gaps in AusPath result codes, and smaller gaps in > the request codes, > with respect to microbiology (including NAT and > > serology). Some of these gaps reflect gaps in LOINC, others reflected > gaps in AusPath > which seems to be a slightly divergent subset of LOINC. We did > > initially try to fill these gaps but no-one seemed to be > > maintaining or monitoring submissions tot he AusPath web site, so we > gave up and decided > to recommend SNOMED CT to labs for all coding purposes with respect > > to comm disease reporting in NSW. The labs > > greeting that suggestion warmly, although all indicated that it would > take time to > change over, but we expected that. > > > >> The NEHTA effort reads like 1 steps forward, 3 steps back. > >> > >> Auspath request codes have: > >> * preferred terms > >> * synonyms > >> > > SNOMED CT has equivalents of these too, out of the box. > > > >> * infinite extensibility based on usage - if you want a new code or > synonym you can > have it and someone will figure out a preferred term and linkage > >> > > > > NEHTA is supposed to be establishing a mechanism to allow local > > extensions to SNOMED CT using a local (Oz) namespace assigned to it by > the College of > American Pathologists (CAP), and shortly by SDO, the international > > Belgium-based SNOMED CT governance body that will be > > taking over from CAP. The idea is that new, local codes can be > assigned quickly and > then, if indicated, they can be sent up for international consideration > > by the SDO for inclusion in SNOMED CT itself in due course as a > single, world-wide code > (which may mean translation or mapping from the local code). I gather > > that NEHTA wants to operate this local SNOMED CT code maintenance > facility itself and > has been recruiting (or trying to recruit) suitably experienced people > > to do so. That's the only bit I am dubious about - would have been > better to outsource > such operational work to an existing centre of nosological excellence, > > like the National Centre for Classification in Health at Uni of Sydney > - they maintain > ICD-10-AM and several other widely used classifications, as well as > > doing research into health classifications and being involved in > teaching medical > information managers etc. > > > >> Auspath report codes are based on a simplified set of LOINC codes, > because proper LOINC > codes go down to method of analysis, which makes them too unique > >> for cross-comparison. LOINC codes are part of SNOMED last I looked. > (Has it changed???) > >> > > > > This simplification was problematic for our requirements (notification > of communicable > diseases to health depts). > > > >> The general method for codifying reports is described in AS4700.2 and > HB262 which is > presently under revision I think. Not all reports are encoded as > >> LOINC, as it depends on the nature of the report. Certainly > individual biochemical > analytes are LOINC coded. > >> > > > > Ian will be pleased to know that our proposed NSW comm dis > notification HL7 message > formats, with which the labs seem happy, are backwardly > > compatible with AS4700.2 and HB262, but extend those to overcome the > ambiguities and > close the interpretation gaps in those documents. We have been planning > > to submit these extensions to Standards Australia once our public > health colleagues in > other states and territories agree to what we propose (they broadly > > do, I think). We have been keeping the relevant NEHTA people in the > loop the whole way > along. > > > >> From memory (it is over a year since we pored over AS4700.2 and > HB262), > >> > > LOINC coding for request types is recommended but not mandated by the > standards, and > results reporting is not specified at all. Or is it the other way round? > > Anyway, for one anything can be used and for the other LOINC is > recommended but not > mandated (and the standards are just recommendations anyway, of course). > > > >> Pap smears are SNOMED > >> coded as one would expect. The general principle is the test/analyte > name would have a > LOINC code and the result value would be numeric or SNOMED coded. It > >> should be a piece of cake to translate unique LOINC test codes to > unique SNOMED > Procedure codes, but the complexity of pathology reporting is not well > >> described in the available NEHTA > >> documents. It is well understood by the pathology informaticians who > actively > contribute to standards development in Australia and NZ. > >> > > > > Mapping test, result, specimen, specimen site and other relevant LOINC > and mostly > lab-specific codes from the 5 or 6 biggest labs in NSW to SNOMED CT, > just > > for the sub-domain of communicable diseases notification, took an > experience > microbiologist and an assistant > > several person-months (part of that was getting up to speed with > SNOMED CT). But only > needs to be done once - maintenance of SNOMED CT subsets thereafter > > should not be too taxing, we think. > > > >> Perhaps someone can understand the rationale for flying a new flag > when everyone is > happy standing behind the old one. > >> > > > > Our impression was that almost everyone was indifferent to the old > LOINC flag, and that > in general path labs saw the advantages of using a single coding > > scheme (ie SNOMED CT) for requests, results, specimens, analytes, test > classes, > anatomical locations, diagnoses, procedures, presenting problems and so > on. > > The future is one in which the clinical setting for a path request is > described in > SNOMED CT codes in the electronic request message to the path lab from > the > > GP or elsewhere, and the lab then sends back the results and > documentation of the test > and specimen as SNOMED CT codes to the GP, also electronically. All > > these SNOMED CT codes can be grist for electronic decision support and > other > value-adding tools at the lab, and in the GP's information system, and > these > > tools can have access to a more wholistic picture of the patient > encoded with a single > coding system, not just LOINC-coded path test results (and ICD-10-AM > > coded diagnoses, MBS-coded procedures, ICPC-2 coded presenting > problems and so on). > > > > None of which is to say that SNOMED CT is perfect - far from it - but > it is far more > comprehensive than any other terminology and its > > comprehensive nature confers very powerful "network effects" on it, I > think. But there > is a lot of R&D work which needs to be done yet to make SNOMED CT > > readily deployable in clinical information systems. In lab and other > "back-room" > information systems, there is some slog work to be done in deploying > SNOMED > > CT, but not much R&D rocket science is needed. Not so for clinical > deployment, though. > But Australia has the necessary expertise and capacity to carry out > > that R&D, all that is needed are some funding bodies with the vision > to fund it. If it > is left to "the market", I fear the results will be disappointing and > > expensive, and will need to be paid for in US$ and Euros. > > > > Tim C > > > > _______________________________________________ > > Gpcg_talk mailing list > > [email protected] > > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > > > __________ NOD32 1935 (20061222) Information __________ > > > > This message was checked by NOD32 antivirus system. > > http://www.eset.com > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
