The Archetype 'Elevator Pitch'


I've been asked for the classic 'elevator pitch': How does a non-openEHR expert, non-geek explain the notion of developing a library of archetypes to their colleague or boss? Here goes for the 2 minute version:


WHAT: The development of a clinician-led library of clinical content specifications can be a foundation piece of national health IT infrastructure, intended to support interoperability of all granular health information, rather than a limited selection of messages or documents as we have now.

WHY: To ensure that the patterns for health data that is being collected and exchanged is consistent and broadly re-used across the jurisdictional eHealth environment, no matter whether it be organisational, regional, national or international. This will provide a firm basis for establishing technical and semantic interoperability. For example, the recording core of clinical concepts such as diagnosis or medication orders will be consistently captured, stored and exchanged across organisations, vendor systems and for a full variety of clinical purposes ranging from home data collection, through primary and secondary care, research and population health.


    • The clinical content itself should be defined, reviewed and declared fit for purpose by clinicians and domain experts, not just technicians.
    • The development and governance process should be managed by expert health informaticians.
    • The end users will be the vendors and organisations.
    • The overall project governance should be led by clinical professional groups +/- a potential consortia with appropriate political/industry groups etc.

HOW: Utilise the current archetype methodology and Clinical Knowledge Manager tool.

RESULT: The outcome of such a program of clinical content standardisation would provide a long term and sustainable approach to developing, maintaining and governing jurisdictional health data specifications. It could form the backbone for a national health data strategy and is a key way to ensure that clinicians contribute their expertise to jurisdictional eHealth programs.


Then perhaps consider extending it to a 5 minute version with some practical context:

In the short term, the existing archetypes in any or all of the national or international CKMs would be leveraged as a starting point. Many of these archetypes are quite mature as the result of implementations. For example, as the basis for the CDA specifications used by the Australian PCEHR and recent NT Health development. They cover core clinical concepts that are used in most settings and across a range of clinical activities.

Each clinically agreed archetype could be utilised as the jurisdictionally agreed pattern/specification for a given clinical concept - a public ‘line in the sand’ if you like. In the early days vendors could use these archetypes as a pattern to transform their existing databases to in order to exchange data between systems. Over time, vendors may choose to gradually re-engineer their existing/legacy databases to directly conform to the models, thus supporting ease of direct interoperability and reduce the need for vendors to manage clinical content independently.

For new vendors or projects, this library of clinical data patterns could provide the basis for ready ‘approved’ data collections (ie approved by the clinicians participating in the development  and review process), rather than reinventing the wheel with their own proprietary data elements and adding further to the creation of data silos.

Funding sources would need to be identified, probably most often from a public source, keeping in mind that the outcomes can then be made publicly and freely available under a Creative Common licence. The outcome would be a national library/repository of free clinical content specifications, based on an open standard, and able to be used as the basis for all national eHealth work – design an archetype once, reuse in any/all clinical contexts, and the data that is created using these archetype patterns will be sharable and interoperable.

Any suggestions for refinements?