Stream: argonaut
Topic: Date based searches
Jay Gustafson (Feb 26 2019 at 16:49):
Note on Searches based on a date or date range:*1
1. Allergies, Immunizations, Medications, Problems and Health Concerns, UDI, Smoking Status do not require a date range search since a system should return all relevant resources.
2. Date range search requirements are included in the Quick Start section for the following resources - Vital Signs, Laboratory Results, Goals, Procedures, and Assessment and Plan of Treatment.
2.1. Vital Signs (/Observation*2): Parameter name: “date”; ‘when taken’ must be included.
2.2. Laboratory Results (/DiagnosticReport*3): Parameter name: “date”; ‘when taken’ & ‘when reported’ must be included.
2.3. Laboratory Results (/Observation*4): Parameter name: “date”; ‘when taken’ should be included.
2.4. Goals (/Goal*5): Parameter name: “date”; no date required.
2.5. Procedures (/Procedure*6): Parameter name: “date”; ‘when performed’ must be included.
2.6. Assessment & Plan of Treatment (/CarePlan*7): Parameter name: “date”; no date required.
3. How to search by date*8 example: /Procedure?date=ge2010-01-01&date=le2011-12-31
*1 http://www.fhir.org/guides/argonaut/r2/
*2 http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-vitalsigns.html
*3 http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-diagnosticreport.html
*4 http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-observationresults.html
*5 http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-goal.html
*6 http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-procedure.html
*7 http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-careplan.html
*8 http://hl7.org/fhir/DSTU2/search.html#date
The major differences we’ve seen in EMRs' date searches have been with AllergyIntolerance, MedicationOrder, MedicationStatement and Condition. These are not required to have a date search by Argonaut (Note #1 above).
Concerns:
• On some FHIR resources, Argonaut specification is not clear on which date on the FHIR object the date parameter should map to. For example: on a CarePlan does the date parameter map to CarePlan.activity.detail.scheduledPeriod.start or CarePlan.period.start? Or on Diagnostic report, is it ‘when taken’ or ‘when reported’?
• On some FHIR resources that are supposed to be searchable by date, the Argonaut spec does not require a date be returned on the object at all (Note #2.4 & #2.6) or is optional (Note #2.3).
Questions:
• Are there any plans to clarify the Argonaut specs by specifying which date on a resource should be used for the date search?
• What is the best strategy for helping a patient get the latest records (since last get) so that overhead, in API use/bandwidth/duplicate checking, is reduced?
Thanks!
Eric Haas (Feb 26 2019 at 17:12):
• On some FHIR resources, Argonaut specification is not clear on which date on the FHIR object the date parameter should map to. For example: on a CarePlan does the date parameter map to CarePlan.activity.detail.scheduledPeriod.start or CarePlan.period.start? Or on Diagnostic report, is it ‘when taken’ or ‘when reported’?
the date parameter for a given resource is linked to an expression that specifies the element on which the search is based.
for example in CarePlan : "date date Time period plan covers CarePlan.period" http://hl7.org/fhir/DSTU2/careplan.html#search
Eric Haas (Feb 26 2019 at 17:13):
these are defined in the FHIR Specification or if Custom SearchParameters in the IG.
Eric Haas (Feb 26 2019 at 17:19):
On some FHIR resources that are supposed to be searchable by date, the Argonaut spec does not require a date be returned on the object at all (Note #2.4 & #2.6) or is optional (Note #2.3).
Yes there are some incongruities between the profiles and search requirements. You can create an issue here We will be working on a FHIR R4 version of Argonaut and will bring this up then.
Eric Haas (Feb 26 2019 at 17:21):
• What is the best strategy for helping a patient get the latest records (since last get) so that overhead, in API use/bandwidth/duplicate checking, is reduced?
look at the $lastN operation in the FHIR Specification? is that the kind of thing you are looking for?
Michele Mottini (Feb 26 2019 at 17:53):
What is the best strategy for helping a patient get the latest records (since last get) so that overhead, in API use/bandwidth/duplicate checking, is reduced?
Search by _lastUpdated if supported by the server
Brian Postlethwaite (Feb 26 2019 at 23:56):
(with the caveat that you'll miss any deletions, but these should be minimal in clinical space, and should be using status values that nullify/cancel content instead of actually deleting the content)
Last updated: Apr 12 2022 at 19:14 UTC
