Next release

Fix possible crash or wrong list of institutions in patients search results

The recent change that added the list of institutitons to the Patient resource (in the custom extension) introduced a bug that could cause Patient searches either to crash (i.e. fail with error 500) or to return Patient resource listing more institutions than actually associated with the patient. Both issue applied only to non-merged endpoints - i.e. those returning a Patient resource for each underlying HIEBus patient record. Merged endpoints - i.e. returning a Patient resource for each HIEBus patient record group (that are the default) - did not present those issues.

(H/81619e4c, H/72bc710d)

Add contact type custom extension to the RelatedPerson resource

The RelatedPerson resource (DSTU2, STU3, R3) has a new CodeableConcept custom extension indicating the type of contact represented by the RelatedPerson resource - e.g. if it is the emergency contact for the patient.


Add access policies and patient institutions to FHIR output.

HIEBus has an internal 'access policy' concept associated to patients and encounters - controlling which users can see those resources and their associated data. Access policies are now mapped to security tags ( elements) in the Patient and Encounter resources (all version). The tags have a fixed system and a value that is the access policy name.

HIEBus has an internal 'institution' concept - roughly corresponding to a health system or hospital. Each patient can be associated with one or more institutions - roughly the health systems or hospitals where they received care. This list is now mapped to the Patient custom extension - each extension instance contains the code and (optional) name of the associated institution as a Coding element (with the code in code and the name in display).


Fix ExplanationOfBenefit.item.sequence so that it is never 0

In some cases pharmacy ExplanationOfBenefit.item.sequence was 0, that is not conformant - now fixed.

(H/c04b10e5, H/4d380d88)

Add the US Core birthsex extension to the Patient resource

It was not present in Patient resources returned by 'merged' endpoints - i.e. those returning a Patient resource for each HIEBus person - aka record group (as opposed to 'non merged' endpoints returning a Patient resource for each HIEBus patient).


Do not omit codings with same code but different systems in the coding extension

Coding elements can have custom extensions listing all the other corresponding codings known to the system (via mappings or because the underlying data supports more than one value), these extensions omitted codings that had the same code but different systems, this has now been fixed - all available codings are listed.


Accept more reference search parameters without a type modifier

Some reference search parameter can reference multiple different resource types - e.g. ExplanationOfBenefit.provider can reference Organization or Practitioner or PractitionerRole. In these cases it was necessary to specify a type modifier or use a URL when searching - e.g. [base]/ExplanationOfBenefit?provider=[id] failed, it was necessary to use [base]/ExplanationOfBenefit?provider:Practitioner=[id] or [base]/ExplanationOfBenefit?provider=Practitioner/[id].

This restriction no longer applies now to all search parameters for which there is only one possible implemented resource - so in the example above even if there are three possible reference resource types in the specification in our implementation only Practitioner references are possible, and so now a request like [base]/ExplanationOfBenefit?provider=[id] is accepted and [id] is automatically interpreted as a Practitioner id.


Fix crash when posting twice the same CarePlan with an associated Goal



Consumers 30.27.0, HIEBus 30.25.0

Fix search parameter and add Location.identifier search parameter

Breaking change

The search parameter was searching by the identifier, now fixed to actually search by name, and added a new identifier search parameter to search by identifier.



Consumers 30.26.1, HIEBus 30.24.0
Consumers 30.26.0, HIEBus 30.24.0

Different mapping of MedicationRequest and MedicationOrder dosageInstruction.text

Breaking change

dosageInstruction.text is populated from Order.Comment insted of Order.Text. Order.Text is now mapped instead of the root text element.

The change can be disabled by system administrators to maintain compatibility if needed.


Bug fix: avoid invalid types for ExplanationOfBenefit.supportingInfo.value[x]

In some circumstances supportingInfo.value[x] was populated with a Range data-type, that is not conformant. Now its possible types are restricted only to the valid ones: Booleans, quantity and string.


Added the DiagnosticReport.specimen, CarePlan.activity-reference and CarePlan.goal search parameters


Always populate ExplanationOfBenefit.supportingInfo.sequence and ExplanationOfBenefit.item.sequence

The sequence elements in some cases where not present, now they are always set with a valid (greater than zero) value.



Consumers 30.25.0, HIEBus 30.23.0
Consumers 30.24.0, HIEBus 30.23.0
Consumers 30.23.0, HIEBus 30.20.2

Always populate Patient.gender

In some circumstances Patient.gender was left empty, now in those cases it is always populated with unknown.



Consumers 30.22.0, HIEBus 30.19.0
Consumers 30.21.0, HIEBus 30.19.0

Bug fix: do not create a 'dummy' CarePlan every time a Goal is created


Bug fix: populate Observation.encounter for labs

Observation.encounter was not populated for labs even if the underlying data had an encounter reference, now fixed.



Consumers 30.20.4, HIEBus 30.17.0
Consumers 30.20.3, HIEBus 30.17.0
Consumers 30.20.2, HIEBus 30.17.0
Consumers 30.20.1, HIEBus 30.17.0
Consumers 30.20.0, HIEBus 30.17.0

Restrict attachment URLs in POSTed data

Breaking change

When POSTing attachments (e.g. DiagnosticReport.presentedForm) URLs (Attachment.url) are no longer accepted by default. Either use or you can ask the system administrators to enable the specific hosts or domains your URLs refer to.



Consumers 30.18.2, HIEBus 30.16.0

Bulk export: configurable content-encoding for ndjson files

By default the content-encoding header of the (gzipped) ndjson files produced by bulk export in AWS S3 is gzip, but this can cause issues like unwanted automatic decompression, so system administrator can now configure it to a different value.


Bulk export: performance improvements

System administrators can configure bulk export to use multiple threads, that can speed it up by factors of 2 or more.


Transaction fixes



Consumers 30.18.1, HIEBus 30.15.0
Consumers 30.18.0, HIEBus 30.15.0
Consumers 30.17.0, HIEBus 30.15.0
Consumers 30.16.5, HIEBus 30.14.1
Consumers 30.16.4, HIEBus 30.14.0
Consumers 30.16.3, HIEBus 30.14.0
Consumers 30.16.2, HIEBus 30.14.0
Consumers 30.16.1, HIEBus 30.14.0
Consumers 30.16.0, HIEBus 30.14.0

Better error messages for non allowed searches

When a user attempts to do a search that is not authorized due to search parameter requirements the resulting error message now includes an explanation of what to do to fix the search.



Consumers 30.15.0, HIEBus 30.13.0

Fixed the OID of the UNII ( coding system

It was set to 2.16.840.1.113883.6.13 instead of the correct 2.16.840.1.113883.4.9, so mapping from FHIR using the OID instead of the URL to identify it did not work correctly.


Bulk export automatically include the Location and Practitioner resource when no _type parameter is specified

Breaking change

Partially restore the behavior of before the H/5a411773change


US Core race and ethnicity extensions fix

In some circumstances the (required) text sub-extension was not populated even if there was a race or ethnicity - now it is always populated using the display of the existing race / ethnicity if no other value is available.


Fix the Immunization.manufacturer mapping


Output 'unknown' for Patient.gender if there are conflicting underlying values

Previously if there were conflicting values it was left empty, producing a resource that was not US Core conformant.


Fix use of custom extension when mapping from Coding bound to a value set (e.g. R4 Encounter.class)


Bulk export included resource types change

Breaking change

Previously referenced Practitioner and Location resources where always included in an export, even if they were not listed in the _type parameter - now if a _type parameter is specified it must list those resources for them to be included in the export. If _type is not specified then Location and Practitioner are now by default not included in the export.

Also, removed the includeAssociatedData _none special param value as Practitioner and Location include are now opt-in only.



Consumers 30.14.0, HIEBus 30.12.0
Consumers 30.13.0, HIEBus 30.12.0
Consumers 30.12.0, HIEBus 30.12.0

Allow multiple operations with the same request URL in the same transaction bundle

Previously POSTing a transaction bundle contained multiple operation with the same request URL (i.e. if the same operation was called multiple times) caused an error 500.


Add the _lastUpdated standard search parameter to the CareTeam, Device, Goal, Specimen, Task, ValueSet, Location, and AuditEvent resources


Put resource-level operation definition inside the individual resource description in the R4 CapabilityStatement

Previously all operation definition were at the top level that is not correct for R4.


Add the token introspection URL to the conformance / capability statement


Add the _lastUpdated standard search parameter to the DocumentReference resource

(H/18c63cd4, H/daf037e6)

Restore US Core MedicationRequest and Condition profiles

They were removed (and so those resources where never tagged as compliant) by mistake



Consumers 30.9.0, HIEBus 30.10.2
Consumers 30.8.2, HIEBus 30.10.2
Consumers 30.8.1, HIEBus 30.10.2
Consumers 30.8.0, HIEBus 30.10.2

Add a SMART-compliant token introspection endpoint

The endpoint is [base]/../api/tokenintrospection and it implements the SMART specifications. It requires authentication and can be used only by users that have been granted specific permission to access it.



Consumers 30.7.0, HIEBus 30.10.0
Consumers 30.6.2, HIEBus 30.10.0

Support ExplanationOfBenefit item-level denial reason and insurance indentifier

Adds new claim and insurance fields to the HIEBus internal data model and maps them to
ExplanationOfBenefit.item.adjudication:denialreason and to the ExplanationOfBenefit contained Organization.identifier


Populate ExplanationOfBenefit.related

Populate the ExplanationOfBenefit.related element from the OriginalClaimNumber internal custom claim property

Fix the extension ExplanationOfBenefit.item

It was not populated with the internal claim item custom properties, now fixed.


Add the token introspection URL to the published SMART configuration


Bulk export: optionally disable export of full history for group members that were added after the _since date.

Adds a custom parameter _disableGroupSinceNewMemberFullHistory that when set to truedisables the export of full history for group members that were added after the _since date. This is not what the specifications prescribe, but it can be usuful in some cirumstances.

No changes in behavior if no _since date is specified.



Consumers 30.6.0, HIEBus 30.7.0
Consumers 30.5.0, HIEBus 30.7.0

List searches and Subscription creations deadlocked


Unauthorized (401) responses now return a valid OperationOutcome body

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


Populate the scope property in refresh and backend authorization token responses

As per SMART specifications.


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.


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.


Always populate OperationOutcome.issue.code

Previously it was mostly missing, that is non-compliant


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

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


Fix to contain compartment URIs instead of resource types.

E.G. instead of just Patient.


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

As per the FHIR specifications.


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

As per the FHIR specifications.


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

As per the FHIR specifications.


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).


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).



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.


Improve CareTeam query performance

Adjusted internal filtering to make CareTeam searches perform more quickly



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.


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.


Forbid resource creation and update when in blinded mode

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


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.


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.


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.


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.



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.


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.


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
UBFacilityType N/A


Check references when POSTing data

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

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.


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.


Fix in R4 Condition.category

Breaking change

The R4 Condition.category coding system for health-concern is now (correctly) instead of
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.


Remove the internal 'FhirCodesXXXXX' codings from CodeableConcepts

Previously CodeableConcepts (especially those in the 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": "",
                    "valueCodeableConcept": {
                        "id": "gender2",
                        "coding": [
                                "system": "",
                                "code": "female",
                                "display": "Female",
                                "userSelected": true
                                "system": "",
                                "code": "F",
                                "display": "Female",
                                "userSelected": false
                                "system": "",
                                "code": "F",
                                "display": "F",
                                "userSelected": false
                                "system": "",
                                "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": "",
                    "valueCodeableConcept": {
                        "id": "gender2",
                        "coding": [
                                "system": "",
                                "code": "F",
                                "display": "Female",
                                "userSelected": false
                                "system": "",
                                "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 extension) or in a coding with a standard FHIR system URI (for CodeableConcept elements).


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)