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

Approach

Page standards status: Informative

Testing out profiling approaches

This section shows different profiling approaches used to develop draft AU PS profiles, ensuring compliance with AU Core and IPS in alignment with the Profile Design Principles for AU Patient Summary. The goal is to identify the most effective way to profile AU PS resources while maintaining conformance to national and international requirements.

We are testing different profiling strategies to assess the impact on:

• how different derivation approaches align with AU Core and IPS
• the impact of using compliance declaration and imposed profiles
• whether the profiles are easy to interpret and apply
• whether FHIR tooling can process and enforce constraints
• ease of use for implementers, including whether a single implementation guide can provide all constraints reducing the need to reference AU Base, AU Core, and IPS separately

FHIR mechanism for ensuring compliance

FHIR provides different key mechanisms for ensuring compliance across different specifications:

1. StructureDefinition Complies With Profile (compliesWith)
   • Declares that a profile complies with a given standard (e.g., AU Core, IPS).
   • A profile does not need to be directly derived from AU Core or IPS but needs to meet all their constraints.
   • Declaring compliesWith AU Core and IPS does not apply rules automatically. It states the intent to comply, meaning the profile itself needs to enforce the necessary constraints.
2. StructureDefinition Dependent Profiles (imposeProfile)
   • Ensures conformance to another profile by applying constraints from the imposed profile.
   • More restrictive than StructureDefinition Complies With Profile, as it inherits all rules of the imposed profile.
   • Ensures a profile applies all constraints from another profile without being directly derived.
3. StructureDefinition Derived from Profiles (derive)
   • Ensures conformance to another profile by applying constraints through inheritance from the base profile.
   • The resulting profiles is a 'profile' can apply further constraints to those inherited from the base profile.
   • A profile can only derive from one profile not multiple
   • Be wary of over-use - humans have trouble understanding the implications of deep stacks of constraining profiles.

TBD

Testing approach

To test the AU patient summary approach we have three main test scenarios that different profile approaches are tested against:

• Test scenario 01: example FHIR resource compliant to AU Core and IPS
• Test scenario 02: example FHIR resource compliant to AU Core but not IPS
• Test scenario 03: example FHIR resource compliant to IPS but not AU Core

The total pool of examples includes:

• set of 'control' examples (27 examples)
• set of 'approach' examples, where there the 'control' set has been adjusted only to change the meta.profile value for each approach A to I.
• set of approach A examples (9 examples)
• set of approach B examples (9 examples)
• etc.

Set of control examples

Originating AU Core examples are the basis for the test examples: MedicationRequest/paracetamol-codeine, MedicationRequest/reaptan and MedicationRequest/simvastatin.

Those originating 3 examples become the set of 27 control examples by:

• Three test scenario variants for each of the 3 original files (becomes 9 files)
• For each of that set, there are then three controls on that using meta using meta.profile e.g. one control asserts only AU Core, another control asserts only IPS, the last control asserts both.

In qa.html, if an instance passes, it does so whether meta.profile has one or multiple profiles. However, an error, warning, or information is triggered, qa.html does not display which profile is the reason. To make clear which profile assertion is triggering each error, warning, or information, we have taken the approach of 'variation' by meta.profile value.

Test scenario	Example instance that is the control check against both AU Core & IPS using meta.profile	Example instance that is the control check against AU Core only using meta.profile	Example instance that is the control check against IPS only using meta.profile
01 Example compliant to AU Core and IPS	simvastatin-01-aucoreips	simvastatin-01-aucore	simvastatin-01-ips
	reaptan-01-aucoreips	reaptan-01-aucore	reaptan-01-ips
	paracetamol-codeine-01-aucoreips	paracetamol-codeine-01-aucore	paracetamol-codeine-01-ips
02 Example compliant to AU Core but not IPS	simvastatin-02-aucoreips	simvastatin-02-aucore	simvastatin-02-ips
	reaptan-02-aucoreips	reaptan-02-aucore	reaptan-02-ips
	paracetamol-codeine-02-aucoreips	paracetamol-codeine-02-aucore	paracetamol-codeine-02-ips
03 Example compliant to IPS but not AU Core	simvastatin-03-aucoreips	simvastatin-03-aucore	simvastatin-03-ips
	reaptan-03-aucoreips	reaptan-03-aucore	reaptan-03-ips
	paracetamol-codeine-03-aucoreips	paracetamol-codeine-03-aucore	paracetamol-codeine-03-ips

Set of approach examples

The table shows different profiling approaches for AU PS profiles. The table includes:

• Profile if and title- hyperlinked to the profile definition
• Profiling approach description - explains how the profile is derived and how it enforces AU Core and IPS constraints
• Test scenarios - indicates if the profile complies with AU Core, IPS, or both
• Example instances used for testing

Conventions used in testing:

• Profile id, name, title and example instances include a suffix (e.g., -a) which identifies the specific profiling approach used
• Example instances used to test a profile carry the same suffix as the profile itself
  • The only variation between instances is in meta.profile, which declares compliance with the profile that has the same suffix.
• Each profile has a set of instances (01, 02, etc) to test different scenarios while maintaining the same profile suffix.
• Each example instance declares conformance to only one profile in meta.profile to make validation results clear. In qa.html, if an instance passes, it does so whether meta.profile has one or multiple profiles. However, if it fails, qa.html does not show which profile the instance failed against. To avoid this issue, we test one profile at a time.

Profile Title	Profiling approach	Test scenario	Example id
EXPERIMENTAL AU PS MedicationRequest Approach A	Approach A: Derive from AU Base Manually apply AU Core rules Manually apply additional IPS rules change the target references of elements flagged with Must Support to point to AU PS profiles where they exist state compliesWith AU Core and IPS	Validate examples compliant with IPS and AU Core	simvastatin-01-a
			reaptan-01-a
			paracetamol-codeine-01-a
		Validate examples compliant with AU Core but not IPS	simvastatin-02-a
			reaptan-02-a
			paracetamol-codeine-02-a
		Validate examples compliant with IPS but not AU Core	simvastatin-03-a
			reaptan-03-a
			paracetamol-codeine-03-a
EXPERIMENTAL AU PS MedicationRequest Approach B	Approach B: Derive from AU Core Manually reapply AU Core constraints (so they appear in the diff similar to US Core approach) Manually apply additional IPS rules change the target references of elements flagged with Must Support to point to AU PS profiles where they exist State compliesWith IPS	Validate examples compliant with IPS and AU Core	simvastatin-01-b
			reaptan-01-b
			paracetamol-codeine-01-b
		Validate examples compliant with AU Core but not IPS	simvastatin-02-b
			reaptan-02-b
			paracetamol-codeine-02-b
		Validate examples compliant with IPS but not AU Core	simvastatin-03-b
			reaptan-01-b
			paracetamol-codeine-03-b
EXPERIMENTAL AU PS MedicationRequest Approach C	Approach C: Derive from AU Core Manually apply additional IPS rules change the target references of elements flagged with Must Support to point to AU PS profiles where they exist State compliesWith IPS	Validate examples compliant with IPS and AU Core	simvastatin-01-c
			reaptan-01-c
			paracetamol-codeine-01-c
		Validate examples compliant with AU Core but not IPS	simvastatin-02-c
			reaptan-02-c
			paracetamol-codeine-02-c
		Validate examples compliant with IPS but not AU Core	simvastatin-03-c
			reaptan-03-c
			paracetamol-codeine-03-c
EXPERIMENTAL AU PS MedicationRequest Approach D	Approach D: Derive from FHIR Manually apply AU Base rules (terminologies and identifiers) Manually apply additional AU Core rules Manually apply additional IPS rules change the target references of elements flagged with Must Support to point to AU PS profiles where they exist State compliesWith AU Core and IPS	Validate examples compliant with IPS and AU Core	simvastatin-01-d
			reaptan-01-d
			paracetamol-codeine-01-d
		Validate examples compliant with AU Core but not IPS	simvastatin-02-d
			reaptan-02-d
			paracetamol-codeine-02-d
		Compliant& with IPS	simvastatin-03-d
			reaptan-03-d
			paracetamol-codeine-03-d
EXPERIMENTAL AU PS MedicationRequest Approach E	Approach E: Derived from IPS Manually apply AU Core rules change the target references of elements flagged with Must Support to point to AU PS profiles where they exist	Validate examples compliant with IPS and AU Core	simvastatin-01-e
			reaptan-01-e
			paracetamol-codeine-01-e
		Validate examples compliant with AU Core but not IPS	simvastatin-02-e
			reaptan-02-e
			paracetamol-codeine-02-e
		Validate examples compliant with IPS but not AU Core	simvastatin-03-e
			reaptan-03-e
			paracetamol-codeine-03-e
EXPERIMENTAL AU PS MedicationRequest Approach F	Approach F: Derive from AU Core use imposeProfile to enforce IPS constraints change the target references of elements flagged with Must Support to point to AU PS profiles where they exist	Validate examples compliant with IPS and AU Core	simvastatin-01-f
			reaptan-01-f
			paracetamol-codeine-01-f
		Validate examples compliant with AU Core but not IPS	simvastatin-02-f
			reaptan-02-f
			paracetamol-codeine-02-f
		Validate examples compliant with IPS but not AU Core	simvastatin-03-f
			reaptan-03-f
			paracetamol-codeine-03-f
EXPERIMENTAL AU PS MedicationRequest Approach G	Approach G: Derive from IPS use imposeProfile to enforce AU Core constraints change the target references of elements flagged with Must Support to point to AU PS profiles where they exist	Validate examples compliant with IPS and AU Core	simvastatin-01-g
			reaptan-01-g
			paracetamol-codeine-01-g
		Validate examples compliant with AU Core but not IPS	simvastatin-02-g
			reaptan-02-g
			paracetamol-codeine-02-g
		Validate examples compliant with IPS but not AU Core	simvastatin-03-g
			reaptan-03-g
			paracetamol-codeine-03-g
EXPERIMENTAL AU PS MedicationRequest Approach H	Approach H: Derive from AU Base use imposeProfile to enforce both AU Core and IPS constraints change the target references of elements flagged with Must Support to point to AU PS profiles where they exist	Validate examples compliant with IPS and AU Core	simvastatin-01-h
			reaptan-01-h
			paracetamol-codeine-01-h
		Validate examples compliant with AU Core but not IPS	simvastatin-02-h
			reaptan-02-h
			paracetamol-codeine-02-h
		Validate examples compliant with IPS but not AU Core	simvastatin-03-h
			reaptan-03-h
			paracetamol-codeine-03-h
EXPERIMENTAL AU PS MedicationRequest Approach I	Approach I: Derive from the FHIR resource State complies with AU Core and IPS Note this is a negative case. The profile does not include, directly or by reference, any rules to make the claims of assertion true. This profile demonstrates behaviour when a 'false' compliesWith is stated.	Validate examples compliant with IPS and AU Core	simvastatin-01-i
			reaptan-01-i
			paracetamol-codeine-01-i
		Validate examples compliant with AU Core but not IPS	simvastatin-02-i
			reaptan-02-i
			paracetamol-codeine-02-i
		Validate examples compliant with IPS but not AU Core	simvastatin-03-i
			reaptan-03-i
			paracetamol-codeine-03-i