Derek, thanks for your usual comprenhensive, collaborative response.
I think the most important question has to do with the December time box. While I can see how making the connectathon the target makes sense technologically, I think we need to show the stakeholders how HIE contributes to improved quality of care and/or better outcomes and/or achieving programmatic goals. Producing some indicators included in PEPFAR’s December target for facility-based service data might be one target. Showing care coordination across multiple sites would be more impressive – comparing number of cases, adherence and lost-to-followup statistics created from multiple independent EHRs to those from HIE-coordinated data. I think this is particularly important because the profiles are so clinically oriented with few data elements useful for program evaluation, quality improvement or public health.
I think you are right about overloading of the term “services,” which my parallel structure was attempting to point out. I am not sanguine about your idea of multiple, co-existing lists of “services” because while it makes some sense informatically, I don’t think it is operationalizable. Different sub-populations of users work with different definitions of services and don’t want to see other users’ definitions. So “general surgery” might be a service offered by a provider or a facility, but is too coarse for insurance or service delivery statistics purposes. Is “general surgery” a single term used by both the facility directory and the medical licensing board, or do they have their own codesets? If we were writing SOPs for apps for medical licensing, facility service directories, service delivery reporting and insurance reporting, what would they say about maintaining the list of services?
I don’t understand why you think a single coordinated registry “unseats” existing partial registries. The coordinated registry does not change the use of the objects it contains any more than including two overlapping coding systems in a terminology service makes one of them more “official” than another. Looked at from a data processing point of view rather than a medical informatics point of view, it seems more sensible to make the initial load of the HWR from the payroll system and the FR from the logistics system than from the congeries of licensing boards. In most industries, the performance systems hang off the accounting system. People coming from the EMR side seeking to include the pharmacy inventory and dispensing system using open source logistics systems have had problems because they are accustomed to putting medical uses first. Putting a person into a HWR or a facility into a FR only gives us a single central reference point, it does not make the person a doctor or turn a building into a hospital. The attribute values that make the difference are still in the control of other responsible agencies, even of other systems.
I was pleased to read the EWEC guidelines, they are a lot more coordinated than in the past. However, I don’t recall seeing guidance on ARV care at delivery for mothers found to be HIV positive and not under treatment. Also, the discussion of breast-feeding by HIV positive mothers is somewhat contradicted by the bolded statements in the breast feeding section. So it doesn’t seem like the program requirements have been harmonized. They don’t address what information is necessary for program monitoring, and unlike past WHO publications, they provide no form specifying the content of an ante-natal visit. So we have less information with which to create a profile or describe an appropriate action in an ICP. I need to review your ICP slides, but an example of how one is designed for use with an EHR would be helpful. I’m still not convinced that it’s more useful than the idea of programs with initiations and state transitions and outcomes.
Saludos, Roger
···
Hi Roger.
Thanks so much for the input and feedback. I’ve put comments regarding some of your points inline (please see below). Please, let’s keep the conversation going.
Warmest regards,
Derek.
On Thursday, 7 August 2014 18:46:20 UTC-4, Roger Friedman wrote:
Sent from my Samsung Epic™ 4G Touch
-------- Original message --------
Subject:RE: What does OpenHIE v1.0 do?
From:“Friedman, Roger (CDC/CGH/DGHA) (CTR)” rd...@cdc.gov To:r.f...@mindspring.com
Cc:
To: ‘ohie-arc…@googlegroups.com’; ‘ohie-s…@googlegroups.com’
Derek –
Thanks so much for preparing this.
I think this focuses too much on the use of existing IHE roles and messages without assuring that the content of those messages is appropriate to meet the programmatic needs of the MOH. For example,
it is virtually certain that the APS does not support the execution of a policy of lifetime ARV treatment for HIV positive pregnant women or the cascade of identification, program registration, lab testing, drug prescription and pickup, patient education and
periodic evaluation of HIV positive patients, all of which are subjects of immediate concern to the HIV program. One important purpose of the HIE is to track HIV (and TB and immunization and cervical cancer) patients across sites of diagnosis, evaluation
and treatment. Roger, I completely agree that the proposed use of IHE profiles in this deck is insufficient to meet the overall programmatic needs of an MOH. The scope of the deck was narrowed (slide 10, bullet 1) to attempt to align with the RHIE functionality presently deployed in Rwanda. This arose out of a recent call (Sandbox call, I think) where it was posited that an OpenHIE v1.0 could perhaps target the RHIE functionality as its “baseline scope”.
I don’t think ICP will work for the purposes for which you intend it. I think it is really hospital-based-physician-centric (Roger, the ICPs I’m thinking of are not at all hospital centric – they are much more focused on community care. I’m thinking of the Every Woman Every Child guideline or the Immunization guideline for infants and children, both of which are WHO publications. I’ve attached the EWEC guideline, so you see what I mean.) are rand does not reflect the realities of the way patients are incorporated into
programmatic services. Sites are already compressing a 30-minute HIV follow-up visit into 5, and now we are going to charge them with updating care plans into the indefinite future in that time? And I don’t think we can rely on doctors to include non-medical
interventions, such as patient education or insecticide-treated bed nets, into their care plans. (I would say one of the big benefits of ICPs is that they coordinate activities, within the fabric of the HIE, between many participants in the overall care delivery network… including the patients themselves. I worry that you are mistaking ICP for CDS, which has tended very much to focus on hospital-centric or physician workflow-centric decision support… that’s really not what I mean at all by ICP.) Just look at the epicycles that arise in determining whether a particular patient is up to date in their immunizations once a shot is missed in its normal window
or a shot of different than expected valence is given.
Furthermore, the ICP proposal still hasn’t addressed the definition of “services.” I think it is referring to services at the level of insurance reimbursement which is much too granular to be useful
for service directories or program administration. You are right that a single definition has not been articulated for service – but this is intentional on my part. Service is an overloaded term. Services can mean available infrastructure at a facility (does it have running water… electricity… an internet connection…). Service can also mean the available clinical care available at a facility (maternal… immunization… basic surgery). Services are also offered by health workers (midwifery… nursing… cardiology…) and some of these require credentials in order to be able to legally offer such services within a jurisdiction. As you say, where services map to billable services it is useful to harmonize the code sets (or ensure there is a crosswalk between them) so that eHealth transactions may be leveraged for insurance purposes and vice versa (the Dutch use their insurance database for population burden of disease reporting, for example). A single services directory can maintain multiple code sets. Each of these code sets may be related to different entities (organizations, facilities and providers) to describe and denote different aspects, as listed. An ICP that is intended to describe, for example, that an HIV patient should have lab tests done every 6 months to establish viral load / CD4 counts / etc. will need to be able to leverage the “service code” to denote lab test so that this rule may be defined. There is not a level of granularity “built in” to an ICP… it uses whatever is the appropriate level of granularity (precision of the code set) that is needed to describe the guideline in operational terms.
I think the idea of a federated, dynamically harmonized list of facilities or health workers as specified in CSD is doomed to failure as a technological solution to a social/organizational problem.
No one organizational unit is going to be the ultimate source of truth for every data element or for any subset of facilities or health workers. There needs to be acceptance of the ideas that data will be shared among multiple stakeholders and that master
list maintainers are stewards not owners. There needs to be an accepted process by which each change to an item of information goes through a vetting process before it is finally accepted for all purposes. There needs to be adequate security to assure that
information does not go beyond its intended audience. Roger, I admit with some embarrassment that I’m missing something here (sadly, it may be something obvious… and if so, I’m very sorry). My growing appreciation for the importance of federated registries is because I believe the sociotechnical problem is so much taller than the technical problem – exactly as you say. Where there exist multiple facilities lists, and governance around their maintenance, I think it will be a distinctly preferable approach – sociotechnically – to embrace these lists and draw them into a registry where they may be de-duped, managed, etc. To instead try to unseat these registries may be “technically” preferred… but it means unseating the existing governance and social infrastructure that exists around them. I think the latter would be fundamentally harder to accomplish than the former. Also – to be clear – nothing about the CSD specification requires or even prefers federated directories for each of the data types (orgs, facilities, providers, services). CSD supports federation but certainly doesn’t mandate it.
Furthermore, the CSD spec still hasn’t addressed the definition of “services.” I think it is referring to medical specialties or approval to perform certain procedures which is too narrowly focused
to be useful for service directories or program administration. Roger… this seems to be arguing for too much precision in service definitions where, above, you argued for not enough.
Again, I do think this a useful roadmap and discussion document, the proposal just needs to be more concrete about how it meets programmatic requirements. Concrete is good; I agree wholeheartedly. Are there recommendations regarding IHE profiles that we should have included in scope for v1.0? To help us all appreciate the urgency of releasing a working HIE, I would favour time-boxing – and a good working constraint might be to have OpenHIE v1.0 ready for conformance testing at IHE’s North American Connectathon. What is your gut instinct about the “right” functional footprint for a December release date of OpenHIE v1.0?
This is a discussion document. As I have said quite regularly, lately, I think we collectively need to figure out what OpenHIE v1.0 will do and (pretty quickly) build out a version of the overall infrastructure that “does that”.
This PPT deck is designed to move some of that discussion forward by unpacking what we would need, in terms of IHE profiles, to “do” the core processes that RHIE does today. This isn’t by any means a definitive design – there are still
quite a few options for how we might leverage one profile or another. But I think this collection of profiles would probably “work”… and that’s a likable thing about any design…
This document needs the group’s help; I look forward to the conversations we will have on this topic.
–
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-architect...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Roger,
Just a quick note to your point about loading the HWR from professional councils. The medical council is the entity that makes the doctor the doctor.
Also, largely by necessity, we are approaching the HWR from the perspective of federated data sources with a de-duplication process. We leave it to the jurisdiction to decide the appropriate governance policy on the authority of the data coming from the various systems.
Derek, thanks for your usual comprenhensive, collaborative response.
I think the most important question has to do with the December time box. While I can see how making the connectathon the target makes sense technologically, I think we need to show the stakeholders how HIE contributes to improved quality of care and/or better outcomes and/or achieving programmatic goals. Producing some indicators included in PEPFAR’s December target for facility-based service data might be one target. Showing care coordination across multiple sites would be more impressive – comparing number of cases, adherence and lost-to-followup statistics created from multiple independent EHRs to those from HIE-coordinated data. I think this is particularly important because the profiles are so clinically oriented with few data elements useful for program evaluation, quality improvement or public health.
I think you are right about overloading of the term “services,” which my parallel structure was attempting to point out. I am not sanguine about your idea of multiple, co-existing lists of “services” because while it makes some sense informatically, I don’t think it is operationalizable. Different sub-populations of users work with different definitions of services and don’t want to see other users’ definitions. So “general surgery” might be a service offered by a provider or a facility, but is too coarse for insurance or service delivery statistics purposes. Is “general surgery” a single term used by both the facility directory and the medical licensing board, or do they have their own codesets? If we were writing SOPs for apps for medical licensing, facility service directories, service delivery reporting and insurance reporting, what would they say about maintaining the list of services?
I don’t understand why you think a single coordinated registry “unseats” existing partial registries. The coordinated registry does not change the use of the objects it contains any more than including two overlapping coding systems in a terminology service makes one of them more “official” than another. Looked at from a data processing point of view rather than a medical informatics point of view, it seems more sensible to make the initial load of the HWR from the payroll system and the FR from the logistics system than from the congeries of licensing boards. In most industries, the performance systems hang off the accounting system. People coming from the EMR side seeking to include the pharmacy inventory and dispensing system using open source logistics systems have had problems because they are accustomed to putting medical uses first. Putting a person into a HWR or a facility into a FR only gives us a single central reference point, it does not make the person a doctor or turn a building into a hospital. The attribute values that make the difference are still in the control of other responsible agencies, even of other systems.
I was pleased to read the EWEC guidelines, they are a lot more coordinated than in the past. However, I don’t recall seeing guidance on ARV care at delivery for mothers found to be HIV positive and not under treatment. Also, the discussion of breast-feeding by HIV positive mothers is somewhat contradicted by the bolded statements in the breast feeding section. So it doesn’t seem like the program requirements have been harmonized. They don’t address what information is necessary for program monitoring, and unlike past WHO publications, they provide no form specifying the content of an ante-natal visit. So we have less information with which to create a profile or describe an appropriate action in an ICP. I need to review your ICP slides, but an example of how one is designed for use with an EHR would be helpful. I’m still not convinced that it’s more useful than the idea of programs with initiations and state transitions and outcomes.
Saludos, Roger
Hi Roger.
Thanks so much for the input and feedback. I’ve put comments regarding some of your points inline (please see below). Please, let’s keep the conversation going.
Warmest regards,
Derek.
On Thursday, 7 August 2014 18:46:20 UTC-4, Roger Friedman wrote:
Sent from my Samsung Epic™ 4G Touch
-------- Original message --------
Subject:RE: What does OpenHIE v1.0 do?
From:“Friedman, Roger (CDC/CGH/DGHA) (CTR)” rd...@cdc.gov To:r.f...@mindspring.com
Cc:
To: ‘ohie-arc…@googlegroups.com’; ‘ohie-s…@googlegroups.com’
Derek –
Thanks so much for preparing this.
I think this focuses too much on the use of existing IHE roles and messages without assuring that the content of those messages is appropriate to meet the programmatic needs of the MOH. For example,
it is virtually certain that the APS does not support the execution of a policy of lifetime ARV treatment for HIV positive pregnant women or the cascade of identification, program registration, lab testing, drug prescription and pickup, patient education and
periodic evaluation of HIV positive patients, all of which are subjects of immediate concern to the HIV program. One important purpose of the HIE is to track HIV (and TB and immunization and cervical cancer) patients across sites of diagnosis, evaluation
and treatment. Roger, I completely agree that the proposed use of IHE profiles in this deck is insufficient to meet the overall programmatic needs of an MOH. The scope of the deck was narrowed (slide 10, bullet 1) to attempt to align with the RHIE functionality presently deployed in Rwanda. This arose out of a recent call (Sandbox call, I think) where it was posited that an OpenHIE v1.0 could perhaps target the RHIE functionality as its “baseline scope”.
I don’t think ICP will work for the purposes for which you intend it. I think it is really hospital-based-physician-centric (Roger, the ICPs I’m thinking of are not at all hospital centric – they are much more focused on community care. I’m thinking of the Every Woman Every Child guideline or the Immunization guideline for infants and children, both of which are WHO publications. I’ve attached the EWEC guideline, so you see what I mean.) are rand does not reflect the realities of the way patients are incorporated into
programmatic services. Sites are already compressing a 30-minute HIV follow-up visit into 5, and now we are going to charge them with updating care plans into the indefinite future in that time? And I don’t think we can rely on doctors to include non-medical
interventions, such as patient education or insecticide-treated bed nets, into their care plans. (I would say one of the big benefits of ICPs is that they coordinate activities, within the fabric of the HIE, between many participants in the overall care delivery network… including the patients themselves. I worry that you are mistaking ICP for CDS, which has tended very much to focus on hospital-centric or physician workflow-centric decision support… that’s really not what I mean at all by ICP.) Just look at the epicycles that arise in determining whether a particular patient is up to date in their immunizations once a shot is missed in its normal window
or a shot of different than expected valence is given.
Furthermore, the ICP proposal still hasn’t addressed the definition of “services.” I think it is referring to services at the level of insurance reimbursement which is much too granular to be useful
for service directories or program administration. You are right that a single definition has not been articulated for service – but this is intentional on my part. Service is an overloaded term. Services can mean available infrastructure at a facility (does it have running water… electricity… an internet connection…). Service can also mean the available clinical care available at a facility (maternal… immunization… basic surgery). Services are also offered by health workers (midwifery… nursing… cardiology…) and some of these require credentials in order to be able to legally offer such services within a jurisdiction. As you say, where services map to billable services it is useful to harmonize the code sets (or ensure there is a crosswalk between them) so that eHealth transactions may be leveraged for insurance purposes and vice versa (the Dutch use their insurance database for population burden of disease reporting, for example). A single services directory can maintain multiple code sets. Each of these code sets may be related to different entities (organizations, facilities and providers) to describe and denote different aspects, as listed. An ICP that is intended to describe, for example, that an HIV patient should have lab tests done every 6 months to establish viral load / CD4 counts / etc. will need to be able to leverage the “service code” to denote lab test so that this rule may be defined. There is not a level of granularity “built in” to an ICP… it uses whatever is the appropriate level of granularity (precision of the code set) that is needed to describe the guideline in operational terms.
I think the idea of a federated, dynamically harmonized list of facilities or health workers as specified in CSD is doomed to failure as a technological solution to a social/organizational problem.
No one organizational unit is going to be the ultimate source of truth for every data element or for any subset of facilities or health workers. There needs to be acceptance of the ideas that data will be shared among multiple stakeholders and that master
list maintainers are stewards not owners. There needs to be an accepted process by which each change to an item of information goes through a vetting process before it is finally accepted for all purposes. There needs to be adequate security to assure that
information does not go beyond its intended audience. Roger, I admit with some embarrassment that I’m missing something here (sadly, it may be something obvious… and if so, I’m very sorry). My growing appreciation for the importance of federated registries is because I believe the sociotechnical problem is so much taller than the technical problem – exactly as you say. Where there exist multiple facilities lists, and governance around their maintenance, I think it will be a distinctly preferable approach – sociotechnically – to embrace these lists and draw them into a registry where they may be de-duped, managed, etc. To instead try to unseat these registries may be “technically” preferred… but it means unseating the existing governance and social infrastructure that exists around them. I think the latter would be fundamentally harder to accomplish than the former. Also – to be clear – nothing about the CSD specification requires or even prefers federated directories for each of the data types (orgs, facilities, providers, services). CSD supports federation but certainly doesn’t mandate it.
Furthermore, the CSD spec still hasn’t addressed the definition of “services.” I think it is referring to medical specialties or approval to perform certain procedures which is too narrowly focused
to be useful for service directories or program administration. Roger… this seems to be arguing for too much precision in service definitions where, above, you argued for not enough.
Again, I do think this a useful roadmap and discussion document, the proposal just needs to be more concrete about how it meets programmatic requirements. Concrete is good; I agree wholeheartedly. Are there recommendations regarding IHE profiles that we should have included in scope for v1.0? To help us all appreciate the urgency of releasing a working HIE, I would favour time-boxing – and a good working constraint might be to have OpenHIE v1.0 ready for conformance testing at IHE’s North American Connectathon. What is your gut instinct about the “right” functional footprint for a December release date of OpenHIE v1.0?
This is a discussion document. As I have said quite regularly, lately, I think we collectively need to figure out what OpenHIE v1.0 will do and (pretty quickly) build out a version of the overall infrastructure that “does that”.
This PPT deck is designed to move some of that discussion forward by unpacking what we would need, in terms of IHE profiles, to “do” the core processes that RHIE does today. This isn’t by any means a definitive design – there are still
quite a few options for how we might leverage one profile or another. But I think this collection of profiles would probably “work”… and that’s a likable thing about any design…
This document needs the group’s help; I look forward to the conversations we will have on this topic.
–
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-architect...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thanks for the response. I understand the need for on-demand documents and it definitely does seem like the way to go in the long run. It does fit more naturally within our anticipated workflows. I fear that for a version 1 on-demand documents may prove a tall order. However, I’m not familiar with the on-demand document profile to comment on the validity of this fear. I look forward to chatting about this more in depth on the SHR call.
I agree that it seems that the alerting mechanism is the one that is still an unknown. It is definitely something what we need to talk more about and come to some concrete decisions. What would be the best format for doing this? Can this be added as a discussion item on the architecture call? (@Shaun, what do you suggest here?) Perhaps we could draw out a workflow that forms the basis of the alerting needs.
Hi Roger,
Just a quick note to your point about loading the HWR from professional councils. The medical council is the entity that makes the doctor the doctor.
Also, largely by necessity, we are approaching the HWR from the perspective of federated data sources with a de-duplication process. We leave it to the jurisdiction to decide the appropriate governance policy on the authority of the data coming from the various systems.
Derek, thanks for your usual comprenhensive, collaborative response.
I think the most important question has to do with the December time box. While I can see how making the connectathon the target makes sense technologically, I think we need to show the stakeholders how HIE contributes to improved quality of care and/or better outcomes and/or achieving programmatic goals. Producing some indicators included in PEPFAR’s December target for facility-based service data might be one target. Showing care coordination across multiple sites would be more impressive – comparing number of cases, adherence and lost-to-followup statistics created from multiple independent EHRs to those from HIE-coordinated data. I think this is particularly important because the profiles are so clinically oriented with few data elements useful for program evaluation, quality improvement or public health.
I think you are right about overloading of the term “services,” which my parallel structure was attempting to point out. I am not sanguine about your idea of multiple, co-existing lists of “services” because while it makes some sense informatically, I don’t think it is operationalizable. Different sub-populations of users work with different definitions of services and don’t want to see other users’ definitions. So “general surgery” might be a service offered by a provider or a facility, but is too coarse for insurance or service delivery statistics purposes. Is “general surgery” a single term used by both the facility directory and the medical licensing board, or do they have their own codesets? If we were writing SOPs for apps for medical licensing, facility service directories, service delivery reporting and insurance reporting, what would they say about maintaining the list of services?
I don’t understand why you think a single coordinated registry “unseats” existing partial registries. The coordinated registry does not change the use of the objects it contains any more than including two overlapping coding systems in a terminology service makes one of them more “official” than another. Looked at from a data processing point of view rather than a medical informatics point of view, it seems more sensible to make the initial load of the HWR from the payroll system and the FR from the logistics system than from the congeries of licensing boards. In most industries, the performance systems hang off the accounting system. People coming from the EMR side seeking to include the pharmacy inventory and dispensing system using open source logistics systems have had problems because they are accustomed to putting medical uses first. Putting a person into a HWR or a facility into a FR only gives us a single central reference point, it does not make the person a doctor or turn a building into a hospital. The attribute values that make the difference are still in the control of other responsible agencies, even of other systems.
I was pleased to read the EWEC guidelines, they are a lot more coordinated than in the past. However, I don’t recall seeing guidance on ARV care at delivery for mothers found to be HIV positive and not under treatment. Also, the discussion of breast-feeding by HIV positive mothers is somewhat contradicted by the bolded statements in the breast feeding section. So it doesn’t seem like the program requirements have been harmonized. They don’t address what information is necessary for program monitoring, and unlike past WHO publications, they provide no form specifying the content of an ante-natal visit. So we have less information with which to create a profile or describe an appropriate action in an ICP. I need to review your ICP slides, but an example of how one is designed for use with an EHR would be helpful. I’m still not convinced that it’s more useful than the idea of programs with initiations and state transitions and outcomes.
Thanks so much for the input and feedback. I’ve put comments regarding some of your points inline (please see below). Please, let’s keep the conversation going.
Warmest regards,
Derek.
On Thursday, 7 August 2014 18:46:20 UTC-4, Roger Friedman wrote:
Sent from my Samsung Epic™ 4G Touch
-------- Original message --------
Subject:RE: What does OpenHIE v1.0 do?
To: ‘ohie-arc…@googlegroups.com’; ‘ohie-s…@googlegroups.com’
Derek –
Thanks so much for preparing this.
I think this focuses too much on the use of existing IHE roles and messages without assuring that the content of those messages is appropriate to meet the programmatic needs of the MOH. For example,
it is virtually certain that the APS does not support the execution of a policy of lifetime ARV treatment for HIV positive pregnant women or the cascade of identification, program registration, lab testing, drug prescription and pickup, patient education and
periodic evaluation of HIV positive patients, all of which are subjects of immediate concern to the HIV program. One important purpose of the HIE is to track HIV (and TB and immunization and cervical cancer) patients across sites of diagnosis, evaluation
and treatment. Roger, I completely agree that the proposed use of IHE profiles in this deck is insufficient to meet the overall programmatic needs of an MOH. The scope of the deck was narrowed (slide 10, bullet 1) to attempt to align with the RHIE functionality presently deployed in Rwanda. This arose out of a recent call (Sandbox call, I think) where it was posited that an OpenHIE v1.0 could perhaps target the RHIE functionality as its “baseline scope”.
I don’t think ICP will work for the purposes for which you intend it. I think it is really hospital-based-physician-centric (Roger, the ICPs I’m thinking of are not at all hospital centric – they are much more focused on community care. I’m thinking of the Every Woman Every Child guideline or the Immunization guideline for infants and children, both of which are WHO publications. I’ve attached the EWEC guideline, so you see what I mean.) are rand does not reflect the realities of the way patients are incorporated into
programmatic services. Sites are already compressing a 30-minute HIV follow-up visit into 5, and now we are going to charge them with updating care plans into the indefinite future in that time? And I don’t think we can rely on doctors to include non-medical
interventions, such as patient education or insecticide-treated bed nets, into their care plans. (I would say one of the big benefits of ICPs is that they coordinate activities, within the fabric of the HIE, between many participants in the overall care delivery network… including the patients themselves. I worry that you are mistaking ICP for CDS, which has tended very much to focus on hospital-centric or physician workflow-centric decision support… that’s really not what I mean at all by ICP.) Just look at the epicycles that arise in determining whether a particular patient is up to date in their immunizations once a shot is missed in its normal window
or a shot of different than expected valence is given.
Furthermore, the ICP proposal still hasn’t addressed the definition of “services.” I think it is referring to services at the level of insurance reimbursement which is much too granular to be useful
for service directories or program administration. You are right that a single definition has not been articulated for service – but this is intentional on my part. Service is an overloaded term. Services can mean available infrastructure at a facility (does it have running water… electricity… an internet connection…). Service can also mean the available clinical care available at a facility (maternal… immunization… basic surgery). Services are also offered by health workers (midwifery… nursing… cardiology…) and some of these require credentials in order to be able to legally offer such services within a jurisdiction. As you say, where services map to billable services it is useful to harmonize the code sets (or ensure there is a crosswalk between them) so that eHealth transactions may be leveraged for insurance purposes and vice versa (the Dutch use their insurance database for population burden of disease reporting, for example). A single services directory can maintain multiple code sets. Each of these code sets may be related to different entities (organizations, facilities and providers) to describe and denote different aspects, as listed. An ICP that is intended to describe, for example, that an HIV patient should have lab tests done every 6 months to establish viral load / CD4 counts / etc. will need to be able to leverage the “service code” to denote lab test so that this rule may be defined. There is not a level of granularity “built in” to an ICP… it uses whatever is the appropriate level of granularity (precision of the code set) that is needed to describe the guideline in operational terms.
I think the idea of a federated, dynamically harmonized list of facilities or health workers as specified in CSD is doomed to failure as a technological solution to a social/organizational problem.
No one organizational unit is going to be the ultimate source of truth for every data element or for any subset of facilities or health workers. There needs to be acceptance of the ideas that data will be shared among multiple stakeholders and that master
list maintainers are stewards not owners. There needs to be an accepted process by which each change to an item of information goes through a vetting process before it is finally accepted for all purposes. There needs to be adequate security to assure that
information does not go beyond its intended audience. Roger, I admit with some embarrassment that I’m missing something here (sadly, it may be something obvious… and if so, I’m very sorry). My growing appreciation for the importance of federated registries is because I believe the sociotechnical problem is so much taller than the technical problem – exactly as you say. Where there exist multiple facilities lists, and governance around their maintenance, I think it will be a distinctly preferable approach – sociotechnically – to embrace these lists and draw them into a registry where they may be de-duped, managed, etc. To instead try to unseat these registries may be “technically” preferred… but it means unseating the existing governance and social infrastructure that exists around them. I think the latter would be fundamentally harder to accomplish than the former. Also – to be clear – nothing about the CSD specification requires or even prefers federated directories for each of the data types (orgs, facilities, providers, services). CSD supports federation but certainly doesn’t mandate it.
Furthermore, the CSD spec still hasn’t addressed the definition of “services.” I think it is referring to medical specialties or approval to perform certain procedures which is too narrowly focused
to be useful for service directories or program administration. Roger… this seems to be arguing for too much precision in service definitions where, above, you argued for not enough.
Again, I do think this a useful roadmap and discussion document, the proposal just needs to be more concrete about how it meets programmatic requirements. Concrete is good; I agree wholeheartedly. Are there recommendations regarding IHE profiles that we should have included in scope for v1.0? To help us all appreciate the urgency of releasing a working HIE, I would favour time-boxing – and a good working constraint might be to have OpenHIE v1.0 ready for conformance testing at IHE’s North American Connectathon. What is your gut instinct about the “right” functional footprint for a December release date of OpenHIE v1.0?
This is a discussion document. As I have said quite regularly, lately, I think we collectively need to figure out what OpenHIE v1.0 will do and (pretty quickly) build out a version of the overall infrastructure that “does that”.
This PPT deck is designed to move some of that discussion forward by unpacking what we would need, in terms of IHE profiles, to “do” the core processes that RHIE does today. This isn’t by any means a definitive design – there are still
quite a few options for how we might leverage one profile or another. But I think this collection of profiles would probably “work”… and that’s a likable thing about any design…
This document needs the group’s help; I look forward to the conversations we will have on this topic.
–
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-architect...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
