...
Somewhere around 2008, we had a conversation at an OpenMRS Implementers Meeting about the need for a more flexible model to allow for more than paper form to be collected when the patient came to clinic. We also new knew that the existing one-encounter-per-paper-form approach was going to fall short as people started using OpenMRS to record hospitalizations. At that meeting, we came up with a more flexible design:
| Mockup | ||||
|---|---|---|---|---|
|
- Encounter would represent the clinical transaction between the care system and patient (e.g., the provider seeing the patient, documentation of a telephone call, vitals and other data collected by a triage nurse, etc.). Basically, it wouldn't change much from the point-in-time "transaction" for which paper encounter forms were used.
- Visit would be added to represent the actual "visit" to the provider over a period of time (hours, days, weeks, or more). A visit could contain one or more encounters. This would correspond to a clinic visit, but could also easily represent a entire hospitalization or virtual visit (like a telephone visit).
- Episodes of Care would be used to link encounter encounters across visits that were related. For example, grouping all encounters relating to a specific diagnosis or to a treatment program.
...
- Encounter must exist (or be created) for any Transaction – i.e., a Transaction must be linked to at least one encounter.
- We could consider allowing a Transaction to span Encounters, since a technical transaction could potentially add/alter data within more than one Encounter (e.g., a chart audit in which multiple charts are affected). This would avoid the need for additional Transaction grouping, but might make the model and API more confusing.
See Also