Building Fragment - Need Help With Choosing encounter-form relationship (one-one or one-many)

[Craig A.]

Hi Everyone,

I'm collecting personal information, including emergency contact information, in an encounter called "personal information." We tested the input time of collecting all information in one form and it takes 30 minutes for our team member to complete the entire form. Instead, I thought to break up the form sections into multiple forms that can be completed in multiple settings to reduce the burden it may have on our clients. I need help deciding if I should have a one-to-one relationship between encounter type and form or if a one-to-many relationship is fine. Most important is the fragment development and reporting. 

Which of the two options below do you suggest?

Option 1:

Encounter Type: Personal Information

Forms:

Section A: Staff observations

Section B: Identification

Section C: Emergency Contact

Etc.

Option 2: 

Encounter Type: Personal Information Section A

Form: Section A: Staff Observations

Encounter Type: Personal Information Section B

Form: Section B: Identification

Encounter Type: Personal Information Section C

Form: Section C: Emergency Contact

Etc

I'm building a fragment that provides a visual indicator to the user stating if an HTMLForm has been completed or not. If the form has been completed, a green checkbox will display with a link to edit the form. If it hasn't been completed, a red x will display with a link to enter a new form. The structure of my encounters and forms has an impact on my FragmentController. I don't know if it has an impact on reporting on the back end. Which option would you suggest?

Thanks for your help!

Craig

[Burke Mamlin]

Hey Craig.  OpenMRS is currently designed closer to a one-form-per-encounter model.  You might find ways to combine forms to contribute to a single encounter, but it might be easier (the tooling will work with you rather than needing workaround) in OpenMRS 1.9+ to take your second approach, where you have one form per encounter.

Cheers,

-Burke

FYI – we've been brainstorming about sessions (encounter transactions), which would help when/if it can be realized – i.e., defining how multiple "steps" (some combination of diagnoses, notes, orders, observations, forms, etc.) can be created in one or more technical transactions that contribute to a single encounter.

--
OpenMRS Developers: http://om.rs/dev
Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
Manage your OpenMRS subscriptions at http://om.rs/id
 
Register today for our Maputo 2015 Implementers Meeting: http://om.rs/moz15

[Jonathan Teich]

Also, some of the personal information is very long-lived, and does not need to be reviewed at each encounter.

Jonathan

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@openmrs.org.