Hi Alvin.
I think the challenges around a CR can be daunting from a governance standpoint, but that there are ways ICT (if we use it smartly) can help with these challenges. I must admit, one of the unhelpful things I often see is the “paralysis of analysis” problem – where initiatives are stuck in their tracks because decision-makers are worried about taking a misstep. It is in unblocking this very paralysis where our technologies can be an assist and can forgive us for having nascent or emerging governance structures regarding client/patient/citizen identifiers. Here’s how I think ICT can help…
Alvin – you are completely correct in pointing out all of the things that must be done or put in place regarding oversight and governance. I’m not sure all will be separate agencies, but generally I think this list is right.What I’d like to suggest, however, is to contemplate the proposition: “what if I did steps 8 & 9 first?”. I’m not at all trying to sound cavalier or “cowboy” about this – but to be sure, there is a wide array of non-controversial, already well-governed use cases where clients have or are being assigned identifiers. What if… right out of the gate… we stood up a way to cross-reference these to a “best-efforts” golden (definitive) demographic record. (By best-efforts, I’m suggesting that the demographic information could contain the “last update” from whichever party most recently had contact with the citizen).
Here’s why I suggest this. Alvin, your steps 1-9 mean the stakeholders will be working out the sometimes quite thorny issues of governance before taking any deployment steps – which means they will be foregoing any value until this is done. Turning the process on its head, and deploying HIE/CR infrastructure first – means that opportunistic information about a client – collected and employed for health purposes – can be leveraged right away. If we do this, a value proposition (such as it is) is immediately realized. This value proposition is constrained to a subset of opportunistic clients and a subset of opportunistic use cases – but this value proposition can, all the same, be very compelling.
I’ll use a specific example from a project with which I’m personally involved. In the TZ BID (Better Immunization Data) implementation, we are collecting into the CR information about mums and babies. We are opportunistically capturing identifying information about these mums (national IDs, if they have them, mobile phone numbers, if they have them, and basic demographic information including name, gender, domicile and DOB). The CR assigns an internal ID to this record when it is saved to the database. Likewise, we are opportunistically capturing information about these mums’ babies. As part of the TZ BID workflows, this information includes the barcode sticker ID that is placed on the baby’s immunization card the first time they present at a vaccination clinic. The baby’s demographic record is, of course, related to the mum’s demographic CR record (it is, literally, a parent-child relationship). This CR information is kept current (via a 2-way, PIX/PDQ interface) with the immunization registry software that is the key point of service application for the vaccination workflows.
On the TZ project, it is still on our plate to connect the information we have about newborn babies to the national CRVS database. There are governance issues around this, and those are not yet worked out. As soon as they are, however, we will be able to light up a simple ICT connection that yields immediate value. There is also not yet a definitive strategy for TZ’s use of (and governance of) a national health ID. We don’t need to wait on this, though. For now, we have our “immunization card” ID# and we followed good practices in how this ID was developed so that, as a candidate option, this ID could be used as a durable identifier for this child as he/she outgrows the child immunization programme and is taken on by the IMCI/primary care delivery network and beyond. My point is that TZ BID’s opportunistic adoption of an identifier for immunization purposes provides opportunistic options for the national ID governance committee and the CRVS governance committee to consider as they undertake their longer-cycle deliberations.
Happily, the OpenHIE CR is a robust cross-reference engine that will “work” with multiple IDs and can also support searching against the demographic data for cases where there is not yet an ID assigned or where it is a local ID that is not known at a point of care. Internally, it uses a globally unique ID for indexing – but this ID doesn’t need to be the one appearing on a health card (it can, literally, just be an OID or a GUID that is created by the database engine). The real power of this is that it supports “bootstrapping” of our identity initiatives out in the world. These initiatives, which may have their own independent governance, can all leverage the CR and its cross-referencing engine to resolve the same Derek Ritz (for example), even though they might have got to that single golden demographic record using different ID#s from each other. Here in Ontario, Canada (where I live), for years all of my health records were indexed to my UHC ID# (my Ontario health insurance plan, or OHIP ID) because that’s how my clinician got paid. Opportunistically, and only recently, the provincial jurisdiction decided to not set up a separate ID for health, but rather to just embrace the insurance ID. This was a governance issue that required a change in the provincial legislation to allow the “financial” ID to be allowed to be used, also, as a “health” ID. No changes were needed in the provincial CR, however. My golden record already had a reference to the OHIP#, and was also cross-referenced to the internal ID that was assigned by my family doctor’s EMR and to the hospital ID assigned by the EPR when I had my knee surgeries, etc. Flexibly, in the absence of any of these IDs, my record can be looked up by my name, address, DOB and mobile phone #, too.
Sorry… this post is now running the risk of being TLDR (too long… didn’t read). The gist, Alvin, is that we might want to opportunistically lead with the technology because of how many useful and flexible options it provides to the various governance processes to “bootstrap” their ID initiatives and because of how it shortens the “time to value” for any health workflow that, in a very non-controversial way, is well-served by immediately adopting IDs for its client subpopulations.
I hope we can launch an active discussion regarding this “bootstrap” concept. A number of us in the implementer community are starting to think that the immediate setup of pervasive OpenHIE infrastructure (even if not all of it is being exercised, immediately) is a smart strategy for health system strengthening and a useful way to focus the crucial governance discussions that must accompany national-scale health data sharing initiatives.
DJ
···
On Thursday, 11 June 2015 05:24:45 UTC-4, alvin.marcelo wrote:
Dear all,
We (at AeHIN) are planning on a capacity-building program on health information exchanges (our reference architecture is OpenHIE). Need your help with the ff.
For the client registry, I was thinking this can get very complex for developing countries quickly unless we take a stepwise approach (without taking our eyes off the long haul) –
Pls comment on this stepwise approach (let’s assume a country that is carte blanche):
- Country establishes governance for civil registration and vital statistics (lets call them the CRVS agency)
- CRVS agency establishes processes for creation of national identifier
- Establish governance for national health ID (NHID agency)
- NHID agency establishes processes for creation and maintenance of national health ID (NHID)
- Establish governance for client registry (if different from #3, CR agency)
- CR agency establishes a client registry
- Establish governance for the HIE (HIE agency)
- integrate the CR to the HIE
- Offer CR services to edge systems
Pls focus on the steps and sequence – (I might be creating too many agencies above and they might be superfluous - )…
Thanks!
Alvin B. Marcelo
ph.linkedin.com/in/alvinmarcelo
www.researchgate.net/profile/Alvin_Marcelo
resume