The constraint 'app-4' for Appointment is not being enforced due to a typo.

[mudlej]

Describe the bug The expression in constraint 'app-4' for Appointment uses 'no-show' instead of 'noshow' which make it useless since there is no status 'no-show'.

Environment Using LinuxForHealth FHIR Server 5.1.1.

To Reproduce Steps to reproduce the behavior:

1. Create a request to Appointment and use 'noshow' as the status and add a cancellation reason. e.g.

       {
            "resourceType": "Appointment",
            "status": "noshow",
            "cancelationReason": {
                "coding": [
                    {
                        "system": "http://terminology.hl7.org/CodeSystem/appointment-cancellation-reason",
                        "code": "pat-mv",
                        "display": "Patient: Moved"
                    }
                ]
            },
            "start": "1996-01-17T00:00:00.000+02:00",
            "end": "1996-01-17T00:00:00.000+02:00",
            "participant": [
                {
                    "actor": {
                        "reference": "Practitioner/2a1ef88f-6efe-4aba-8ec3-e4a303973fdf"
                    },
                    "status": "accepted"
                }
            ]
        }

2. POST it to FHIR at FHIR_API/Appointment
3. See the error message in the response body. { "severity": "error", "code": "invariant", "details": { "text": "app-4: Cancelation reason is only used for appointments that have been cancelled, or no-show" }, "expression": [ "Appointment" ] } 4- Using 'no-show' will be rejected as well because the status code is 'noshow'.

Expected behavior The request should be accepted since it doesn't violate the rule.

Additional context This could be solved easily by removing the dash from the expression part of the constraint, as in the pull request.

[lmsurpre]

Thats a good find. We actually get these constraints straight from the specification and so what you found here is actually a spec bug: https://hl7.org/fhir/R4B/appointment.html#invs

It looks like that was reported to HL7 at https://jira.hl7.org/browse/FHIR-37896 and they already fixed it for R5. I think it would be reasonable to back-port that fix for our R4B implementation.

[mudlej]

I think so. It's a typo in the specification, which results in the opposite of the expected behavior. Thanks for deciding to back-port the fix.