Join AMPATH in development of an AngularJS interface for OpenMRS

jdick · September 25, 2015, 7:37am

As some of you saw in the demo last week:

AMPATH is working on an AngularJS front-end to OpenMRS. Presently, we are trying to get out a version 1.0 which does the following:

Has representations for OpenMRS REST resources
Login view/controller
Patient Dashboard - view demographics and historical patient data
Clinic Dashboard - view appointments per day, per month, and view defaulters
FormEntry - develop schema to represent forms + some content (e.g. pages, sections), integrate into OpenMRS forms representations (store and access forms through rest calls to AMRS/OpenMRS).

We are hoping that this code is useful to others. But, we recognize we are likely developing in a way that is organization specific. To create a more useful tool, we are looking to partner with another organization to co-develop, where possible, AngularJS tools and back-end OpenMRS modules supporting these tools (e.g. coming up with a generic and automated way of creating database tables with rest endpoints).

Please let me know if you or your organization has an interest in working with us.

Take a look at our GitHub repositories as well : https://github.com/ampath/ng-amrs

Thanks!

janflowers · October 12, 2015, 8:27pm

The team in Mozambique is also working on an AngularJS POC app that might be useful to you. We have been working with Thoughtworks and @darius to use some of the Bahmni code, but we needed more customization on the UI part so are doing that separately. @pascal, @valvijo, and myself were talking this morning and thought it might be a good moment for us to step back and talk about POC work as a community. There may be a lot of duplication of effort happening and we might find it useful to decide which layers we can collaborate together to create, and which layers need customization from the context they are being used in. Maybe @darius is interested in this topic as well since he is the representative of the Thoughtworks AngularJS POC app?

jdick · October 13, 2015, 5:33am

Jan, there are at least 5 groups that I know of now using or planning to build an Angular Frontend.

I think it would be useful to come up with a roadmap of where angular POC should be going. This should identify the modules that are generic as well as identify the space which likely require user customization.

Perhaps we can use a design call in the next few weeks to get this process started. But, the OpenMRS may be the most fruitful opportunity to hammer something out.

pascal · October 13, 2015, 6:36am

I think it would be a good idea to have a discussion about this on a design call. It makes sense to collaborate on common code

mseaton · October 13, 2015, 1:21pm

Hey Jonathan,

One piece I’d be interested in collaborating further on in the near-term, is in the schema definition that you are putting together. This is something I’d love for us to be able to utilize more broadly, if possible, as a more generic means of documenting the “data model” of our system in a format that can also be interpreted and utilized by a variety of tools, including both angular formentry, html form entry, other UIs (eg. the registrationapp module configuration), as well as reporting tools.

Let me know if this is of interest.

Thanks, Mike

jdick · October 13, 2015, 3:59pm

Mike, agreed, it would be good to come up with a “standard” json schema to define forms for various consumers. same would be true of creating processors to consume form data for various cases.

As a starting point, take a look at the schema we’re presently using for the adult form:

https://github.com/AMPATH/ng-amrs/blob/master/app/scripts/formentry/formschema/form1.json

Let’s find a time to discuss in the near future.

mseaton · October 13, 2015, 4:53pm

Thanks - I saw those and that was what spurred my thinking.

We have a proliferation of form definition techniques that are around and growing. These include:

xforms: Uses Form/Field/FormField htmlformentry: Uses XML, but embedded within a specific form view bahmni: Uses concept sets and some custom json config registrationapp: Uses a custom json appconfig descriptor ng-amrs: Uses a custom json format

It would be great if we could evolve these into a revised Form/FormField/Field/other model that is backed by a core API + web services, and which form entry technologies would define in Java, XML, or JSON as they prefer (and which implementations could define in the way that they prefer).

I would imagine our schema needs are pretty common across the board, even if the form entry technologies themselves take different approaches.

And the side-benefit is that reporting tools can then easily provide things like a “form data export” out-of-the-box, without regard for the technology used to get the data in. It simply just inspects the common schema and does it’s thing.

Mike

burke · October 14, 2015, 1:09pm

I’d love to see both:

Agreement on where/how folks building AngularJS could share code. Can functionality be bundled into modules that can be shared via bower (e.g., form modeling, authentication, etc.)? Would an AngularJS “openmrs” module help (e.g., server binding)? Is there any hope/benefit of sharing any aspects of the UI (approach to routing, login, etc.)?
Agreement on a form model. Deciding on what, if anything, can be used/borrowed/changed in the existing FormService that models fields and then maps them onto forms. I would favor solving the simple things and providing a shared mechanism for extending/customizing the model. That would allow us to collaborate on the simple stuff in the short term and evolve into tackling fancier features over time without slowing anyone down.

darius · October 14, 2015, 1:40pm

Definitely +1 to starting to talk about this in design calls, leading up to high-bandwidth discussions in Singapore.

michael · October 19, 2015, 7:26pm

Just a reminder that we will be holding an tutorial on AngularJS during the first OpenMRS World Summit in Singapore. Space is still available, so don’t wait – sign up now if you are interested in learning more about AngularJS!

http://om.rs/15

AngularJS & REST Web Services 101 Tuesday, 14:00-18:00 OpenMRS software development is moving towards building web components that can work with each other, instead of being part of the Java module framework. Since the release of the webservices.rest module, we have focused on improving the REST resources so that we have a complete API that is accessible over HTTP and developers with different language skills can contribute. This tutorial will provide instructions on how to use the OpenMRS REST API to build custom user interfaces using modern/popular tools. Most efforts in the community have focused on using AngularJS, and we’ll showcase some of the “best practices” in AngularJS development.

jdick · November 6, 2015, 4:23pm

I just wanted to follow up on json form representation.

Please take a look at the following:

github.com

jonathandick/formentry2/blob/master/schema.json

/*
Introduction
This document outlines the rules for creating a valid schema.
Each question will serve as a template to produce a valid angular formly field.

Rules
1. Every form has at least 1 page
2. Every page has at least 1 tab or 1 section (tabs are optional)
3. Every tab has at least 1 section
4. An question can contain other questions. However a group of questions exists only within a section. In other words,
   you can not have a group with questions in different sections of the form.
5. The questions array is ordered: questions will appear on the form in the order they are found in the quetions array.
6. Each modelType must be associated with a function to produce a formly field. This function takes a question and a model and populates the model.
7. A question can only be asked once on a common level of a particular branch. In other words, you can not ask, "Are you on ARVs?"
   in more than one place on the form unless the question is nested within another question (and that question does not already ask the question).
8. A question can be asked have multiple answers only if it is of an appropriate type, e.g. "group_repeating", "multi-checkbox"
9. As a question may have multiple answers, the model should store answers as arrays, not as strings/numbers etc.
10. Metadata specific to a question will be placed in the questionMetadata object of a question.
    For example, each obs needs a concept and this would be placed in the questionMetadata object.
*/

This file has been truncated. show original

We’re going to spend the next few weeks refactoring our formentry module.

The “questions” object may be most relevant from a general perspective as it describes how a general question would be represented. The issue of pages, tabs and sections may be more specific to our particular implementation.

Would love other’s thoughts.

JJ

pascal · November 6, 2015, 6:13pm

Thanks @jdick. I just want to loop @valvijo in on this, since this is something we’re also thinking about at the moment.

valvijo · November 9, 2015, 6:45am

Hi @jdick and @pascal,

This idea of standardizing forms and rules sounds really good!! I think that this is important to have in mind the different types of devices we can use with AngularJS forms, for instance a mobile form can be different in structure comparing with a tablet or desktop form. This is what led moz to create custom forms with bahmni app. There are different needs, and for sure, many things can be standardized and reused.

Valério

dkayiwa · November 9, 2015, 7:18am

As we do this, it will also be great to document why existing standards were not appropriate for us and hence explain the need to come up with some thing new.

jdick · November 13, 2015, 4:07pm

Dear All,

We have come up with a preliminary schema which can be viewed at:

github.com

AMPATH/json-schema-template/blob/master/schema.template.json

/*
Introduction
This document outlines the rules for creating a valid schema.
Each question will serve as a template to produce a valid angular formly field.

Rules
1. Every form has at least 1 page
3. Every page has at least 1 section
4. A question can contain other questions. However a group of questions exists only within a section. In other words,
   you can not have a group with questions in different sections of the form.
5. The questions array is ordered: questions will appear on the form in the order they are found in the questions array.
6. Each type must be associated with a function to produce a formly field. This function takes a question and a model and populates the model.
7. Optional "rendering" is used to specify the way an element is displayed on the form. [Rendering should be there for types that can have multiple 
   rendering possibilities suchs 'obs']
8. Optional "concept" is allowed for "obs" & "obsGroup" types only.
9. A question can only be asked once on a common level of a particular branch. In other words, you can not ask, "Are you on ARVs?"
   in more than one place on the form unless the question is nested within another question (and that question does not already ask the question).
8. A question can be asked have multiple answers only if it is of an appropriate type, e.g. "group_repeating", "multi-checkbox"
9. As a question may have multiple answers, the model should store answers as arrays, not as strings/numbers etc.
10. Metadata specific to a question will be placed in the questionMetadata object of a question.

This file has been truncated. show original

There are is a description of the schema in that document which I have pasted below.

The general aim is to generically describe, using json, a form question. This should be representative of any question on a form independent of the data source it is eventually stored in.

There are certain elements of a question which hold true of any question. We have tried to keep these at the top level. We have also created a “questionOptions” field which is an object intended to store type specific data. For example, an obs question would have an associated concept.

Our team is somewhat divided on using a questionOptions object. One argument is that it’s a bit neater to house these properties within an object. The other is that given json is flexible, there’s no harm to including property at the top level. As other designers use this schema, they will include whatever properties they need.

We would love to get specific feedback on the above issue (regarding a questionOptions object) in addition to any other feedback.

P.S. @dkayiwa, can you point us towards existing documentation on form schema, especially a json schema if one exists?
`

Rules

Every form has at least 1 page

Every page has at least 1 section

A question can contain other questions. However a group of questions exists only within a section. In other words, you can not have a group with questions in different sections of the form.

The questions array is ordered: questions will appear on the form in the order they are found in the questions array.

Each type must be associated with a function to produce a formly field. This function takes a question and a model and populates the model.

Optional “rendering” is used to specify the way an element is displayed on the form. [Rendering should be there for types that can have multiple rendering possibilities suchs ‘obs’]

Optional “concept” is allowed for “obs” & “obsGroup” types only.

A question can only be asked once on a common level of a particular branch. In other words, you can not ask, “Are you on ARVs?” in more than one place on the form unless the question is nested within another question (and that question does not already ask the question).

A question can be asked have multiple answers only if it is of an appropriate type, e.g. “group_repeating”, “multi-checkbox”

As a question may have multiple answers, the model should store answers as arrays, not as strings/numbers etc.

Metadata specific to a question will be placed in the questionMetadata object of a question. For example, each obs needs a concept and this would be placed in the questionMetadata object.

Optional “formlyTemplateOptions” field allow the form developer to pass custom template options to formly if they want to. [These will be used instead of formentry provided default whenever provided]

missilen · December 5, 2016, 4:54pm

Hi, I am interested in testing out the front end. Do you have the username and password for the demo servers?

thanks Tim