Release 5 FHIR CI-Build

This page is part of the Continuous Integration Build of FHIR Specification (v5.0.0: R5 - STU ). This is the current published version in it's permanent home (it will always (will be available incorrect/inconsistent at this URL). For a full list of available versions, see times).
See the Directory of published versions . Page versions: R5 R4B R4 R3

Example OperationDefinition/Observation-lastn (Narrative)

Maturity Level : N/A
Responsible Owner: Orders and Observations Work Group Standards Status : Informative Compartments : Device , Encounter , Group , Patient , Practitioner , RelatedPerson

This is the narrative for the resource. See also the XML , JSON or Turtle format.

Note that this is the formal definition for the lastn operation as an OperationDefinition on Observation. See the Operation documentation

Generated Narrative: OperationDefinition Observation-lastn

URL: [base]/Observation/$lastn

Parameters

Use Name Scope Cardinality Type Binding Documentation
IN max 0..1 positiveInt

max is an optional input parameter to the lastn query operation. It is used to specify the maximum number of Observations to return from each group. For example for the query "Fetch the last 3 results for all vitals for a patient" max = 3.

OUT return 1..1 Bundle

The set of most recent N Observations that match the lastn query search criteria.

The key differences between this query operation and simply searching Observation using the combination of _count and _sort parameters are:

  • The lastn query returns only the last N resource grouped by code. Using the _count query method doesn't restrict the total matches so you may need to page through several "A" Observations before getting to Observation "B".
  • The server is responsible for grouping the observations by codes. This frees the client from needing to determine which codes she should ask for.

This operation cannot be performed on observations that the user is not authorized to see. It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.

 

 

Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.