Close Encounters of the Electronic Medical Record System Kind

Last week I noticed this email to the openmrs developers list asking some extremely relevant and practical questions about modeling clinical data in openmrs.

In my project, I need to model a cancer treatment summary form in OpenMRS. For example, a chemotherapy treatment summary form may contain such fields as name and address of institution where chemotherapy was given, oncologist’s name, nurse or nurse practitioner’s name, and up to eight medications used in the treatment. Each medication has five fields that needs to be filled out: name of medication, dose per administration, number of doses, cumulative dose and how given.

My questions are:

  1. Is it OK to model this type of form as a single OpenMRS encounter (i.e. chemotherapy treatment encounter)?
  2. Is there any other (and better) way to model this type of form using existing OpenMRS entities?
  3. Can we model each chemotherapy medication as a separate obs and add five notes to represent each of the medication’s five attributes (i.e. name, dose, etc) respectively?
  4. Is there a better way to model an observation with multiple attributes (e.g. an OpenMRS data type with multiple sub-
  5. Is there a way to link one encounter with another and how? e.g. I may want to model an aggregated cancer treatment summary form  as an encounter, which contains all of the treatments received by a patient, and link that form to multiple individual cancer treatment forms modeled also as an encounter.

When I read this I thought to myself, maybe this author has a background similar to mine with large vendor-supplied clinical information systems and integrated health networks. There’s something here that is subtly different to OpenMRS – the Encounter definition.

Encounters used by vendors

Typically, the encounter is the central entity in a large clinical information system. It roughly maps to a visit/stay and aggregates everything that transpired during that time – orders, procedures, observations, charges, claims, etc. Types of encounters can include: outpatient, lab clinic, emergency, outpatient surgery, inpatient, etc.

The encounter starts at the admission date/time and ends upon discharge. There is one main encounter per admission. For some outpatient encounters I’ve seen the encounter start when the patient presents at the desk for check-in then auto-discharge at midnight.

I’ve seen a few clinical areas diverge from this definition. For example, some clinicians view an encounter spanning multiple visits for a specific treatment or problem – like in mental health or kidney dialysis. Sometimes these are modeled as a “recurring encounter” in the clinical information system – but on the information level each is a single encounter and aggregated into some group structure.

Encounters in OpenMRS

Burke and Darius led a break out session at the 2009 implementers meeting. I wasn’t there but I believe that the notes represent the understanding and the direction of the community.

Encounter

  • an encounter is an instant of creating data and why its 1 to 1 with forms
  • Encounter has a single date/time
    • GM> An encounter represents the interaction between a clinician and a patient. If a patient sees more than one clinician during a visit then there was more than one encounter, even it was for the same problem or part of the same program. Typically, at the sites, each workflow is optimized to have the clinican document the encounter on a single form which is later recorded in the system by a data entry clerk.
    • GM> An encounter is associated with no more than one visit and no more than one episode of care.

Visit

  • A visit happens from admission to discharge. For outpatient visits, the discharge happens automatically at the end of the day.
  • Visit has start/stop
    • GM> A visit represents the interaction between the patient and the clinic/facility. A patient comes to a location and has one or more encounters with clinicians.
    • GM> A visit can be associated with more than one episode of care. A visit can be associated with more than one encounter.

Episode

  • Episode of care is a span of time where some data was collected, orders placed, encounters happened, etc
  • Episode has start/stop
  • An episode of care is a program workflow”. “If an outpaitent comes to a clinic for both an tb visit and hiv visit…is that two Visit entries or one? It should be one visit and the patient is in two different episodes of care.”
    • GM> Episodes span multiple visits and have a purpose/program. An episode of care is typically associated with more than one visit. An episode of care is usually associated with more than one encounter.

Encounters defined by standards

ASTM defines an encounter as “(1) an instance of direct provider/practitioner to patient interaction, regardless of the setting, between a patient and a practitioner vested with primary responsibility for diagnosing, evaluating or treating the patient’s condition, or both, or providing social worker services. (2) A contact between a patient and a practitioner who has primary responsibility for assessing and treating the patient at a given contact, exercising independent judgment.”

HITSP defines an encounter as: “An encounter between a patient and a healthcare practitioner or healthcare provider (e.g. hospital or clinic) for clinical care. May also be used to refer to an encounter between a patient and a physician or other practitioner, as distinguished from ancillary services, such as lab tests or vaccinations.”

Conclusion

I believe the difference in vendor versus openmrs definitions for encounter lies in the subtle ambiguity of the HITSP definition, “an encounter between a patient and a healthcare practitioner…” – the OpenMRS defintion – … “an encounter between a patient and … or  healthcare provider (e.g. hospital or clinic)” – the vendor definition. Certainly the openmrs understanding of encounter is more consistent with the ASTM description.

I hope this adds some clarity to those new to the community. Perhaps I’ve erred in my interpretation of the breakout minutes from the implementers meeting, or perhaps the core openmrs group has altered their way of thinking since then. I welcome any clarification or correction in the comments.

3 Responses to “Close Encounters of the Electronic Medical Record System Kind”

  1. Paul Biondich September 13, 2010 at 15:08 #

    You’ve got it exactly right Glen… however, we unfortunately don’t have the visits and episodes yet modelled in the system. However, they are clearly on the roadmap for version 1.9

    Thanks for the additional data around the HITSP and ASTM definitions!

    Vital gathering and prescreening by a nurse is a classic encounter
    Outpatient clinical appointment is a classic visit
    Preventive care is a classic episode of care. :)

  2. Andrew Kanter September 13, 2010 at 21:59 #

    Great summary, Glen. I am not sure we added to this discussion at the 2010 meeting, but this is a great way to begin the discussion again in preparation for 1.9!

  3. Burke September 14, 2010 at 09:16 #

    Thanks for posting this, Glen.

    One correction: an encounter can only occur within a single visit; however, it could belong to 0-to-n episodes of care.

    We are moving toward encounter as an “encounter transaction” that reflects the clinical transaction (a note, a lab report, a set of orders, etc.) comprised of 0-to-n observation, orders, notes, or metadata (form data).

    Visit represents the inpatient, outpatient, nursing home, emergency department, etc. visit, which may contain multiple encounters — e.g., patient sees nurse, then doctor, then social worker, then lab, with each creating an encounter within the same visit. Ending a visit is tricky and real life will undoubtedly mean that some encounter may need to be connected to a previous visit (e.g., note entered after the patient has left the clinic).

    Episodes of care is a way to group visits and/or encounters that relate to a specific diagnosis or treatment — e.g., all visits and/or encounters related to a pregnancy. Once these are established in the system, then programs & workflows will likely get re-designed to make use of these episodes of care to link visits/encounters to treatment programs.

    Cheers!

    -Burke

Leave a Reply:

Gravatar Image