Description:
An encounter, generally speaking, makes possible the following:
- It allows a Patient to establish contact with an HCP.
- It allows the HCP to capture information about the Patient such as
- Demographics
- Insurance/Guarantor information
- Primary Care/Referral Physician
- Location(s) of the patient during care
- Next of Kin
- Reason for contact
- It provides a medium for care delivery (via orders, treatment)
The creation of an encounter makes it possible for the patient to receive care. Most
encounter related information is captured during the Registration business process. This information
may be updated to while care is being delivered and new facts come to light (say when a Patient gets
a new insurance or his address changes etc.).
The information generated during an encounter is put to a variety of uses such as to trace Orders/Observations as belonging to
a Patient/Encounter, to determine relationships between Physicians (or other roles accessing information) and Patients for access control, to keep track of
referrals by Physicians on or off staff. Encounters also provide information on the kind of care the Patient arrived for (Surgery, Radiology test) and thus helps
the HCP update the infrastructure around patient traffic.
When encounters are grouped together as Episodes, the HCP may also keep track of the overall
quality and direction of the care being delivered to the Patient.
There has been discussion in the CORBAMed DTF of OMG about the role Encounter
Management plays in the overall Health Care Architecture. The HALFEM RFI issued by CORBAMed is a step in the direction
of building the Encounter Component(s) and relating them with the other components complete with interdependencies /interactions.
The goal of this project is to capture the information content of encounters as events in the health care and develop an integrated framework for Encounter Services as part of the overall HealthCare Framework.
Description
A patient coming into a hospital has to have an order from a physician regarding their purpose to come to the hospital. After they are registered and admitted, their order needs to be placed within the context of clinical environment.
Orders contain information about the patient such as:
- The Medical Record Number
- Name
- Sex
- Date of Birth
And other specific information related to the patient. This information is obtained from their medical record. Orders also contain information related to the orders themselves, such as:
- The Order item
- Status of the order
- Priority given to the text/exam/procedure
- Date/time requested
- Department for which the order is given etc.
Order items are codes given to each test/ procedure that
is/ can be performed in a particular hospital or healthcare facility. Each of these tests
is also associated with a charge. The codes, the name of the tests and their respective
charges are stored in a central data store from which they are accessed. Once the orders
are placed with all this information, then they need to be routed to the respective department.
Every large hospital consists of several departments like Radiology, Laboratory, Endoscopy, Surgery
etc. Some hospitals may have some departments but may have to rely on other hospitals or external/ private
institutions for some services. Each of these departments have their own requirements as far as orders are
concerned. Apart from the information that is required or provided in all the orders, each department may
have its own requirements when orders are being placed. Therefore depending on which department the
order is being placed for; the order will require the department-specific information. For example, consider
an order for the laboratory: it will specify the specimen source, which could be arterial blood, where as this
information is quite unnecessary for a Radiology order.
As orders are created and sent to the departments, charges are generated as a result of placing the order
and the test being performed. The orders on being processed generate results.
The project aims to capture all this information in a framework. The idea behind this is to use the framework
as a component in a larger picture, which makes up the architecture of the healthcare domain.
|
For problems or questions about this web, contact webmaster@cadse.cs.fiu.edu |