Scenario modeling underway #donormilk #patient-member-subgroup


Mikhail Elias <hyperledger@...>
 

Hi - Scenario modeling updates to the wiki are now underway :
https://wiki.hyperledger.org/groups/healthcare/analysis-human-milk#services_model

The scenario documentation follows a standard template :
https://wiki.hyperledger.org/groups/healthcare/scenario-template

You will also find brief instructions for modeling scenarios using this template here :
https://wiki.hyperledger.org/groups/healthcare/scenario-modeling-instructions


In summary, there are three sections to each scenario : narrative summary, structured analysis and sources.

* Narrative summary : This is the starting point for each scenario. Analysts are encouraged to provide sufficient detail so that the summary serves as a standalone description of the scenario, and it is possible to identify roles, resources, contexts, rules/policies and flows, including exceptions or alternatives that may occur.

* Structured analysis : Based on the narrative summary, the analyst should be able to fill in the various list items in the second template section. This is typically an iterative process, often requiring further elaboration/clarification within the narrative itself. Analysts should refer to the roles/actors, resources and contexts enumerated on the main services model page, using wiki-links to the individual wikipages for each entity (still to be created). Each such entity will have a structured template for the information contained on each wikipage, enabling fluid navigation between all entities comprising the scenario.

* Sources : Scenarios should refer to the primary data (interviews, meeting transcripts) or knowledge base (publications, policies and guidelines) from which the narrative material was prepared. This practice ensures good bidirectional traceability and supports verification/validation.

Let me know whether you have any questions or feedback.

The next steps include preparation of additional analytical artifacts using this baseline services system model -- identification of problems, risks and needs linked directly to specific scenarios and related model elements, including quantitative analyses, as well as new policies (functional and quality of service requirements) directed toward specification of the technical solution.

The goal is to enable a fluid and iterative analytical methodology that supports agile technical solution development while also supporting the broader range of planning and marketing/communications activities and stakeholders.

We have been having some discussion about prototyping a visual design tool that could facilitate this type of system modeling work, possibly incorporating configuration file and code generation capabilities. It could potentially serve as a possible replacement for Composer and a Fabric workbench.


Marissa Iannarone
 

Hi Mikhail,

You are a true Wiki guru! Thank you for putting this together and I'm eager to hear feedback from the team. 

Here are a few thoughts to consider, and I'm happy to add a discussion item to the call this Friday if people would like to discuss.
  • The scenarios seem analogous to 'epics' found in agile software development- larger pieces of work that then get broken down into specific tasks for execution, and I think this is a good way for us to identify pieces of work to be done
  • I see the ultimate purpose of these scenarios to help us define what needs to get built, and I think that JIRA is a better tool to facilitate the translation from scenario/epic to product; is there something that the wiki would offer that couldn't be kept in JIRA? I think we could take a lot of the structure/definitions/components that have been identified in the scenario modeling work and create guidelines for using JIRA, which allows us to better track work at the task level and who is doing what.
  • It has been difficult to get folks to engage with the wiki thus far, and I'm wondering if we go this route how likely it is that we will get the engagement that we hope
Best,
Marissa

Marissa Iannarone
Associate with Forum Solutions LLC
phone number: +01 (360) 525 4961
email: mari.iannarone@...



On Mon, Oct 8, 2018 at 3:56 PM Mikhail Elias <hyperledger@...> wrote:
Hi - Scenario modeling updates to the wiki are now underway :
https://wiki.hyperledger.org/groups/healthcare/analysis-human-milk#services_model

The scenario documentation follows a standard template :
https://wiki.hyperledger.org/groups/healthcare/scenario-template

You will also find brief instructions for modeling scenarios using this template here :
https://wiki.hyperledger.org/groups/healthcare/scenario-modeling-instructions


In summary, there are three sections to each scenario : narrative summary, structured analysis and sources.

* Narrative summary : This is the starting point for each scenario. Analysts are encouraged to provide sufficient detail so that the summary serves as a standalone description of the scenario, and it is possible to identify roles, resources, contexts, rules/policies and flows, including exceptions or alternatives that may occur.

* Structured analysis : Based on the narrative summary, the analyst should be able to fill in the various list items in the second template section. This is typically an iterative process, often requiring further elaboration/clarification within the narrative itself. Analysts should refer to the roles/actors, resources and contexts enumerated on the main services model page, using wiki-links to the individual wikipages for each entity (still to be created). Each such entity will have a structured template for the information contained on each wikipage, enabling fluid navigation between all entities comprising the scenario.

* Sources : Scenarios should refer to the primary data (interviews, meeting transcripts) or knowledge base (publications, policies and guidelines) from which the narrative material was prepared. This practice ensures good bidirectional traceability and supports verification/validation.

Let me know whether you have any questions or feedback.

The next steps include preparation of additional analytical artifacts using this baseline services system model -- identification of problems, risks and needs linked directly to specific scenarios and related model elements, including quantitative analyses, as well as new policies (functional and quality of service requirements) directed toward specification of the technical solution.

The goal is to enable a fluid and iterative analytical methodology that supports agile technical solution development while also supporting the broader range of planning and marketing/communications activities and stakeholders.

We have been having some discussion about prototyping a visual design tool that could facilitate this type of system modeling work, possibly incorporating configuration file and code generation capabilities. It could potentially serve as a possible replacement for Composer and a Fabric workbench.


Mikhail Elias <hyperledger@...>
 

Hi Marissa,

Thanks for the feedback. There are certainly a variety of methodologies and plenty of views/opinions about each. Agile practices typically rely on levels or layers -- and plenty of mixed metaphors -- to describe how work is organized. For example : initiatives, epics, features, stories, tasks, etc.

On the one hand, concepts such as epics and stories are used to establish a narrative framework from the client's perspective - a description of the user's domain that serves to map out a solution from the current-state ( as-is, problem-state) to the future-state (to-be, goal-state). Having this type of narrative can help with stakeholder communication as well as product/service/solution marketing.

On the other hand, concepts like product backlogs and tasks are defined from the developer's perspective - capturing discrete units of work. And higher-level concepts like themes and initiatives incorporate the organization management's perspective - but could be the client's or the product developer's/service provider's management.

The human milk services system could be described as an epic, with each 'scenario' representing a user story. Our current use of 'scenario' is really more of a temporary placeholder, but is closer to what is typically referred to as a 'use case'.

Jira is a great tool for software development teams, who represent one set of stakeholders in the overall platform-product development organization or multi-stakeholder collaboration. The wiki supports activities -- such as building a shared knowledge base -- that Jira is not intended to support; and our WG is chartered to work on a range of knowledge-intensive activities beyond software product development.

I would recommend we define a clear interface between documenting epics and stories via the wiki, and mapping these into product features, backlog items, tasks, etc., using Jira. Migrating to Confluence will facilitate this since both are designed to be complementary tools within the same vendor's product suite.

It is an important and valuable exercise to further refine methodologies for development of distributed, multi-stakeholder IT infrastructure platform-product-services systems. The business case is excellent - there are numerous regional health systems integration, e-government and smart-cities initiatives that fail to scale beyond early-stage pilots because they are unable to engage multiple stakeholders due to lack of appropriate tools and methodologies. Integrating and balancing multi-stakeholder perspectives and workflows under a common set of metaphors seems to still be a work in progress.


Mikhail Elias <hyperledger@...>
 

I also believe it is important that we review and consider updating the WG Charter and Mission statement, as outlined in last Friday's meeting agenda.

Preparing a more formal strategic plan outlining goals, strategies and objectives, along with a project portfolio plan and roadmap may also be important related activities to undertake at this point.

A key consideration going forward is the extent to which we focus on software platform-product development versus supporting a broader developer ecosystem. This would drive decisions about how we design and implement WG collaboration and developer tools such as Confluence and Jira.

Do we envision building one or more healthcare infrastructure platform-products using Fabric, other Hyperledger tools and other projects sponsored by the Linux Foundation?

Do we envision building an infrastructure platform onto which third-party apps are deployed -- or otherwise integrated with -- to support the broad range of use cases within a health system?

Do we envision collaborating with the Public Sector WG and Social Impact WG on solutions, for example, to support regional- or national-scale public health and healthcare delivery systems?

Do we envision integrating our solutions into broader regional integration, e-government or e-marketplace infrastructure solutions, for example, as part of smart-cities initiatives?

We may be better able to engage stakeholders going forward with a clearer definition of mission and scope of work, as well as by defining a stronger business case for supporting and investing resources into this work.

Having a well-defined plan for how we can help develop and support an ecosystem of solution and services providers with developing, deploying and maintaining this type of platform-product-services infrastructure model, and making the investment case for financing these types of hybrid public-private sector development programs -- especially in Latin America, Africa and Asia -- would be an invaluable resource to decision-makers and planners.

Assuming these activities are within scope of the Linux Foundation and Hyperledger project, having these strategic plans in place could provide critically important support to a broader group of stakeholders as financing decisions regarding the 2030 Agenda wrap up and stakeholders shift focus toward implementation.


Marissa Iannarone
 

Hi Mikhail,

Great points. Regarding the donor milk use case, I agree that there is certain information that is better suited for the wiki, and that JIRA is more product team focused than externally facing. I do think defining what information goes where will be helpful to ensure we don't have duplication of effort/information. I also don't want to over-engineer on the documentation side where not needed. Your comments are a great reminder that the donor milk use case is just one example of how this wiki framework could be used, and PoCs like this certainly aren't the only focus of the HCWG. That's why getting other opinions on this would be helpful.

Regarding the charter, I would vote to get it to the top of the agenda for our next meeting to ensure it is discussed. You provide some great questions for us to answer.

Best,
Marissa

Marissa Iannarone
Associate with Forum Solutions LLC
phone number: +01 (360) 525 4961
email: mari.iannarone@...



On Tue, Oct 9, 2018 at 10:36 AM Mikhail Elias <hyperledger@...> wrote:
I also believe it is important that we review and consider updating the WG Charter and Mission statement, as outlined in last Friday's meeting agenda.

Preparing a more formal strategic plan outlining goals, strategies and objectives, along with a project portfolio plan and roadmap may also be important related activities to undertake at this point.

A key consideration going forward is the extent to which we focus on software platform-product development versus supporting a broader developer ecosystem. This would drive decisions about how we design and implement WG collaboration and developer tools such as Confluence and Jira.

Do we envision building one or more healthcare infrastructure platform-products using Fabric, other Hyperledger tools and other projects sponsored by the Linux Foundation?

Do we envision building an infrastructure platform onto which third-party apps are deployed -- or otherwise integrated with -- to support the broad range of use cases within a health system?

Do we envision collaborating with the Public Sector WG and Social Impact WG on solutions, for example, to support regional- or national-scale public health and healthcare delivery systems?

Do we envision integrating our solutions into broader regional integration, e-government or e-marketplace infrastructure solutions, for example, as part of smart-cities initiatives?

We may be better able to engage stakeholders going forward with a clearer definition of mission and scope of work, as well as by defining a stronger business case for supporting and investing resources into this work.

Having a well-defined plan for how we can help develop and support an ecosystem of solution and services providers with developing, deploying and maintaining this type of platform-product-services infrastructure model, and making the investment case for financing these types of hybrid public-private sector development programs -- especially in Latin America, Africa and Asia -- would be an invaluable resource to decision-makers and planners.

Assuming these activities are within scope of the Linux Foundation and Hyperledger project, having these strategic plans in place could provide critically important support to a broader group of stakeholders as financing decisions regarding the 2030 Agenda wrap up and stakeholders shift focus toward implementation.