Guiding principles and assumptions when modelling

This page covers some of the principles and assumptions that heavily influence the content, presentation, and process for modelling in Clinical Informatics at the Agency.

Assumptions

Clinical informatics specifications are intended to support exchange scenarios: exchange of clinical information between humans, between machines and between human and machines. The assumptions on producing and consuming systems are basically:

• data is likely to be sourced from multiple legacy systems that may not have the capability to talk to each other
• data is likely to be consumed / processed into multiple legacy systems that don’t have the capability talk to each other
• some system will have local code systems, some only text, some will support one or more well managed international code systems such as LOINC or SNOMED CT, some will support one or more national code systems such as PBS items or AIR vaccine codes
• some systems will have more relevant data items to exchange than we specify
• some systems will have fine grained structures, some will have larger grained data structures

Principles

The specifications for exchange are designed to, for a particular language (CDA or FHIR):

• Cover the ‘payload’, everything else is out of scope: packaging requirements, rendering requirements, storage requirements, security, confidentiality, management of data e.g. how to update or withdraw the content
• Represent an agreement on the common set of data that is agreed to be able to be authored and consumed in an electronic exchange of healthcare data for a defined scenario
• Represent an agreement on the ‘minimal’ set of data agreed for a defined scenario
• Explain the expectation for authoring and consuming data, including data not in the agreed common set
• Additional content may be supplied only where it does not negate or qualify data in the agreed common set
• Guiding principles includ
  • Semantic interoperability - the meaning of information must be recognisable to all parties, both humans and machines.
  • Maximise expressivity - do not limit what can be expressed.
  • Minimise distortion - allow information to be expressed faithfully, without distortion.
  • Minimise reading effort - information should be easy to retrieve/interpret.
  • Allow reuse
  • Information may be used decades after it is exchanged
• The primary idea is the faithful representation of a piece of data so that it is able to be consumed safely by others, i.e.
  • authoring systems are able to perform minimal, safe, transformation into an exchange format
  • authoring systems provide enough data with enough quality to be consumed
  • consuming systems are able to recognise and handle a piece of data that is covered by the model, e.g. ‘I know what this is… it is a problem onset date’
  • consuming systems are able to recognise and handle a piece of data that they have never seen before

On clinical practice and limiting permitted values:

• Sometimes statements of clinical best practice are used to request restrictions on the information that can be captured in a clinical document. Those requests are based on a confusion and must be resisted. When designing data structures for the recording or exchange of clinical information (such as SCSs) the structures need to permit all expected values of data elements to be carried. The role of the data structures is to permit accurate reporting of clinical practice, not to guide clinical practice. If clinical guidance says that certain values or units of measure are used, that is important, those values and units of measure must be catered for. If clinical guidance says that certain values are deprecated or others are preferred, that must not limit the values permitted in the data structure. It should instead affect clinical training and may affect user interface design.

Profiles will be derived from a HL7 AU Base profile unless the use case to be supported is unique or an edge case that has legitimate requirements and it does not make sense to include this content in a national standard. The solutions and specifications published by the Agency will be based upon nationally agreed content that is derived from international standards. The gap for implementers for any particular project will be the difference between the specified solution for the specific use case and the nationally agreed form of that content, the HL7 AU Base profiles. This approach should enable rapid development and adoption of clinical informatics outcomes from the work program.

Specific modelling considerations:

• All content that is expected be understood nationally needs to be represented in a HL7 AU profile, or is fully covered by the FHIR resource itself – no party should need to read an Agency specification to understand any item other than an implementation platform specific requirement or constraint e.g. IHIs are in the HL7 AU Base implementation guide as is all terminology planned to be used but more constrained value sets are in Agency profiles
• Emphasis on reusability such that small variations are relaxed so that a profile can serve three use cases rather than have three profiles that differ by fractions (even normative fractions)
• Ensure semantic alignment between the FHIR model and the CDA model (take into account the two reference models); better a slightly awkward structure to ensure a safe transform from one format to another than an elegant solution in one format that has no fairly obvious or consistent representation in the other
• Where possible have clinical models robust to being handled out of a document paradigm, i.e. include context semantics in the clinical statement such as author, subject, recorder, encounter, and time
• Align to Argonaut AU (same elements with must support, same mandatory elements), as much as reasonable
• Should improve alignment to international standards and HL7 models incl where possible replace NCTIS section codes with LOINC codes and ensuring section codes provide sufficient semantic context
• Modelling of open / closed profiles should serve the use case - generally this is almost always open in some way to allow for local additional content to be supplied at the discretion of authoring systems
• All common, acceptable-quality (are or can be defined as FHIR terminology resources) terminology are supported