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.

Here are a couple of things that I learned:

1. Get involved early – provide unlimited feedback on proposals

Get on IRC as much as possible, especially early on. Get to know the students. Tell the students that email you to come on IRC. Start teaching them about the domain, about the product, about the technology stack. Treat every student like they are already in the program. Indeed, a student’s willingness to socialize can be an indicator of integration with the community.

Customize the proposal template – make it your own. Add what you need – UI Mockups, requirements, evaluation framework, project plan. Try doing all your requirements analysis with the students during the application phase. Have students send you their proposal a week early and use it as a tool to teach …  tell them where more detail is needed.

It was surprising how many students just submitted a boiler plate application. I rejected these immediately. To be shortlisted the application had to include at least a paragraph about the specific project (even if it was regurgitated from the project description).

2. Set aside time every day for the project

Technology, time zones, language, school, and work schedules made status meetings difficult early in the summer.

At the midterm evaluation point, we started checking in daily on irc Monday-Saturday. During the 1/2 hour of daily check-in my student had complete access to me. It was a time that I could make the project the focus of my attention. I believe that this communicated to the student that people are interested in the project … that the work is important. When I made it a priority the student responded in the same way.

–

Obviously, this is not everything I learned. I grew a great deal during my participation but some of it was personal growth. I feel far more prepared now to be a mentor than I was at the onset of the program. Perhaps I will be invited to participate again next year.

I’m planning a 12 day cycle. It starts on a Monday and ends on a Saturday. The 13th day is a day of grace. There will be 5 iterations over the whole summer.

Programming is a smaller part of creating good software.

The project struck me as really cool and I have a lot of respect for the Regenstrief Institute (I’d worked with LOINC and the Unified Service Action Model). So I cruised over to openmrs.org. Within a few minutes I’d hopped on IRC and there was a user called doc_paul who greeted me nicely.  I soon realized we shared a few of the same [unconventional] views about clinical systems. I asked a few questions about EAV modeling in OpenMRS and the derivation from RMRS. That was it. I subscribed to the dev list before I left.

I skimmed the dev messages for over a year and observed that the community wasn’t like other open source communities. These people were supportive, helpful, kind,  and not driven by egos. I thought, this is something I would like to be a part of.

Late in 2008 I saw a posting from Andy about the Millennium Villages Project looking to hire a software engineer. I responded.  After a brief discussion we found a couple of challenges (1) The funding could not be easily dispersed to a Canadian, and (2) I was already earning significantly more than his budget. We decided that maybe I could get involved on a part-time volunteer basis.

February 2009 I flew down to Portland, OR to meet him. We spent a day together talking about concept management and the needs of MVP.  Concept management is one of my strengths. I felt it was a good match. I agreed to create a module in OpenMRS to meet some if their concept management needs.

April 2009 Andy invited me to a working group meeting in Abidjan, Cote d’Ivoire to discuss a OASIS-related project for Francophone West Africa. I think it helped that I speak French fluently. While in Abidjan we also attended the HELINA conference.

June  2009.  I created a Spanish version of the MVP concept-dictionary for Joaquin Blaya.

July 2009. My wife had our second baby. Our life turned topsy-turvy. My free-time ceased to exists and work on MVP’s OpenMRS module was completely derailed.

October 2009 – I discovered that I worked with a friend of Gerry Douglas of Baobab Health, that he went to the same School of Computer Science that I did, and that he was coming to town for a visit. We made arrangements for him to present his PhD research in a Colloquium at the University. It was a fabulous presentation and a great visit.

September 2009 – February 2010. Andy and I kept in touch.

March 2010 – Andy contacted me about becoming a GSOC mentor and continuing the work I started last summer.

This brings me to the present.

Firzhan Naqash was selected to complete the Concept Proposal Module. Congratulations Firzhan! FH lives in Sri Lanka, attends the University of Moratuwa, and loves to code (I think he likes James Bond too). Check out his blog to follow the progress.

Andy Kanter and I are looking forward to the summer.