Existing Wording: A patient encounter is further characterized by the setting in which it takes place. Amongst them are ambulatory, emergency, home health, inpatient and virtual encounters. An Encounter encompasses the lifecycle from pre-admission, the actual encounter (for ambulatory encounters), and admission, stay and discharge (for inpatient encounters). During the encounter the patient may move from practitioner to practitioner and location to location.

Because of the broad scope of Encounter, not all elements will be relevant in all settings. For this reason, admission/discharge related information is kept in a separate Hospitalization component within Encounter. The class element is used to distinguish between these settings, which will guide further validation and application of business rules.

There is also substantial variance from organization to organization (and between jurisdictions and countries) on which business events translate to the start of a new Encounter, or what level of aggregation is used for Encounter. For example, each single visit of a practitioner during a hospitalization may lead to a new instance of Encounter, but depending on local practice and the systems involved, it may well be that this is aggregated to a single instance for a whole hospitalization. Even more aggregation may occur where jurisdictions introduce groups of Encounters for financial or other reasons. Encounters can be aggregated or grouped under other Encounters using the partOf element. See below for examples.

Encounter instances may exist before the actual encounter takes place to convey pre-admission information, including using Encounters elements to reflect the planned start date or planned encounter locations. In this case the status element is set to 'planned'.

The Hospitalization component is intended to store the extended information relating to a hospitalization event. This is always expected to be the same period as the encounter itself, where this is different then another encounter is entered which captures this information which is a partOf this encounter instance

Proposed Wording: Add Encounter.hospitalization.period

Comment:

In DSTU1, there was an Encounter.hospitalization.period that was removed in DSTU2. The Encounter.period is not sufficient since an encounter could start in the emergency department and then progress into a hospitalization. Having a single Encounter.period doesn't indicate both the arrival date (in the ED) and also the date when the actual admission to inpatient took place.

The scope section is contradictory when it acknowledges "There is also substantial variance from organization to organization (and between jurisdictions and countries) on which business events translate to the start of a new Encounter, or what level of aggregation is used for Encounter. For example, each single visit of a practitioner during a hospitalization may lead to a new instance of Encounter, but depending on local practice and the systems involved, it may well be that this is aggregated to a single instance for a whole hospitalization" yet then follows by saying "The Hospitalization component is intended to store the extended information relating to a hospitalization event. This is always expected to be the same period as the encounter itself, where this is different then another encounter is entered which captures this information which is a partOf this encounter instance."

As a side note, the DAF Meaningful Use Data Element Mapping does need both an Encounter.period and Encounter.hospitalization.period

Additional URLs: http://hl7.org/fhir/2015May/encounter.html#5.18.1 http://hl7.org/fhir/2015May/encounter-daf.html#5.18.12.2