But the coding experts tell us that even using experts, the more one tries to pin down a concept, the more likely that divergence of opinion will emerge. (A bit like Heisenberg's uncertainy principle.)

Non-clinicians really have little idea of how clinicians make real world clinical decisions. I left an open invitation with one EHR developer (who had never engaged directly in a clinical encounter to study the process) a few years ago to sit in for a half day or more. It's still open.

National emphasis on a limited standardised classification (around 2000 terms) would deliver most of the benefits of automation for a mere fraction of the cost of what idealists seem to be wanting.

The next most useful thing would be training all clinicians to type. Non-typists leave very sketchy notes. Handwriting recognition could be easier that typing training, but I haven't heard of anyone using it productively in GP land yet (any news anyone).

The cost of the SNOMED licence is a pittance compared with the cost of training all the clinicians in the country about SNOMED. I expect the numbers would be documented in the relevant NeHTA consultancies on terminology more than a year ago. Anyone seen them??

If a single "body" was responsible for e-health process and outcomes, then we might have a hope of seeing a sensible work program that delivered something real. All we will get is a lot of reports justifying bureaucratic decisions and expenditure to the satisfaction of Senate Estimates Committee.


Ian.


At 9:54 am +1100 13/2/06, Jon Patrick wrote:
I think there may be some misconceptions about the difficulty of making a
terminology readily available for routine work. Some comments interspersed
below.

    Date:       Sat, 11 Feb 2006 09:27:29 +1100
    From:       Tim Churches <[EMAIL PROTECTED]>

    Ian Cheong wrote:
    > At 7:44 am +1100 11/2/06, David More wrote:
    >> Ian,
    >>
    >> I think it is important to remember the lack of terminology was a key
    >> reason for the failure of a number of the HealthConnect trials.
    >>
    >> Spending on terminology capability and development may not be a bad
    >> investment at all in my view - it is required if any form of real
    >> inter-operation between systems is to be achieved. Communication 'by
    >> blob' helps - communication of understanding and context is way better.
    >>
    >> Cheers
    >>
    >> David
    >
    > Yes, but terminology is mainly for machine processing.
    >
    > Detailed comprehensive terminology costs a bomb and leads to enormous
    > downstream costs.
    >
    > A limited terminology with classification is probably all one needs to
    > do most decision support - something closer to 2000 terms, according to
    > various experts around the traps.
    >
    > It is likely that yet another tiny little bureaucratic decision will
    > point us in a less than optimal direction for decades.
A few observations: 0) Yes, encoding information using a clinical terminology is indeed
    mainly for machine processing. But that's the point - it better enables
    the machines to do the information processing drudge work, to allow us
    humans to concentrate on more interesting things. Health informatics is
    not only about speeding up human-to-human communication.
Automatic and semi-automatic methods of data capture at the point of care
should add little if any time cost if the systems are well designed.
While clinicians need data retrieval of patient records for their everyday
work and effective interoperability is fundamental to achievng that we also
have an eye on the prospect of radically improving the analytics of health
information systems. Effective data capture will enable us to deliver much
superior data analytics so that people can more effectively study what is
systemic about the nature of populations of health within their bailiwick.

1) The US Dept of Health and Human Services paid teh College of American
    Pathologists (CAP) a once-off US $35m fee for a perpetual license for
    all of SNOMED CT for all of US (available to everyone, public and
    private sectors) with updates for 5 years and an option to renew for
    updates after that.
2) On a population prorata basis that equates to about AUD$3m for a
    similar five years of updates for all sectors of all of Australia, or
    about $600k per annum. That's probably less than the annual fancy
    sandwich meeting catering bill for the DoHA...
3) Just because SNOMED CT has several hundred thousands concepts in it
    doesn't mean that you need to use them all. You can easily pick subsets
    of SNOMED CT for particular purposes. But if you need more deatil, with
    SNOMED CT, it is already there (in most cases - there are still some
    gaps in its detailed coverage of concepts, but these can be filled in
    due course, especially now that CAP is more open to shared governance
    and ownership of SNOMED CT).
In the prototype systems we are trialling here we can search for terms across
all of SNOMED in about 1 second. If we restrict the search space to a range
suited to a particular speciality we can add in extra intelligence to use up
that  1 second.
4) The challenge is to develop smarter technologies for automatically
    encoding medical concepts expressed or chosen via structured pick lists
    or look-ups, in free text notes, and via natural language speech into
    SNOMED CT codes. It's doable, and Jon Patrick's group at Sydney Uni has
    already made a start.
We expect to demonstrate in our public showcase in 2 weeks a prototype of
real-time data entry onto an exact replica of an existing hospital form data
entry of categorical information (tick boxes), text notes and drawings,
including conversion to SNOMED codes. This is the product of a few students
over the summer.

     There is a big opportunity for the development of
    home-grown technologies to do this which don't cost a bomb, and which
    can be incorporated in next-generation clinical information systems or
    retro-fitted to existing ones.
here, here!! This is what we are working towards. Tim C
    _______________________________________________
    Gpcg_talk mailing list
    [email protected]
    http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
Jon
---------------------------------------------------------
Prof. Jon Patrick                       BH +61-2-9351 3524
Chair of Language Technology            FX +61-2-9351 3838
School of Information Technologies
University of Sydney
Sydney, 2006
NSW
Australia
--------------
Scamseek Project                http://www.cs.usyd.edu.au/~lkmrl/scamseek.htm
Personal WEB Page:                      http://www.it.usyd.edu.au/~jonpat
Language Technology Research Group      http://www.cs.usyd.edu.au/~rcdmnl/
Information Systems WEB PAge:           http://www.infosys.usyd.edu.au
School  WEB Page:                       http://www.cs.usyd.edu.au
----------------------------------------------------------



_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk


--
Dr Ian R Cheong, BMedSc, FRACGP, GradDipCompSc, MBA(Exec)
Health Informatics Consultant, Brisbane, Australia
Elected Member, GPCG Management Committee
Internet: [EMAIL PROTECTED]
(for urgent matters, please send a copy to my practice email as well: [EMAIL PROTECTED])

PRIVACY NOTE
I am happy for others to forward on email sent by me to public email lists.
Please ask my permission first if you wish to forward private email to other parties.
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

Reply via email to