What does OpenHIE v1.0 do?

Legacy ohie-architecture
1

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.

I don’t think ICP will work for the purposes for which you intend it. I think it is really hospital-based-physician-centric and 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. 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.

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.

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.

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.

Saludos, Roger

···

Hi all.

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… :wink:

This document needs the group’s help; I look forward to the conversations we will have on this topic.

Warmest regards,

Derek.

–

**Derek Ritz,**P.Eng., CPHIMS-CA
ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

–
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.

2

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. :slight_smile:

Warmest regards,

Derek.

11-03-06 WHO MNCH guidelines.pdf (1.08 MB)

···

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. :wink:

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?

Saludos, Roger

-------- Original message --------
Subject:Fwd: What does OpenHIE v1.0 do?
From:Derek Ritz derek...@gmail.com
To:ohie-ar...@googlegroups.com,ohie-s...@googlegroups.com
Cc:

Hi all.

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… :wink:

This document needs the group’s help; I look forward to the conversations we will have on this topic.

Warmest regards,

Derek.

–

**Derek Ritz,**P.Eng., CPHIMS-CA
ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

–
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.