AU Core Implementation Guide
0.2.2-preview - Preview Australia flag

This page is part of the Australian Core IG (v0.2.2-preview: AU Core) based on FHIR R4. For a full list of available versions, see the Directory of published versions

Resource Profile: AU Core RelatedPerson

Official URL: http://hl7.org.au/fhir/core/StructureDefinition/au-core-relatedperson Version: 0.2.2-preview
Standards status: Draft Maturity Level: 0 Computable Name: AUCoreRelatedPerson

Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License. HL7 Australia© 2022+; Licensed Under Creative Commons No Rights Reserved.

This profile sets minimum expectations for a RelatedPerson resource to record, search, and fetch related persons associated with a patient. It is based on the AU Base Related Person profile and identifies the additional mandatory core elements, extensions, vocabularies and value sets that SHALL be present in the RelatedPerson resource when conforming to this profile. It provides the floor for standards development for specific uses cases in an Australian context.

Usage scenarios

The following are supported usage scenarios for this profile:

  • Record or update information about a related person referenced by another resource
  • Read information about a related person referenced by another resource

Comparison with other national and international specifications

A resource conforming to this profile:

No equivalent International Patient Access or International Patient Summary profile.

Conformance in reverse is not guaranteed, i.e. a resource conforming to US Core MAY NOT conform to AU Core.

Profile specific implementation guidance

  • An individual’s IHI SHOULD be used in RelatedPerson.identifier if available, in preference to Medicare or DVA numbers
  • See guidance on the construction of an identifier on the relevant Identifier profile page and the section on Business Identifiers in AU Base
  • See the Representing communication preferences section for guidance
  • When constructing an address
    • an international address can be represented using the core Address data type
    • an Australian address SHOULD be represented using the Australian Address data type profile

Usage:

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

This structure is derived from AUBaseRelatedPerson

NameFlagsCard.TypeDescription & Constraintsdoco
.. RelatedPerson C0..*AUBaseRelatedPersonA person related to a patient in an Australian healthcare context
au-core-relper-01: If present, name shall at least have text, family name, or given name
... Slices for identifier S0..*Identifier, AUIHI, AUMedicareCardNumber, AUDVANumber, AUHealthCareCardNumber, AUPensionerConcessionCardNumber, AUCwlthSeniorsHealthCardNumber, AUMedicalRecordNumber, AUInsuranceMemberNumberA human identifier for this person
Slice: Unordered, Open by pattern:type
.... identifier:ihi S0..1AUIHIIndividual Healthcare Identifier (IHI)
.... identifier:medicare S0..1AUMedicareCardNumberMedicare Card Number
.... identifier:dva S0..1AUDVANumberDepartment of Veterans' Affairs (DVA) Number
... active 0..1booleanWhether this related person's record is in active use
Fixed Value: true
... patient S1..1Reference(AU Core Patient)The patient this person is related to
... name SC0..*HumanNameA name associated with the person
... telecom S0..*ContactPointA contact detail for the person
... address S0..*Address, AustralianAddressAddress where the related person can be contacted or visited
... communication S0..*BackboneElementA language which may be used to communicate with about the patient's health
.... language S1..1CodeableConceptThe language which can be used to communicate with the patient about his or her health
.... preferred S0..1booleanLanguage preference indicator

doco Documentation for this format

Constraints

IdGradePath(s)DetailsRequirements
au-core-relper-01errorRelatedPersonIf present, name shall at least have text, family name, or given name
: name.exists() implies name.all(text.exists() or family.exists() or given.exists())

 

Other representations of profile: CSV, Excel, Schematron

Notes:

Below is an overview of the mandatory and optional search parameters and combined search parameters. FHIR search operations and the syntax used to describe the interactions is described here.

Any search parameter defined in FHIR may be ‘allowed’ by the system unless explicitly marked as “SHALL NOT”. A few items are marked as MAY in this implementation guide to highlight their potential relevance.

Parameter(s) Conformance Type(s) Requirements (when used alone or in combination)
patient SHALL reference The client SHALL provide at least an id value and MAY provide both the Type and id values. The server SHALL support both.
_id SHOULD token
identifier SHOULD token The client SHALL provide both the system and code values. The server SHALL support both.

The client SHOULD support search using IHI, Medicare Number, and DVA Number identifiers as defined in the profile. The server SHOULD support search using the using IHI, Medicare Number, and DVA Number identifiers as defined in the profile.
name SHOULD string
patient.identifier SHOULD token The client SHALL provide both the system and code values. The server SHALL support both.

The client SHOULD support search using IHI, Medicare Number, and DVA Number identifiers as defined in the AU Core Patient profile. The server SHOULD support search using the using IHI, Medicare Number, and DVA Number identifiers as defined in the AU Core Patient profile.
patient+relationship SHOULD reference +token

Mandatory Search Parameters

The following search parameters and search parameter combinations SHALL be supported:

  1. SHALL support searching using the patient search parameter:
    • SHALL support these _revinclude parameters: Provenance:target
    • SHOULD support chained searching of patient canonical identifier patient.identifier (e.g. patient.identifier=[system|][code])

    GET [base]/RelatedPerson?patient={Type/}[id] or optionallyGET [base]/RelatedPerson?patient.identifier=[system|][code]

    Example:

    1. GET [base]/RelatedPerson?patient=5678
    2. GET [base]/RelatedPerson?patient.identifier=http://ns.electronichealth.net.au/id/medicare-number|32788511952
    3. GET [base]/RelatedPerson?patient.identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8003608833357361

    Implementation Notes: Fetches a bundle of all RelatedPerson resources for the specified patient (how to search by reference and how to search by token)

Optional Search Parameters

The following search parameters and search parameter combinations SHOULD be supported:

  1. SHOULD support fetching a RelatedPerson using the _id search parameter:
    • SHALL support these _revinclude parameters: Provenance:target

    GET [base]/RelatedPerson/[id] or GET [base]/RelatedPerson?_id=[id]

    Example:

    1. GET [base]/RelatedPerson/2169591
    2. GET [base]/RelatedPerson?_id=2169591
    3. GET [base]/RelatedPerson?_id=2169591&_revinclude=Provenance:target

    Implementation Notes: Fetches a single RelatedPerson (how to search by the logical id of the resource)

  2. SHOULD support searching for a related person by an identifier using the identifier search parameter:
    • SHALL support these _revinclude parameters: Provenance:target

    GET [base]/RelatedPerson?identifier={system|}[code]

    Example:

    1. GET [base]/RelatedPerson?identifier=http://ns.electronichealth.net.au/id/medicare-number|32788511952
    2. GET [base]/RelatedPerson?identifier=http://ns.electronichealth.net.au/id/hi/ihi/1.0|8003608833357361
    3. GET [base]/RelatedPerson?identifier=http://example.org/fhir/mrn|12345

    Implementation Notes: Fetches a bundle containing any RelatedPerson resources matching the identifier (how to search by token)

  3. SHOULD support searching for a related person based on text name using the name search parameter:
    • SHALL support these _revinclude parameters: Provenance:target

    GET [base]/RelatedPerson?name=[string]

    Example:

    1. GET [base]/RelatedPerson?name=Wang

    Implementation Notes: Fetches a bundle of all RelatedPerson resources matching the name (how to search by string)

  4. SHOULD support searching using the combination of the patient and relationship search parameters:
    • SHALL support these _revinclude parameters: Provenance:target
    • SHOULD support multipleOr search on relationship (e.g.relationship={system|}[code],{system|}[code],...)

    GET [base]/RelatedPerson?patient={Type/}[id]&relationship={system|}[code]{,{system|}[code],...}

    Example:

    1. GET [base]/RelatedPerson?patient=5678&relationship=http://terminology.hl7.org/CodeSystem/v3-RoleCode|MTH,http://snomed.info/sct|133932002

    Implementation Notes: Fetches a bundle of all RelatedPerson resources for the specified patient and relationship code(s) SHOULD support search by multiple codes. (how to search by reference and how to search by token)