For guidance I searched the GSOC documentation and found a related FAQ.

3. What are the goals of this program?
Google Summer of Code has several goals:

1. Create and release open source code for the benefit of all
2. Inspire young developers to begin participating in open source development
3. Help open source projects identify and bring in new developers and committers
4. Provide students the opportunity to do work related to their academic pursuits. during the summer (think “flip bits, not burgers”)
5. Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)

OpenMRS has also published expectations for GSOC 2011: Summer of Code 2011 – Expectations

My Conclusion

In my opinion, successful working code is not the only objective. Integration to the community is the primary objective with the students having a positive real-world experience.

Is it possible to have a project that meets all functional objectives but I still consider the project unsuccessful? Definitely, yes.

Is it possible to have a student project that does not accomplish the functional objectives but still I consider the project a huge success? Yes, absolutely.

Evaluation Criteria

The following are a list of activities that I consider important as a participant in the GSOC program.

Blog

Publish meaningful articles to your blog about OpenMRS, GSOC, and web development in Java. At least one post per week is acceptable.

My student sent me a detailed progress report this week. This is great, as I read it I was thinking that it would be good for a blog as two or three posts.

Wiki

The quality of the documentation on the wiki, particularly the project page, determines the future usefulness of your work.
Types of documentation that the student should publish are:

1. Project Management – timelines, milestones, progress to date
2. User documentation – “how-to” instructions
3. Technical design documentation – SSDs, domain models, flowcharts, Design Patterns, …

This should be updated weekly and synchronized with the code you’re writing. At the end of the week there shouldn’t be features in your code that aren’t documented on the wiki (from a user perspective or a technical perspective).

SVN

If you’re working solo in an openmrs branch or module repository you should check in every time you work on the project. If I don’t see 3 or 4 commits from a student in a week then I’m wondering if there is a problem.

Helpful Links:

• Requesting a Branch
• How to Submit Code

Mailing List

Every one should be on the mailing list. If you’re encountering a steep learning curve, you can ask questions If you’re a strong student, you answer questions.  So either way I’d like to see a student participating on the mailing list several times (minimum 3) per week.

Often, the mailing list is more appropriate than contacting a mentor directly by email. The work we’re doing, the issues we encounter, and the decisions we take should be recorded and available publicly for future community members.

Weekly Meetings

Attendance is a must … and you have to talk. People are interested in what you have to say.
Ask one question per developer call. Provide feedback once per developer call (you know, when Paul asks if anyone has any other thoughts on something … usually followed by moments of silence)

Helpful Links:

• Weekly Developer Meeting
• Weekly Design Review Meeting

Presentation. You will be evaluated on your presentation. I’m stating here that I’m available for my student to review it and practice together. I’ll listen to it every day during the week leading up to the presentation. The day of the presentation is too late to find out that:

1. Your skype connection cuts in and out when you’re talking;
2. You speak English at warp speed and no one can understand;
3. Your screen is freezing on adobe connect and other participants can’t follow you;
4. You’ve prepared too much material and there is no time for questions;
5. Your presentation does not include suggested content, such as a live demo.

These are all easy to work around and your mentor is glad to help you, myself included.

Methods and Software Quality

Bare minimum you must follow OpenMRS conventions and testing methods. In my opinion this is even more important than functional completeness of the project.
Useful links:

• Code Style
• Coding Conventions
• Unit Tests
• Unit Testing Conventions
• Unit Testing Annotations

At the end of any week all code will adhere to these guidelines.

Functional Objectives

Does the code behave the way that is expected? Does it do what it is supposed to?

If you have a backup mentor that is also a domain user this is really helpful. Andy Kanter was great last year for this purpose; he’d load up the module and provide rich, functional feedback.

Mentor Feedback Should be Weekly

In my opinion, waiting until midterm is too long to provide feedback to the student. I believe that this should happen on a weekly basis. I noticed that openmrs gsoc organizers implemented a weekly report to leadership, but I believe this should be happening directly between mentor and student as well.

I’m preparing a weekly report to show my student which areas he’s doing the best in and which areas he can spend more time on – based on the evaluation criteria listed above. The midterm and final evaluations then become the accumulation of the weekly reports.

I like this approach because it shows the relative importance of community participation and other activities in comparison to simply “coding up new features”.

Participation should be natural, not last minute. I don’t want to see 5 svn commits within an hour on Sunday night; that’s meaningless.

Ready. Set. Go.

Less than a week until start date. I’m looking forward to the summer. I’m extremely pleased with student I’m working with. He’s got mad skills and great drive. We’re going to have a fun time.

“This morning I started on it as soon as I got into the office. I was so into it that I didn’t even take off my coats. I sat here for 2 hours working with 2 coats on. Just now I have finally paused to remove them.”

Sadly, I can’t remember the last time I felt this way about my work. What is wrong with this? It reminds me of a quote I heard.

“The less a project or task or opportunity at work feels like the sort of thing you would do if this is just a job, the more you should do it.”

Moving forward let’s look for opportunities that we’re naturally drawn to. When you wake up in the morning, what are you thinking about doing? Are you so excited to get started that you won’t even pause to take your coat off?

To date, I’ve published a couple of interviews and received some positive feedback.

I’m trying to release these on a bi-weekly basis. But there is a fair amount of legwork in scheduling, editing, and publishing. I missed one cycle on the week of American Thanksgiving. Perhaps, due to the upcoming holiday season it’s been harder to schedule interviews lately.

Please drop me a line if you have suggestions on who I can speak with. Or just let me know what you think of the interviews. I’d love to hear from you. mcglen@gmail.com

OpenMRS Spotlight – Jonathan Galingan (National Telehealth Centre, Philippines) from Glen McCallum.

How is OpenMRS being used in Asia?

When I heard that OpenMRS is being used in two hospitals in the Philippines I just had to find out more. Jonathan Galingan of the National Telehealth Centre fills us in on the details.

OpenMRS Spotlight – Joaquin Blaya (eHealth Systems).

How did this recent PhD graduate living in Boston end up founding a tech startup in Chile?

When I heard Joaquin Blaya is establishing a company around OpenMRS I had a ton of questions. He’s answered them here for all of us.

I believe there is a more fundamental question here: should OpenMRS be used to manage reference data? It is not the first time I’ve seen OpenMRS suggested as a solution to manage non-patient information.

Definitions

To me, the introduction of the term “Master” indicates that the reference data is depended on by more than one instance of an application or by several different applications. For example, Terminology Management is one component of Master Data Management for a healthcare organization.

Scenarios

For a one-stop-shop (monolithic system architecture) where all of your data capture and reporting is done on a single system it is fine to manage reference data in that same location. I believe this is the case with most OpenMRS installations.

Evidence that this is an issue 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.

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.