Hi All,

I'm really glad to announce that, I have got completed the main end to end functionality as my mentor expected from me, before the mid term which gonna happen next week.

Features completed:

• HTML/X form entry submissions.
• Anonymous submissions.
• Care Provider Console (For Care providers: to review the received patient narratives--encounters)
• Module settings panel: (For admins: to switch X/HTML form as they wish and config the default patient used by the encounters and encounter type.)
• Captcha validation before form submissions.
• Initial WebRTC  integration.

And I have documented a brief user guide at wiki: https://wiki.openmrs.org/x/IAIzAw

And... Here are some screenshots :-)

Hi All,

The module work is going really well. I have finished embedding of the both Xforms and HTML forms into the module and now both allows to fill forms, gets saved properly and creates new encounters. Care seeker panel also have the basic functionality. In overall module works pretty well with Authenticated (logged in) users.

Currently I am focusing on the Anonymous submission stuff; Things seems like lil bit complicated than I expected since the other modules (X and HTML form entry modules) depends on some parameters which collects while authentication process. So currently I am trying to by-pass them using the Spring AOP advicer class (as daniel suggested) or if not using a deamon thread (as wyclif suggested)

I have hosted the current version of the Module at my EC2 server so you can check the progress of work:

URL: http://54.235.163.128:8080/openmrs
user name: admin
password: Admin123

Hi All,

Its the 4th week of GSoC, well just passed a big month of period after the GSoC coding start date! This week was a great week, So many improvements and development happened.

1. Created a Xform (customized for the patient narratives' collection) Of course I have created required concepts to map the observations used at Form.

I wanna Thank bunch for Daniel Kayiwa for the great help and guidance given for me from the very beginning of Xform integration till the end of Xforms creation process.

Final look after the Xform integration

2. The care provider console improvements.





3. HTML form entry integration -- I wanna thank Mark Goodrich for the valuable guidance given for me to get done things related to HTML forms integration in my custom module UI.

After getting things done, I have created a small guide including my learning’s related to this case: How to Embed HTML Form (generated by HTML Form Entry module) in a custom module


Look after the HTML form integration.

Hi All,

Its the end of the third week of gsoc and it was a busy week for me.
So much research and development happened this week. Since i haven't work with Concept dictionary , Encounters and Observations before, I had to read lot about them. Actually now I understand why OpenMRS is a very unique software amoung all other healthcare related software products, Its because of the wonderful *Concept-Dictionary* it made of and the extensible framework it has.

Currently I am working on to build a basic Care provider console which will show up all the encounters filtered by a particular encounter type.

If all goes well it should look like this :-)

Introduction

At the heart of every OpenMRS implementation is a concept dictionary that defines the medical concepts (questions and answers) used as the building blocks for forms, orders, clinical summaries, reports and almost every aspect of the data.  Most OpenMRS implementations have an open concept dictionary - one that is considered incomplete and evolves over time. Therefore, as clinicians document conditions, the OpenMRS concept dictionary must be expandable to accommodate meaningful clinical data.
What follows is an introduction to the Concept Dictionary, OpenMRS's unique foundation, and how it provides flexibility for the implementation.

Definitions

Concept Dictionary

The concept dictionary represents a fundamental building block of OpenMRS. Similar to a dictionary defining the function, meaning, and relationships of the words, the concept dictionary defines the name, code, and appropriate attributes for any observations or data collected (including medical tests, drugs, results, symptoms and conditions). To even further simplify the concept dictionary, one could compare it to an infinitely large Excel spreadsheet, where patients are represented as rows and concepts are represented by columns.

Concept

The concept is the basic element of flexibility in OpenMRS. Concepts are the individual data points collected from a population of patients. Concepts include both questions and answers.
For example, blood type data is collected for a patient.  The question is "What is the blood type for the patient?", with a set of discrete answers of "A, B, AB or O".  To implement this in OpenMRS with concepts, the question is a concept ("blood type") and each response ("A", "B", "AB" and "O") is also a concept.  For this one question, a total of 5 concepts are required.
What about a question where the answer is not a discrete answer?  If the question is "What is the name of your first pet?", the answer would be expressed in a text box.  It would not be possible to provide a complete list of every possible name for your pet.  In this example, there would be one concept -- "name of first pet".
The bottom line is, if you need a medical word within your electronic records system, it needs to be defined within the concept dictionary.  More detail about all the possible concepts in a later section.

Encounter

A single, specific interaction between the patient and a provider. An encounter can be any interaction and includes doctor visits, laboratory tests, food distribution, home visits, counselor appointments, etc. Encounters are typically represented as a form (consisting of hundreds of observations), but could also be a touch-screen patient registration or a single lab test for CD4.  For example, a patient visits a health center or hospital.  For each electronic form completed for that patient, a new encounter is created.  Each will have a unique encounter_id and encounter_type.  Forms could be completed by different departments (ie.  drug pickup, visit with an HIV clinician, Diabetes visit, food package received), and will have an associated encounter_type (ie. ART Drug Regimen Pickup, Adult intake, food assistance, lab test, etc).  Each encounter has an encounter type, date/time, location and provider.

Observations

Anything actively measured or observed during an encounter. As an example, patients' weights, heights, blood pressures, and BMIs are observations, as well as qualitative facts including the number of years a patient smoked, the activities in which the patient experiences shortness of breath, and finding on an X-ray. Although typically an observable question, demographics are an exception, and are recorded as separate concepts. Each observation has a unique obs_id.
These are possible scenarios for encounters and observations:

• One visit with one encounter without observations – Touch screen patient registration in Haiti
• One visit with one encounter with one observation – Touch screen patient registration in Rwinkwavu, Rwanda with weight recorded
• One visit with one encounter and many observations – HIV followup form
• One visit with multiple encounters and many observations – HIV followup form along with ART drug regimen pickup.  This would show 2 encounters, where each encounter would have a different encounter id and encounter type.

Demographics

Demographics are any descriptive characteristic of a person. This includes: name, address, date of birth, age, and any other social construct involvement.