...
...
| Table of Contents |
|---|
What is this?
openmrs-esm-patient-chart is a patient dashboard microfrontend for the OpenMRS SPA. It provides a simple dashboard with cards detailing the patient's information, such as vitals, demographic and relationships.
For more information visit:-
https://github.com/openmrs/openmrs-esm-patient-chart
How do I install this?
Requirements: Java 8, Latest NodeJS & NPM, Latest Git, Latest OpenMRS Platform with the Latest SPA Module installed
...
git clone https://github.com/openmrs/openmrs-esm-patient-chart
- cd openmrs-esm-patient-chart
- npm install
- npm run build
- Serve the built dist/openmrs-esm-patient-chart.js and configure it in your SPA Module's root-config
Then, have a look at the Frontend Implementer DocumentationO3 Setup, Configuration & Deployment for installing microfrontends for the SPA Module.
...
At it's core, a widget is simply a component. Presently, the majority of work on this application has been using react. A widget might be something like a card displaying conditions, or a set of cards for displaying orders. Widgets are defined using the widgetDefinitions configuration option.
{
...
"widgetDefinitions":
...
[
...
{
...
"name":
...
"myWidget",
...
"esModule"
...
:
...
"@my-moodule-with-widgets
...
}
...
]
}
The chart rendering engine will attempt to load the above module, using SystemJS to dynamically load my-module-with-widgets. Note: this module must be listed in your import map in order for SystemJS to be able to import it. Please see here for more instructions on managing your import map. On import, System.JS provides an es6 module. Based on the above configuration, the rendering engine expects there to be a property within the module called "myWidget". If you are creating your own module to serve widgets, please be sure to use the exact same name to export the widget as you use in the widget definition.
...
A dashboard is a collection of widgets with a layout. We provide a simple layout manager to make it relatively straightforward to configure your dashboards. A dashboard definition consists of the following
{
...
"name":
...
"dashboardName"
...
"title":
...
"title
...
of
...
dashboard"
...
"layout":
...
{
...
"columns":
...
n
...
}
...
"widgets":
...
[
...
{
...
"name":
...
"widget1",
...
"esModule"
...
:
...
"@widget1-module"
...
"layout"
...
:
...
{
...
"columnSpan":
...
n
...
"rowSpan":
...
n
...
}
...
},
...
{
...
"name":
...
"widget2",
...
"esModule"
...
:
...
"@widget2-module"
...
Configuring the primary
}
]
}
Dashboards make it relatively straight forward to take a collection of widgets and display them using a grid layout (see css-grid, if you're interested). The layout is simple, it allows a user to say how many columns will be in the grid. You specify this in the config under layout.columns. Within the widgets configuration, you can also specify the number of columns and/or rows you want the widget to occupy using layout.columnSpan and layout.rowSpan properties within the widget. The widgets are rendered in the order they are listed in the config. An example may illustrate things more clearly. Let's set up a dashboard with 4 columns. If widget1 is set to 3 columns, and widget2 is set to 2 columns, then widget1 will be displayed on the first row. Because 3 + 2 = 5 > 4, widget2 will be bumped to the next row and occupy the first two columns. If no layout is specified in the configuration, the dashboard will default to using 1 column and 1 row to display the widget.
TabbedViews
TabbedViews exist to support scenarios where the user may want to have a second level of navigation under the primary navigation bar. In configuration consists solely of defining a name, title and navbar:
{
"name": "myTabbedView",
"title": My Tabbed View",
"navbar": [
{
"label": "View 1",
"view": "view1"
"path": "/view1
},
{
"label": "View 2",
"view": "view2,
"path": "/view2"
}
]
}
The above uses the following configuration:
{
name: "resultsTabbedView",
title: "Results",
navbar: [
{
label: "Overview",
path: "/overview",
view: "resultsOverviewDashboard"
},
{
label: "Vitals",
path: "/vitals",
view: "VitalsSummary"
},
{
label: "Height and Weight",
path: "/heightAndWeight",
view: "HeightAndWeightSummary"
}
]
}
In the next section, we discuss the primary navigation bar which uses an identical configuration set up as the navbar in the TabbedView. We discuss the properties within the navbar configuration below.
Primary navigation bar:
{
...
"primaryNavbar":
...
[
...
{
...
"label":
...
"Summary",
...
"view":
...
"summaryDashboard"
...
"path":
...
"/summary"
...
},
...
{
...
"label":
...
"Results",
...
"view":
...
"resultsTabbedView"
...
"path":
...
"/results"
...
},
...
{
...
"label":
...
"Conditions",
...
"view"
...
:
...
"conditionsOverview",
...
"path"
...
:
...
"/conditions"
...
}
...
]
}
The above will automatically generate a primary navigation bar with three items. The configuration for an item includes three required properties: label, view and path. The label is what will be displayed to the user on the navigation bar. View is a generic term we will use to refer to what will be displayed by clicking on the link. We have created three views: widgets, dashboards and tabbedViews. Please see below for a detailed description of these concepts. The path property is provided so that you can link to these features from within widgets you create. In the example above, a route will be created to serve conditionsOverview widget at /patient/:patientUuuid/chart/conditions.
...
This widget may now be referenced in the primaryNavbar (or in a tabbedView) by setting the "view" property of the navbar to the name of the widget. For example, we could have the following:
...
...
{
...
"label":
...
"My
...
Widget",
...
"view"
...
:
...
"myWidget",
...
"path"
...
:
...
"/mywidget"
...
When the preceding is seen rendered, it will look to see if there is a definition in widgetDefinitions --> dashboardDefinitions --> tabbedViewDefinitiions. If it does not find a definition, then it will return a <div> displaying the reason it could not be found. If it does find a definition, then it will render that type of view. As the preceding suggests, the rendering engine will first look in widget}