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
<*> 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/
