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
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.
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?
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
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.
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.
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.
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!
AngularJS & REST Web Services 101Tuesday, 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.
I just wanted to follow up on json form representation.
Please take a look at the following:
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.
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.
We have come up with a preliminary schema which can be viewed at:
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?
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]