I'm trying to understand what these reference view points have to do 
with getting the data between organizations.
In a single care place, the data for the patient may have to come from 
multiple locations to be available to build
a diagnosis.   The MRI may be done at a facility 40 miles away, the Lab 
test may be done across town, but all
of this needs to be available to a physician to make a diagnosis and 
treatment plan, whether the patient is at the point
of care or not.   To manage a continuity of care system (which doesn't 
exist in the US), one must be able
to rather freely move information around.  This doesn't happen if the 
various systems can't or won't talk
to each other.  The idea of a "virtual patient record" is to avoid 
precisely the issue of information showing up
at a doctor's office which you no longer visit.  In the US, it is very 
hard to get a patient-centered view of the
treatment of a patient.   The only examples I know of are where a 
patient creates their own chart and carries
it with them between providers.  Other than that, the patient never has 
their medical record.  It is scattered
amongst the various points of care that a patient has to deal with.   It 
is the movement of data from one care provider
to another (or the virtual movement) that requires multiple information 
systems to communicate with each other.

I don't think we are in any disagreement, just different viewpoints on 
the same situation.

Dave


Philippe AMELINE wrote:
> David,
>
> I am not very at ease with this vision.
>
> Let's express it simply: what you try to do with a person/care workflow 
> is to make sure that will be present, at a given place and a given time, 
> the patient, the professionals and the proper material.
> If you work in the care place's referential, you can assume that the 
> material doesn't move, and that the professionals are also "fixed". This 
> referential sees the patient as a moving object passing through (from 
> inpatient to outpatient).
> If you work in the patient's referential, the patient doesn't move, but 
> materials and professionals are passing by in front of him.
>
> So, you have two moving referentials. And you have to synchronize them. 
> This is typically the topology of a continuity of care system.
>
> In the same way, from the patient point of view, health professionals 
> are changing inside his/her own care team (they enter the team, maybe 
> change their positions (for example from a GP you see sometimes to your 
> usual GP), then probably disappear someday).
> So, when some information has to be transfered from one team member to 
> another one, they have to use the continuity of care system in order to 
> know who is in charge at this moment. Elsewhere, the information may end 
> up at a doctor's you no longer visit.
>
> Continuity of care "is" the patient, not a communication between care 
> places.
>
> Regards,
>
> Philippe
>
> David Forslund a écrit :
>
>   
>> Philippe AMELINE wrote:
>>  
>>
>>     
>>> Will,
>>>
>>> Who is the "user" you want to show workflow diagrams too?
>>> Is he/she an health professional or a citizen/patient?
>>>  
>>>    
>>>
>>>       
>> I can't speak for Will, but I think workflow is useful for the tasks 
>> that people need to do in
>> caring for a patient.   In the work we did with City of Hope, the 
>> workflow for a clinical
>> trial took an entire wall to illustrate.   There are a large number of 
>> tasks involved in setting
>> up and carrying out a clinical trial and there are large numbers of 
>> dependencies in the process.
>> It is a classic workflow problem.   The people caring for the patient 
>> don't need to look
>> at a diagram of the workflow, but a system which assists them needs the 
>> workflow specification
>> to ensure that all the right things are being done.   The diagram is to 
>> setup and evaluate the
>> process to ensure that the specification is correct.   The execution of 
>> the workflow is invisible
>> to the user other than that they are given tasks to do. 
>>
>> If care is done at multiple healthcare organizations, there needs to be 
>> communication between
>> those organizations.  This may or may not involve workflow.   I had a 
>> procedure done last year
>> ordered by my doctor but done at another location.  When I visited him 
>> this year, I found out that
>> the results had never been sent to him (not even simply on paper).  
>> Information from one system to another
>> almost unrelated system is common and important if one is to have 
>> continuity of care. 
>>
>> Dave
>>  
>>
>>     
>>> From my point of view, and according to the tools I already elaborated 
>>> and tested, the health professional should be provided with two 
>>> different kind of tools : front office tools and back office tools. 
>>> Quite in the same way market places information systems work inside banks:
>>> - front office tools are groupware services dedicated to continuity of 
>>> care, they belong to the public health information system. The citizen 
>>> is the owner and grants access to the members of his/her care team.
>>> - back office tools belong to care places, and are "record oriented".
>>>
>>> You may disagree with this model , but if you don't, then you will 
>>> realize that there is no use to have the back office systems communicate 
>>> with something else than the front office system. This is why I pointed 
>>> out that exchanges from one Hospital IS to another has probably no 
>>> genuine use case.
>>>
>>> I am ok to put a workflow engine among the front office services, but 
>>> are you talking about a workflow of people/acts (something like a care 
>>> path) or a workflow of documents?
>>>
>>> Best regards,
>>>
>>> Philippe
>>>
>>> Will Ross a écrit :
>>>
>>>  
>>>    
>>>
>>>       
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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/
 


Reply via email to