Child pages
  • Encounter Resource
Skip to end of metadata
Go to start of metadata

This is the API documentation  for the OpenMRS FHIR Module ,Encounter Resource. 

Encounter Resource represents 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. For more information please refer http://hl7-fhir.github.io/encounter.html


Shown below is an example of how an OpenMRS Encounter objects would map to FHIR Encounter resource, as proposed by Grahame Grieve.

The left side of the relationship indicates the OpenMRS attribute, while the right indicated the FHIR resource mapping.

Encounter
Integer uuid :: n/a - goes in the URL e.g. [base]/Encounter/[encounterId]
Date encounterDatetime :: Encounter.period
Patient patient :: Encounter.subject
Integer patientId :: not mapped 
Set<EncounterProvider> encounterProviders :: Encounter.participant
Location location :: Encounter.location
EncounterType encounterType : not mapped
Set<Order> orders :: not mapped
Visit visit :: Encounter.partOf

 

Shown below is a sample FHIR Encounter Resource.

FHIR Encounter Resource
{
	resourceType: "Encounter",
	status: "finished",
	class: "inpatient",
	subject: {
		reference: "Patient/dd738d54-1691-11df-97a5-7038c432aabf",
		display: "Daisylene Ekeno(Identifier:1865TU-8)"
	},
	participant: [1]
		0:  {
			individual: {
				reference: "Practitioner/bf218490-1691-11df-97a5-7038c432aabf",
				display: "Super User(Identifier:admin)"
			}
		}
	period: {
		start: "2006-02-07T00:00:00",
		end: "2006-02-07T00:00:00"
	},
	location: [1]
		0:  {
			location: {
				reference: "Location/8d6c993e-c2cc-11de-8d13-0010c6dffd0f",
				display: "Inpatient Ward"
			},
			period: {
				start: "2006-02-07T00:00:00",
				end: "2006-02-07T00:00:00"
			}
		}
}

Available RESTful web services for the Encounter Resource supported by the API

GET Requests

Search
/ws/fhir/Encounter/{id}This request will fetch the Encounter for the given unique uuid. Here id represents, the logical resource id associated with the resource.
/ws/fhir/Encounter?_id={id}This request will fetch all Encounter using the given uuid value. This will return a List of Encounter as the response.Here _id parameter represents, the logical resource id associated with the resource.
/ws/fhir/Encounter?patient.identifier={identifier}This request will fetch Encounters per patient, identified by the given patient's identifier. This will return a List of Encounter ( 0..* Encounter ) as the response. Here the identifier parameter represents, patient identifier.
/ws/fhir/Encounter?patient.identifier={identifier}&part-of={uuid}Search encounters belongs to a patient specified in given identifier. If part-of= none then it will return all visits and encounters which doesn't have parent visit. If part-of specified it will return encounters of patient with matching visit uuid value specified in part-of field.
/ws/fhir/Encounter?_id={id}&part-of={uuid}Search encounters belongs to a of given id. If part-of= none then it will return only encounter. Otherwise it will return encounter both match id and the visit uuid.

POST Requests

Operations

/ws/fhir/Encounter/$everything

With body : <Parameters xmlns="http://hl7.org/fhir"/

This request will return bundle resource with resources that associate with encounter which associate with given encounter Id
/ws/fhir/Encounter

If the request body has a partOf attribute, an OpenMRS Encounter will be created with associated to the given Visit.

If the partOf attribute is not present , we will close all active Visits for that patient and create an new OpenMRS Visit.

DELETE Requests

Operations
/ws/fhir/Encounter/{id}This request will retire the Encounter with the given uuid. If the resource does not exist, a 404 is returned. If the OpenMRS API refuses to retire the encounter, the status code 405 is returned.

OpenMRS specific constrains

  • To implement FHIR Encounter we have used both OpenMRS Visit and OpenMRS Encounter resources. For every Encounter an OpenMRS Visit resource will be created. In a case where the patient is trasfered between different sections, a new OpenMRS Encounter will be created and that will be attached to the relevant OpenMRS Visit. 

 

 

  • No labels