@mseaton and I continued brainstorming this on this week’s TAC call. In general, we agree that OpenMRS would benefit from recognizing an “Encounter session”. Below are some rough notes from the conversation.
Encounter Session
- An encounter session would be specific to user & patient.
- The frontend could include an optional encounter within
- Ideally, encounter session would be introduced in the Platform to centralize business logic, simplify frontend logic, and to allow it to evolve toward support for draft encounters.
Encounter Session API ideas
- Create a new encounter session for patient.
- This would include user, patient, and encounter type.
- Might throw an exception if an encounter session already exists.
- What encounter sessions exist for patient?
- Optionally scoped to current user ± encounter type.
- Close/delete encounter session
- Allows a client to abort/cancel an encounter session.
What changes for an app/esm developer?
- When creating data for an encounter (e.g., orders, obs, notes, etc.), an application would check for an active encounter session (e.g., within the application’s session context) and, if found, default to adding data to that encounter.
- When storing data outside of an encounter session, first look for an existing encounter session and, if one doesn’t exist, create one.
- Eventually, we’d like for apps to be able to query the backend for an encounter types appropriate for their features (e.g., which encounter types allow for orders? Or does a given encounter type support orders?).
Note: there are related conversations in the OpenMRS3 Slack channel.