Smile CDR v2024.05.PRE
On this page:

6.14.1Reading Data

 

This section contains information about methods for reading data from the CDR.

6.14.2Diff Operation

 

The $diff operation can be used to generate a differential between two versions of a resource, or even two different resources of the same type.

Differentials generated by this operation are in FHIR Patch format.

In generated differentials, where a value has changed (i.e. a replace operation), an additional part value will be present on the given operation called previousValue. This part shows the value as it was in the from version of the resource.

6.14.3Diff Instance

 

When the $diff operation is invoked at the instance level (meaning it is invoked on a specific resource ID), it will compare two versions of the given resource.

6.14.3.1Parameters

  • fromVersion=[versionId]: (optional) If specified, compare using this version as the source. If not specified, the immediately previous version will be compared.
  • includeMeta=true: (optional) If specified, changes to Resource.meta will be included in the diff. This element is omitted by default.

To invoke:

GET http://fhir.example.com/baseR4/Patient/123/$diff

The server will produce a response resembling the following:

{
  "resourceType": "Parameters",
  "parameter": [ {
    "name": "operation",
    "part": [ {
      "name": "type",
      "valueCode": "replace"
    }, {
      "name": "path",
      "valueString": "Patient.name.family"
    }, {
      "name": "previousValue",
      "valueId": "Smyth"
    }, {
      "name": "value",
      "valueId": "SmithB"
    } ]
  } ]
}

6.14.4Diff Type

 

When the $diff operation is invoked at the type level (meaning it is invoked on a resource type but not on an individual instance), it will compare two different resources of the same type.

6.14.4.1Parameters

  • from=[reference]: Specifies the source of the comparison. The value must include a resource type and a resource ID, and can optionally include a version, e.g. Patient/123 or Patient/123/_history/2.
  • to=[reference]: Specifies the target of the comparison. The value must include a resource type and a resource ID, and can optionally include a version, e.g. Patient/123 or Patient/123/_history/2.
  • includeMeta=true: (optional) If specified, changes to Resource.meta will be included in the diff. This element is omitted by default.

To invoke:

GET http://fhir.example.com/baseR4/$diff?from=Patient/1&to=Patient/2

The server will produce a response resembling the following:

{
  "resourceType": "Parameters",
  "parameter": [ {
    "name": "operation",
    "part": [ {
      "name": "type",
      "valueCode": "replace"
    }, {
      "name": "path",
      "valueString": "Patient.id"
    }, {
      "name": "previousValue",
      "valueId": "1"
    }, {
      "name": "value",
      "valueId": "2"
    } ]
  } ]
}

6.14.5$everything operation

 

The HAPI-FHIR server supports the Patient/$everything operation and accepts all the IN parameters defined in the documentation. Additionally, Smile CDR allows you to provide an _id parameter, in order to filter the set of patients you wish to get everything for. The following requests are all equivalent, and these example queries fetch everything for Patient/1, Patient/2 and Patient/3:

  1. Using a GET.
GET [base]/Patient/$everything?_id=1,2,3
  1. Using a GET with alternate _id parameter style.
GET [base]/Patient/$everything?_id=1&_id=2&_id=3
  1. Using a POST.
POST [base]/Patient/$everything
{
   "resourceType": "Parameters",
   "parameter": [ {
      "name": "_id",
      "valueString": "1"
   }, {
      "name": "_id",
      "valueString": "2"
   },{
      "name": "_id",
      "valueString": "3"
   }
   ]
}
  1. Making 3 individual instance-level $everything operation calls.
GET [base]/Patient/1/$everything
GET [base]/Patient/2/$everything
GET [base]/Patient/3/$everything

Below is a table containing all the possible resources the $everything command can return:

Resource List
Account
AdverseEvent
AllergyIntolerance
Appointment
AppointmentResponse
AuditEvent
Basic
BodyStructure
CarePlan
CareTeam
ChargeItem
Claim
ClaimResponse
ClinicalImpression
Communication
CommunicationRequest
Composition
Condition
Consent
Coverage
CoverageEligibilityRequest
CoverageEligibilityResponse
DetectedIssue
Device
DeviceRequest
DeviceUseStatement
DiagnosticReport
DocumentManifest
DocumentReference
Encounter
EnrollmentRequest
EpisodeOfCare
ExplanationOfBenefit
FamilyMemberHistory
Flag
Goal
Group
ImagingStudy
Immunization
ImmunizationEvaluation
ImmunizationRecommendation
Invoice
List
MeasureReport
Media
Medication
MedicationAdministration
MedicationDispense
MedicationRequest
MedicationStatement
MolecularSequence
NutritionOrder
Observation
Organization
Person
Practitioner
Procedure
Provenance
QuestionnaireResponse
RelatedPerson
RequestGroup
ResearchSubject
RiskAssessment
Schedule
ServiceRequest
Specimen
SupplyDelivery
SupplyRequest
VisionPrescription