Encounter - Revision history

Admin at 14:48, 9 April 2020

2020-04-09T14:48:29Z

@@ Line 20: / Line 20: @@
 | End date/time
 | The date or time that the encounter ended.
 |}

Admin at 14:30, 9 April 2020

2020-04-09T14:30:12Z

← Older revision		Revision as of 14:30, 9 April 2020
Line 13:		Line 13:
	\|-		\|-
	\| Encounter type		\| Encounter type
	\| The overall nature of the encounter mapped to the encounter type ontology		\| The overall nature of the encounter mapped to the encounter type ontology.
	\|-		\|-
	\|		\| Completion status
	\|		\| Concept: The status of the encounter when the event is sent. It can be completed, ongoing, or planned. In some systems, encounters are created before they start.
	\|-		\|-
	\|		\| End date/time
	\|		\| The date or time that the encounter ended.
	\|}		\|}

Admin at 14:27, 9 April 2020

2020-04-09T14:27:28Z

← Older revision		Revision as of 14:27, 9 April 2020
Line 5:		Line 5:
	Similarly, an accident and emergency attendance may have a subsidiary encounter for the initial assessment.		Similarly, an accident and emergency attendance may have a subsidiary encounter for the initial assessment.
	The additional properties relating to encounter types (such as method of admission, or critical care function type) are considered as non-core and are referenced via the information model concepts. Each property type has a concept and each value class is considered concept. Consequently these are not specified in this document but are available via the ontology.		The additional properties relating to encounter types (such as method of admission, or critical care function type) are considered as non-core and are referenced via the information model concepts. Each property type has a concept and each value class is considered concept. Consequently these are not specified in this document but are available via the ontology.

			{\| class="wikitable"
			! colspan="2" style="font-weight:bold; background-color:#c0c0c0;" \| Encounter: (inherits patient event)
			\|-
			\| style="font-weight:bold; background-color:#efefef;" \| Field
			\| style="font-weight:bold; background-color:#efefef;" \| Description
			\|-
			\| Encounter type
			\| The overall nature of the encounter mapped to the encounter type ontology
			\|-
			\|
			\|
			\|-
			\|
			\|
			\|}

Admin: Created page with "An encounter is an interaction between a patient and healthcare provider for the purpose of providing care, including assessment of care needs. Encounters are the mainstay of..."

2020-04-09T14:21:05Z

Created page with "An encounter is an interaction between a patient and healthcare provider for the purpose of providing care, including assessment of care needs. Encounters are the mainstay of..."

New page

An encounter is an interaction between a patient and healthcare provider for the purpose of providing care, including assessment of care needs. Encounters are the mainstay of care provision and the concept covers encounters in any care domain. For example, a GP consultation is an encounter and an in-patient stay is an encounter.
Encounters are often defined according to the publisher’s definition or even the nature of the IT system in use.
In the DDS, an encounter model is a superset of the different encounter models from the different domains and systems. The different patterns are differentiated by the use of Encounter types or archetypes.
For example, a hospital stay would be considered an encounter. The admission and discharge events are also considered an encounter, subsidiary to the hospital stay encounter.
Similarly, an accident and emergency attendance may have a subsidiary encounter for the initial assessment.
The additional properties relating to encounter types (such as method of admission, or critical care function type) are considered as non-core and are referenced via the information model concepts. Each property type has a concept and each value class is considered concept. Consequently these are not specified in this document but are available via the ontology.