© 2021-2023 Opala. All Rights Reserved.
Version 1.1.1.0
Most observations are simple name/value pair assertions with some metadata, but some observations group other observations together logically, or even are multi-component observations. Observations are used to support diagnosis, monitor progress, determine baselines and patterns and even capture demographic characteristics.
Many observations have relationships to other observations and should to be grouped together. The following structures have been defined to do this:
DiagnosticReport.resultObservation.component, Observation.hasMember and Observation.derivedFrom.Because the idea of what to group together is often highly contextual and based upon the end-user's point of view, the choice of which structure to use is driven by jurisdiction, organizational practice, and context.
The sections below provides guidance around when to use which structure.
DiagnosticReport relates directly to an order (ServiceRequest). The DiagnosticReport.code names the panel and serves as the grouping element (traditionally referred to as a "panel" or "battery" by laboratories).
The DiagnosticReport.result element references the individual observations. Several examples 
demonstrate observation grouping using DiagnosticReport as the grouping structure.
This element is used for any supporting result that cannot reasonably be interpreted and used outside the scope of the Observation resource of which it is a component.
Component observations may make up the separate and individual parts of the observation, or they may provide qualifying information to Observation.code and may only be able to be understood in relation to the Observation.code. Therefore, all code-value and component.code-component.value pairs need to be taken into account to correctly understand the meaning of the observation.
Note: Components should only be used when there is only one method, one observation, one performer, one device, and one time.
Any observations that are clinically relevant outside the context of being a component of another observation should be represented by separate Observation resources.
Observation.hasMember and Observation.derivedFrom, and the core extensions Observation-sequelTo and Observation-replaces , are used for any supporting result that can be interpreted and used on its own, and has one or more different values for method, observation, performer, device, time, and/or error.
Use Postman to test Opala's Patient Access API by querying the API and returning the results. The Opala Collection is a group of API requests that are already saved in the Postman app and arranged in folders. You can access the Opala's Patient Access Sandbox and, if you have the correct credentials, the production environment as well. For more information see Setting Up Postman in this documentation set.
The Observation resource encompasses measurements and simple assertions made about a patient, device, or other subject.
All Observations for a Specific Patient
To search for all observations for the specified patient:
[baseurl]/Observation?patient=[id][baseurl]/Observation?subject=Patient/[id]
All Patients with a Specific Observation Code
To retrieve all the patients who have an Observation resource with a specific value for Observation.code:
[baseurl]/Patient?_has:Observation:patient:code=http://loinc.org|[LOINC Code]
All Observations and Patients with a Specific Code
To retrieve the instances of the Observation resource along with the Patient:
[baseurl]/Observation?code=http://loinc.org|[LOINC Code]&_include=Observation:patient
resource. for the elements in the Observation resource for the Observation resource for the Observation resource