mks-d

{
   "resourceType":"Bundle",
   "id":"8519fb54-ce84-4246-92a7-dfbc8901456d",
   "meta":{
      "lastUpdated":"2021-07-02T14:04:05.161+00:00"
   },
   "type":"searchset",
   "total":1,
   "link":[
      {

mks-d

Estimate

Evaluation for the work on carbonizing the AMPATH form engine (user-facing only, i.e., the formentry module, written in Angular 6).

Main Renderer

File: form-renderer.component.html Time: 12h Work: Convert classes, e.g., going from btn btn-default to Carbon counterparts, potentially swap out components or create intermediate stubs such as mat-tab-group, etc.

Components

mks-d

Uuid	Void/Retire	Identifier type	Name	Description	Prefix	Suffix	First identifier base	Min length	Max length	Base character set	_version:1	_order:6000
90563743-a6c8-4c23-8244-f50361f2a997		df255fa5-eb77-414d-89e5-5f068ba63a54	Location Prefixed Identifier Source	Location Prefixed Identifier Source	provider:idgen.locationBasedPrefixProvider		100000	6		0123456789ACDEFGHJKLMNPRTUVWXY

mks-d

package org.openmrs.module.htmlformentry;

import static java.util.Calendar.MILLISECOND;

import java.util.Calendar;
import java.util.Date;
import java.util.Map;
import java.util.TimeZone;

import org.junit.Assert;

mks-d

{
  "id": "prp.latestServicePlan.widget",
  "instanceOf": "coreapps.template.dashboardWidget",
  "order": 1,
  "config": {
    "widget": "latestobsforconceptlist",
    "icon": "icon-user-md",
    "label": "Sample PRP Widget",
    "concepts": "0144f175-3231-4d12-8d97-ec8b4d348cab, e322170f-2417-45eb-86ab-5f8eb0170510"
  },

mks-d

While working on one of our Java projects on macOS it was required to do a search and replace in all Java files containing a string sequence. In our case it was required to change every JavaDoc "@since 2.3.0" into "@since 2.1.5, 2.3.0".

sed is the tool for this, and since BSD's implementation differs from GNU sed, we opted to stick to GNU sed which is available on Homebrew:

brew install gnu-sed

Then the magic combining find and sed:

find src/ -name '*.java' | xargs gsed -i -e "s/@since 2.3.0/@since 2.1.5, 2.3.0/g"

mks-d

Strangely we could do for so long without a dedicated OpenMRS Initializer domain for locations. Until now we were simply bringing in locations metadata through OpenMRS MDS packages. MDS packages are always a convenient fallback mechanism when the desired OpenMRS Initializer domain is not (yet) available.

It was on our to do list for some time to finally address the case of locations. It is now done, please check the README about it here.

Let us look at a sample use on a Bahmni distribution of one of our clients that supports a small community health clinic in Haiti. Starting from an existing default Bahmni setup we want to end up with just two locations:

• Clinic
• Community

'Clinic' is the login location for providers at the clinic itself, whereas 'Community' is an ad-hoc location for providers performing community surveys while offline using Bahmni Connect. We had to deal with the

mks-d

One of our Bahmni instances was not able to trigger any Bahmni Reports because - somehow - a report that could never be completed was stuck as 'Processing'. That piece of information could be seen in the 'Reports Queue' under 'My Reports':

It was clear that this report was not really processing and that the information was lingering, yet blocking the scheduling of any new report with an error 500:

The server encountered an internal error that prevented it from fulfilling this request.

Restarting Bahmni Reports didn't do anything to it:

mks-d

<style>
html {
  font: Helvetica;
  color: #3f3f40;
}

div .simple-page {
  text-align: center;
}

mks-d

Original	Corrected
Syndrome d'Obrinsky/Prune belly	Aplasie congénitale de la musculature abdominale (Syndrome d'Obrinsky)
Rosacee	Acné rosacée
Déficience de le marche	Difficulté à la marche, non classée ailleurs