Why the NEHTA Clinical Data Specifications Will Go Nowhere.

In early 2002 an organisation called the National Infostructure Development (NID) was funded to develop the information infrastructure that would be required as part of an implementation of the then planned HealthConnect. A key component was the Clinical Information Project (CIP).

The CIP focus was the clinical information content of shared EHRs for HealthConnect and the broader EHR agenda. The clinical information content relates to information that needs to be captured, stored and viewed to support the HealthConnect objective of improved delivery of health care and better quality of care.

Because the developmental focus of HealthConnect as a whole was based on the concept of event summaries, which were to make up the Shared EHR, the focus of the CIP was on the development of forms together with information content and definitions suitable for discharge summaries, referrals, result information and so on (the so called 'high priority' forms).

Efforts in this area continued when NEHTA took over responsibility for the CIP – since renamed a couple of times and, now seen as part of the Clinical Communications component of NEHTA's work. Recently (in December, 2006 and in February) we witnessed the release of two 500 page documents outlining the information structure and content of discharge summaries and specialist referrals.

What are we to make of these documents and how are they to be used?
_________________________________

In their introductory document the authors say:-

“NEHTA has released specifications to standardise the content of electronic referrals across Australia. This work also makes possible the development of improved decision support systems, which will be able to make use of the information in electronic versions of clinical documents (such as referrals) to assist healthcare practitioners make better decisions; and is an important step towards realising shared electronic health records.”

And they also say:-

“A Comprehensive Specification

It is important to understand the philosophy behind specifying referral content as comprehensively as appears in this specification. The specification needs to be comprehensive to capture as much information as required for the recipient to understand the patient's condition as fully as possible. However, it is quite clear that any one referral sent by a healthcare practitioner is unlikely to require the full suite of details embodied in the specification. In developing the referral specification, NEHTA has considered:

• - how prescriptive the referral template should be, in terms of:

o structure;
o comprehensiveness; and
o the terminology used;

• - the burden imposed on clinicians creating and receiving referrals; and

•- the burden on clinical information systems to capture, send and/or receive and process structured information.

Therefore, while the specification is prescriptive with respect to structure, information richness, and terminology, it is not prescriptive about which information should be sent under what circumstances. It is important to note that the specification was also designed for use within clinical information systems to reduce the burden of data entry for the referring healthcare provider, and the subsequent data interpretation, storage and manipulation by the referred-to provider.

The specification and included samples therefore indicate the richness of information that can be expressed, sent and ultimately imported into clinical information systems and shared electronic health records. The specification should not be interpreted as the set of information that must be sent, irrespective of the condition of the patient and the purpose of the referral.

Implementation Considerations

The establishment of clinical information systems that can interoperate regarding the transmission and computer interpretation of referrals (and other documents) is an evolutionary process. NEHTA anticipates that, in the first instance, the health community will review the GP and Specialist/Critical Care Referral Content Specification to become familiar with the content and intention of the specification, and plan to implement elements of the specification where possible within planned system upgrades.

Once the additional elements required by interoperable systems become available, the systems that have incorporated the specification will be able to quickly transition to interoperability. The key additional elements are outlined below.”

____________________________________

The document then goes on to cite SNOMED CT, HL7 V2.x and provider and patient identification.

I must say it takes some special form of arrogance to publish a set of specifications such as this without any reference to, or suggestion of, even the simplest of trial implementations, or ‘proof of concept and viability’, or any of the tools that are obviously required to make any sense or use of the material.

I am sure any system provider offered this specification would say: “Where in the world is something of this structure and complexity working and how much are you going to pay me to be your trial horse?”

Comments such as “NEHTA anticipates that, in the first instance, the health community will review the GP and Specialist/Critical Care Referral Content Specification to become familiar with the content and intention of the specification, and plan to implement elements of the specification where possible within planned system upgrades.” provide no assurance any of this is going anywhere in the foreseeable future – and leads to the inevitable question “Why should I spend anything on all this until it is clear that others are?”.

The other obvious problem is that NEHTA says that one does not need to do a comprehensive implementation of this specification but provides no roadmap to guide development and implementation priorities. Unless this is provided this looks like it’s pretty much an 'all or none' in terms of what is needed to begin developing system specifications. And the “all” is a huge project I would suggest, especially as the specification seems to only exist as an untested MS Word document at present!

The last major issue is that nowhere in the documentation is there any mention of how interoperation, if ever attempted, will be certified and provide a robust guarantee of accuracy, reliability, future maintenance and safety. If you offer a specification of this nature for use you take on the obligation to maintain and certify compliance with the specifications that you produce in perpetuity. Plans in this area simply do not exist as far as I can tell.

Slipping back to reality for a moment, the facts are these:

1. A national HealthConnect project, as originally envisaged, seems to have a very low probability of actually ever being implemented, even though NEHTA says it is still being worked on. The most obvious reason for this is that the costs of such a project (almost certainly billions of dollars) are not likely to easily be provided by Government – despite a compelling business case to make major investments in the e-Health space.

2. The world has moved on to more pragmatic international standards with experts and implementers on both sides of the Atlantic seeking simpler and more practical implementable approaches for deployment of interoperable systems. In the US the Continuity of Care Document (CCD) is emerging (deploying features of HL7, CDA R2 and ASTM CCR) as a credible standard and in the UK work has been undertaken to reduce the information content on the NHS Spine down to the minimum possible.

3. Without a guarantee of major investment in these specifications no vendor will invest to develop compliance. Attempts at mandating such specifications are likewise doomed as large vendors will simply say 'you set up the certification mechanisms so compliance can be verified and you pay us all our costs at time and material rates and we will develop what you require!” Meanwhile, small vendors will probably be put out of business if they attempt to address the complexity inherent in the specifications.

4. Unless the specification is implemented as a whole how are partially compliant systems to ‘understand’ what they are being sent? There are also versioning and maintenance issues that will emerge over time that are not addressed as best I can see. What is likely to happen as new versions of this specification are developed or new terminology is implemented. All of a sudden interoperation between old and new versions will become much more problematic. OpenEHR and its predecessor designs have devoted vast effort to addressing such matters. It is not clear the same is true with this work.

It seems clear that as of now, NEHTA would be far better off working with HL7 to spend whatever limited resources are available to assist with and influence the CCD and make sure it is suitable for Australia rather than continuing with what is an ill-considered, go it alone, and now past its time, local initiative. That way, more local skills in support of a global standard and its implementation would be developed in Australia. This in turn would enable Australia to maintain a place at the 'top table' of standards developers, and ensure that it can draw upon various sources of implementation capabilities and resources internationally.

Unless NEHTA is prepared to fund a range of genuine ‘proof of concept’ implementations of its specifications (to confirm their functionality, utility, viability and technical correctness) this is all going to be a waste of time and money. Even if NEHTA does decide to take that path the likelihood of eventual adoption by the Australian Health IT community would have to be rated as unlikely at best.

David.