FHIR Chat · ExampleScenario · fhir/infrastructure-wg

Stream: fhir/infrastructure-wg

Topic: ExampleScenario

---

Gustav Vella (Nov 18 2018 at 13:48):

not sure this question belongs in this stream. Am putting it here since ExampleScenario part of Infrastructure.

Gustav Vella (Nov 18 2018 at 13:48):

I'm trying to set up a way of having users describe valid "clinical usecases" - using local site systems and the data they contain. My working definition of clinical usecases is twofold:
- a protocol for treatment (research or standard healthcare)
- a protocol for an improved process/workflow at a given caregiver site
Both can have goals defined as primary or secondary endpoints - the secondary ones being inputs for the next primary ones (general pattern for clinical research).
I could also have a protocol for a new treatment AND improved process goals

This is still early stage so I'm using a document template to describe systems and Processes of a given site as structured narratives and scenarios - hence the way systems process data is also a scenario (Data Granularity, Data Retrievability: just in time vs. hourly vs 1/day). Eventually I hope to come up with something more formal like a Zachmann framework or petri net and do some nlp to support linking the narratives to the formalism. That bit is still a long way up the road.
The need is grounded in gruesome reality not theoretical aspirations: I just have the problem that my physicians are writing broken usecases which don't hold water after a first quick cross-check

Gustav Vella (Nov 18 2018 at 13:50):

This is what my template looks like:

• Scenario Title/Name

• Source (the origin of the scenario (e.g. in an interview or discussion).

  • Who is claiming that this is a scenario?
  • Who, if need be, is the contact person for queries?

• Role:
  -A role is always a role within the given environment and processes in which the system will be involved.

  • By giving the role, and limiting the description of activities to that given role, hidden interactions can be revealed and addressed.

• The Context or Background/Setting describes the relevant environment of the user.

  • The context helps, recognize the needs and constraints of the user in order to design adequate solutions.
  • By describing the context, subtle constraints or requirements are revealed and can be explicitly addressed.

• The Primary Goal is what the user is trying to achieve

  • The Primary Goal must not contain any secondary objectives. Any secondary objectives should be listed in the “Motivation & Expectation” sections.
  • The primary goal should be objectively verifiable. It serves for developing software tests for software development and quality assurance.

• The typical course of activity. Course of the actual activity:

  • The course of activity is described in a narrative but concrete way. It simplifies the visualization and comprehension of the scenario.
  • The activity case is free of variations, edge cases or special cases and focusses on the actual purpose. Edge cases and variations should rather to be dealt with in the Use Cases within the solution domain (as opposed to the problem domain)

• Besides the primary goals, the user has further secondary Motives and possibly several concrete Expectations, which may be relevant to the scenario.

  • These expectations shed light on aspects which have to be taken into consideration in a solution. This information is very important for designing a valid concept.
  • Expectations usually depend on the respective scenario. If personas are used, the general attitudes towards life would be documented there and not within the scenario.

• Boundaries and Confines (of the scenario): Sometimes it may be necessary or helpful to clearly distinguish the boundaries between one scenario and another.

  • This is necessary, in order to avoid mixing up activities in scenarios. It also serves the purpose of indicating which parts should be addressed separately when working on the concept.
  • If you notice that you have to specify too many boundaries to make the case, you probably should check whether the primary goal has been too widely defined.

• Frequency of Occurrence is the number per units of time by which the scenario occurs in practice. In other words, the frequency with which the specific person (role) will on average pursue that given primary goal.

  • This information serves activities in the conceptual phase of software development (Usability and Design) which will decide on adequate prominence and accessibility of a given functionality within the whole application user interface.
    • A specific number (or range) as well as a time span should always be given.
    • Positve examples: “2.5 times per month, “A maximum of once per year”
    • Negative examples: “several times per month”, “3-4 times”, “quite seldom”

This template can also be used to describe systems: As with a user, a system or its components "want" something (an action) in order to achieve something (a goal). A system or its components also have a context and a frequency with which this happens.

Gustav Vella (Nov 18 2018 at 13:51):

now to the point:

I'm looking at https://hl7.org/fhir/2018Jan/examplescenario.html and am thankful. And was positively surprised when @David Hay pointed this out to me. Especially the precondition / postcondition with structured references to the process steps. What is the intention of the new resource? I'm trying to understand the intent which led up to that model. Has anyone filled in a set of scenarios for a real usescase which they could share? I hear there is some tooling for this: @Jose Costa Teixeira ?

Lloyd McKenzie (Nov 18 2018 at 15:19):

I suspect what you really need is PlanDefinition. PlanDefinition lets you define protocols, activity templates, etc. The purpose of ExampleScenario is to provide an example walkthrough that describes the specific instances created when a given protocol is executed. While it can be used to explain a protocol, it's explaining by example ("Dr. Jones admits patient Eva Everywoman on June 2, 2018, then orders the following lab tests: ...") rather than by describing the specific rules, goals, etc. The latter is the purpose of PlanDefinition. ExampleScenario's primary purpose is for inclusion in implementation guides to help developers understand how the abstract behavior described in a specification would be realized in a 'real' scenario.

Gustav Vella (Nov 18 2018 at 16:50):

Thanks @Lloyd McKenzie - You are right with PlanDefinition. I expressed myself a bit clumsily vis s vis plan vs. instance. Taking the inverse of your statement >>While it can be used to explain a protocol, it's explaining by example<<, I should be able to sensibly use ExampleScenario as a way towards a valid PlanDefinition. right? That's one aspect I'm pursuing - but that's the smallest problem. The bigger challenge is this: Given I have a plan definition on one side - which I have to execute on 17 cancer care sites, I want to be sure that I can execute it in a valid way on those sites - within their different local systems and with their varying processes. What I'm looking for is a way to formally describe the site/caregiving organization - their capabilities (systems & processes). I have to translate the execution of that protocol in terms of the capabilities of that site. I have to validate the use case/protocol execution based on the capabilites (systems an processes) on that site. So I have the docs, documentalists, and some IT staff, name the systems and processes and write the plan definition in terms of a narrative relating to the local systems and processes. ExampleScenario seemed to be the "Glue" to help me get there more formally. It's obvious to me that domain specialists or algorithms have to do the formal linking-up to systms but PlanDefinition helps me get as close as possible.

Gustav Vella (Nov 18 2018 at 16:50):

How would I best describe the systems and processes on site formally? What would that be in FHIR .. more formally beyond ExampleScenario? Would that really be a PlanDefinition?

David Hay (Nov 18 2018 at 17:51):

yeah - PlanDefinition would be how the plan is formally expressed - but couldn't the ExampleScenario (+/- extensions) be used to 'document' what is happening in a specific situation (or instance) as a step towards deriving the PlanDefinition?

Lloyd McKenzie (Nov 18 2018 at 17:53):

You would create site-specific PlanDefinitions that are based on the "master" PlanDefinition. The ExampleScenario could be used to demonstrated how a PlanDefinition might work on a specific patient for a specific set of problems over a specific period of time

Gustav Vella (Nov 18 2018 at 18:09):

OK thanks. I guess I have to look at the specs again and try things out a little first.

---

Last updated: Apr 12 2022 at 19:14 UTC