AU Core Condition Consensus Discussion

[dt-r]

Check out AU Core Condition, 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 Condition should support the minimum requirements to record, search, and fetch problems, diagnoses, and health concerns associated with a patient.

Comment on:

• If this profile was mandated tomorrow, what problems would that cause for your organisation?
• What's missing?
• What elements are not relevant to AU Core - not in the Core of the Core?
• Should anything change? What about the concepts you are using, is it sufficiently covered by the terminology in AU Core?

[HDA-Carmen]

From Healthdirect National Health Services Directory (NHSD):

1. We would not be able to adhere to spec as we do not have patient data. NHSD would like to adopt the Conditions resource however, but our use case is for conditions-based searching for services that provide treatment or do you suggest we use another resource?
2. NHSD also have a "conditions eligibility" attribute, which defines the age group - for example, babies and infants, youths and adolescents, adults, geriatrics. We need this to help filter our services from those that treat only a specific cohort.

[brettesler-ext]

I would probably not use Condition resource; it is an 'event' pattern resource (https://hl7.org/fhir/R4/workflow.html#event) - hence the 1..1 subject element (Patient | Group) for recording events so would think not entirely suitable. This would be more definitional - describe what type of cohort is appropriate - potentially Group resource could define this (https://hl7.org/fhir/R4/group.html) Group.characteristic could possibly handle an express of Condition existence and age ranges - linking that to HealthcareService is something to consider - can have the Group defined managed by an Organization which might be a round about way to link to HealthcareService.
or look at some of the more workflow oriented resources ActivityDefinition (https://hl7.org/fhir/R5/activitydefinition.html - these seem not ideal in R4 but might be able to create Group association with ActivityDefinition.participant as HealthcarService to define suitable healthcare services for a group).

[dt-r]

Discussed in 2023-11-02 AU Core TDG Agenda/Minutes. Outcome: Outside of scope of AU Core and will take the discussion to Zulip.

[brettesler-ext]

We should have an explicit position on how to do 'free text' medical history i.e. are these always Condition?

[dt-r]

I don't think AU Core needs to declare how this works now. If there is a position, or strong community requirement on how to support this we could bring it in but otherwise I don't see this as AU Core R1 scope.

For context I've seen 'free text' handled as:
Section.text - where this is essential CDA level 2 of a narrative only section
Section.entry.reference.display - where the text of each entry is supplied in the display element
Condition.text - is an option but the Condition resource moving into R5 requires some structured element.

[dt-r]

Discussed in 2023-11-02 AU Core TDG Agenda/Minutes. To be progressed via #65.

[brettesler-ext]

We should clarify how Condition.code and Condition.bodySite work together i.e bodySite is redundant as body site pre-coordinated in Condition.code or qualifies Condition.code as body site is not defined in code.

[gonatf]

Similar issue in servicerequest which depends on post/pre coordination approach

[dt-r]

I don't think this is a requirement for AU Core to address. How this works together for some use case can and should be handled by a downstream use case IG. The generic case is defined by the FHIR standard on how these elements can work together. I don't see a ubiquitous conformance requirement in Australia that works across all use cases for all system actors outside of what is defined by the FHIR Standard.

[dt-r]

Discussed in 2023-11-02 AU Core TDG Agenda/Minutes. To be progressed via #64.

[gonatf]

Worth considering an assertion date as in allergyintolerance? See https://build.fhir.org/ig/HL7/fhir-extensions/StructureDefinition-condition-assertedDate.html

[dt-r]

Discussed in 2023-11-02 AU Core TDG Agenda/Minutes. Outcome: park until discussion on Must Support in AU Core.

[reubendaniels]

From Queensland Health:

1. Category - currently supports problem-list-item and encounter-diagnosis as values. It is suggested that additional values such as Unknown or Not Specified be added to reflect scenarios where it is unclear whether the condition is a problem or diagnosis. Alternatively, category could be made optional, but preference would be to add extra values.

2. If we needed to capture a diagnosis type (A qualifier to indicate the type of diagnosis eg. Comorbidity, Complication) - where would we capture this in the AU Core Condition profile?

3. Code for the Condition/Problem or Diagnosis is currently extensibly bound to the https://healthterminologies.gov.au/fhir/ValueSet/clinical-condition-1 NCTS value set. It is suggested that an AU Core specific value set is defined for this binding for the following reasons:

• An AU Core value set can be maintained/curated through the HL7 Australia standards development process independent of the NCTS. Note: an AU Core value set may still be published in the NCTS if HL7 Australia and the NCTS operator are open to this.
• The NCTS value set is itself defined as including all the member of the Problem/Diagnosis SNOMED CT-AU reference set. While many of these concepts are likely to be appropriate for this binding, the reference set may not have been developed with the same goals as AU Core. Further, changes to the reference set (e.g. retirement of member concepts by the Australian NRC or SNOMED International) would impact this value set's expansion and thus the binding.

[dt-r]

1. Query - has this been raised in International? Supporting Unknown and Not Specified can be done by DAR extension in general and unknown should be part of the definition of 'missing data' (assuming we retain a Must Support flag for this element). Specified is more interesting. What is the case for QLD Health to share these values?

[brettesler-ext]

#1 would like to work out any specific usage i.e. other categories to consider
#2 are these how the Condition relates to other Conditions/Procedures? or part of the Condition.code ?

[dt-r]

Discussed item 1 in 2023-11-02 AU Core TDG Agenda/Minutes. Outcome: Agreement that the proposer should raise this discussion at international level as not AU specific.

Items 2 & 3 not discussed.

[dt-r]

@reubendaniels I think we should take the question on diagnosis-type to Zulip to discuss before brining a proposal to the TDG.

[RichardTON]

The text should be improved in au-core-cond-02: If a coded body site is provided, at least one code shall be from SNOMED CT
Consider
au-core-cond-02: If a coded body site is provided, at least one of it's codes shall be from SNOMED CT

That makes it clear that each instance of bodySite is tested separately. That a SNOMED CT code on one bodySite does not mean that all of the other bodySites can use codes without SNOMED CT translations.

[dt-r]

Not for consensus discussions. Converted to issue #67 to be examined by IG author for suggested wording improvement.

[RichardTON]

Suggest including the R5 constraint con-3

<constraint>
<key value="con-3"/>
<severity value="error"/>
<human value="If condition is abated, then clinicalStatus must be either inactive, resolved, or remission."/>
<expression value="abatement.exists() implies (clinicalStatus.coding.where(system='http://terminology.hl7.org/CodeSystem/condition-clinical' and (code='inactive' or code='resolved' or code='remission')).exists())"/>
<source value="http://hl7.org/fhir/StructureDefinition/Condition"/>
</constraint>

[dt-r]

I support the pre-adoption of an R5 constraint into the R4 definition.

[dt-r]

@RichardTON On comparison of the R4 Condition resource and R5 condition resource this rule is present in both. The change in R5 is to refactor and renumber the constraints.

See the R4 constraint con-4 that is the equivalent of R5 con-3 noting the FHIRPath changes made in R5.

[angusmillar]

At Sonic we have been working on a Guidance Base Requesting CDS service that requires patient context. The service has a rules engine that is driven from a selected list of Patient 'Clinical Context' codes, made up by us! Some examples of these codes are (Lymphoma, Leukaemia, Eosinophilia, Chest Pain ACS, Iron Deficiency, etc) There are over 132 of these terms. I raise this as we have been looking at the FHIR Condition resource as a target for these 'Clinical Context' codes. In the future, I suspect we would want to drive the rules from a known list of Conditions and a CDS Hooks service.

[dt-r]

@angusmillar I think this need and how it could be supported is a better discussion to have on Zulip as a next step.

[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