Clinician/analyst focused vocabulary mapping workflow.

[natb1]

Summary

The vocabulary mapping that exists in Perseus today is one of the key sources
of value because it creates a streamlined user experience compared to other
options. This benefit is mitigated, though, with workflows that are indirect
and include ETL activities such as database integration and design of the data
flow. We want a streamlined workflow for vocabulary mapping that specifically
targets an analyst-type persona (clinician, informaticist, data scientist, statistician, etc.)

• Include a one paragraph brief summarizing the scope of the proposal.
  Outline the scope of the proposal by using plain language, and also be explicit
  about what is out of scope.

• Summarize the key user personas that will be affected by this proposal. Describe the
  user workflow.

• Summarize the value created by the proposal - ex. what audience will be impacted
  and what is the size of that audience. What are the limitations of the existing solutions.

• Describe a strategy for acceptance testing of the proposal.

• Is the proposal supported by the current (non-functional) design?
  If not, also draft a design proposal for review. List the relevant design proposals and
  how they are related to this feature proposal.

• Draft the development tasks that would be required to implement the proposal.
  Estimate the level of effort for each task in person days. No task should take more
  than 5 person days.

• Summarize the anticipated maintenance costs for the proposal.

  • Does the proposal have a dependency on
    cross-cutting functionality such as database management, scheduling, logging etc.? What
    maintenance would be required if the implementation of that cross-cutting concern changed.
  • Does the proposal have an implicit dependency on future releases?
    For example, support for new SDK's, bindings or new documentation specifications
    would all require ongoing updates in future releases.
  • End user support: What support will end user personas require to use the feature?
    How will that support requirement be mitigated.

• Provide a plan for executing/sponsoring the implementation and maintenance of the proposal.
  What are the main risks to implementation and how can they be mitigated?

• Attend the Perseus Working Group to discuss your proposal.

User Personas and Workflows

The target persona is a clinician-type user - differentiated from an engineering-type
user by domain knowledge and technical capability. This persona needs a "self-service"
workflow that enables them to create vocabulary mappings that can be provided to
the engineering-type persona as part of a specification to develop the ETL. The workflow
must be streamlined so that the steps make sense from the perspective of different personas.
I.e. the analyst's experience should be personalized so they are not expected to
know Perseus implementation details to accomplish their task. Ex:

• Analyst should not be exposed to data integration tasks.
• Vocabulary mapping should be decoupled from data flow design.
• Mapping activities should use existing data profile, rather than importing CSV.

Value Summary

Vocabulary mapping is a core use case for Perseus and it is differentiated
by other solutions by having a streamlined user experience. Curating the
workflow the analyst will help ensure the experience is streamlined.

Acceptance Testing

An analyst persona can navigate to a page in Perseus
and - "self-service", without support from other resources
or additional documentation - perform
all the tasks necessary to create a vocabulary mapping
to serve as part of an ETL specification. This includes:

• defining new vocabularies
• mapping vocabularies to columns in the source data
• validating and customizing mappings

In particular, these activities can be done without context switching
or navigating around engineering focused activities. Ex. the vocabulary
mapping workflow must use an existing data profile rather that
asking the analyst to export and upload a csv of their health data.

This acceptance criteria will be validated against user feedback. In
addition, an automated testing strategy must be developed to
verify implementation details and mitigate regressions.

Design Considerations

There are several reasons to recommend partitioning the operational
and software architecture into a new "component" focused on the vocabulary mapping
use case.

• The Perseus project is not optimized for developer experience. Ex:
  • Software dependencies from many technologies and often very out of date.
  • Container environment is very heavy, has many interdependencies, and very limited tooling for dev.
• We would like to invite new contributors to participate in development
  of this key use case. We expect software boundaries to follow team boundaries.
• We expect user experience boundaries to flow from software boundaries.

For these reasons the design recommendation to develop a component that can be
developed, operationalized tested as a decoupled component of the core Perseus codebase.

Implementation Plan

Maintenance Plan

Execution Plan

Working Group Notes