AU FHIR Base identifier data type profiles - bad use of pattern, fixed value, and binding.

RichardTON commented 5 years ago

From Zulip thread https://chat.fhir.org/#narrow/stream/179166-implementers/topic/CodeableConcept.20child.20elements.20appears.20twice

There are profiles where CodeableConcept elements have a pattern and their child element text has a fixed value, e.g. Practitioner. This is invalid (see Zulip thread) but is not rejected by the validator. It does create a strange display in the snapshot tab.

RichardTON commented 5 years ago

I suggest that the solution is to move the fixed value from the text element to the pattern. The pattern becomes

      <patternCodeableConcept>
        <coding>
          <system value="http://terminology.hl7.org/CodeSystem/v2-0203"/>
          <code value="NPI"/>
        </coding>
        <text value="HPI-I"/>
      </patternCodeableConcept>

and the fixed value for text is removed,

brettesler-ext commented 4 years ago

need to review in PA; this is not quite the same as intent

if there is a type then must be a code + system as specified
text is optional but fixed if present
using pattern alone would require the text to be present if type is present..

robeastwood-agency commented 4 years ago

A reassessment of this issue was undertaken, given the recent shift for all identifiers to be represented in datatype profiles.

In short, the issue remains in the below listed Identifier datatype profiles, in that the snapshot table repeats type.id, type.extension, type.coding and type.text, when the following conditions exist:

Identifier.type has patternCodeableConcept to constrain coding AND
Identifier.type.text (in a separate node) has a min value and fixedString constraints

The HPI-O identifier profile does not exhibit this problem as it includes the type.text constraint within the patternCodeableConcept node; as shown above (and see here):

The fix is to follow the pattern used by HPI-O Identifier profile; and it affects these Identifier datatype profiles:

Note that the same issue may be in other profiles, as the above assessment was made on Identifier datatype profiles only.

dtr-agency commented 4 years ago

In general type.text should not be set in AU Base profiles. It is a misuse of that element - the intention of setting a code with display is to declare a common means of representing this data, text should be allowed to serve a local purpose, e.g. for the sending system to indicate a meaningful local label.

It is unreasonable for the national definition of an identifier data type to prohibit the inclusion of a local label for an identifier, i.e. the system will reject a medical record number if an identifier has the text URN.

Definition of text element: A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user. There will be a forthcoming issue for this to be removed to be reconsidered for real world identifiers.

RichardTON commented 4 years ago

au-medicareprovidernumber has a binding to a CodeSystem. Bindings are to ValueSets, not CodeSystems.

RichardTON commented 4 years ago

The identifier profiles include a mandatory slice with a fixed value of identifier type, so the binding is redundant and distracting. Examples with this problem include

au-ahpraregistrationnumber
au-cwlthseniorshealthcardnumber
au-employeenumber
au-ihinumber

dtr-agency commented 4 years ago

Overview

The issues around Identifier.type across the set of profiles (#471 | #302 | #319) are being progressed together as a proposal for ratification at the WG. A work in progress build of the proposal is available.

The expectation is that Identifier profiles are not 'Base profiles'. These profiles represent well formed identifiers that may be used as-is for the purposes of conformance and are the recommended agreed representations of these identifiers.

Principles

A set of principles are driving the changes in this proposal. These are not complete - they only address the issues and inconsistencies present in the current set of identifiers in AU Base.

Proposed principles around Identifier type:

type is mandatory - mandating type is appropriate for profiles for 'well formed' identifiers
every Identifier data type profile shall have guidance on the coding of type:
- a fixed code in structure, or
- a required binding either to V2 Identifier Type - AU Extended value set or to a subset such as DVA Entitlement
- if the required binding is the wide V2 Identifier Type - AU Extended value set then there shall be a preferred code in Usage Notes (only applies to ABN, ARBN, ACN)
if a fixed code is present:
1. it shall be from the required V2 Identifier Type - AU Extended value set
2. shall not have the 'required binding' present as it is already satisfied by the fixed code
3. code will be fixed by pattern
4. coding will not be restricted to 1..1 as this is too restrictive
text should not be constrained in all real world identifier profiles as per #471

Proposed principles around Identifier system & value cardinality:

All profiles that define identifier types (rather than special cases) should mandate system and value.

Proposed principles around assigner:

Local identifiers (e.g. Employee Number, Local Prescription Number) should provide guidance on assigner:

Mandating this assigner only appropriate for profiles for 'well formed' identifiers - otherwise assigner should be optional
assigner.display should be mandated in either case as the agreed base means of providing this information (the Reference type is too open to leave unconstrained)

robeastwood-agency commented 3 years ago

Further updates have been made to the build branch to align with the current proposal: http://build.fhir.org/ig/ci-collaborative/au-fhir-base-r4/branches/Proposal-identifier-data-type-structural-changes/profiles.html

hl7au / au-fhir-base