(C/c8ce7078)
In some cases it was output as a timingDateTime, that is non-compliant - now fixed to always use either timingPeriod or timingDate.
(H/d6d40bc7)
The error message was in issue.code and the issue type was in issue.details.text - now fixed swapping them.
(H/38ef4624)
When searching Patients using _summary or _elements so that Patient.gender was not requested (subsetted resource) it was returned always as unknown (even if the underlying Patient did have a different value). Now fixed not populating Patient.gender when it is not requested.
(H/fd75198a)
The recent change that added the list of institutitons to the Patient resource (in the http://careevolution.com/fhirextensions#patientInstitutions 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)
The RelatedPerson resource (DSTU2, STU3, R3) has a new CodeableConcept custom extension http://careevolution.com/fhirextensions#patientAssociatedParty-contactType indicating the type of contact represented by the RelatedPerson resource - e.g. if it is the emergency contact for the patient.
(H/bf2f8144)
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 (meta.security elements) in the Patient and Encounter resources (all version). The tags have a fixed system http://careevolution.com/accesspolicyname 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 http://careevolution.com/fhirextensions#patientInstitutions - 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).
(H/a84550bb)
In some cases pharmacy ExplanationOfBenefit.item.sequence was 0, that is not conformant - now fixed.
(H/c04b10e5, H/4d380d88)
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).
(H/ba29b636)
Coding elements can have custom extensions http://careevolution.com/fhirextensions#coding 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.
(H/d6653f0b)
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.
(H/dff6ac7a)
(H/e1fcc8f4)
Consumers 30.27.0, HIEBus 30.25.0
Breaking change
The Location.name 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.
(H/7ec16607)
Consumers 30.26.1, HIEBus 30.24.0
Consumers 30.26.0, HIEBus 30.24.0
dosageInstruction.textBreaking 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.
(H/84229d25)
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.
(H/9432ec74)
DiagnosticReport.specimen, CarePlan.activity-reference and CarePlan.goal search parameters(H/108c8ba6)
ExplanationOfBenefit.supportingInfo.sequence and ExplanationOfBenefit.item.sequenceThe sequence elements in some cases where not present, now they are always set with a valid (greater than zero) value.
(H/672b1ddb)
Consumers 30.25.0, HIEBus 30.23.0
Consumers 30.24.0, HIEBus 30.23.0
Consumers 30.23.0, HIEBus 30.20.2
Patient.genderIn some circumstances Patient.gender was left empty, now in those cases it is always populated with unknown.
(H/e4e32b1b)
Consumers 30.22.0, HIEBus 30.19.0
Consumers 30.21.0, HIEBus 30.19.0
(H/b4ce8ab2)
Observation.encounter for labsObservation.encounter was not populated for labs even if the underlying data had an encounter reference, now fixed.
(H/f3543a88)
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
Breaking change
When POSTing attachments (e.g. DiagnosticReport.presentedForm) URLs (Attachment.url) are no longer accepted by default. Either use Attachment.data or you can ask the system administrators to enable the specific hosts or domains your URLs refer to.
(H/6f6ae5dc)
Consumers 30.18.2, HIEBus 30.16.0
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.
(H/c3dbe303)
System administrators can configure bulk export to use multiple threads, that can speed it up by factors of 2 or more.
(H/cf77b039)
Resource reads (e.g. GET Patient/[id]) are now supported inside transactions
Multiple searches with the exact same request URL in a transaction caused a crash, now result in a error 400 with an explanation
Failures in searches and operations within a transaction resulted in a failure of the whole transaction, now they are reported as errors just for that individual transaction entry
Transaction searches and operations did not work with absolute request URLs
(H/d972d6e9)
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
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.
(H/f46dcaf4)
Consumers 30.15.0, HIEBus 30.13.0
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.
(H/b2a8be8f)
Breaking change
Partially restore the behavior of before the H/5a411773change
(H/d9fc5dff)
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.
(H/1b93ce0b)
When mapping to FHIR populate Immunization.manufacturer.display with the underlying display value and Immunization.manufacturer.identifier.value with the underlying code
Keep the mapping to a contained Organization resource for backward compatibility, populating also Organization.identifier.value with the underlying code
When mapping from FHIR use first Immunization.manufacturer.display and Immunization.manufacturer.identifier.code, look at the referenced contained organization only if Immunization.manufacturer.display is empty
When mapping from FHIR create the manufacturer term in the default term namespace - not to 'pollute' the CareEvolution namespace
(H/175d5a31)
Previously if there were conflicting values it was left empty, producing a resource that was not US Core conformant.
(H/4e9d73d8)
Consider only our own custom http://careevolution.com/fhirextensions#coding extension and not other extensions with a coding value
Use the extension userSelected value (if present) also when there is no main code
(H/db40ab63)
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.
(H/5a411773)
Consumers 30.14.0, HIEBus 30.12.0
Consumers 30.13.0, HIEBus 30.12.0
Consumers 30.12.0, HIEBus 30.12.0
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.
(H/1b1c4f54)
_lastUpdated standard search parameter to the CareTeam, Device, Goal, Specimen, Task, ValueSet, Location, and AuditEvent resources(H/f2717a37)
Previously all operation definition were at the top level that is not correct for R4.
(H/db7e4a10)
(H/732d4b0b)
_lastUpdated standard search parameter to the DocumentReference resource(H/18c63cd4, H/daf037e6)
They were removed (and so those resources where never tagged as compliant) by mistake
(H/c6d17608)
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
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.
(C/9d9505cf)
Consumers 30.7.0, HIEBus 30.10.0
Consumers 30.6.2, HIEBus 30.10.0
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
(H/70be298c)
ExplanationOfBenefit.relatedPopulate the ExplanationOfBenefit.related element from the OriginalClaimNumber internal custom claim property
http://careevolution.com/fhirextensions#properties extension ExplanationOfBenefit.itemIt was not populated with the internal claim item custom properties, now fixed.
(H/48b7261d)
(H/399d233a)
_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.
(H/6b03399b)
Consumers 30.6.0, HIEBus 30.7.0
Consumers 30.5.0, HIEBus 30.7.0
(C/26e6556f)
Previously they returned a custom (non-FHIR) JSON or XML response body.
(C/4fc647dd)
scope property in refresh and backend authorization token responsesAs per SMART specifications.
(C/ac4859f6)
Previously any user that had read access to the Patient resource could also execute bulk exports, now this permission can be denied.
(H/cecc5aa1)
Previously the content encoding was a non-standard x-gzip, now it is the standard gzip.
(H/792ba36f)
OperationOutcome.issue.codePreviously it was mostly missing, that is non-compliant
(H/5b367c8e)
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)
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)
_source search parameter type to be URI instead of tokenAs per the FHIR specifications.
(H/a62efc87)
agent search parameter type to be reference instead of tokenAs per the FHIR specifications.
(H/06507682)
topic search parameter type to be token instead of stringAs per the FHIR specifications.
(H/88628545)
Some Patient searches and searches including non-conformant resources on endpoints configured to suppress non-conformant resources resulted in crashes (error 500).
(H/27051f78)
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)
Consumers 30.4.0, HIEBus 30.6.1
Consumers 30.3.0, HIEBus 30.6.0
. . . for patients that did not have an associated user that last modified it.
(H/33472c4a)
Adjusted internal filtering to make CareTeam searches perform more quickly
(H/ebaadb57)
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
This allow endpoints to revert to the old behavior where CodeableConcept.text was always populated.
(H/07b839d6)
Meta.source and the corresponding DSTU2/STU3 extensionThis allow endpoints to revert to the old behavior where Meta.source or the corresponding extension (for DSTU2/STU3) was not populated.
(H/b4af7db0)
It caused weird errors when updating certain resources (notably Patient)
(H/56f0f079)
fullUrlNow 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)
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)
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)
If-None-Exist on create, update, or in a transactionOur server does not support conditional create (yet), so it is better to fail instead of just ignoring that header / element.
(H/42871b25)
Consumers 30.1.0, HIEBus 30.2.0
Consumers 30.0.0, HIEBus 30.2.0
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)
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 requiredThe 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.
CarePlan.activity.detail.status defaults to in-progressPreviously it was not populated if there was no available value.
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.
Patient.gender is set to unknown if there is no available valuePreviously it was not populated in that case.
Procedure.status is set to completed if there is no available valuePreviously it was not populated in that case.
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)
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)
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.
(H/ab0b619e)
Previously such data - typically coming from wearable dvices like FitBit - was not visible via FHIR at all.
(H/f217f7d5)
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)
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)
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)