Hi David,
Hospital records are back office systems scattered in the landscape.
A "virtual patient record" is just trying to build a front office system
out of this data.
Odyssée is aimed at providing a "real" patient owned system that is
dedicated to continuity of care.
What I mean is that this system can exchange data with legacy IS, but
mainly manages a specific set of information. This specific "continuity
of care" information links the two referentials together.
It is pretty much like a "concurrent engineering" system:
In the automobile industry, specialists from several domains (body,
engine, cooling) must collaborate on the same vision of the car to
design (motor's position is given by the body design, but crash test
needs to adapt the body to the motor position, etc). They all have
specialized legacy systems, but also work on a "concurrent engineering"
system to envision the global integration (this system is called an
Artifact, but it is not a good name in the medical domain).
A good specialist of these concepts stated that:
In concurrent engineering, we must introduce a human dimension that
corresponds to the different participants in a design project, and a
knowledge dimension corresponding to the experience, competence and
situation of participants. Generally we can say that a viewpoint is
taken by a person according to his/her knowledge, domain of
competence and his/her objective in his/her activity.”
In the medical domain, we all know that depending on his/her activity
(MD, nurse...) and specialty (general practice, cardiology...), the
health professionals have specific legacy systems or specific viewpoint
oriented settings in the legacy system.
So, the "concurrent engineering" system is mandatory when you want to
embrace the whole patient over time: that is continuity of care.
To come back to the initial thread of information exchanges, I hope that
you understand my position better: the concurrent engineering system
must be fed (for very well selected information) by legacy systems, but
also manage its own set of information. In the other hand, mixing data
from legacy systems in a "virtual record" is a mix up of every viewpoint
in the same garbage collector.
Philippe
David Forslund a écrit :
>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
>
>
>
>
>
>
>
>
>
>
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/
