Skip to main content

R4 Encounter

The Encounter resource describes an "interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient." (HL7 FHIR R4 Encounter)

Supported Profiles

This API supports the following FHIR profiles:

Operations

The General Purpose FHIR R4 Patient resource supports the following standard operations. However, support varies by the targeted CareRecord or solution.

CareRecord / SolutionCreateReadUpdateSearch
GEHRIMED-Yes-Yes
myAvatarYesYesYesYes
myEvolv-Yes-Yes
myUnity-Yes-Yes
Referral Manager----
info

Not all Netsmart solutions support Encounter search. See supported operations table above and consult your target solution's documentation for more information.

This resource supports a combination of standard and custom search parameters in addition to the common parameters.

Standard Parameters

NameTypeDescription
datedateA date within the period the Encounter lasted
episode-of-carereferenceEpisode(s) of care that this encounter should be recorded against
patientreferenceREQUIRED The patient or group present at the encounter
statustokenarrived

Custom Parameters

NameTypeDescription
enddateDeprecated. Use date parameter with le prefix instead.
startdateDeprecated. Use date parameter with ge prefix instead.

Search Examples

The POST method is recommended as it keeps health information out of the URL.

Search Program Admissions by Patient
curl -X POST https://fhir.netsmartcloud.com/v4/Encounter/_search \
-H "Authorization: {Bearer Token}" \
-H "Accept: application/fhir+json" \
-H "Content-Type: application/x-form-urlencoded" \
-d "patient=Patient/345" \
-d "status=arrived"
Search Program Discharges by Patient
curl -X POST https://fhir.netsmartcloud.com/v4/Patient/_search \
-H "Authorization: {Bearer Token}" \
-H "Accept: application/fhir+json" \
-H "Content-Type: application/x-form-urlencoded" \
-d "patient=Patient/345" \
-d "status=finished"

Special Considerations

The General Purpose API FHIR R4 Encounter resource has the following considerations in addition to the shared special considerations.

Status does not indicate Status

The HL7 FHIR Encounter concept encompasses multiple existing Netsmart concepts: Program Admission, Program Discharge, and Visit. This API has associated the Encounter.status with the following concepts to support ProviderConnect Enterprise workflows.

HL7 FHIR StatusNetsmart ConceptID Prefix
arrivedProgram Admissionarrived_
finishedProgram Dischargefinished_

You would use the arrived status to see all admissions for a patient and then review the Encounter.period to determine whether the admission is still active or if the patient has been discharged. An additional search using the finished status will return additional discharge related content for those admission encounters.

Visit Encounters are not supported

Due to the Status exception described above this API is unable to support visit-related encounters.

Program Discharge Encounters must include the Program Admission Identifier

Program Discharge encounters provide additional content related to the discharge of an admission. This means we need to associate the Program Discharge encounter with the originating Program Admission encounter. This API supports this with an Identifier.

{
"resourceType": "Encounter",
"id": "finished_91||6546.61",
"identifier": [
{
"use": "old",
"system": "http://ntst.com/fhir/related-admission",
"value": "arrived_3||6386.71"
}
],
"status": "finished",
// additional Encounter content
}

myAvatar Encounter IDs are Not FHIR Conformant

As shown in previous examples, the IDs assigned to myAvatar Program Admissions and Discharges use || delimiters which are not allowed per the FHIR spec. This API allows them through however in newer APIs we will be replacing the || with -- to bring the IDs into conformance. This also applies to the ID prefix delimiter used on the API which in newer APIs replace _ with ...

If this is an issue with your FHIR Client then please consider using our Certified and Regulated APIs instead.