Background

Several years ago, the OpenMRS community started a project to create a cloud-based web application built on top of the Open Concept Lab (OCL) that specialized in concept dictionary management for the OpenMRS community. The “OCL for OpenMRS Squad” was formed (see https://wiki.openmrs.org/pages/viewpage.action?pageId=224527062) and volunteers defined requirements and began ReactJS development. With a 2021 investment from Digital Square, the minimum viable product for the OpenMRS Dictionary Manager was brought to launch and notably used by MSF to manage and subscribe to a concept dictionary for a Bahmni implementation in Bangladesh. The squad remains active and the Dictionary Manager is now a key platform in the nascent OpenMRS HIV Reference Implementation initiative, as part of the CDC’s Technical Assistance Platform, with significant growth in traffic and content expected in 2022 and beyond. A surge of interest from national teams is expected through this mechanism - in fact, the first implementing teams are already using the Dictionary Manager to set up content packages for field teams to apply and adapt (stored in OCL here: https://app.openconceptlab.org/#/orgs/OHRITechGroup/collections/). 

In the meantime, OCL’s two open-source tools, the TermBrowser and the Terminology Server, were completely overhauled with a host of new features and are now in a place where they can begin to support the specialized functionality and workflows of the Dictionary Manager in a more robust, sustainable, enterprise-ready manner. A Nov-2021 comparison of features between the TermBrowser and Dictionary Manager found that approximately 70% of user interface features in the Dictionary Manager were at least partially supported in the TermBrowser, creating a high maintenance burden to keep these features aligned. Furthermore, new capabilities needed by users of the Dictionary Manager, such as the ability for a user to make non-breaking changes to a curated concept, require new workflows and user experience designs that would need to be done for both the Dictionary Manager and the TermBrowser.

By integrating these products, we eliminate overlapping functionality and duplication of effort, thus simplifying life for field staff, so that there is one central, trusted tool. The table below summarizes the unique OpenMRS components that would be ported over to the OCL TermBrowser and identifies some of the duplicative components that would likely be eliminated.

Examples of components that would be ported over from the OpenMRS Dictionary Manager to the OCL TermBrowser	Examples of duplicative components in the Dictionary Manager that would be eliminated (e.g. replaced by equivalents in the OCL TermBrowser)
Dictionary Management Module User in-app progress notifications OpenMRS Class-based Concept Schemas Selenium UI testing framework	User Profile, including listing of user repositories Organization Search Organization Details, including listing of organization repositories Search and Listing of public repositories Apps Menu

Integrating these products also reduces long-term maintenance and the amount of time it takes for new core OCL capabilities to be introduced to the OpenMRS community, making valuable features and workflows created for OpenMRS requirements available to all OCL users. This change will allow the volunteer-based OCL for OpenMRS Squad to focus on supporting the unique needs of the OpenMRS community, rather than having its limited capacity split by also maintaining a full web application with considerable overlap in functionality with the OCL TermBrowser. 

In addition to specific “shelf-ready artifacts”, including documentation and automated tests, this work contributes to a more shelf-ready product in several key ways:

• The OCL TermBrowser is currently under more active development and has higher test coverage

• OCL and OpenMRS development resources can be more efficiently allocated and responsive to user needs with the elimination of duplicative components that need to be maintained and focusing on new feature development on a single platform rather than in two platforms

• OCL maintains a growing set of resources and documentation with a weekly Community call that is focused on curating artifacts and adapting them for public use. Bringing these products closer together will help us to develop more useful public documentation more quickly.

• Core OCL infrastructure is improving rapidly, in part due to preparation for FISMA and WHO cybersecurity certification. One example is automated error tracking and notification, that the core OCL team actively monitors to address issues and troubleshoot with users. An integrated Dictionary Manager / TermBrowser can more readily benefit from these improvements.

• Other important software features (like a bulk import user interface) that already exist in the OCL TermBrowser will immediately be available to Dictionary Manager users upon integration.

Through prior OCL for OpenMRS fellowships and interviews with OpenMRS implementers, the OpenMRS Community and OCL for OpenMRS Squad identified key capacity gaps among community and implementation technologists in several areas: a) advanced front-end development, b) UX design, c) terminology/content product management, and d) collaborative, open source development processes. This investment will address these capacity gaps by onboarding and embedding fellows from the OpenMRS implementer community into the OCL for OpenMRS Squad, where they will actively contribute to achieving this project’s goals and, in doing so, build expertise among the implementer community while achieving their own professional development goals.

Digital Health Technologies

Open Concept Lab The Open Concept Lab (OCL) is a suite of open-source tools to help manage and use health terminologies. The OCL Terminology Service is RESTful API with support for FHIR based on the Sharing Valuesets and Concept Maps (SVCM) IHE Profile. It is designed to be used in a shared, cloud-based environment or as an architectural component within an organization’s data exchange architecture. The OCL TermBrowser is the primary tool for browsing, searching and managing content on an OCL Terminology Server, and it can also browse terminology on other SVCM compatible servers, such as HAPI FHIR. The Terminology Service is written in Python/Dango with Postgres as primary data store and Elastic Search as the search index. OCL’s current FHIR service is built on the HAPI FHIR Application Layer. The TermBrowser is a ReactJS web application.

OpenMRS The OpenMRS platform is a generic platform for developing electronic medical record (EMR) system implementations. It is designed to collect and manage patient-centric longitudinal medical data. The platform consists of a database, an abstraction layer between code and the database (i.e., Hibernate, a tool to map between Java objects and a database), a Java-based service layer, and a web services (a bespoke REST interface and a standard FHIR interface). The data model is heavily influenced by the HL7 Reference Information Model and uses a central concept dictionary to define the data it contains. As a result, the system is very flexible – not focused on a specific vertical use case – and can be adapted for any patient-centric health solution. The platform is designed to be modular, making it extremely extensible by allowing customizations to be added or removed to meet local needs.

Multiple APIs are available, supporting interoperability with external systems. Proven interoperability already exists between multiple systems, leveraging various parts of the OpenHIE architecture. For example, OpenMRS has leveraged the OpenHIE architecture to support case-based reporting, patient identity management and other services.  We also use Open Concept Lab for terminology support, and actively collaborate with the Open Concept Lab team for our terminology needs. We have been working closely with OpenHIE, building and evaluating the ability of OpenMRS to share data through the defined OpenHIE architectural stack. More information is available at https://wiki.openmrs.org/display/docs/Technical+Overview. OpenMRS is available in several different versions, including containerised versions which can be plugged into the broader Instant OpenHIE architecture.

Use Cases and User Stories

Implementer Interviews in 2021 followed one of three patterns. Each of these teams wished it was easier for their local non-technical colleagues to take on the burden of content work.

This will unlock the capacity of more local-level team members in each of these examples:

• Limited Resources set-up (The One Man Army model): The most commonly found setup. Only one person to look after concepts; often, the person is a developer who already has to manage complex technologies. They must now also find time for all the steps from content creation, to expert review, to form creation, to reporting. Overwhelmed with tasks, responsibilities, and stakeholders, these folks often feel like a one-man army. They wish their PM/BA team members could share this responsibility. 

• Some Content Team Resources (The Content Manager model): Typically limited to ~1 person at an implementation whose job focuses almost entirely on creating and managing forms and medical codes needed in the field. But they still have to turn to their developer colleagues if the software gets too complicated for them to use themselves. They wish they had tools to make their work faster, so they can focus on addressing incoming needs from clinical staff. 

• The Centralized Content Team model: This is more common among large organizations (teams managing many sites at a multi-national scale, such as international NGOs). These centralized Management level personas often have many other oversight responsibilities, and they wish staff closer to the field could take on more ownership of content management.

Objectives and Activities

This investment will be used to (a) integrate the OpenMRS Dictionary Manager and OCL TermBrowser web applications and improve shelf-readiness for local capacity; and (b) embed fellows from community and implementer groups into the OCL for OpenMRS Squad to build local capacity in UX design and development.

These objectives will be achieved by leveraging and strengthening the current OpenMRS fellowship program. In addition to receiving mentorship from senior technologists, fellows will be expected to participate in an OpenHIE Terminology Academy “boot camp”, complete a capstone project, serve as active members for the integration of these web applications, and engage with implementing organizations interested in applying the integrated web application.

Work Package 1: Integrate the OpenMRS Dictionary Manager and OCL TermBrowser web applications and improve shelf-readiness for content managers in the field

We anticipate adoption of the OpenMRS Dictionary Manager to be a major driver of growth for OCL in the coming months and years. The objectives and activities below (along with related activities in other awards) are critical to ensure that OCL and OpenMRS are prepared to handle this growth in a sustainable way and that new users have the necessary guidance and support.

Objective 1.1: Integrate OpenMRS Dictionary Manager components into the OCL TermBrowser to improve product sustainability and shelf-readiness for content managers in the field

This objective will bring workflows, functionality, and design paradigms from the OpenMRS Dictionary Manager directly into the OCL TermBrowser, providing a single platform and a unified experience for people managing OpenMRS concept dictionaries and other types of terminology content. This will be accomplished by porting existing ReactJS components from the Dictionary Manager over to the TermBrowser and eliminating certain duplicative components. Both products are written in ReactJS and leverage the same OCL Terminology Server REST API.

Note that this objective is just one of the key steps identified in a 2022 OpenMRS Dictionary Manager Plan that was developed as part of another Digital Square funded award. The plan was developed through a series of calls with OpenMRS and OCL community members with frequent input from the OCL for OpenMRS squad and the OCL Architecture call. The plan lays out a technical roadmap for unified design, integration and future feature requirements. Specifically, it includes new user experience designs, new user workflows in the TermBrowser, and the development of key back-end functionality into the OCL Terminology Server to support dictionary management (e.g. concept modifications) – all of these are beyond the scope of what is laid out here in this objective. Some of these items will take place simultaneously through resources that have already been committed, while others are awaiting community contributions or new resourcing. Most importantly, the 2022 OpenMRS Dictionary Plan represents a shared vision about how to meet the needs of two dynamic open source communities in a sustainable way.

Activities:

• Activity 1.1.1: Integration Plan - Joint planning for porting OpenMRS Dictionary Components over to the OCL TermBrowser

  • A high-level plan for integration of the Dictionary Manager into the OCL TermBrowser was already developed as part of OCL’s 2022 with the OpenMRS community. The plan includes porting of components in addition to new workflows and feature development. This activity focuses on creating a detailed work plan only for porting of components. New feature development is out of scope for this award.

  • Outputs:

    • Output 1.1.a: Joint plan for porting OpenMRS Dictionary Components over to the OCL TermBrowser

• Activity 1.1.2: Integrate Dictionary Manager and TermBrowser - Port selected components from the OpenMRS Dictionary Manager into the TermBrowser

  • Components identified in Output 1.1.a

  • Outputs:

    • Output 1.1.b: Port components identified in Output 1.1.a from the OpenMRS Dictionary Manager into the OCL TermBrowser

• Activity 1.1.3: Expand automated testing - Improve software productization by expanding automated tests for the OCL TermBrowser

  • OpenMRS Dictionary Manager has already implemented Cypress UI tests, and the OCL TermBrowser already implements some automated unit tests.

  • The OCL TermBrowser will adopt the Dictionary Manager’s UI testing framework and OpenMRS subscription testing (e.g. using the OCL Subscription Module), and automate within the software release process

  • Many of the individual OpenMRS Dictionary Manager tests will be ported over to the OCL TermBrowser and automated

  • Additional UI tests will be defined and implemented in the TermBrowser based on community priorities

  • Outputs:

    • Output 1.1.c: Draft plan for automation of user interface and subscription tests

    • Output 1.1.d: Implement automated testing framework as mapped out in Output 1.1.c

    • Output 1.1.e: Implement and automate actual UI tests as mapped out in Output 1.1.c

 

Objective 1.2: Revise and Expand field-staff-friendly documentation for the integrated Dictionary Manager and TermBrowser product

During OCL’s annual planning, we decided that 2022 is the “year of the user” for OCL. The timing is right to expand and revise documentation and related artifacts for users, implementers, and decision makers. Both the OCL TermBrowser and the OpenMRS Dictionary Manager have limited product information and user documentation available, with most of OCL’s current documentation being technical in nature and targeting developers (e.g. swagger and API references). OCL's main documentation site is at docs.openconceptlab.org.

With the Dictionary Manager integrated into the OCL TermBrowser, existing documentation will also need to be revised. Recent user experience work by OpenMRS fellow Suruchi Dhungana, Joe Amlung with Regenstrief, and Paul Adams with Sonder have produced materials such as user personas, use cases, and workflows that, with some adaptation for public use, would be invaluable for users and potential implementers.

Activities:

• Activity 1.2.1: Documentation Plan - Develop joint documentation plan for product information and user, implementer and technical documentation

  • The documentation plan will be developed collaboratively by the OCL and OpenMRS communities with input from other stakeholders

  • The documentation plan will include priorities as presented in this proposal and documentation outputs outside of the scope of this award, laying out a plan that extends beyond 2022 and that other community members may contribute to

  • The documentation plan include at minimum outputs related to product information, user documentation and technical documentation

  •  will be informed and prioritized by:

    • Shelf-readiness and maturity guidance provided by Digital Square, which includes (but is not restricted to):

      • Developer documentation (software design, patterns)

      • Implementer documentation (installation guides, architectural implementation patterns for scale, implementation validation checks

      • Administrator guides (configuration options and descriptions of features/options)

      • User guides and operation manuals (outlining the functionality of the system and how it operates)

    • Existing materials that can be adapted to public documentation with a small amount of work:

    • Immediate documentation needs from community members

  • Outputs:

    • Output 1.2.a: Documentation plan

• Activity 1.2.2: Product Information - Develop product information documentation

  • Product information consists of materials that outline key functions, value proposition, and quick access documents for decision makers.

  • Some relevant artifacts already exist that with a small amount of effort could be adapted as public documentation. Existing artifacts include:

    • Series of Shiriki webinar presentations on concept dictionary management

    • Planning documentation for the OpenMRS Dictionary Manager

    • Draft marketing materials for OCL TermBrowser that need to be expanded for the integration with the Dictionary Manager

  • Outputs:

    • Output 1.2.b: New “Production information” section published to OCL Docs (docs.openconceptlab.org) according to the plan from Output 1.2.a

• Activity 1.2.3: User Documentation - Create public user documentation, including user personas and workflows

• Create user documentation covering the key OpenMRS dictionary management use cases, defined workflows, user personas and user stories

• Some relevant artifacts already exist that could be adapted as public documentation:

  • Project-specific (OpenMRS, WHO SMART Guidelines, PEPFAR Metadata Sharing Platform) user experience materials, including user personas, use cases, workflows, and user stories

  • Generic user experience materials that are currently being developed for OCL that would be relevant across projects

• Outputs:

  • Output 1.2.c: New “User Documentation” section published to OCL Docs (docs.openconcetlab.org) according to the plan from Output 1.2.a

• Activity 1.2.4: Technical Documentation - Create public Technical Documentation covering a few priority gaps, including the generic Connector framework, Validation schemas, and functional requirements

  • Based on operational needs

    • OCL Terminology Service Functional Requirements

    • OCL Generic Connector framework documentation

    • OCL Validation Schema documentation, based on the existing OpenMRS validation schema

  • Outputs:

    • Output 1.2.d: Add new pages for “Functional Requirements”, “OCL Connector Framework”, and “Validation Schema” to the existing “Technical Documentation” section on OCL Docs (docs.openconceptlab.org) according to the plan from Output 1.2.a

 

Objective 1.3: Align Installation and Deployment of a bundled OpenMRS and OCL implementation with Instant OpenHIE

Implementers and developers may wish to fire up Instant OpenHIE preconfigured with OpenMRS and OCL, in order to take advantage of the integrated OpenMRS Dictionary Manager / OCL TermBrowser product and workflows.

The OpenMRS v3 distribution (https://github.com/openmrs/openmrs-distro-referenceapplication/tree/3.x) is  already containerized and is bundled with the OCL Subscription Module, which allows an OpenMRS instance to subscribe to a concept dictionary published and managed on an instance of the OCL Terminology Server. 

All OCL services and products are containerized and are generally compatible with Instant OpenHIE’s approach.

We anticipate multiple configurations to be of interest to the community, supporting various development environments and implementation scenarios. Configuration scenarios may include:

• Instant OpenHIE bundled with OpenMRS v3 and configured to interface with OCL Online for both the OCL Terminology Service and OCL TermBrowser (i.e. with no local OCL instances)

• Instant OpenHIE bundled with OpenMRS v3 and the OCL TermBrowser, both of which are configured to point to the OCL Terminology Service hosted at OCL Online

• Instant OpenHIE bundled with OpenMRS v3 and with OCL TermBrowser and OCL Terminology Server (i.e. no interaction with OCL Online)

Activities:

• Activity 1.3.1: Instant OpenHIE Documentation - Develop implementation and technical documentation on the Instant OpenHIE configuration scenarios bundled with OpenMRS v3 based on inputs from OCL and OpenMRS communities and Instant OpenHIE subject matter experts

  • The first step is to develop documentation to define the specific Instant OpenHIE configuration scenarios of interest to guide further specification and development

  • Note that we expect actual specification and development of the documented Instant OpenHIE configuration scenarios to take place within the timeline of this award; however, we cannot commit to this due to dependencies on inputs and technical contributions from other organizations.

  • Outputs:

    • Output 1.3.a: Implementation and technical documentation of Instant OpenHIE configuration scenarios bundled with OpenMRS v3 and OCL to guide further specification and development

 

Work Package 2: Embed fellows from community and implementer groups into the OCL for OpenMRS Squad to build local capacity in UX design and development

Historically, the OpenMRS Dictionary Management Web App and Subscription Module have been built by US-based developers in partnership with interns from Andela, a software talent company originally based in Nigeria. Few OpenMRS implementations have shared requirements or development resources with the OCL for OpenMRS Squad.

As a result of limited local capacity in terminology, product management, UX design, and development, OpenMRS implementations rely on contributions from developers and PMs who are not familiar with the local context. By supporting the targeted implementation of the OpenMRS Fellowship Program, this investment will be used to increase local talents’ capacity to design and develop OCL, improving the likelihood of local adoption, contributions from implementers, and the long term sustainability of two Global Goods. 

Objective 2.1: Strengthen engagement of community and implementer groups into the OCL for OpenMRS Squad by building sustainable local capacity in UX design and development.

With this objective, we aim to strengthen the connection between country implementations and the OCL for OpenMRS Squad by strategically recruiting and engaging fellows from 2-3 OpenMRS implementations and matching them with established technical mentors. This work builds on recent improvements to and expands the scale of the current OpenMRS Fellowship Program by strengthening fellow and mentor selection as well as increasing implementation participation.

We envision that this investment will support up to three of the following types of fellowships:

• Level 3/4 Development, focused on ReactJS development

• Level 4/5 Development, focused on ReactJS and possibly Python development

• Project Management/Business Analysis, focused on eliciting and communicating user needs  as well s supporting UX design

An initial set of candidates for Mentors and Backup Mentors have already been identified (note that this list of mentors is not be confirmed at this stage):

• Sunny Aggarwal, Sr. Engineer, OCL

• Joe Amlung, Regenstrief – Mentor for PM fellow

• Michael Bontyes, MSF – Mentor for BA/Documentation fellow?

• Grace Potma, OpenMRS – Backup mentor for PM fellow

• Jonathan Payne, OCL – Backup mentor for Development fellows

This objective will be achieved through the following activities:

• Activity 2.1.1: Conduct outreach to implementations 

  • Outputs:

    • Output 2.1.a: Documentation of outreach activities

• Activity 2.1.2: Recruit, select, and match fellows with project mentors

  • Outputs:

    • Output 2.1.b: Documentation of recruitment process and selection outcome

• Activity 2.1.3: Conduct orientation webinars for fellows and mentors

  • Outputs:

    • Output 2.1.c: Presentation materials and notes from orientation webinars for fellows and mentors

• Activity 2.1.4: Assist fellows to create a fellowship plan, outlining specific activities and target skills/knowledge.

  • Outputs:

    • Output 2.1.d: Fellowship plans outlining specific fellow activities and target skills/knowledge for up to 3 fellow/mentor pairs

• Activity 2.1.5: Support fellows to design a capstone project, including an optional rotation with an OpenMRS implementation

  • Outputs:

    • Output 2.1.e: Links to final write-ups of fellow capstone projects

 

Objective 2.2: Build local capacity in UX design and development by embedding fellows into the OCL for OpenMRS Squad.

This objective aims to build expertise with the OCL and OpenMRS platforms by implementing fellowship plans and associated country-level rotations.

As part of the OpenMRS Fellowship Program, fellows will receive approximately 9 months of mentorship and real-world experience as active members of the project team. In addition to gaining valuable technical skills, fellows will become skilled at using open source community processes and tools to collaborate together on priority feature. Fellows will demonstrate their learning via a capstone project. This capstone project may be combined with a rotation with an implementation as part of a “mentorship cascade.”

This objective will be achieved through the following activities:

• Activity 2.2.1: Support fellows to complete a Terminology Boot Camp (see “Terminology Academy” at academy.ohie.org)

  • The OpenHIE Terminology Academy online course was developed in 2021Q4 and will provide foundational knowledge for fellows to contribute productively to work packages outlined in this award and, more generally, to be active contributors to the OCL for OpenMRS squad

  • Outputs:

    • Output 2.2.a: Notes from Terminology Boot Camp meetings and facilitator reflections on the experience

• Activity 2.2.2: Provide ongoing support to mentors via “Mentorship for Mentors” sessions

  • Outputs:

    • Output 2.2.b: Links to presentation materials and notes from Mentorship for Mentors sessions

• Activity 2.2.3: Mentor fellows to complete technical tasks and a capstone project/implementation rotation based on their specialization

  • Outputs:

    • Output 2.2.c: Quarterly documentation of fellow progress on assigned technical tasks and capstone project

• Activity 2.2.4: Monitor fellows’ progress using their fellowship plan, periodic blog posts, progress reports, and a final evaluation

  • Outputs:

    • Output 2.2.d: Documentation of final evaluation

 

Community Feedback

The normal way of doing work for both the OpenMRS and OCL communities is through open, community-focused forums. Our established processes create opportunities for feedback from all relevant personas, from terminology SMEs to field end-users. These forums include:

• Weekly OCL for OpenMRS Squad call (forum will serve as a primary and operational meeting for this award)

• Weekly OCL Architecture call

• Weekly OCL Developer call

• Weekly CIEL Office Hours call (forum to hear many practical use cases and challenges faced by concept managers in the field)

• Bi-weekly CIEL & OCL User Requirements PM/BA call

• Monthly OpenHIE Terminology Services Subcommunity call

• Monthly OCL & OpenMRS Product Leadership call

 

Schedule

Activity	Team Location Month/ Quarter	Quarter
		2022Q2	2022Q3	2022Q4	2023Q1
		1	2	3	4
Work Package 1: Integrate OpenMRS Dictionary Manager with OCL TermBrowser and improve shelf-readiness		x	x	x	x
Objective 1.1: Integrate OpenMRS Dictionary Manager components into the OCL TermBrowser to improve product sustainability and shelf-readiness for content managers in the field		x	x	x	x
Activity 1.1.1: Integration Plan		x
Activity 1.1.2: Integrate Dictionary Manager and TermBrowser		x	x	x
Activity 1.1.3: Expand automated testing				x	x
Activity 1.1.4: User Testing and Detailed Feedback from Field Staff Representatives			x	x	x
Objective 1.2: Revise and Expand field-staff-friendly documentation for the integrated Dictionary Manager and TermBrowser product		x	x	x	x
Activity 1.2.1: Documentation Plan		x
Activity 1.2.2: Product Information			x	x
Activity 1.2.3: User Documentation			x	x
Activity 1.2.4: Technical Documentation				x	x
Objective 1.3: Align Installation and Deployment of a bundled OpenMRS and OCL implementation with Instant OpenHIE				x	x
Activity 1.3.1: Instant OpenHIE Documentation				x	x
Work Package 2: Embed fellows from community and implementer groups into the OCL for OpenMRS Squad to build local capacity in UX design and development		x	x	x	x
Objective 2.1: Strengthen engagement of community and implementer groups into the OCL for OpenMRS Squad by building sustainable local capacity in UX design and development.		x	x	x	x
Activity 2.1.1: Conduct outreach to implementations		x
Activity 2.1.2: Recruit, select, and match fellows with project mentors		x
Activity 2.1.3: Conduct orientation webinars for fellows and mentors		x	x
Activity 2.1.4: Assist fellows to create a fellowship plan, outlining specific activities and target skills/knowledge.		x	x
Activity 2.1.5: Support fellows to design a capstone project, including an optional rotation with an OpenMRS implementation				x	x
Objective 2.2: Build local capacity in UX design and development by embedding fellows into the OCL for OpenMRS Squad		x	x	x	x
Activity 2.2.1: Support fellows to complete a Terminology Boot Camp (see “Terminology Academy” at academy.ohie.org)		x
Activity 2.2.2: Provide ongoing support to mentors via “Mentorship for Mentors” sessions		x	x	x	x
Activity 2.2.3: Mentor fellows to complete technical tasks and a capstone project/implementation rotation based on their specialization		x	x	x	x
Activity 2.2.4: Monitor fellows’ progress using their fellowship plan, periodic blog posts, progress reports, and a final evaluation		x	x	x	x

 

Deliverables

Deliverable	Month/Quarter Due
Work Package 1: Integrate the OpenMRS Dictionary Manager and OCL TermBrowser web applications and improve shelf-readiness
Objective 1.1: Integrate OpenMRS Dictionary Manager components into the OCL TermBrowser to improve product sustainability and shelf-readiness
Output 1.1.a: Joint plan for porting OpenMRS Dictionary Components over to the OCL TermBrowser	2022Q2
Output 1.1.b: Port components identified in Output 1.1.a from the OpenMRS Dictionary Manager into the OCL TermBrowser	2022Q4
Output 1.1.c: Draft plan for automation of user interface and subscription tests	2022Q2
Output 1.1.d: Implement automated testing framework as mapped out in Output 1.1.c	2022Q3
Output 1.1.e: Implement and automate actual UI tests as mapped out in Output 1.1.c	2023Q1
Output 1.1.f: User Testing Protocol	2022Q3
Output 1.1.g: User Testing Findings, Iteration 1: UX and Workflow Feedback	2022Q4
Output 1.1.g: User Testing Findings, Iteration 2: UX and Workflow Feedback	2023Q1
Objective 1.2: Revise and Expand documentation for the integrated Dictionary Manager and TermBrowser product
Output 1.2.a: Documentation plan	2022Q2
Output 1.2.b: New “Production information” section published to OCL Docs (docs.openconceptlab.org) according to the plan from Output 1.2.a	2022Q3
Output 1.2.c: New “User Documentation” section published to OCL Docs (docs.openconcetlab.org) according to the plan from Output 1.2.a	2022Q4
Output 1.2.d: Add new pages for “Functional Requirements”, “OCL Connector Framework”, and “Validation Schema” to the existing “Technical Documentation” section on OCL Docs (docs.openconceptlab.org) according to the plan from Output 1.2.a	2023Q1
Objective 1.3: Align Installation and Deployment of a bundled OpenMRS and OCL implementation with Instant OpenHIE
Output 1.3.a: Implementation and technical documentation of Instant OpenHIE configuration scenarios bundled with OpenMRS v3 and OCL to guide further specification and development	2022Q4
Work Package 2: Embed fellows from community and implementer groups into the OCL for OpenMRS Squad to build local capacity in UX design and development
Objective 2.1: Strengthen engagement of community and implementer groups into the OCL for OpenMRS Squad by building sustainable local capacity in UX design and development.
Output 2.1.a: Documentation of outreach activities	2022Q2
Output 2.1.b: Documentation of recruitment process and selection outcome	2022Q2
Output 2.1.c: Presentation materials and notes from orientation webinars for fellows and	2022Q3
Output 2.1.d: Fellowship plans outlining specific fellow activities and target skills/knowledge for up to 3 fellow/mentor pairs	2022Q3
Output 2.1.e: Links to final write-ups of fellow capstone projects	2023Q1
Objective 2.2: Build local capacity in UX design and development by embedding fellows into the OCL for OpenMRS Squad.
Output 2.2.a: Notes from Terminology Boot Camp meetings and facilitator reflections on the experience	2022Q2
Output 2.2.b: Links to presentation materials and notes from Mentorship for Mentors sessions	2022Q3, 2022Q4, 2023Q1
Output 2.2.c: Quarterly documentation of fellow progress on assigned technical tasks and capstone project	2022Q3, 2022Q4, 2023Q1
Output 2.2.d: Documentation of final evaluation for each fellow	2023Q1

 

Risk Mitigation

• The OpenMRS is highly volunteer driven, meaning that the momentum that the OCL for OpenMRS Squad has experienced over the last 2 years is not guaranteed to continue, which would put the ongoing development of the OpenMRS-specific components at risk.

  • The Fellowship program proposed here is directly targeting this potential risk, attempting to increase capacity for this project and institutionalize the knowledge in field-friendly documentation.

• The applicant pool for the fellowship program may not have the required background or skill level, which could limit progress on certain technical outputs and increase the burden on mentors.

  • Based on lessons learned from the OpenMRS fellowship program in 2021, we will also assign “backup mentors” to each fellow to help spread the mentorship burden. We are also connecting some core engineering expertise from the OCL team to ensure that oversight is available.

• Availability of Instant OpenHIE subject matter expertise is critical for designing the right implementation scenario configurations and making Instant OpenHIE bundled with OpenMRS+OCL a reality.

  • The OCL team already participates in a number of forums with Instant OpenHIE subject matter experts and we anticipate that as long we start early in the project, we will be able to move this work forward throughout the project timeline.