Structure Definition: Encounter Profile
Canonical URL: https://signalbhn.org/fhir/StructureDefinition/encounter
Simplifier project page: Signal Encounter
Derived from: US Core Encounter STU6 (R4)
Module: Clinical Categorization Module
Formal profile content
| Encounter | I | Encounter | There are no (further) constraints on this element Element IdEncounter An interaction during which services are provided to the patient Alternate namesVisit Definition- -
| |
| identifier | S Σ | 0..* | Identifier | There are no (further) constraints on this element Element IdEncounter.identifier (USCDI) Identifier(s) by which this encounter is known DefinitionIdentifier(s) by which this encounter is known.
|
| use | Σ ?! | 0..1 | codeBinding | There are no (further) constraints on this element Element IdEncounter.identifier.use usual | official | temp | secondary | old (If known) DefinitionThe purpose of this identifier. Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers. Applications can assume that an identifier is permanent unless it explicitly says that it is temporary. Identifies the purpose for this identifier, if known . IdentifierUse (required)Constraints
|
| type | Σ | 0..1 | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.identifier.type Description of identifier DefinitionA coded type for the identifier that can be used to determine which identifier to use for a specific purpose. Allows users to make use of identifiers when the identifier system is not known. This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type. A coded type for an identifier that can be used to determine which identifier to use for a specific purpose. Identifier Type Codes (extensible)Constraints
|
| system | S Σ | 1..1 | uri | There are no (further) constraints on this element Element IdEncounter.identifier.system (USCDI) The namespace for the identifier value DefinitionEstablishes the namespace for the value - that is, a URL that describes a set values that are unique. There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers. Identifier.system is always case sensitive.
General http://www.acme.com/identifiers/patient Mappings
|
| value | S Σ | 1..1 | string | There are no (further) constraints on this element Element IdEncounter.identifier.value (USCDI) The value that is unique DefinitionThe portion of the identifier typically relevant to the user and which is unique within the context of the system. If the value is a full URI, then the system SHALL be urn:ietf:rfc:3986. The value's primary purpose is computational mapping. As a result, it may be normalized for comparison purposes (e.g. removing non-significant whitespace, dashes, etc.) A value formatted for human display can be conveyed using the Rendered Value extension. Identifier.value is to be treated as case sensitive unless knowledge of the Identifier.system allows the processer to be confident that non-case-sensitive processing is safe.
General 123456 Mappings
|
| period | Σ I | 0..1 | Period | There are no (further) constraints on this element Element IdEncounter.identifier.period Time period when id is/was valid for use DefinitionTime period during which identifier is/was valid for use. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| assigner | Σ I | 0..1 | Reference(Organization) | There are no (further) constraints on this element Element IdEncounter.identifier.assigner Organization that issued id (may be just text) DefinitionOrganization that issued/manages the identifier. The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization.
|
| status | S Σ ?! | 1..1 | codeBinding | There are no (further) constraints on this element Element IdEncounter.status (USCDI) planned | arrived | triaged | in-progress | onleave | finished | cancelled + Definitionplanned | arrived | triaged | in-progress | onleave | finished | cancelled +. Note that internal business rules will determine the appropriate transitions that may occur between statuses (and also classes). Current state of the encounter. EncounterStatus (required)Constraints
|
| statusHistory | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.statusHistory List of past encounter statuses DefinitionThe status history permits the encounter resource to contain the status history without needing to read through the historical versions of the resource, or even have the server store them. The current status is always found in the current version of the resource, not the status history.
| |
| status | 1..1 | codeBinding | There are no (further) constraints on this element Element IdEncounter.statusHistory.status planned | arrived | triaged | in-progress | onleave | finished | cancelled + Definitionplanned | arrived | triaged | in-progress | onleave | finished | cancelled +. Note that FHIR strings SHALL NOT exceed 1MB in size Current state of the encounter. EncounterStatus (required)Constraints
| |
| period | I | 1..1 | Period | There are no (further) constraints on this element Element IdEncounter.statusHistory.period The time that the episode was in the specified status DefinitionThe time that the episode was in the specified status. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| class | S Σ | 1..1 | CodingBinding | There are no (further) constraints on this element Element IdEncounter.class (USCDI) Classification of patient encounter DefinitionConcepts representing classification of patient encounter such as ambulatory (outpatient), inpatient, emergency, home health or others due to local variations. Codes may be defined very casually in enumerations or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Classification of the encounter. EncounterclassHistory-class (extensible)Constraints
|
| classHistory | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.classHistory List of past encounter classes DefinitionThe class history permits the tracking of the encounters transitions without needing to go through the resource history. This would be used for a case where an admission starts of as an emergency encounter, then transitions into an inpatient scenario. Doing this and not restarting a new encounter ensures that any lab/diagnostic results can more easily follow the patient and not require re-processing and not get lost or cancelled during a kind of discharge from emergency to inpatient.
| |
| class | 1..1 | CodingBinding | There are no (further) constraints on this element Element IdEncounter.classHistory.class inpatient | outpatient | ambulatory | emergency + Definitioninpatient | outpatient | ambulatory | emergency +. Codes may be defined very casually in enumerations or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Classification of the encounter. EncounterclassHistory-class (extensible)Constraints
| |
| period | I | 1..1 | Period | There are no (further) constraints on this element Element IdEncounter.classHistory.period The time that the episode was in the specified class DefinitionThe time that the episode was in the specified class. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| type | S Σ | 1..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.type (USCDI) Specific type of encounter DefinitionSpecific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation). Since there are many ways to further classify encounters, this element is 0..*. Valueset to describe the Encounter Type USCoreEncounterType (extensible)Constraints
|
| serviceType | Σ | 0..1 | CodeableConceptBinding | Element IdEncounter.serviceType Specific type of service DefinitionBroad categorization of the service that is to be provided (e.g. cardiology). Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Broad categorization of the service that is to be provided. SignalHealthcareServiceType (required)Constraints
|
| priority | 0..1 | CodeableConcept | There are no (further) constraints on this element Element IdEncounter.priority Indicates the urgency of the encounter DefinitionIndicates the urgency of the encounter. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Indicates the urgency of the encounter. encounter-priority (example)Constraints
| |
| subject | S Σ I | 1..1 | Reference(US Core Patient Profile) | There are no (further) constraints on this element Element IdEncounter.subject (USCDI) The patient or group present at the encounter Alternate namespatient DefinitionThe patient or group present at the encounter. While the encounter is always about the patient, the patient might not actually be known in all contexts of use, and there may be a group of patients that could be anonymous (such as in a group therapy for Alcoholics Anonymous - where the recording of the encounter could be used for billing on the number of people/staff and not important to the context of the specific patients) or alternately in veterinary care a herd of sheep receiving treatment (where the animals are not individually tracked). Reference(US Core Patient Profile) Constraints
|
| episodeOfCare | Σ I | 0..* | Reference(EpisodeOfCare) | There are no (further) constraints on this element Element IdEncounter.episodeOfCare Episode(s) of care that this encounter should be recorded against DefinitionWhere a specific encounter should be classified as a part of a specific episode(s) of care this field should be used. This association can facilitate grouping of related encounters together for a specific purpose, such as government reporting, issue tracking, association via a common problem. The association is recorded on the encounter as these are typically created after the episode of care and grouped on entry rather than editing the episode of care to append another encounter to it (the episode of care could span years). References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| basedOn | I | 0..* | Reference(ServiceRequest) | There are no (further) constraints on this element Element IdEncounter.basedOn The ServiceRequest that initiated this encounter Alternate namesincomingReferral DefinitionThe request this encounter satisfies (e.g. incoming referral or procedure request). References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| participant | S Σ | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.participant (USCDI) List of participants involved in the encounter DefinitionThe list of people responsible for providing the service.
|
| type | S Σ | 0..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.participant.type (USCDI) Role of participant in encounter DefinitionRole of participant in encounter. The participant type indicates how an individual participates in an encounter. It includes non-practitioner participants, and for practitioners this is to describe the action type in the context of this encounter (e.g. Admitting Dr, Attending Dr, Translator, Consulting Dr). This is different to the practitioner roles which are functional roles, derived from terms of employment, education, licensing, etc. Role of participant in encounter. ParticipantType (extensible)Constraints
|
| period | S I | 0..1 | Period | There are no (further) constraints on this element Element IdEncounter.participant.period (USCDI) Period of time during the encounter that the participant participated DefinitionThe period of time that the specified participant participated in the encounter. These can overlap or be sub-sets of the overall encounter's period. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| individual | S Σ I | 0..1 | Reference(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core RelatedPerson Profile) | There are no (further) constraints on this element Element IdEncounter.participant.individual (USCDI) Persons involved in the encounter other than the patient DefinitionPersons involved in the encounter other than the patient. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core RelatedPerson Profile) Constraints
|
| appointment | Σ I | 0..* | Reference(Appointment) | There are no (further) constraints on this element Element IdEncounter.appointment The appointment that scheduled this encounter DefinitionThe appointment that scheduled this encounter. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| period | S I | 0..1 | Period | There are no (further) constraints on this element Element IdEncounter.period (USCDI) The start and end time of the encounter DefinitionThe start and end time of the encounter. If not (yet) known, the end of the Period may be omitted.
|
| length | I | 0..1 | Duration | There are no (further) constraints on this element Element IdEncounter.length Quantity of time the encounter lasted (less time absent) DefinitionQuantity of time the encounter lasted. This excludes the time during leaves of absence. May differ from the time the Encounter.period lasted because of leave of absence.
|
| reasonCode | S Σ | 0..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.reasonCode (USCDI) Coded reason the encounter takes place Alternate namesIndication, Admission diagnosis DefinitionReason the encounter takes place, expressed as a code. For admissions, this can be used for a coded admission diagnosis. For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis). Reason why the encounter takes place. EncounterReasonCodes (preferred)Constraints
|
| reasonReference | S Σ I | 0..* | Reference(US Core Condition Problems and Health Concerns Profile | US Core Condition Encounter Diagnosis Profile | US Core Procedure Profile | Observation | ImmunizationRecommendation) | There are no (further) constraints on this element Element IdEncounter.reasonReference (USCDI) Reason the encounter takes place (reference) Alternate namesIndication, Admission diagnosis DefinitionReason the encounter takes place, expressed as a code. For admissions, this can be used for a coded admission diagnosis. For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis). Reference(US Core Condition Problems and Health Concerns Profile | US Core Condition Encounter Diagnosis Profile | US Core Procedure Profile | Observation | ImmunizationRecommendation) Constraints
|
| diagnosis | Σ | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.diagnosis The list of diagnosis relevant to this encounter DefinitionThe list of diagnosis relevant to this encounter.
|
| condition | Σ I | 1..1 | Reference(Condition | Procedure) | There are no (further) constraints on this element Element IdEncounter.diagnosis.condition The diagnosis or procedure relevant to the encounter Alternate namesAdmission diagnosis, discharge diagnosis, indication DefinitionReason the encounter takes place, as specified using information from another resource. For admissions, this is the admission diagnosis. The indication will typically be a Condition (with other resources referenced in the evidence.detail), or a Procedure. For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis). Reference(Condition | Procedure) Constraints
|
| use | 0..1 | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.diagnosis.use Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …) DefinitionRole that this diagnosis has within the encounter (e.g. admission, billing, discharge …). Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. The type of diagnosis this condition represents. DiagnosisRole (preferred)Constraints
| |
| rank | 0..1 | positiveInt | There are no (further) constraints on this element Element IdEncounter.diagnosis.rank Ranking of the diagnosis (for each role type) DefinitionRanking of the diagnosis (for each role type). 32 bit number; for values larger than this, use decimal
| |
| account | I | 0..* | Reference(Account) | There are no (further) constraints on this element Element IdEncounter.account The set of accounts that may be used for billing for this Encounter DefinitionThe set of accounts that may be used for billing for this Encounter. The billing system may choose to allocate billable items associated with the Encounter to different referenced Accounts based on internal business rules.
|
| hospitalization | S | 0..1 | BackboneElement | There are no (further) constraints on this element Element IdEncounter.hospitalization (USCDI) Details about the admission to a healthcare service DefinitionDetails about the admission to a healthcare service. An Encounter may cover more than just the inpatient stay. Contexts such as outpatients, community clinics, and aged care facilities are also included. The duration recorded in the period of this encounter covers the entire scope of this hospitalization record.
|
| preAdmissionIdentifier | 0..1 | Identifier | There are no (further) constraints on this element Element IdEncounter.hospitalization.preAdmissionIdentifier Pre-admission identifier DefinitionPre-admission identifier.
| |
| origin | I | 0..1 | Reference(Location | Organization) | There are no (further) constraints on this element Element IdEncounter.hospitalization.origin The location/organization from which the patient came before admission DefinitionThe location/organization from which the patient came before admission. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Location | Organization) Constraints
|
| admitSource | 0..1 | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.hospitalization.admitSource From where patient was admitted (physician referral, transfer) DefinitionFrom where patient was admitted (physician referral, transfer). Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. From where the patient was admitted. AdmitSource (preferred)Constraints
| |
| reAdmission | 0..1 | CodeableConcept | There are no (further) constraints on this element Element IdEncounter.hospitalization.reAdmission The type of hospital re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission DefinitionWhether this hospitalization is a readmission and why if known. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. The reason for re-admission of this hospitalization encounter. encounter-admission (example)Constraints
| |
| dietPreference | 0..* | CodeableConcept | There are no (further) constraints on this element Element IdEncounter.hospitalization.dietPreference Diet preferences reported by the patient DefinitionDiet preferences reported by the patient. Used to track patient's diet restrictions and/or preference. For a complete description of the nutrition needs of a patient during their stay, one should use the nutritionOrder resource which links to Encounter. For example, a patient may request both a dairy-free and nut-free diet preference (not mutually exclusive). Medical, cultural or ethical food preferences to help with catering requirements. Diet (example)Constraints
| |
| specialCourtesy | 0..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.hospitalization.specialCourtesy Special courtesies (VIP, board member) DefinitionSpecial courtesies (VIP, board member). Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Special courtesies. SpecialCourtesy (preferred)Constraints
| |
| specialArrangement | 0..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.hospitalization.specialArrangement Wheelchair, translator, stretcher, etc. DefinitionAny special requests that have been made for this hospitalization encounter, such as the provision of specific equipment or other things. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Special arrangements. SpecialArrangements (preferred)Constraints
| |
| destination | I | 0..1 | Reference(Location | Organization) | There are no (further) constraints on this element Element IdEncounter.hospitalization.destination Location/organization to which the patient is discharged DefinitionLocation/organization to which the patient is discharged. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Location | Organization) Constraints
|
| dischargeDisposition | S | 0..1 | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.hospitalization.dischargeDisposition (USCDI) Category or kind of location after discharge DefinitionCategory or kind of location after discharge. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. [National Uniform Billing Committee](http://www.nubc.org/), manual UB-04, UB form locator 17 USCoreDischargeDisposition (preferred)Constraints
|
| location | S | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.location (USCDI) List of locations where the patient has been DefinitionList of locations where the patient has been during this encounter. Virtual encounters can be recorded in the Encounter by specifying a location reference to a location of type "kind" such as "client's home" and an encounter.class = "virtual".
|
| location | S I | 1..1 | Reference(Location) | There are no (further) constraints on this element Element IdEncounter.location.location (USCDI) Location the encounter takes place DefinitionThe location where the encounter takes place. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| status | 0..1 | codeBinding | There are no (further) constraints on this element Element IdEncounter.location.status planned | active | reserved | completed DefinitionThe status of the participants' presence at the specified location during the period specified. If the participant is no longer at the location, then the period will have an end date/time. When the patient is no longer active at a location, then the period end date is entered, and the status may be changed to completed. The status of the location. EncounterLocationStatus (required)Constraints
| |
| physicalType | 0..1 | CodeableConcept | There are no (further) constraints on this element Element IdEncounter.location.physicalType The physical type of the location (usually the level in the location hierachy - bed room ward etc.) DefinitionThis will be used to specify the required levels (bed/ward/room/etc.) desired to be recorded to simplify either messaging or query. This information is de-normalized from the Location resource to support the easier understanding of the encounter resource and processing in messaging or query. There may be many levels in the hierachy, and this may only pic specific levels that are required for a specific usage scenario. Physical form of the location. LocationType (example)Constraints
| |
| period | I | 0..1 | Period | There are no (further) constraints on this element Element IdEncounter.location.period Time period during which the patient was present at the location DefinitionTime period during which the patient was present at the location. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| serviceProvider | S I | 0..1 | Reference(US Core Organization Profile) | There are no (further) constraints on this element Element IdEncounter.serviceProvider (USCDI) The organization (facility) responsible for this encounter DefinitionThe organization that is primarily responsible for this Encounter's services. This MAY be the same as the organization on the Patient record, however it could be different, such as if the actor performing the services was from an external organization (which may be billed seperately) for an external consultation. Refer to the example bundle showing an abbreviated set of Encounters for a colonoscopy. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(US Core Organization Profile) Constraints
|
| partOf | I | 0..1 | Reference(Encounter) | There are no (further) constraints on this element Element IdEncounter.partOf Another Encounter this encounter is part of DefinitionAnother Encounter of which this encounter is a part of (administratively or in time). This is also used for associating a child's encounter back to the mother's encounter. Refer to the Notes section in the Patient resource for further details.
|
| Encounter | I | Encounter | There are no (further) constraints on this element Element IdEncounter An interaction during which services are provided to the patient Alternate namesVisit Definition- -
| |
| identifier | S Σ | 0..* | Identifier | There are no (further) constraints on this element Element IdEncounter.identifier (USCDI) Identifier(s) by which this encounter is known DefinitionIdentifier(s) by which this encounter is known.
|
| use | Σ ?! | 0..1 | codeBinding | There are no (further) constraints on this element Element IdEncounter.identifier.use usual | official | temp | secondary | old (If known) DefinitionThe purpose of this identifier. Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers. Applications can assume that an identifier is permanent unless it explicitly says that it is temporary. Identifies the purpose for this identifier, if known . IdentifierUse (required)Constraints
|
| type | Σ | 0..1 | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.identifier.type Description of identifier DefinitionA coded type for the identifier that can be used to determine which identifier to use for a specific purpose. Allows users to make use of identifiers when the identifier system is not known. This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type. A coded type for an identifier that can be used to determine which identifier to use for a specific purpose. Identifier Type Codes (extensible)Constraints
|
| system | S Σ | 1..1 | uri | There are no (further) constraints on this element Element IdEncounter.identifier.system (USCDI) The namespace for the identifier value DefinitionEstablishes the namespace for the value - that is, a URL that describes a set values that are unique. There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers. Identifier.system is always case sensitive.
General http://www.acme.com/identifiers/patient Mappings
|
| value | S Σ | 1..1 | string | There are no (further) constraints on this element Element IdEncounter.identifier.value (USCDI) The value that is unique DefinitionThe portion of the identifier typically relevant to the user and which is unique within the context of the system. If the value is a full URI, then the system SHALL be urn:ietf:rfc:3986. The value's primary purpose is computational mapping. As a result, it may be normalized for comparison purposes (e.g. removing non-significant whitespace, dashes, etc.) A value formatted for human display can be conveyed using the Rendered Value extension. Identifier.value is to be treated as case sensitive unless knowledge of the Identifier.system allows the processer to be confident that non-case-sensitive processing is safe.
General 123456 Mappings
|
| period | Σ I | 0..1 | Period | There are no (further) constraints on this element Element IdEncounter.identifier.period Time period when id is/was valid for use DefinitionTime period during which identifier is/was valid for use. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| assigner | Σ I | 0..1 | Reference(Organization) | There are no (further) constraints on this element Element IdEncounter.identifier.assigner Organization that issued id (may be just text) DefinitionOrganization that issued/manages the identifier. The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization.
|
| status | S Σ ?! | 1..1 | codeBinding | There are no (further) constraints on this element Element IdEncounter.status (USCDI) planned | arrived | triaged | in-progress | onleave | finished | cancelled + Definitionplanned | arrived | triaged | in-progress | onleave | finished | cancelled +. Note that internal business rules will determine the appropriate transitions that may occur between statuses (and also classes). Current state of the encounter. EncounterStatus (required)Constraints
|
| statusHistory | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.statusHistory List of past encounter statuses DefinitionThe status history permits the encounter resource to contain the status history without needing to read through the historical versions of the resource, or even have the server store them. The current status is always found in the current version of the resource, not the status history.
| |
| status | 1..1 | codeBinding | There are no (further) constraints on this element Element IdEncounter.statusHistory.status planned | arrived | triaged | in-progress | onleave | finished | cancelled + Definitionplanned | arrived | triaged | in-progress | onleave | finished | cancelled +. Note that FHIR strings SHALL NOT exceed 1MB in size Current state of the encounter. EncounterStatus (required)Constraints
| |
| period | I | 1..1 | Period | There are no (further) constraints on this element Element IdEncounter.statusHistory.period The time that the episode was in the specified status DefinitionThe time that the episode was in the specified status. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| class | S Σ | 1..1 | CodingBinding | There are no (further) constraints on this element Element IdEncounter.class (USCDI) Classification of patient encounter DefinitionConcepts representing classification of patient encounter such as ambulatory (outpatient), inpatient, emergency, home health or others due to local variations. Codes may be defined very casually in enumerations or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Classification of the encounter. EncounterclassHistory-class (extensible)Constraints
|
| classHistory | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.classHistory List of past encounter classes DefinitionThe class history permits the tracking of the encounters transitions without needing to go through the resource history. This would be used for a case where an admission starts of as an emergency encounter, then transitions into an inpatient scenario. Doing this and not restarting a new encounter ensures that any lab/diagnostic results can more easily follow the patient and not require re-processing and not get lost or cancelled during a kind of discharge from emergency to inpatient.
| |
| class | 1..1 | CodingBinding | There are no (further) constraints on this element Element IdEncounter.classHistory.class inpatient | outpatient | ambulatory | emergency + Definitioninpatient | outpatient | ambulatory | emergency +. Codes may be defined very casually in enumerations or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Classification of the encounter. EncounterclassHistory-class (extensible)Constraints
| |
| period | I | 1..1 | Period | There are no (further) constraints on this element Element IdEncounter.classHistory.period The time that the episode was in the specified class DefinitionThe time that the episode was in the specified class. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| type | S Σ | 1..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.type (USCDI) Specific type of encounter DefinitionSpecific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation). Since there are many ways to further classify encounters, this element is 0..*. Valueset to describe the Encounter Type USCoreEncounterType (extensible)Constraints
|
| serviceType | Σ | 0..1 | CodeableConceptBinding | Element IdEncounter.serviceType Specific type of service DefinitionBroad categorization of the service that is to be provided (e.g. cardiology). Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Broad categorization of the service that is to be provided. SignalHealthcareServiceType (required)Constraints
|
| priority | 0..1 | CodeableConcept | There are no (further) constraints on this element Element IdEncounter.priority Indicates the urgency of the encounter DefinitionIndicates the urgency of the encounter. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Indicates the urgency of the encounter. encounter-priority (example)Constraints
| |
| subject | S Σ I | 1..1 | Reference(US Core Patient Profile) | There are no (further) constraints on this element Element IdEncounter.subject (USCDI) The patient or group present at the encounter Alternate namespatient DefinitionThe patient or group present at the encounter. While the encounter is always about the patient, the patient might not actually be known in all contexts of use, and there may be a group of patients that could be anonymous (such as in a group therapy for Alcoholics Anonymous - where the recording of the encounter could be used for billing on the number of people/staff and not important to the context of the specific patients) or alternately in veterinary care a herd of sheep receiving treatment (where the animals are not individually tracked). Reference(US Core Patient Profile) Constraints
|
| episodeOfCare | Σ I | 0..* | Reference(EpisodeOfCare) | There are no (further) constraints on this element Element IdEncounter.episodeOfCare Episode(s) of care that this encounter should be recorded against DefinitionWhere a specific encounter should be classified as a part of a specific episode(s) of care this field should be used. This association can facilitate grouping of related encounters together for a specific purpose, such as government reporting, issue tracking, association via a common problem. The association is recorded on the encounter as these are typically created after the episode of care and grouped on entry rather than editing the episode of care to append another encounter to it (the episode of care could span years). References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| basedOn | I | 0..* | Reference(ServiceRequest) | There are no (further) constraints on this element Element IdEncounter.basedOn The ServiceRequest that initiated this encounter Alternate namesincomingReferral DefinitionThe request this encounter satisfies (e.g. incoming referral or procedure request). References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| participant | S Σ | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.participant (USCDI) List of participants involved in the encounter DefinitionThe list of people responsible for providing the service.
|
| type | S Σ | 0..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.participant.type (USCDI) Role of participant in encounter DefinitionRole of participant in encounter. The participant type indicates how an individual participates in an encounter. It includes non-practitioner participants, and for practitioners this is to describe the action type in the context of this encounter (e.g. Admitting Dr, Attending Dr, Translator, Consulting Dr). This is different to the practitioner roles which are functional roles, derived from terms of employment, education, licensing, etc. Role of participant in encounter. ParticipantType (extensible)Constraints
|
| period | S I | 0..1 | Period | There are no (further) constraints on this element Element IdEncounter.participant.period (USCDI) Period of time during the encounter that the participant participated DefinitionThe period of time that the specified participant participated in the encounter. These can overlap or be sub-sets of the overall encounter's period. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| individual | S Σ I | 0..1 | Reference(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core RelatedPerson Profile) | There are no (further) constraints on this element Element IdEncounter.participant.individual (USCDI) Persons involved in the encounter other than the patient DefinitionPersons involved in the encounter other than the patient. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core RelatedPerson Profile) Constraints
|
| appointment | Σ I | 0..* | Reference(Appointment) | There are no (further) constraints on this element Element IdEncounter.appointment The appointment that scheduled this encounter DefinitionThe appointment that scheduled this encounter. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| period | S I | 0..1 | Period | There are no (further) constraints on this element Element IdEncounter.period (USCDI) The start and end time of the encounter DefinitionThe start and end time of the encounter. If not (yet) known, the end of the Period may be omitted.
|
| length | I | 0..1 | Duration | There are no (further) constraints on this element Element IdEncounter.length Quantity of time the encounter lasted (less time absent) DefinitionQuantity of time the encounter lasted. This excludes the time during leaves of absence. May differ from the time the Encounter.period lasted because of leave of absence.
|
| reasonCode | S Σ | 0..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.reasonCode (USCDI) Coded reason the encounter takes place Alternate namesIndication, Admission diagnosis DefinitionReason the encounter takes place, expressed as a code. For admissions, this can be used for a coded admission diagnosis. For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis). Reason why the encounter takes place. EncounterReasonCodes (preferred)Constraints
|
| reasonReference | S Σ I | 0..* | Reference(US Core Condition Problems and Health Concerns Profile | US Core Condition Encounter Diagnosis Profile | US Core Procedure Profile | Observation | ImmunizationRecommendation) | There are no (further) constraints on this element Element IdEncounter.reasonReference (USCDI) Reason the encounter takes place (reference) Alternate namesIndication, Admission diagnosis DefinitionReason the encounter takes place, expressed as a code. For admissions, this can be used for a coded admission diagnosis. For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis). Reference(US Core Condition Problems and Health Concerns Profile | US Core Condition Encounter Diagnosis Profile | US Core Procedure Profile | Observation | ImmunizationRecommendation) Constraints
|
| diagnosis | Σ | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.diagnosis The list of diagnosis relevant to this encounter DefinitionThe list of diagnosis relevant to this encounter.
|
| condition | Σ I | 1..1 | Reference(Condition | Procedure) | There are no (further) constraints on this element Element IdEncounter.diagnosis.condition The diagnosis or procedure relevant to the encounter Alternate namesAdmission diagnosis, discharge diagnosis, indication DefinitionReason the encounter takes place, as specified using information from another resource. For admissions, this is the admission diagnosis. The indication will typically be a Condition (with other resources referenced in the evidence.detail), or a Procedure. For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis). Reference(Condition | Procedure) Constraints
|
| use | 0..1 | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.diagnosis.use Role that this diagnosis has within the encounter (e.g. admission, billing, discharge …) DefinitionRole that this diagnosis has within the encounter (e.g. admission, billing, discharge …). Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. The type of diagnosis this condition represents. DiagnosisRole (preferred)Constraints
| |
| rank | 0..1 | positiveInt | There are no (further) constraints on this element Element IdEncounter.diagnosis.rank Ranking of the diagnosis (for each role type) DefinitionRanking of the diagnosis (for each role type). 32 bit number; for values larger than this, use decimal
| |
| account | I | 0..* | Reference(Account) | There are no (further) constraints on this element Element IdEncounter.account The set of accounts that may be used for billing for this Encounter DefinitionThe set of accounts that may be used for billing for this Encounter. The billing system may choose to allocate billable items associated with the Encounter to different referenced Accounts based on internal business rules.
|
| hospitalization | S | 0..1 | BackboneElement | There are no (further) constraints on this element Element IdEncounter.hospitalization (USCDI) Details about the admission to a healthcare service DefinitionDetails about the admission to a healthcare service. An Encounter may cover more than just the inpatient stay. Contexts such as outpatients, community clinics, and aged care facilities are also included. The duration recorded in the period of this encounter covers the entire scope of this hospitalization record.
|
| preAdmissionIdentifier | 0..1 | Identifier | There are no (further) constraints on this element Element IdEncounter.hospitalization.preAdmissionIdentifier Pre-admission identifier DefinitionPre-admission identifier.
| |
| origin | I | 0..1 | Reference(Location | Organization) | There are no (further) constraints on this element Element IdEncounter.hospitalization.origin The location/organization from which the patient came before admission DefinitionThe location/organization from which the patient came before admission. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Location | Organization) Constraints
|
| admitSource | 0..1 | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.hospitalization.admitSource From where patient was admitted (physician referral, transfer) DefinitionFrom where patient was admitted (physician referral, transfer). Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. From where the patient was admitted. AdmitSource (preferred)Constraints
| |
| reAdmission | 0..1 | CodeableConcept | There are no (further) constraints on this element Element IdEncounter.hospitalization.reAdmission The type of hospital re-admission that has occurred (if any). If the value is absent, then this is not identified as a readmission DefinitionWhether this hospitalization is a readmission and why if known. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. The reason for re-admission of this hospitalization encounter. encounter-admission (example)Constraints
| |
| dietPreference | 0..* | CodeableConcept | There are no (further) constraints on this element Element IdEncounter.hospitalization.dietPreference Diet preferences reported by the patient DefinitionDiet preferences reported by the patient. Used to track patient's diet restrictions and/or preference. For a complete description of the nutrition needs of a patient during their stay, one should use the nutritionOrder resource which links to Encounter. For example, a patient may request both a dairy-free and nut-free diet preference (not mutually exclusive). Medical, cultural or ethical food preferences to help with catering requirements. Diet (example)Constraints
| |
| specialCourtesy | 0..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.hospitalization.specialCourtesy Special courtesies (VIP, board member) DefinitionSpecial courtesies (VIP, board member). Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Special courtesies. SpecialCourtesy (preferred)Constraints
| |
| specialArrangement | 0..* | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.hospitalization.specialArrangement Wheelchair, translator, stretcher, etc. DefinitionAny special requests that have been made for this hospitalization encounter, such as the provision of specific equipment or other things. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. Special arrangements. SpecialArrangements (preferred)Constraints
| |
| destination | I | 0..1 | Reference(Location | Organization) | There are no (further) constraints on this element Element IdEncounter.hospitalization.destination Location/organization to which the patient is discharged DefinitionLocation/organization to which the patient is discharged. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(Location | Organization) Constraints
|
| dischargeDisposition | S | 0..1 | CodeableConceptBinding | There are no (further) constraints on this element Element IdEncounter.hospitalization.dischargeDisposition (USCDI) Category or kind of location after discharge DefinitionCategory or kind of location after discharge. Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. [National Uniform Billing Committee](http://www.nubc.org/), manual UB-04, UB form locator 17 USCoreDischargeDisposition (preferred)Constraints
|
| location | S | 0..* | BackboneElement | There are no (further) constraints on this element Element IdEncounter.location (USCDI) List of locations where the patient has been DefinitionList of locations where the patient has been during this encounter. Virtual encounters can be recorded in the Encounter by specifying a location reference to a location of type "kind" such as "client's home" and an encounter.class = "virtual".
|
| location | S I | 1..1 | Reference(Location) | There are no (further) constraints on this element Element IdEncounter.location.location (USCDI) Location the encounter takes place DefinitionThe location where the encounter takes place. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.
|
| status | 0..1 | codeBinding | There are no (further) constraints on this element Element IdEncounter.location.status planned | active | reserved | completed DefinitionThe status of the participants' presence at the specified location during the period specified. If the participant is no longer at the location, then the period will have an end date/time. When the patient is no longer active at a location, then the period end date is entered, and the status may be changed to completed. The status of the location. EncounterLocationStatus (required)Constraints
| |
| physicalType | 0..1 | CodeableConcept | There are no (further) constraints on this element Element IdEncounter.location.physicalType The physical type of the location (usually the level in the location hierachy - bed room ward etc.) DefinitionThis will be used to specify the required levels (bed/ward/room/etc.) desired to be recorded to simplify either messaging or query. This information is de-normalized from the Location resource to support the easier understanding of the encounter resource and processing in messaging or query. There may be many levels in the hierachy, and this may only pic specific levels that are required for a specific usage scenario. Physical form of the location. LocationType (example)Constraints
| |
| period | I | 0..1 | Period | There are no (further) constraints on this element Element IdEncounter.location.period Time period during which the patient was present at the location DefinitionTime period during which the patient was present at the location. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration.
|
| serviceProvider | S I | 0..1 | Reference(US Core Organization Profile) | There are no (further) constraints on this element Element IdEncounter.serviceProvider (USCDI) The organization (facility) responsible for this encounter DefinitionThe organization that is primarily responsible for this Encounter's services. This MAY be the same as the organization on the Patient record, however it could be different, such as if the actor performing the services was from an external organization (which may be billed seperately) for an external consultation. Refer to the example bundle showing an abbreviated set of Encounters for a colonoscopy. References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. Reference(US Core Organization Profile) Constraints
|
| partOf | I | 0..1 | Reference(Encounter) | There are no (further) constraints on this element Element IdEncounter.partOf Another Encounter this encounter is part of DefinitionAnother Encounter of which this encounter is a part of (administratively or in time). This is also used for associating a child's encounter back to the mother's encounter. Refer to the Notes section in the Patient resource for further details.
|
{ "resourceType": "StructureDefinition", "id": "signal-encounter", "url": "https://signalbhn.org/fhir/StructureDefinition/encounter", "name": "SignalEncounter", "title": "Encounter Profile", "status": "active", "fhirVersion": "4.0.1", "kind": "resource", "abstract": false, "type": "Encounter", "baseDefinition": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-encounter", "derivation": "constraint", "differential": { "element": [ { "id": "Encounter.serviceType", "path": "Encounter.serviceType", "binding": { "strength": "required", "valueSet": "https://signalbhn.org/fhir/ValueSet/signal-healthcare-service-type" } } ] } }
Profile usage
This resource is used to capture 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. Encounter is primarily used to record information about the actual activities that occurred.
Procedure and Encounter
In general, a Procedure resource may not be necessary for capturing the type of encounter for billing purposes, Encounter.type SHOULD be used for capturing billable codes and the primary description of the encounter.
The Procedure and encounter have references to each other (Procedure.encounter and Encounter.reasonReference, respectively). In the case both are used these SHOULD be to different procedure resources. I.E. the former for the procedure that was performed during the encounter (stored in Procedure.encounter). The latter used for cases where an encounter is a result of another procedure (stored in Encounter.reasonReference) such as a follow-up encounter to resolve complications from an earlier procedure.
See additional information on Structure Definition: Procedure Profile.
Encounter vs. Admission (EpisodeOfCare)
Per the Encounter scope and usage:
The admission component is intended to store the extended information relating to an admission event. It is always expected to be the same period as the encounter itself. Where the period is different, another encounter instance should be used to capture this information as a partOf this encounter instance.
The definition of admission in a Signal context does not fit for this use. We are using the Structure Definition: EpisodeOfCare Profile to store Signal's admission information. See Clinical Categorization Module for additional information on Encounter vs. EpisodeOfCare.
Special Note for available Encounter Procedure Codes
Encounter procedure codes (billable codes for services performed for a patient during an encounter) SHOULD be captured in Encounter.type (see below for more info). These codes will be populated through a complex set of logic to allow a provider to see only the most relevant codes based on a number of factors, including:
- Qualifications and licenses held by the provider location(s) selected as the serviceProvider via the
Organization.extension.qualificationon file - Programs and services provided by their organization via the
HealthcareServiceresource and the associated Service Category and Service Type SQL lookup/crosswalk table - Potentially as services available via contracted rates
Profile element notes
.status
- Will typically contain
finishedin this system, since these typically only entered after they have occurred. An exception would be when an encounter isentered-in-errorand should be completely removed from the patient's medical record after it came into the system.
.class
- Determined by provider.
- Will typically contain
AMB, as this represents healthcare in a practitioner's office or nonresident care. - For long term care,
IMPwill likely be used to represent a patient admitted to a facility. - See value set definitions for more information.
.type
- SHALL contain the procedure code representing the encounter.
- This code is not required to have an explicit contracted rate based on the provider and procedure.
- In the case this code is not billable encounter for a provider, the code SHOULD represent the same concept as the healthcare service performed. E.g. an Encounter record for a survey may not have an associated bill but SHOULD represent that procedure in CPT or SNOMED terminology.
- See for Finance Module for billing information.
.serviceType
- SHALL represent the Signal Service Type (defined by BHA or other) for high-level categorization
- SHOULD match service type(s) available on the EpisodeOfCare
.subject
- SHALL reference the Patient/client defined on the EpisodeOfCare
.episodeOfCare
- EpisodeOfCare resource that contains the patient, program(s) and service type(s)
- SHOULD match [one of] the service type(s) on the EpisodeOfCare
- MAY point to more than one EpisodeOfCare if service is applicable to a plurality of concurrent ongoing services (EpisodeOfCare resources) for the same patient
.basedOn
- MAY represent the Referral that caused the initial admission.
- The referral information will also be contained on EpisodeOfCare and SHALL be preferentially used to Encounter
.participant.individual
- SHOULD reference the Structure Definition: Practitioner Profile for the primary performer (see .participant.type)
.participant.typeSHOULD be set toPPRFto indicate this as the primary performer- When the
EpisodeOfCare.teamelement is populated, this individual SHOULD be listed there if it is used here
.reasonReference or .reasonCode
- MAY represent a procedure or condition that caused this encounter
- SHALL NOT represent the services performed during this Encounter.
Encounter.typewill be the primary method to identify the type of encounter. Furthermore, Structure Definition: Procedure Profile may reference this encounter with additional type and/or information.)
.period
- The start and end time of the encounter
.length
- MAY be used to represent time the encounter lasted. In this case it SHALL match applicable time units on Structure Definition: ChargeItem Profile
- This SHOULD NOT be used for billing purposes but instead for reporting puroses on Encounter lengths
.account
- MAY be used to specify payer and/or funding that is different from one specified on EpisodeOfCare
.location.location
- SHOULD be used to specify the Place of Service (POS) Codes maintained by CMS.
- See Structure Definition: Location Profile for more information on POS.
.serviceProvider
- SHALL reference the Organization resource for the Provider (provider-location). See Organization Services Module
.partOf
- MAY be used to point to encounter that created this encounter