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
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.
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.
**Derek Ritz,**P.Eng., CPHIMS-CA
+1 (905) 515-0045
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
For more options, visit https://groups.google.com/d/optout.