Understanding the scope of AUCDI

The AUCDI focuses on necessary clinical health data to support high quality healthcare delivery and quality data for exchange and reuse. The first release of AUCDI was as an initial, carefully curated data foundation that is being enhanced and extended as standards, policies, technical implementations, and clinical requirements mature and evolve.

Key considerations in determining the scope were to:

  • Support clinical safety and best practice,
  • Create a foundational layer of common data groups that are tightly controlled and governed to provide a robust and clear structure for information sharing,
  • Include data that is well understood, commonly used, and well supported by existing clinical systems, and
  • Identify incremental change that will create benefits and support broad reuse across multiple use cases.

Scope drivers

In developing the initial releases of AUCDI as a new national data standard, the focus was on striking a balance between meeting clinicians’ data requirements and maintaining the integrity of data captured by existing clinical systems. The goal of future releases of AUCDI is to progressively refine the specification towards best practice in clinical data documentation. This approach supports clinical workflow and optimises the potential for the reuse of health data in data-driven initiatives such as Clinical Decision Support (CDS) and Artificial Intelligence (AI). At the same time, AUCDI has been carefully curated to avoid the future risk of backwardly incompatible changes and their inherent cost in clinical system rework. This balance creates a solid foundation for future development.

Scope of AUCDI

The scope and level of detail of the clinical content in AUCDI has been driven and agreed by the Sparked Clinical Design Group, comprising clinicians, informaticians, subject matter experts, terminologists and implementers. The design is tightly focused on prioritising the most efficient and practical ‘clinical core data’ ready for use within clinical systems, rather than providing the complete or final data groups. The underlying intent is that over time the data groups will grow towards more comprehensive models, while striving to maintain backward compatibility with previous releases.

The initial selection of data groups in the AUCDI and their level of detail, were principally guided by alignment to existing clinical systems implementations in Australia; ensuring that they can meet identified clinical requirements and maintain support for safe clinical care.

High level scope of AUCDI

AUCDI includes the following data groups:

  • Adverse reaction risk summary
  • Alcohol consumption summary
  • Biomarkers
    • Estimated glomerular filtration rate (eGFR)
    • Haemoglobin A1c (HbA1c)
    • Lipids
    • Urine albumin-creatine ration (uACR)
  • Education summary
  • Encounter – clinical context
  • Estimated Date of Delivery (EDD)
  • Financial summary
  • Food and nutrition summary
  • Goal
  • Health education (ISM)
  • Health issue
  • Housing summary
  • Last Menstrual Period Assertion (LMP)
  • Living arrangement summary
  • Medical equipment supply
  • Medication use statement
  • Measurements & Vital signs
    • Body temperature
    • Body height
    • Body weight
    • Blood pressure
    • Pulse (Heart rate)
    • Respiration
    • Waist circumference
  • Occupational summary
  • Physical activity summary
  • Physical assistance (ISM)
  • Pregnancy assertion
  • Problem/Diagnosis summary
  • Procedure
  • Psychosocial therapy
  • Service Request
  • Sex and gender
  • Substance use summary
  • Tobacco smoking summary
  • Vaccination administration

AUCDI does not include:

  • Representations of
    • The patient, including date of birth, Aboriginal and Torres Strait Islander status) and
    • Related people, such as carers
    • Health care providers
    • Organisations
  • System information, or system-derived information – including information related to technical aspects of recording data (such as author and record date/timestamp) and will be managed in the technical implementation specifications (for example in a FHIR IG),
  • Administrative information that is not relevant for recording or reuse within a health record,
  • Workflow,
  • Payment information, such as credit card details,
  • User interface or form implementation requirements,
  • Higher-level technical concepts such as security, access, privacy, and consent, and
  • Non-clinical recording context such as author, participants, location of service.

National clinical building blocks

Each data group can be considered a standalone building block. Data sets, comprising one or more clinical concepts, will include a corresponding data group for each concept, aggregating and constraining the building blocks to meet the requirements of a specific clinical use case.

Within each data group, most data elements are deliberately designated as optional to keep AUCDI neutral to any specific use case and optimise the reusability of data groups across all implementation scenarios. Data elements are made mandatory only where they are essential in every possible use case or when the rest of a data group relies on a mandatory index data element to make sense, such as the name of a diagnosis in the Problem/Diagnosis summary data group. In specific technical specifications, implementations, or FHIR IGs, the optional data elements can subsequently be made mandatory to suit the clinical use case.

Some data elements, for example, ‘Comment’ or ‘Clinical indication’, might be found in many data groups. This is a deliberate design pattern to promote coherence across the data groups. For example, ‘Comment’ serves as a universal data element with a uniform description across all data groups where it is relevant. The overarching context of the data group ensures that the content of one comment can be distinguished from another. Similarly, ‘Clinical indication’ is represented within only a few data groups, however, the consistent naming and description across each data group, such as ‘Procedure completed’ and ‘Medication use statement’, supports design coherence and consistency of AUCDI. However, the specific semantics of each value set may be tailored to most accurately represent the clinical concept.

Iterative growth and development

The intention is that the selection of data groups would grow and expand over time so that additional clinical use cases are addressed and included. The AUCDI will also therefore grow to include more clinical content to address data groups that are not currently well recorded in existing implementations. It is recognised that some clinical information systems do not natively support structured data groups and elements specifically relating to social determinants of health and goals, therefore, it is expected that Smart Forms currently under development to support health care assessments and team care arrangements, will implement these data groups in the short term.

This approach allows data groups to expand whilst simultaneously addressing previously un-recorded/ or inconsistently recorded health data against specifically defined use case examples.  Such use cases represent consensus driven clinical requirements expressed by the clinical design group.  It is acknowledged that content from newly added clinical concepts may also not be immediately represented in the AU Core FHIR IG and other national technical specifications, however, will provide the roadmap to inform future technical implementations.

Additional concepts and data elements proposed by the Sparked CDG for potential inclusion in AUCDI during scoping workshops have been added to the AUCDI backlog for future consideration.