AU Core Patient Consensus Discussion

[dt-r]

Check out AU Core Patient, noting the draft general conformance and Must Support data obligations.

To see the full constraints inherited from AU Base view the Key Elements Table

AU Core Patient should support the minimum requirements to record, search, and fetch basic demographics and other administrative information about an individual patient.

Comment on:

• If this profile was mandated tomorrow, what problems would that cause for your organisation?
• What's missing? What about support for MRNs?
• What is the preferred identifier to support where an individual is not eligible for an IHI e.g. tourist or other temporary stay in Australia. Passport is proposed for use (see example Patient/italia-sofia).
• Should anything change? What about the concepts you are using, is it sufficiently covered by the terminology in AU Core?

[heathfrankel]

Please allow active value of false to support Patient records that have been deactivated or merged.

Can we spell out the official name use for the purposes of Medicare compliance and IHI lookups?

[dt-r]

Discussed in 2023-09-28 AU Core TDG Agenda/Minutes.

Motion to remove constraint on Patient.active passed. Change tracked via #50.

Patient name discussed, decision this belongs in AU Base. GitHub tracker hl7au/au-fhir-base#802 raised.

[dt-r]

From @ir4y

I have a question about the fixed value for the active field in Patient, Practitioner, PractitonerRole, and Organization.
Could you please share a bit more details on why it is a fixed true value?

There are multiple use cases when you need to make a resource inactive. @heathfrankel mentioned some of them in the GitHub discussion (please check related topics for dedicated resources) and all of them make sense to me.

Originally posted by @ir4y in #43

[dt-r]

Discussed in 2023-09-28 AU Core TDG Agenda/Minutes.

Motion to remove Patient.active passed. Change tracked via #50.

[kimberley-hilton]

Noting that AU Core Patient currently includes Gender but not Sex. From a national data reporting perspective, there would be value in both. Existing metadata from METEOR: https://meteor.aihw.gov.au/content/741686 and https://meteor.aihw.gov.au/content/741842

[dt-r]

AU Core Patient supports patient.gender = Administrative Gender - the gender that the patient is considered to have for administration and record keeping purposes.

It's not a good match to ttps://meteor.aihw.gov.au/content/741842

Patient gender identity aligned to Australian Bureau of Statics Standard for Sex, Gender, Variations of Sex Characteristics and Sexual Orientation Variables, 2020 is supported in FHIR on the Patient resource using the genderIdentity extension and Gender Identity Response value set.

• Man or male may be represented by sending the SNOMED CT code 446151000124109|Identifies as male gender|
• Woman or female may be represented by sending the SNOMED CT code 446141000124107|Identifies as female gender|
• Non-binary may be represented by sending the SNOMED CT code 33791000087105|Identifies as nonbinary gender|, see example Patient/example4
• [I/They] use a different term (please specify) may be represented by sending only text and no code, see example Patient/example7
• Prefer not to answer may be represented by sending the code “asked-declined”, see example Patient/example0
• Not stated or inadequately described may be represented by the code “unknown”

Patient Gender and Sex and the Gender Harmony IG provide a lot of good information on the work that has been done to define concepts of sex and gender with HL7.

I think from an AU Core and AUCDI perspective it will be a conversation around which concepts do we need to bring into the data set and the FHIR IG.

[dt-r]

Discussed in 2023-11-16 AU Core TDG Agenda/Minutes. Proposal for sex and gender concepts to be progressed through Jan to March 2024. See https://confluence.hl7.org/pages/viewpage.action?pageId=212730453 and agenda of meetings to come through AU FHIR WG Calendar.

[koushiki-suri]

For preferred identifier to support where an individual is not eligible for an IHI e.g. tourist or other temporary stay in Australia - Passport seems to be the most plausible one but we will need to include the issuing country with it to make sure it is unique.
Australian Visa Grant number might be another one which I believe is unique for international visitors but it might not be something as readily available on the patient as a passport number.

[heathfrankel]

Can the Usage scenarios be more specific as this will provide better guidance around the constraints being applied in the profile. For example:

• Synchronising Patient Administration System patient records with departmental or financial systems
• Support SMART Apps such as Smart Forms in Primary Care and Hospital Systems
• Support primary care and aged care quality indicator data extracts (enabling a client to use raw data to produce QIs)
• Diagnostic requests, specialist referrals and aged care transfers
• Hospital theatre bookings

I am also have a concern that we are trying to conform with international and US profiles, which is making the minimum requirements for AU vendors unnecessary, such as the must support for _revinclude Provenance, _id (the read request is more commonly used for this) in searches and the various combinations (I guess they are should, but then from a compliance perspective this is meaningless - wont need to be implemented). A mandatory identifier may also be problematic for scenarios with foreign patients without IHI/MCN (yes I know missing data extensions can be added, but this could be challenging for new implementers).

On the other hand, we need to consider that a AU Core Responder may be implementing using a façade pattern and not have generic search capabilities, in this case it may be useful to indicate exactly which identifier types that shall be supported in search requests, e.g. IHI and MCN, but not DVA or MRN.

[grahamegrieve]

Agree with Heath, and we should also be clear about how to. For instance, we might choose to support synchronisation and data extracts via bulk data - this would affect which search parameters we mark as must-support. btw I don't believe that must-support for Provenance is from US core - I don't see it there.

[dt-r]

To be progressed via #83

[nielmdrec]

• For the active flag, we need support for false because Medirecords system allows us to inactivate a Patient
• For the identifiers, we also added a slice for External Patient Identifier (code = PT). This was useful when we were integrating with an external system (e.g. Hospital). We would store the external system's MRN in this External Patient Identifier. We reserved the MRN identifier for our system's MRN.

[grahamegrieve]

that's still an MRN

[dt-r]

Discussed in 2023-09-28 AU Core TDG Agenda/Minutes.

Motion to remove Patient.active passed. Change tracked via #50.

[utsavigajjar]

• AU Core Patient should inlclude both Sex and Gender.
• Why do we not have generalPractitioner included on AU Core Patient?

I have a specific use case where a client application needs to retrieve and update following data elements for a Patient. Would be great to discuss and understand where to map those elements on existing AU Core Patient resource profile.
Data elements are:

• Patient's NDIS Number
• PBS Safety Number
• Religion
• Any restrictions on sharing Patient's record
• Living Arrangement
• Household Composition
• Type of Disability, if any.
• Citizenship Status
• Australian Visa Status
• Patient consent to receive comms via Email or SMS
  Whilst you can record different types of consent on Patient's record in PAS. Consent to recieve comms is the most common one most apps are interested in. Can this be included on the Patient resource?

[dt-r]

Discussed gender and sex in 2023-11-16 AU Core TDG Agenda/Minutes. Proposal for sex and gender concepts to be progressed through Jan to March 2024. See https://confluence.hl7.org/pages/viewpage.action?pageId=212730453 and agenda of meetings to come through AU FHIR WG Calendar.

[dt-r]

@utsavigajjar, other items raised as #84.

[dt-r]

In Patient profile, the description of (extension:dateOfArrival says: 'Date of first arrival in Australia' and data type 'date' is aligned with the description. However in Patient profile the short description is : 'Year of Arrival'. Knowing 'date' datatype can support only year, is it encouraged to use 'Year' only?

Originally posted by @techintrorepo in #48

[dt-r]

Discussed in 2023-09-28 AU Core TDG Agenda/Minutes.

Motion to remove support for dateOfArrival extension passed. Change tracked via #51.

[newok05]

I'm unclear as to why interpreterRequired, communication.language and communication.preferred is unique to Australia. Should this not be agreed at an international level?

[dt-r]

International level defines the extension and elements that could be used. The question for AU Core is do we in AU Core?

Additionally, AU Base provides useful localisation of the language code set - same terminology (BCP 47) - but puts in a value set 'Common languages in Australia':

• languages that are supported by the national interpreter service in Australia
• AU specific languages like AUSLAN and first nations languages

The binding on that isn't restrictive, any language can be included.

[xtfer]

Specifying a preferred identifier where an IHI (or other standard healthcare identifier) is not available is problematic. The IHI can be used because it's a national identifier for this use case, but a passport number is not a consistent identifier (an individual could have history recorded under more than one passport number), is non-unique without the country being namespaced, nor I suspect is it collected with any consistency(?). We'd be creating a defacto healthcare identifier by specifying it as a preferred alternative and that should be out of scope (?).

This is not a resource identifier, it's not required to identify the record. If I want to find information on a patient and I do not have any of the valid details for them, I'm unlikely to search their passport number. The workflow is more likely to be to matched based on other factors.

[iDavidWiebe]

People without an IHI.
Best practice would advise not using another identifier. Creates confusion and rarely meets the full need. I was thinking about how big of a problem this is. To be able to track someone that doesn't have an IHI until they get one or until the complete their interactions with the Australian Health System. Do we notify anyone when they are discharged?
Searching for the Patient would have to be done by their name and with the qualifier that they don't have an IHI.
If they need an identifier, the replacement identifier would be another Patient Identifier Type, "No IHI Identifier".
Constructing the identifier should be simple and obvious.
Using things like the date when the patient record was created, realizing that they didn't have an IHI. And something with their name.
Like: 231101DWiebe
The derivation rule can be stronger, but at least you could easily remember what would work in a search of "No IHI Identifiers" for the patient you are looking for.

[WarrenArndt]

Will ethnicity/ancestry type data attributes be included in AU core patient in addition to indigenous status?

https://www.abs.gov.au/statistics/classifications/australian-standard-classification-cultural-and-ethnic-groups-ascceg

[dt-r]

@WarrenArndt, support for this element in not in the current AU Core Profile or AUCDI R1. There is a draft extension in AU Base but I haven't significant interest in adding that as a supported AU Core, and therefore all systems as a minimum requirement. If you would like to propose it's inclusion you can raise a GitHub issue in this repository with the proposal.

[dt-r]

This discussion is now closed. Feedback on AU Core should be raised using GitHub issues. Feedback might be suggesting a feature, pointing out a place where a specification is unclear or over-restrictive, identifying a spelling or grammar issue, identifying a defect, or suggesting that an entire area needs to be rethought.

Integration with HL7 JIRA is coming and when available specification feedback will be migrated to JIRA. An announcement will be posted in this discussion when it is available.

Questions on this profile can be raised in chat.fhir.org: https://chat.fhir.org/#narrow/stream/179173-australia