There is an intermediate value to the workflows if they can be used in
software. One
can model the behavior of the system without having to have the entire
system under
workflow management. This can help assess the accuracy of the workflow
diagrams
to be sure that side effects are what you think they are. Think of this
a s a visual use
case model. Adding a little formality to the process without going all
the way to
the running system can add substantially to the quality of the process.
Dave
Will Ross wrote:
> These workflows are intentionally not computable. They are simple
> visual aids to sketch the overall operational processes where a user
> interacts with software, without descending into the complexities of
> computable steps. The diagrams are deliberately chunked into single
> page views with a limited number of high level process steps and
> decision gates. The purpose of the diagrams is to excel at
> describing the general use of the software within the daily workflow
> of a specific user (in this case, a clerk at the registration desk)
> while at the same time communicating to the programmers the general
> flow of interactive tasks between a line worker and the enterprise
> software package. I think of the diagrams as a "visual use case."
> Collectively, the entire suite of drawings is an inventory of every
> user process in the facility with an interactive dependency on the
> specific software package (in this case "HealthPro").
>
> [wr]
>
> - - - - - - - -
>
> On Mar 23, 2006, at 9:39 PM, David Forslund wrote:
>
>
>> Is this workflow put into a "computable" form or is it just to help
>> understand the various processes?
>> If it is "computable", what are you using to describe the workflow.
>> This
>> type of workflow
>> is rather easily described in XPDL, for example, and can drive the
>> various tasks and user inputs.
>>
>> Most of this workflow as described would be internal to a healthcare
>> system and thus
>> doesn't need to use a standard. However, if one wants to switch
>> software
>> suites or
>> connect in a partner for part of the process, using an implemented
>> standard would help a lot.
>>
>> Dave
>> Will Ross wrote:
>>
>>> Dave,
>>>
>>> Attached is a diagram which is part of a practice management software
>>> replacement project I am managing for a group of rural ambulatory
>>> clinics. This particular diagram maps the initial steps at one
>>> clinic as Reception interacts with the current software ("HP") when a
>>> patient arrives for an appointment. These high level procedural
>>> diagrams completely map user interaction with the HealthPro software
>>> at this facility. The user centered workflows are grouped into
>>> procedural chunks to enable analysis and planning for migration to
>>> the replacement practice management software, which is ClearHealth
>>> from Uversa. Using these maps allows lead users in the key
>>> operations areas (Scheduling, Billing, Medical Records, etc) to step
>>> through the ClearHealth demo, creating a gap analysis to identify
>>> software features that must be added to ClearHealth. I anticipate
>>> implementation of ClearHealth at our first clinic site this summer.
>>> I started this open source project in February 2004 and have been
>>> fortunate to raise enough funds to aggressively and comprehensively
>>> add the necessary features to the base ClearHealth product. All the
>>> new code being paid with grant funds will be released under the
>>> GPL. The project portal is located here:
>>>
>>> http://www.phoenixpm.org/
>>>
>>> With best regards,
>>>
>>> [wr]
>>>
>>> - - - - - - - -
>>>
>>> On Mar 23, 2006, at 6:44 AM, David Forslund wrote:
>>>
>>>
>>>
>>>> I wholeheartedly agree with you, Will! Do you have some example
>>>> workflow diagrams that you have found useful?
>>>>
>>>> Dave
>>>> Will Ross wrote:
>>>>
>>>>
>>>>> Philippe,
>>>>>
>>>>> Actually, I am still talking about Wayne's focus on the user.
>>>>> As a
>>>>> project manager I spend much of my time in a balancing act by
>>>>> advocating for someone else's perspective. When I work with
>>>>> with IT
>>>>> developers and vendors, the most important missing voice is
>>>>> generally
>>>>> the perspective of the user. Workflow diagrams and use case
>>>>> narratives are excellent tools to bring the user back into the
>>>>> center
>>>>> of the technology planning process, and they also provide users
>>>>> with
>>>>> a convenient way to redirect well intentioned but inappropriate
>>>>> technology proposals.
>>>>>
>>>>> Until we have compelling informatics solutions that meet actual
>>>>> clinical user needs, adoption of new IT proposals will be
>>>>> minimal at
>>>>> best, which describes the current state of EHR deployment in this
>>>>> country (i.e., minimal).
>>>>>
>>>>> With best regards,
>>>>>
>>>>> [wr]
>>>>>
>>>>> - - - - - - - -
>>>>>
>>>>> On Mar 23, 2006, at 3:43 AM, Philippe AMELINE wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> Any opinion on YAWL ( http://www.yawl.fit.qut.edu.au/ )?
>>>>>>>
>>>>>>> Tim C
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I very much like the way Wayne Wilson explicated the Big problem :
>>>>>>
>>>>>> "The very first thing to do is to build a believable (to
>>>>>> doctors and
>>>>>> patients) scenario for needing to get information from one system
>>>>>> to the next, preferably in real time. IF you don't lead with that
>>>>>> from a
>>>>>> demonstrably practical point of view and just assume a generic
>>>>>> need
>>>>>> justifies all (interchange is good and will save the world, etc.),
>>>>>> then I suggest that this interoperability demo is no different
>>>>>> than a
>>>>>> vendor plug fest designed to show managers why they should keep
>>>>>> buying the
>>>>>> same stuff they have already bought."
>>>>>>
>>>>>> And how funny it was to see that 6 posts after, all this vanished
>>>>>> into a workflow engines comparison (very interesting, by the way).
>>>>>>
>>>>>> From my point of view, Wayne is very right to ask for a scenario
>>>>>> "for
>>>>>> needing to get information from one system to the next". And I
>>>>>> think
>>>>>> that such a scenario will be pretty much artificial if these
>>>>>> systems are HIS since the genuine main reason to communicate is
>>>>>> continuity of
>>>>>> care, and that it is the very issue that hospitals don't address
>>>>>> at all -
>>>>>> and even rarely understand.
>>>>>>
>>>>>> This "generic need" that would justify a "need for communication"
>>>>>> between HIS is a myth that became a religion when a sufficient
>>>>>> number of people started to make a living by building standards
>>>>>> for it. This is
>>>>>> not an issue for the citizen.
>>>>>>
>>>>>> My 2 € ;-)
>>>>>>
>>>>>> Philippe
>>>>>>
>>>>>>
>>>>>>
>>>>> [wr]
>>>>>
>>>>> - - - - - - - -
>>>>>
>>>>> will ross
>>>>> project manager
>>>>> mendocino informatics
>>>>> 216 west perkins street, suite 206
>>>>> ukiah, california 95482 usa
>>>>> 707.272.7255 [voice]
>>>>> 707.462.5015 [fax]
>>>>> www.minformatics.com
>>>>>
>>>>> - - - - - - - -
>>>>>
>>>>>
>>>>>
>>> [wr]
>>>
>>> - - - - - - - -
>>>
>>> will ross
>>> project manager
>>> mendocino informatics
>>> 216 west perkins street, suite 206
>>> ukiah, california 95482 usa
>>> 707.272.7255 [voice]
>>> 707.462.5015 [fax]
>>> www.minformatics.com
>>>
>>>
>>>
>>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> [wr]
>
> - - - - - - - -
>
> will ross
> project manager
> mendocino informatics
> 216 west perkins street, suite 206
> ukiah, california 95482 usa
> 707.272.7255 [voice]
> 707.462.5015 [fax]
> www.minformatics.com
>
> - - - - - - - -
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/openhealth/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
