Wednesday, November 09, 2022

Can We Expect A Better Outcome This Time From The ADHA And The CSIRO?

This release appeared last week.

Australian Digital Health Agency and CSIRO join forces to help connect Australia's healthcare system

Published 1 November 2022

The Australian Digital Health Agency and Australia’s national science agency, CSIRO’s Australian e-Health Research Centre (AEHRC) have launched a new collaboration combining their skills and expertise to deliver a centre of excellence for connectivity across the Australian healthcare system, through the National Clinical Terminology Service (NCTS).

CEO of the Australian Digital Health Agency Amanda Cattermole PSM said the Agency’s collaboration on the use of innovative digital services through its partnership with AEHRC would create a world-leading terminology service and capability for Australia.

“It will further strengthen both organisations’ reputations as leaders in clinical terminology,” she said.

Under the new partnership, the Agency retains responsibility for governance and the strategic role of end to end management, SNOMED CT licensing and the relationship with SNOMED International, while CSIRO will deliver the services and functions required to manage the NCTS, as well as content authoring and tooling.

The intention of the collaboration is to enable connectivity across all health care settings. This is achieved through driving future interoperability standards and governance discussions across different systems and health care settings to improve connectivity.

Dr David Hansen, CEO of AEHRC said:

“This partnership presents an exciting opportunity to improve the connectedness of Australia’s healthcare system.

“The services that we provide help enable different parts of the system to ‘talk’ to one another, enabling smoother health service delivery, reduced patient burden and fewer costs.”

The NCTS currently provides terminology services and tools that include an online browser, a mapping and authoring platform and CSIRO’s national syndication server (Ontoserver).

To date, more than 100 organisations in Australia have accessed the Ontoserver licence through the NCTS sublicence – lowering the barrier to the adoption of interoperability standards in our health records.

“We hope this extended partnership will see adoption escalate further,” Dr Hansen said.

Over the next five years, work will continue through this partnership to refresh other NCTS tooling and develop terminology content published through the NCTS. This will further improve health information connectivity for Australian consumers and healthcare providers.

Media contact
Mobile: 0428 772 421
Email: media@digitalhealth.gov.au

About the Australian Digital Health Agency
When it comes to improving the health of all Australians, the role of digital innovation and connection is a vital part of a modern, accessible healthcare system. Against the backdrop of COVID-19, digital health has seen exponential growth in relevance and importance, making it more pertinent than ever for all Australians and healthcare providers.

Better patient healthcare and health outcomes are possible when you have a health infrastructure that can be safely accessed, easily used and responsibly shared.

For further information: www.digitalhealth.gov.au.
The Australian Digital Health Agency is a statutory authority in the form of a corporate Commonwealth entity.

About CSIRO
At CSIRO, we solve the greatest challenges through innovative science and technology. We are Australia's national science agency and innovation catalyst, collaborating to boost Australia's innovation performance.

The Australian e-Health Research Centre (AEHRC) is CSIRO’s digital health research program – enabling the digital transformation of healthcare to improve services and clinical treatment for Australians. We have world leading capability in areas such as clinical terminology and data interoperability; health data analytics; clinical image analysis; genomics data analytics and engineering; biostatistics, mobile health, tele-health and health internet of things, amongst many others.

Here is the link:

https://www.digitalhealth.gov.au/newsroom/media-releases/australian-digital-health-agency-and-csiro-join-forces-to-help-connect-australias-healthcare-system

I was amazed to discover I have been wondering about all this – on the blog – since 2006! Here are 3 blogs from the distant past!

-----

Wednesday, December 13, 2006

Is SNOMED CT a Practical Usable Clinical Terminology Today?

In a recent posting at the E-Health Insider web-site it is reported that the Royal College of Physicians is urging a “universal and rapid SNOMED deployment” to be undertaken by the UK Connecting for Health IT Program.

The article can be found here:

http://www.ehiprimarycare.com/news/item.cfm?ID=2338


More interesting than the article is an anonymous response to the suggestion found at the bottom of the article. This is worth quoting in full as it goes to make some points and provide some useful resources for those interested in the area of practical, clinically useful SNOMED CT implementation.

“12 Dec 06 12:29

SNOMED: caveat emptor

Readers of this article (and the RCGP) are advised to check the detail before rushing into demands for immediate SNOMED implementation.

Major suppliers, would be implementers and academics are on public record stating SNOMED has manifest and significant quality control and implementation issues.

http://hl7-watch.blogspot.com/

http://www.shopcreator.com/mall/infopageviewer.cfm/Abiescouk/SCT06download

On a purely pragmatic level, clinical code sets supporting QOF/QMAS on the DoH website (URL changes almost daily :-( ) for SNOMED have not been updated since 2005 release (unlike those for the Read Codes which are up to date). This latter alone is unlikely to encourage jobbing GPs to queue up as guinea pigs for the 'imminent' releases of SNOMED enabled systems from EMIS, In Practice and others.

It just isn't as simple as whip the system suppliers I'm afraid.”

A review of the material found on these pages certainly raises some interesting and very complex questions and I would suggest anyone with an interest in the area review these two sites and the links / downloads provided carefully.

The messages I came away from all this material with were as follows:

1. If David Markwell’s presentation from March 2006 is to be believed the work of encapsulating the complexity for SNOMED CT behind a useable clinically friendly interface has yet to be completed. Without well engineered seamless interfaces to the use of SNOMED CT adoption and use of the terminology will be very slow indeed

2. The Kaiser Permanente implementation of SNOMED CT within its EPIC software implements a narrow subset of the full contents of SNOMED to make clinical coding and billing easier.

3. Professor Alan Rector (a global terminology guru if there is one) from Manchester University has recently said in a presentation that “Unless we can formalise the mutual constraints ... HL7 v3 + SNOMED = Chaos'. 'The documentation is beyond human capacity ... to write or to understand'.”

4. Other groups appear to be really struggling to deploy usable clinician friendly systems.

5. There are some significant academic linguists and ontologists who have very significant concerns about the underlying data model on which SNOMED CT is based.

6. The emergence of supporting terminologies in areas where localisation to a specific country is needed (e.g. in the local formulary) has been slower that might have been expected.

7. There is at least some concern regarding the overall data quality of the material already contained in SNOMED CT.

8. There also seem to some harmonisation issues between HL7 V3.0, CEN/ISO Standards and OpenEHR with Archetypes which indirectly impinge to some extent of terminology use.

What does all this mean practically?

I think that it is at least possible that large scale deployment of clinician friendly SNOMED CT may be more delayed than is anticipated at present – i.e. out to beyond 2010 and there is even the possibility that it may all prove ‘too hard’ and some simpler better designed approach – based on the lessons learnt from SNOMED CT – may need to be engineered.

Whatever happens it seems clear all those interested in the area should spend some time getting familiar with the current state of play so they can formulate, for themselves, informed estimates of just when systems which fulfil the promise of SNOMED CT are likely to be available.

I for one will not be holding my breath. Just as HL7 V3.0 and openEHR have taken over a decade to be developed and are not yet quite ready for ‘prime time’ as far as I know I suspect history will repeat with SNOMED CT.

I hope I am wrong!

David.

Dr David G More MB PhD9 comments

-----

Monday, July 18, 2011

It Seems SNOMED CT Has A Few Issues That Need to Be Addressed. Right Now It Is Apparently Broken And Needs to Be Fixed!

The following paper was formally released a few weeks ago.

J Am Med Inform Assoc. 2011 July; 18(4): 432–440.

Published online 2011 April 21. doi: 10.1136/amiajnl-2010-000045                     PMCID: PMC3128394

Getting the foot out of the pelvis: modeling problems affecting use of SNOMED CT hierarchies in practical applications

Alan L Rector,1 Sam Brandt,2 and Thomas Schneider1

1School of Computer Science, University of Manchester, Manchester, UK

2Siemens Health Services, Malvern, Pennsylvania, USA

Correspondence to Alan L Rector, School of Computer Science, University of Manchester, Manchester M13 9PL, UK; rector@cs.manchester.ac.uk

Received December 13, 2010; Accepted December 30, 2010.

Abstract

Objectives

(a) To determine the extent and range of errors and issues in the Systematised Nomenclature of Medicine – Clinical Terms (SNOMED CT) hierarchies as they affect two practical projects. (b) To determine the origin of issues raised and propose methods to address them.

Methods

The hierarchies for concepts in the Core Problem List Subset published by the Unified Medical Language System were examined for their appropriateness in two applications. Anomalies were traced to their source to determine whether they were simple local errors, systematic inferences propagated by SNOMED's classification process, or the result of problems with SNOMED's schemas. Conclusions were confirmed by showing that altering the root cause and reclassifying had the intended effects, and not others.

Main results

Major problems were encountered, involving concepts central to medicine including myocardial infarction, diabetes, and hypertension. Most of the issues raised were systematic. Some exposed fundamental errors in SNOMED's schemas, particularly with regards to anatomy. In many cases, the root cause could only be identified and corrected with the aid of a classifier.

Limitations

This is a preliminary ‘experiment of opportunity.’ The results are not exhaustive; nor is consensus on all points definitive.

Conclusions

The SNOMED CT hierarchies cannot be relied upon in their present state in our applications. However, systematic quality assurance and correction are possible and practical but require sound techniques analogous to software engineering and combined lexical and semantic techniques. Until this is done, anyone using SNOMED codes should exercise caution. Errors in the hierarchies, or attempts to compensate for them, are likely to compromise interoperability and meaningful use.

Keywords: Knowledge bases, knowledge representations, methods for integration of information from disparate sources, knowledge acquisition and knowledge management, developing and refining EHR data standards (including image standards), data models, data exchange, controlled terminologies and vocabularies, communication, integration across care settings (inter- and intraenterprise), ontologies, terminology, EHRs

The full free text is available here:

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3128394/?tool=pubmed

This paper needs to be carefully considered as it is written by an internationally recognised authority in the area of clinical terminology deployment.

Here is a link to his home page:

http://www.cs.man.ac.uk/~rector/home_page_rector/

The range of issues and problems identified included the following:

  • Errors and omissions with propagation and helter-skelter modelling
  • Incomplete modeling: myocardial infarction and ischemic heart disease
  • Issues with sites of systemic disorders
  • Errors in modeling anatomy: Structure-Entire-Part (SEP) triples and the ankle in the abdomen
  • Overgeneralized concepts with underspecified ‘fully specified names’
  • Lack of distinction between structure and function
  • Inconsistent modeling of complications: hypertensive disorders

Detailed examples of each of these are found in the text.

The full text of the conclusions is as follows:

“This study has five classes of outcome:

  • On the SNOMED hierarchies. There are sufficient anomalies in the hierarchies that they cannot be used without significant modification in our applications. More generally, we question whether clinicians entering codes or researchers retrieving information understand their implications. As postcoordination relies on accurate classification, it is doubtful that applications using postcoordination will behave predictably.
  • On the use of description logic in SNOMED. Using a description logic is both part of the problem and part of the solution. The response to the issues raised here is not to abandon SNOMED's description logic but to use it more effectively. Using a description logic means that the correcting root errors found in modules will usually repair analogous problems throughout SNOMED.
  • On the possibility of quality assurance of SNOMED. Given modern tooling and computer power, the barriers quality assurance of SNOMED can now be overcome, although no well-integrated toolset is yet available.
  • On practicality of quality assurance of SNOMED. This was a preliminary study and not exhaustive, but it required less than three person-months using poorly integrated tools. Given an integrated toolset, we estimate that a thorough quality assurance of the Core Problem List Subset would require a small team under 2 years, probably less. This would cover a high fraction of all uses of SNOMED. Most changes would be propagated automatically by the description logic into the full SNOMED corpus. Applying these methods to the remainder of the SNOMED findings would require further resources, but they would be minor by comparison with the effort already devoted to SNOMED's development, let alone to those that will be required for its implementations.lvii
  • On methods required. Using a description logic requires staff who understand both medical content and description logics. It requires adapting the techniques of software engineering to tracing and managing errors. Space does not permit setting out a detailed methodology.lviii However, key maxims should include:
    • Start from clinically important concepts—use clinical intuition.
    • Focus on the classified hierarchies—reclassify after every change.
    • Work in small modules—so that reclassification is quick.
    • Look upwards first and then downwards—there are fewer ancestors than descendants.
    • Trace all errors to their root cause—avoid local ‘kluging.’
    • Look for analogous errors and repair using consistent patterns—for example, complications and sites.
    • Reformulate problematic sections systematically rather than attempting to repair them—for example, head injury and branches in anatomy.
    • Use a combination of lexical and semantic methods—as first suggested by Campbell et al19 and now made straightforward using Ontology Patterns Preprocessing Language (OPPL).20
    • Test systematicallymaintain a suite of ‘unit tests’ covering all issues identified; include tests for unintended consequences of changes; run test suite after every major set of changes and before each release.

Some might argue that many of the erroneous classifications reported here are several steps removed from the original concept in the hierarchies and would be ignored by clinicians. However, the semantics of the description logic underpinning SNOMED is unambiguous. Software and queries must follow them literally. Likewise, the reliability of postcoordination is a function of the reliability of the classifier, which is best determined by its manifestation in the hierarchies.

Until comprehensive quality assurance has been undertaken, anyone using, or mandating, SNOMED should be aware that the hierarchies contain serious anomalies. Should a ‘Reference terminology’ classify diabetes as a disease of the abdomen; fail to classify myocardial infarction as ischemic heart disease; place the arteries of the foot in the abdomen?

Without further quality assurance, clinicians may not realize the implications of what they are saying; researchers may not realize what their queries should retrieve, and postcoordination cannot be expected to be reliable. Interoperability, and therefore meaningful use, will be limited.”

I suggest anyone who is interested in the area read the whole paper carefully and then e-mail NEHTA (terminologies@nehta.gov.au) asking them just when the work recommended here will be undertaken and finalised. A decision to deploy SNOMED CT was made by NEHTA about 4 years ago and the very limited use so far also suggests there are some significant implementation problems.

It seems that while SNOMED is the best available choice for a clinical terminology there is a real effort to be undertaken to make it fully ‘fit for purpose’. Right now is seems it isn’t. It is especially worrying that there seem to be some clear patient safety issues.

Again we seem to be seeing that NEHTA has over promised and under delivered. They need to get weaving and push for the changes Prof. Rector is suggesting with IHTSDO - the international maintainers of SNOMED.

David.

-----

Dr David G More MB PhD6 comments

Sunday, December 04, 2011

NEHTA's Unreality Just Seems To Roll On And On. This Will Take Years. What Planet Are They On?

The following announcement appeared last week

NEHTA licenses CSIRO software for e-health rollout

The software will aid the transition to a standardised dictionary of clinical terms

The National E-Health Transition Authority (NEHTA) has licensed software from the Commonwealth Scientific and Industrial Research Organisation (CSIRO) to aid the move to a standardised dictionary of clinical terms as part of the Federal Government’s Personally Controlled Electronic Health Record (PCEHR) project.

The $467 million project involves the establishment of a PCEHR system that encompasses patient health summaries which both patients and their healthcare providers can access by 1 July 2012.

Australian e-Health Research Centre (AEHRC) chief executive, David Hansen, told Computerworld Australia that the Department of Health and Ageing (DoHA) and NEHTA would soon require healthcare software vendors to make the transition to SNOMED CT, a clinical terminology which encompasses a group of terms that would underpin the PCEHR going forward.

“Whenever there’s a problem, a diagnosis or a clinical description that’s needed to be put in our electronic health records, clinicians, whether they know it or not because it’s in the software, will be picking a term from the SNOMED CT vocabulary,” Hansen said.

NEHTA adopted SNOMED CT about five years ago when they started standardising electronic health information, but usage is still quite low, Hansen said.

CSIRO will provide a free download of the software, called Snapper, which was developed at the AEHRC – a joint venture between CSIRO and the Queensland Government – from November 2011 until 30 June 2013 to support software companies and healthcare providers in making the move.

“Most existing electronic systems do not use the SNOMED CT dictionary, but a mix of existing standard and local data dictionaries. The Snapper tool will help to translate terms in the existing system to terms from SNOMED CT,” Hansen said.

“The Snapper tool will enable information captured in an emergency department computer system to be understood by the computer systems used for hospital in-patients, and again by GP computer systems once the patient has been discharged.

“It will also help with the maintenance as SNOMED is released every six months and help them know which terms they might want to add and so on.”

The Java-based software, compatible with PCs, Macs and Linux, is standalone and while SNOMED CT comes as part of the package, Hansen said, users will be able to update automatically in the future.

More here:

http://www.cio.com.au/article/408608/nehta_licenses_csiro_software_e-health_rollout/

Being curious I thought I would see just what Snapper was.

Snapper

Developed at the Australian e-Health Research Centre, CSIRO’s Snapper incorporates rich semantic feedback to produce the most fully-featured and easiest to use tool for creating mappings from existing term lists or value sets to SNOMED CT and AMT. These semantic mappings enable the meaning of terms in existing clinical terminologies to be described using concepts or expressions from SNOMED CT.

In addition, the intuitive graphical interface allows quick and easy generation and maintenance of customised term lists (Reference Sets) that can then be exported into current software or accessed via an RF2-conformant terminology server.

  • All-in-one: Map your existing terminology to SNOMED CT or build SNOMED CT compliant Reference Sets without needing to fiddle around with browsers and a spreadsheet.
  • Easy to use: Snapper provides a full browsing experience to enable users to understand the SNOMED CT and AMT content.
  • Time-saving: Snapper imports a list of source terms for mapping each term to SNOMED CT and provides an automap feature to provide a "first pass" mapping.
  • Fully featured: Snapper supports the full semantics of SNOMED CT and AMT. Full support is given for creation and syntactic and semantic checking of SNOMED CT’s post-coordination expression syntax, where required.
  • Intuitive GUI: Snapper has unique visualisation features, such as the interactive ontology visualiser and the expression editor. Drag and drop functionality provides for a modern user interface experience.
  • Full lifecycle: Ongoing maintenance of Reference Sets is supported through the use of RF2-based timestamps and timestamp-aware comparison algorithms.

More information, necessary licenses and downloads are here:

http://research.ict.csiro.au/software/snapper

So, in summary what Snapper is, is a terminology mapping tool  to allow systems that have an embedded terminology that is presently used for coding information to convert their present term set to a SNOMED-CT set of associations.

I assume what this means is that if you have an existing set of say drug names or say ICPC codes these can be converted to the SNOMED equivalent in a partially automated way - because - as it made clear, the automap feature only provides a “first pass” map.

A few things occur to me with all this:

A review of the Information Requirements for the PCEHR’s Shared Health Summary (SHS) shows that while SNOMED-CT is preferred, free text is still going to be OK. It is going to be a good while before most software that might create a SHS will be SNOMED-CT compliant.

Any mapping that is done will inevitably introduce all sorts of problems that will need to be manually reviewed and resolved. Any errors could have some rather nasty consequences.

Third if SNOMED-CT is the be used - and it is really the only kid on the block at present - would it not be more sensible to use it directly and not via a map. If terms are going to be applied to text I would feel a direct use would be appropriate - remembering there is a need to minimise user effort by using focussed sub-sets etc. Really it is vital that the clinician is the one that attaches the meaning to a code and this is best done using a direct interaction with the SNOMED hierarchy I would think. This becomes especially relevant if clinical decision support is to be driven from the codes.

This really means provider software need to be configured and tailored to use the terminology from the ground up in an ideal world!

I am also reminded of the comments of Prof. Alan Rector (who really understands this stuff like few in the world) that are found here:

http://aushealthit.blogspot.com/2011/07/it-seems-snomed-ct-has-few-issues-that.html

“Until comprehensive quality assurance has been undertaken, anyone using, or mandating, SNOMED should be aware that the hierarchies contain serious anomalies. Should a ‘Reference terminology’ classify diabetes as a disease of the abdomen; fail to classify myocardial infarction as ischemic heart disease; place the arteries of the foot in the abdomen?

Without further quality assurance, clinicians may not realize the implications of what they are saying; researchers may not realize what their queries should retrieve, and post-coordination cannot be expected to be reliable. Interoperability, and therefore meaningful use, will be limited.”

I also note the arrangement only goes until 2013. I suspect that with most involved in e-Health in Australia rather pre-occupied with PCEHR related activities the focus on SNOMED may not be very intense at this stage.

It also seems a little odd that there was not some form of procurement process undertaken for software and services to support SNOMED implementation. There are companies like Healthlanguage and (http://www.healthlanguage.com/)  and Apelon (http://www.apelon.com/) out there who do this work globally.

Interestingly Apelon have just won a contract to help Canada with a similar program.

See here:

http://www.apelon.com/News/PressReleases/PR_Archive2011/PR_20111114.aspx

Somehow, while being very pleased we have Australian effort and expertise in the area, I feel this is another NEHTA  initiative which may not lead very far in terms of real clinical outcomes in the short or even medium term.

Recognising the limited progress in the five years since SNOMED-CT was adopted I fear we may be waiting another few before some real clinical benefits flow.

To speed things up things some real funds and support need to be provided along with things like Snapper. To date it is not clear that is the plan - to say the least! As of now the expectations of rapid adoption are really pretty unreal - pressure from NEHTA and DoHA or not!

Bottom line. This is not a solution to an urgent problem. We need a total reboot of governance and leadership in Australian E-Health to get us back on the rails.

For those who can access it (at the NETHA Vendor Portal) the NEHTA Version 2.0 Blueprint reveals all sorts of reality checks on time-lines and delivery which really need serious public discussion. Dream on David!

David.

Dr David G More MB PhD2 comments

---- End posts

With this small nibble of history what impresses me is that this present release almost seems to be starting again! Note the whole project is given a 5 year time frame!

What is the betting that much will have changed do you reckon?

David.

 

1 comment:

  1. "To date, more than 100 organisations in Australia have accessed the Ontoserver licence through the NCTS sublicence – lowering the barrier to the adoption of interoperability standards in our health records."

    I have been around for a very long time. I am not persuaded that accessing the Ontoserver licence equates to 'using and implementing its facilities.

    Nor am I persuaded that this lowers the barrier to the adoption of interoperability standards in our health records.

    ReplyDelete