AU Patient Summary Implementation Guide
0.6.0-cibuild - CI Build Australia flag

AU Patient Summary Implementation Guide, published by HL7 Australia. This guide is not an authorized publication; it is the continuous build for version 0.6.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7au/au-fhir-ps/ and changes regularly. See the Directory of published versions

General Guidance

Page standards status: Informative

Approach of this Implementation Guide

AU Patient Summary (AU PS) is provided to support the use of patient summaries in HL7® FHIR®© in an Australian context. AU PS is based on IPS and AU Core, setting the minimum conformance expectations for implementing support for AU PS documents in systems.

AU PS will by design:

  • ensure compliance with AU Core and IPS (see localisation of the IPS)
  • support additional requirements agreed as necessary to support patient summaries in an Australian healthcare context
  • support varied stakeholder needs and use of AU PS artefacts e.g. government policy, implementers, tooling developers, testers, IG authors/maintainers etc.

Scope of AU PS FHIR Artefacts

HL7 AU PS profiles:

  • Resources to define 'minimum' support expectations for use in the Australian healthcare context
  • Actors to define systems that play a role in AU Core data exchange

It is anticipated that capability statements or extension profiles may be included in future releases of this IG.

Extension Approach

All extensions used in AU PS are defined in the FHIR Extensions Pack or AU Base.

It is anticipated that extension profiles may be included in future releases of this IG.

Search Parameter Approach

AU PS does not define any search capabilities. It is anticipated that search parameter profiles may be included in future releases of this IG.

Terminology Approach

AU PS does not define any new terminology FHIR artefacts. Terminology supported in AU PS are published in AU Base, the base FHIR specification, HL7 Terminology (THO), or the National Clinical Terminology Service (NCTS). As part of profiling, AU PS inherits the AU Core localised terminology and indicates local support expectations for an AU PS actor using Must Support and Obligations.

Profile Approach

AU PS resource profiles:

  • are based on the AU Core profile, or where not available, the AU Base profile (where it exists)
  • apply additional requirements inherited from IPS (in accordance with the AU PS Profile Design Principles)
  • have additional requirements as agreed by the AU PS project applied
  • use compliesWithProfile to assert compliance with IPS

The differential view therefore shows the patient summary requirements that are additional to AU Core. In some profiles, e.g. AU PS Organization, the only additional requirements from AU Core are the obligations for AU PS actors.

AU PS Patient current profiling approach

Figure 1: Profiling approach for AU PS Patient profile

The AU PS Bundle profile is not based on AU Core or AU Base as no resource profile exists in either IG. The approach to profiling for AU PS Bundle is to:

  • apply requirements inherited from IPS (in accordance with the AU PS Profile Design Principles)
  • apply additional requirements as agreed by the AU PS project
  • use compliesWithProfile to assert compliance with IPS

This approach to AU PS Bundle profiling has been taken as at this time there is a tooling limitation that prevents meeting both of the below conditions:

  • derivation from Bundle (IPS)
  • changing reference targets to AU PS profiles (as AU PS profiles derive from AU Core and not IPS they cannot be easily assessed as meeting IPS rules by the tooling)
Profile Approach

AU PS profiles are designed to ensure compliance with AU Core and IPS. AU PS profiles design principles are as follows:

  • SHALL ensure resources validate against both IPS and AU Core profiles (where both profiles exist)
    • Cardinality
    • Fixed values and patterns
    • Data type sub-elements and profiles
    • Data type choices
    • Invariants
  • AU PS profiles SHALL validate reference elements against AU PS profile where defined, otherwise the AU Core profile where available, otherwise the AU Base profile where available
  • In AU PS profiles, inherited AU Core profile value sets are preferred over equivalent IPS profile value sets:
    • where an element has a required binding, the element SHALL apply the intersection of both value sets (AU Core and IPS)
    • where an element has a lesser binding, use the AU Core value set and binding strength (where AU Core is equivalent or stronger) or use the IPS value set where the binding strength is stronger
  • An AU PS profile SHALL inherit the IPS profile obligations and MAY strengthen the IPS profile obligations (using a specialisation of the defined obligation) or add an obligation (e.g. SHOULD:persist), as required in the Australian context. A weaker obligation SHALL NOT be specified.
  • Where both AU Core and IPS profiles do not exist, SHALL ensure resources validate against:
    • IPS profile (where only the IPS profile exists)
    • AU Core profile (where only the AU Core profile exists)
  • Where a profile referenced in AU PS Bundle is not defined in IPS, or has Must Support elements with no obligations in IPS, the AU PS obligations default to:
    • AU PS Producer: SHALL:populate-if-known
    • AU PS Consumer: SHALL:handle and SHOULD:display

Adopting the approach in both IPS and AU Core, AU PS profiles are 'open' and allow for additional content undefined by AU PS (and IPS) to be shared. See the section Extensibility – “Additional” Sections or Elements for information.

Additional detail on profiling is described in the guidance section Localisation of the IPS.

Profiling Options

When managing profile complexity and requirements in the national and international context for AU PS, the following mechanisms are available:

  1. Derived from Profiles (derive)
  2. Informal alignment (humans authoring of rules in a profile)
  3. Complies With Profile (compliesWith)
  4. Dependent Profiles (imposeProfile)

These mechanisms offer differing capabilities and advantages. Typically HL7 AU profiles use derivation to manage compliance within HL7 AU inheritance. However, AU PS will comply to both HL7 AU (AU Core) and IPS and therefore additional mechanism(s) on top of derivation from the underlying HL7 AU profile stack are required. At this time additional requirements are included in AU PS profiles via informal alignment (i.e. human authoring, human checking, and compliesWith checks).

For a human, the main differences with use of imposeProfile are:

  • does not rely on humans to maintain compliance rules from the target profile
  • does not visually show human reader of the source profile any rules from the target profile, i.e. a human reader must view and understand both profiles to understand the rules
  • where two or more profiles offer optional alternatives (e.g. differing preferred bindings or data type choices) does not preference one over another

Currently the only AU PS profile to use imposeProfile is AU PS Composition . To support future maintenance it is under consideration that all AU PS profiles derive from AU Core, where available, and use imposeProfile to apply IPS rules. That would mean that a number of IPS-imposed requirements including cardinality, terminology, and flagging of Must Support would not be directly visible in the formal views within this guide. Or, if we chose to make the additional IPS constraints visible + use imposeProfile, those constraints would be repeated from a validation sense and could be an additional validation burden.

Users of this implementation guide are encouraged to provide their feedback about the potential use of imposeProfile.

Actor Approach

AU PS Actors are defined to describe the specific sets of functionality supported by systems that play a role in AU Core data exchange. Each actor is defined by:

  • an ActorDefiniition that includes reference to support expectations (narrative conformance requirements)
  • resource profiles that define expectations using Must Support and Obligations

AU PS actor design to ensure compliance with AU Core and IPS:

  • SHALL inherit the narrative conformance requirements including Missing Data, Empty Sections, Known Absence of Data
  • SHALL inherit IPS Document requirements (see AU PS profile approach)
  • SHALL inherit Must Support and Obligation requirements
  • MAY strengthen inherited requirements as required for the Australian context. A weaker requirement SHALL NOT be specified.

Capability Statement Approach

AU PS does not define any capability statements. It is anticipated that capability statements may be included in future releases of this IG.

Extensibility – “Additional” Sections or Elements

As in IPS, a producer can send:

  • "additional" elements beyond those flagged with Must Support in a profile
  • "additional" sections (often referred to as "undefined" sections) beyond those defined in the AU PS Composition

Additional sections or elements are often required by other profiles the system may conform to, allowing local requirements, including technical and workflow context for the resource, to be reflected and extending the health information supported in exchanges. For this reason, extensibility is generally encouraged and expected in AU PS profiles. Only in some exceptionally rare use case profiles are rules tightened to limit the nature of additional information that can be sent.

Implementers intending to populate the AU PS with an unprofiled resoure type, e.g. MedicationAdministration, are recommended to consider the corresponding AU Base profile, e.g. AU Base MedicationAdministration, as guidance for that resource type in an Australian healthcare context.

Extensibility – “Additional” Sections

Implementers need to be aware, the rules of the Composition.section:All Slices defined in the AU PS Composition profile apply to all sections, defined or undefined:

  • Composition.section.title is mandatory and has obligations defined for AU PS Producers and AU PS Consumers
  • Composition.section.text is mandatory and has obligations defined for AU PS Producers and AU PS Consumers

It is recommended that where a producing system intends to populate "additional" sections there is some definition available in a specification describing the intended contents and use of these additional sections.

Extensibility – “Additional” Elements

Specification authors adopting AU PS are encouraged to enable greater interoperability and software re-use by avoiding reductions in an element's cardinality.

Depending on local requirements, a consumer (i.e. client application) may ignore these "additional" elements, may treat the data as for rendering only, or be capable of recognising and using the element.

Structuring Terminology Choices

The AU PS shares the same structure as IPS and contains sections that can include coded elements in reusable “minimal” data blocks.

The AU PS identifies a number of terminologies as Must Support for AU PS consumers and producers. Primary terminologies used in this specification include SNOMED CT Australian Edition (SNOMED CT-AU) for clinical concepts (e.g. allergies, problems, procedures, medicines), LOINC for observation codes (e.g. pathology results and vital signs), UCUM for units of measure, ISO 3166 for countries, PBS Item codes for medicines, Australian Immunisation Register codes for vaccines, and FHIR defined CodeSystems.

Within the AU PS context (i.e. the Australian healthcare context), the Australian localised value sets, developed and published by the National Clinical Terminology Service (NCTS) and the HL7 AU FHIR Working Group are preferred over IPS value sets to support the consumer on their healthcare journey in the AU healthcare context.

In an IPS context, IPS proposes that to support interoperability of IPS content between organisations that use different SNOMED CT value set content, a "common proximal ancestor" strategy is used. See IPS Structuring Terminology Choices for more information.

Patient Safety in IPS Context

See the guidance defined in IPS Patient Safety in IPS Context.

Medicinal Product Identification

See the guidance defined in AU Core Medicine Information.

Representing Body Site, Which May Include Laterality

See the guidance defined in AU Core Representing Body Site, Which May Include Laterality.

Provenance

See the guidance defined in IPS Provenance.