Derek –
Thanks for the time and attention you have devoted to this. The idea of a business process engine driving an EMR is an interesting one that I like on an abstract basis. Could you please send/post a link to the PEPFAR study?
I think that this is a bridge too far for our constituency. They are still struggling with the transition from register-based hospital records to encounter-based hospital records, and now with OpenHIE we are trying to move them to a unified longitudinal patient record. Getting a working consensus on the information requirements for an EMR is hard enough without also having to agree on a workflow. I see the struggles going on in the disease-specific centers here at CDC over what should go into care coordination profiles; all of them seem to be having conflicts between research and clinical interests and will result in heavier clinical data gathering burdens, when we know that the clinic is already overburdened in our countries. Once consensus has been reached, in order to be sustainable across administrations, there needs to be a compelling value proposition. I don't think that we are even doing this in the US; from what I have seen at Kaiser, they are spending lots of time creating custom screens for departments and physicians to hide the underlying information models. Such a process seems much too resource intensive for our clients. Most of them have too few physicians to carry out protocols they already agree on, such IMAI, and have challenges such as stock-outs and missing/broken equipment that require them to improvise. I should note that the PEPFAR patient card and register system, which is based on IMAI and was turned into an HIV patient tracking program, in practice was found not to provide enough detail to support primary care for co-morbidities or for unrelated diseases and conditions whose treatment plans would be affected by the HIV status of the patient. With the increased focus on HIV care & treatment rather than infrastructure and on quantifying the program's impact on morbidity and incidence, I don't think we can count on increased funding for these activities, although we might expect a scale-up of EMRs.
I also worry about the central location of these capabilities. I think we still have to base our designs on a distributed or intermittent connection model. I don't think there is a generalized way at looking at the possibly incomplete data collected at an encounter in perhaps an ad hoc manner and figuring out the path in the ICP by which the data was generated. Therefore the ICP engine would have to be in the EMR. I do think that there is a place for programs and program workflow states in the EMR, but that is at a much coarser level than that which you are proposing.
I haven't seen any illustration of how a process would change in a BPML-driven system. Take the move toward rapid testing and away from blood tests for malaria. The transition does not take place uniformly, there are patients awaiting test results in the old process when the new process comes into effect, and the clinic will fall back on the old lab tests when they are out-of-stock on rapid tests. I am sure that there are BPML-driven systems in other domains that have addressed this problem, but I haven't seen anything written about the process. Do you have any cites?
Again, thanks for doing this, I definitely think it has promise, maybe just not in the here and now.
Saludos, Roger
···
-----Original Message-----
From: Derek Ritz
Sent: May 14, 2014 5:50 PM
To: ohie-architecture@googlegroups.com
Subject: Supporting Integrated Care Pathways (ICPs)… a discussion document
Hi all.
This document generally describes how we might weave support for
guideline-based care into the fabric of OpenHIE. It introduces the notion
of integrated care pathways (ICPs), looks at how care guidelines (such as
HIV, TB or Maternal care) can be expressed using ICPs, and then explores
how support for ICPs might be added to OpenHIE. Lastly the document
proposes how an ICP-focused working group, such as was agreed to during the
Indy Architecture meeting, might be launched.
This is a discussion document. I very much look forward to the discussion.
Warmest regards,
Derek.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Roger.
Thanks for the comments. You may be surprised to learn that I’m very much in agreement. I think what you have drawn out is a fundamentally important distinction between ICPs (integrated care pathways) and CDS (clinical decision support). There is a VERY common misconception regarding the difference between these two.
CDS is what you would expect to find in a local EMR. It is built into the system… and it manifests itself in the forms themselves (which fields are mandatory… which are optional) and in the logic that may be triggered when clinical readings or orders are logged to the EMR’s database. The CDS functionality focuses on what should be the flow of a care encounter between a patient and a health worker.
ICPs stand back from these individual care events. Their focus is on the coarsely defined “rules” regarding HIV care, or maternal care or what have you. Things like: an HIV patient should have lab test to establish CD4 count every 6 months… or, a pregnant mum should have 4 ANC visits over the coarse of her pregnancy and at the first one she should be tested for HIV and, if the test is positive, the PMTCT protocols will kick in. The ICP applies to the care coordination; it is the overarching guideline that describes how various care delivery participants, over time, will provide continuity of care for a patient/client. The EMR’s scope applies to a patient’s encounter with a single caregiver. The HIE’s scope applies to a patient’s encounter with the entire care delivery network. This latter interaction is where the ICP adds its value.
It is hard to define the exact boundary between CDS and ICP. There is no “hard” boundary and we should not try to pretend otherwise. Overlap is fine… it is like having a belt AND suspenders. But a gap is a place where continuity of care can “fall thru the cracks”.
Roger, I don’t at all believe that ICP capability is a bridge too far. In fact, I think that the most important things we can get from eHealth investments are ways to both “meter the system” and to “exert process control upon it”. Being able to aggregate eHealth transaction traffic to develop indicators gives us progress against the first of these (it helps us meter the system). Being able to generate alerts gives us an important way to make progress on goal #2. Even just basic messaging (SMS… email?) can enable us to start to close the “know-do” gap and better deliver guideline-based care to our populations-of-interest.
Please… let’s keep this conversation going. It is an important topic.
Warmest regards,
Derek.
···
On Mon, May 19, 2014 at 8:31 AM, r.friedman@mindspring.com wrote:
Derek –
Thanks for the time and attention you have devoted to this. The idea of a business process engine driving an EMR is an interesting one that I like on an abstract basis. Could you please send/post a link to the PEPFAR study?
I think that this is a bridge too far for our constituency. They are still struggling with the transition from register-based hospital records to encounter-based hospital records, and now with OpenHIE we are trying to move them to a unified longitudinal patient record. Getting a working consensus on the information requirements for an EMR is hard enough without also having to agree on a workflow. I see the struggles going on in the disease-specific centers here at CDC over what should go into care coordination profiles; all of them seem to be having conflicts between research and clinical interests and will result in heavier clinical data gathering burdens, when we know that the clinic is already overburdened in our countries. Once consensus has been reached, in order to be sustainable across administrations, there needs to be a compelling value proposition. I don't think that we are even doing this in the US; from what I have seen at Kaiser, they are spending lots of time creating custom screens for departments and physicians to hide the underlying information models. Such a process seems much too resource intensive for our clients. Most of them have too few physicians to carry out protocols they already agree on, such IMAI, and have challenges such as stock-outs and missing/broken equipment that require them to improvise. I should note that the PEPFAR patient card and register system, which is based on IMAI and was turned into an HIV patient tracking program, in practice was found not to provide enough detail to support primary care for co-morbidities or for unrelated diseases and conditions whose treatment plans would be affected by the HIV status of the patient. With the increased focus on HIV care & treatment rather than infrastructure and on quantifying the program's impact on morbidity and incidence, I don't think we can count on increased funding for these activities, although we might expect a scale-up of EMRs.
I also worry about the central location of these capabilities. I think we still have to base our designs on a distributed or intermittent connection model. I don't think there is a generalized way at looking at the possibly incomplete data collected at an encounter in perhaps an ad hoc manner and figuring out the path in the ICP by which the data was generated. Therefore the ICP engine would have to be in the EMR. I do think that there is a place for programs and program workflow states in the EMR, but that is at a much coarser level than that which you are proposing.
I haven't seen any illustration of how a process would change in a BPML-driven system. Take the move toward rapid testing and away from blood tests for malaria. The transition does not take place uniformly, there are patients awaiting test results in the old process when the new process comes into effect, and the clinic will fall back on the old lab tests when they are out-of-stock on rapid tests. I am sure that there are BPML-driven systems in other domains that have addressed this problem, but I haven't seen anything written about the process. Do you have any cites?
Again, thanks for doing this, I definitely think it has promise, maybe just not in the here and now.
Saludos, Roger
-----Original Message-----
From: Derek Ritz
Sent: May 14, 2014 5:50 PM
To: ohie-architecture@googlegroups.com
Subject: Supporting Integrated Care Pathways (ICPs)… a discussion document
Hi all.
This document generally describes how we might weave support for
guideline-based care into the fabric of OpenHIE. It introduces the notion
of integrated care pathways (ICPs), looks at how care guidelines (such as
HIV, TB or Maternal care) can be expressed using ICPs, and then explores
how support for ICPs might be added to OpenHIE. Lastly the document
proposes how an ICP-focused working group, such as was agreed to during the
Indy Architecture meeting, might be launched.
This is a discussion document. I very much look forward to the discussion.
Warmest regards,
Derek.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.