30.5.0

Consumers 30.5.0, HIEBus 30.7.0

List searches and Subscription creations deadlocked

(C/26e6556f)

Unauthorized (401) responses now return a valid OperationOutcome body

Previously they returned a custom (non-FHIR) JSON or XML response body.

(C/4fc647dd)

Populate the scope property in refresh and backend authorization token responses

As per SMART specifications.

(C/ac4859f6)

Be able to deny permissions to execute bulk export

Previously any user that had read access to the Patient resource could also execute bulk exports, now this permission can be denied.

(H/cecc5aa1)

Fixed content encoding of bulk export files in Amazon S3

Previously the content encoding was a non-standard x-gzip, now it is the standard gzip.

(H/792ba36f)

Always populate OperationOutcome.issue.code

Previously it was mostly missing, that is non-compliant

(H/5b367c8e)

Generate data absent reason extension for Immunization.occurrence (R4) / Immunization.date (DSTU2)

Previously those elemnts where simply omitted if there was no value available to populate them, that is non-conformant.

(H/3043bae6)

Fix CapablityStatement.rest.compartment to contain compartment URIs instead of resource types.

E.G. http://hl7.org/fhir/CompartmentDefinition/Patient instead of just Patient.

(H/1f4bbdbe)

Fix the _source search parameter type to be URI instead of token

As per the FHIR specifications.

(H/a62efc87)

Fix the AuditEvent agent search parameter type to be reference instead of token

As per the FHIR specifications.

(H/06507682)

Fix the R4 Measure topic search parameter type to be token instead of string

As per the FHIR specifications.

(H/88628545)

Fix crashes when suppressing non-conformant resources

Some Patient searches and searches including non-conformant resources on endpoints configured to suppress non-conformant resources resulted in crashes (error 500).

(H/27051f78)

Change in the logic use to generate Patient.deceased[x]

Previously if the system had conflicting values (some sources reporting deceased and some not) the deceased[x] element was not populated and had a DataAbsentReason extension of unknown, now it is populated with the deceased value (either 'yes' or a date).

(H/63523f64)

30.4.0

Consumers 30.4.0, HIEBus 30.6.1
Consumers 30.3.0, HIEBus 30.6.0

Fixed crash generating R4 Provenance

. . . for patients that did not have an associated user that last modified it.

(H/33472c4a)

Improve CareTeam query performance

Adjusted internal filtering to make CareTeam searches perform more quickly

(H/ebaadb57)

30.2.0

Consumers 30.2.3, HIEBus 30.4.0
Consumers 30.2.2, HIEBus 30.4.0
Consumers 30.2.1, HIEBus 30.4.0
Consumers 30.2.0, HIEBus 30.4.0

Added an internal setting to disable the 'do not generate CodeableConcept.text' feature

This allow endpoints to revert to the old behavior where CodeableConcept.text was always populated.

(H/07b839d6)

Addedd an internal setting to disable populating R4 Meta.source and the corresponding DSTU2/STU3 extension

This allow endpoints to revert to the old behavior where Meta.source or the corresponding extension (for DSTU2/STU3) was not populated.

(H/b4af7db0)

Forbid resource creation and update when in blinded mode

It caused weird errors when updating certain resources (notably Patient)

(H/56f0f079)

Fix error processing transaction create/update with empty entry fullUrl

Now create (POST) and update (PUT) entries without a populated fullUrl element are accepted and correctly processed as per specifications, previously they caused an error.

(H/e5143709)

Fixed crash when creating or updating resources that had conflicting references

For example a Procedure referencing a Patient and an Encounter that references a different Patient.
Now instead the client gets a 400 error specifying which references are in conflict.

(H/5e7afeae)

Support conditional create

Add support for the If-None-Exist header in POST and PUT request and for the IfNoneExist request element for transaction. See the specifications.

(H/58591a19)

Fail with a 400 if user specifies If-None-Exist on create, update, or in a transaction

Our server does not support conditional create (yet), so it is better to fail instead of just ignoring that header / element.

(H/42871b25)

30.1.0

Consumers 30.1.0, HIEBus 30.2.0
Consumers 30.0.0, HIEBus 30.2.0

Fix crash when updating ExplanationOfBenefit

POSTing or PUTting ExplanationOfBenefit that (1) already existed, (2) had less associated services (ExplanationOfBenefit.item) than the existing one and (3) had care team members associated with the services that no longer existed caused a crash.

(H/6587e369)

Better profile conformance handling

meta.profile is populated only when the resource is actually conformant to the specified US Core or Carin BB profile - previously it was assumed that they were conformant.

meta.profile is no longer populated for all STU3 resources.

There is a new internal configuration flag that allows endpoint to suppress resources that are not conformant with either the base specifications or the US Core / Carin BB profiles.

Encounter.reasonCode no longer handled as if it was required

The Encounter.reasonCode element used to be treated as if it was a required element, so if it could not be populated the system produced a DataAbsentReason extension. It is not actually a required element, so now there won't be such DataAbsentReason extension any more.

DSTU2 CarePlan.activity.detail.status defaults to in-progress

Previously it was not populated if there was no available value.

DSTU2 Procedure.code, Procedure.performed, Device.udi, Device.type, Goal.description and Goal.status are required by the Argonaut profiles

. . . so they now they have a DataAbsentReason extension if there is no available value.

DST2 and R4 Patient.gender is set to unknown if there is no available value

Previously it was not populated in that case.

DSTU2 Procedure.status is set to completed if there is no available value

Previously it was not populated in that case.

R4 Encounter.type, Device.udi and Device.type are required by the US Core profiles

. . . so they now they have a DataAbsentReason extension if there is no available value.

(H/702c779e)

Standard coding system URIs fixes

Breaking change

Various standard conding system URIs where incorrect or missing, they are now fixed:

System Old system URI New system URI
HCPCS http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets
Ub04PointOfOriginNewBorn https://www.nubc.org/CodeSystem/PointOfOrigin-NewBorn https://www.nubc.org/CodeSystem/PointOfOriginNewBorn
UBFacilityType N/A https://rosetta.careevolution.com/UBFacilityType
CDT N/A http://www.ada.org/cdt
UNII N/A http://fdasis.nlm.nih.gov

(H/5ec05d8e)

Check references when POSTing data

When validating ($validate operation) and POSTing / PUTing resources the system check also that there are no conflicting references - e.g. a Procedure referencing a Patient and an Encounter that references a different Patient.

Breaking change: FHIR POST / PUT that previously were OK (and generated conflicting references in CareEvolutionData) are now rejected.

(H/ab0b619e)

R4 Observation resource now includes data from the DeviceDataContext and DeviceDataPoints CareEvolution concepts

Previously such data - typically coming from wearable dvices like FitBit - was not visible via FHIR at all.

(H/f217f7d5)

Fix in R4 Condition.category

Breaking change

The R4 Condition.category coding system for health-concern is now (correctly) http://hl7.org/fhir/us/core/CodeSystem/condition-category instead of http://terminology.hl7.org/CodeSystem/condition-category.
See the US Core Condiiton category value set.

Also, added the 16100001 SNOMED code (Death diagnosis) to the possible category codes, in addition to problem-list-item, encounter-diagnosis and health-concern.

(H/4d617edb)

Remove the internal 'FhirCodesXXXXX' codings from CodeableConcepts

Previously CodeableConcepts (especially those in the http://careevolution.com/fhirextensions#term extension of Code elements) could contain one or more codings with systems like [Site URI]/codes/FhirCodes. . . ., e.g.:

        "gender": "female",
        "_gender": {
            "id": "gender1",
            "extension": [
                {
                    "url": "http://careevolution.com/fhirextensions#term",
                    "valueCodeableConcept": {
                        "id": "gender2",
                        "coding": [
                            {
                                "system": "http://fhir.carevolution.com/codes/FhirCodes/Gender",
                                "code": "female",
                                "display": "Female",
                                "userSelected": true
                            },
                            {
                                "system": "http://fhir.carevolution.com/codes/CareEvolution/Gender",
                                "code": "F",
                                "display": "Female",
                                "userSelected": false
                            },
                            {
                                "system": "http://fhir.carevolution.com/codes/FhirCodesAlternate1/Gender",
                                "code": "F",
                                "display": "F",
                                "userSelected": false
                            },
                            {
                                "system": "http://fhir.carevolution.com/codes/HL7Gender/Reference",
                                "code": "F",
                                "display": "Female",
                                "userSelected": false
                            }
                        ]
                    }
                }
            ]
        },

These codings are an artifact of the internal logic used to map to standard FHIR codes, and have now been removed from the output, e.g.:

        "gender": "female",
        "_gender": {
            "id": "gender1",
            "extension": [
                {
                    "url": "http://careevolution.com/fhirextensions#term",
                    "valueCodeableConcept": {
                        "id": "gender2",
                        "coding": [
                            {
                                "system": "http://fhir.carevolution.com/codes/CareEvolution/Gender",
                                "code": "F",
                                "display": "Female",
                                "userSelected": false
                            },
                            {
                                "system": "http://fhir.carevolution.com/codes/HL7Gender/Reference",
                                "code": "F",
                                "display": "Female",
                                "userSelected": false
                            }
                        ]
                    }
                }
            ]
        },

There is no loss of information because the actual standard FHIR code is available in either the code elements itself (for code elements with a http://careevolution.com/fhirextensions#term extension) or in a coding with a standard FHIR system URI (for CodeableConcept elements).

(H/6dfab04c)

No longer populate the CodeableConcept text element from existing codings.

Breaking change

The text element is populated only when there is an actual separate text in the source data, to better align with the FHIR specifications.
See the documentation on how to use text and display elements.

(H/e56568a6, H/1ad2da96)