where does the patient record "live"?
The default assumption in most settings is a patient record is assigned to the patient's primary doctor or health facility. For example, OpenMRS, designed for a hospital setting, treats referrals as orders:
"Referrals are requests (i.e., orders) for the patient to be seen by another service. These are orders just like drugs and tests. For example, I might evaluate a patient for shoulder pain and a rash, order a drug to treat the rash, order an x-ray to evaluate the shoulder pain, and write two referral orders (one to dermatology to follow up the rash and another to physical therapy to evaluate & treat the shoulder pain)." -Burke Mamlin
This shows an important background assumption: the patient record is "owned by/assigned to" someone - namely the clinician making the referral requests.
This does not seem to be appropriate for some other typical settings where, for example, a nurse in a busy clinic refers a pregnant women to a higher level facility. There may be no clear "ownership" relationship in such a circumstance and not always an expectation that the higher clinic will report back to the nurse making the referral.
But the idea of anchoring/assigning each patient record to some other entity in the system appears almost an essential requirement to give the system some basic coherence. So what should this be?
records "owned" by clinics / CHWs?
For the kinds of scenarios we are faced with, "ownership" of the patient record in a system seems to rest more appropriately with a clinic than a clinician. Most patients seems to have a "Home Clinic" and the referrals we are interested in handling entail attendance at a different location.
Even if we are dealing with a Community Health Worker [CHW] cadre who visit women locally who may never even attend a clinic, CHWs usually are working under the auspices of a clinic, and so the patients they register can be regarded as having that clinic as their Home Clinic.
referrals within a hierarchy
We are assuming that clinics are nodes in the system, typically arranged in a geographical hierarchy which is mirrored by a hierarchy of levels in the health system (village dispensary refers to local Health Center, which refers to District Hospital).
A patient might typically be referred "up" such a hierarchy - from dispensary to clinic or to hospital. From the point of view of a digital system designed to cope with referrals, this "within hierarchy" referral model may not pose too many problems.
But reality is messier than this. Patients may be referred to clinics outside of the hierarchy, or within the hierarchy but not in a tidy "upward" chain. And, we need to be able to cope with simple non-referral movement from one clinic to another, both temporary and permanent.
Mary gets referred
Let us imagine a specific referral. Mary belongs to Clinic P, but she is ill and the nurse at clinic P decides to refer to her to Health Center Q.
When Mary arrives at Health Center Q, she says "I was at Clinic P". Assume for the moment connectivity is 100% guaranteed. We might want to consider what should happen in the digital system, and how should that be affected by (or affect) the "ownership" property of the record. For example:
- Health Center Q can view Mary's patient record, but cannot write to it (since it "belongs" to Clinic P)?
- Health Center Q can view Mary's patient record and can write to it (this would likely assume some granting of permission somehow from Clinic P)?
- Health Center Q takes over "ownership" of Mary's record? (who decides this - what are the permissions involved?)
All of these questions are important, but they already require two huge assumptions. One we have granted for the sake of argument (100% connectivity), the second is that there is no problem in identifying Mary's record correctly. This is not generally the case.
Clearly re-identification is a pre-requisite of even starting to deal with the complex "ownership" and "permissions" issues associated with a patient being referred.
So anyone interested in referral systems we are envisaging, in which the records are held in a common background database, has to concern themselves first with the issue of (re-)identification of a patient.
In case it is not clear, re-identification is a problem because names do not uniquely identify someone. Indeed, names may be spelled differently at different times, so cannot even be matched textually. Disambiguating information may help (date of birth, village, etc.) but in general it is clear that what we need for an efficient system one can trust to maintain the integrity of individual records is a unique id or some biometric identification sytem.
Let us cut to the chase and propose that the advantages lie with biometric identification. The great advantage here is that, unlike with a unique id, the biometric marker cannot be lost or mislaid.
Biometrics do not belong entirely to the future. Fingerprint scanning, as offered by Simprints, represents a functioning biometric identification system for our context which is already integrated with both the Mangologic and CommCare platforms (among others).
We mentioned at the begining the problem of double counting. With a unique id (or biomarker), this potential problem inherent in people moving around, can be resolved. In counting the number of patients attending a clinic, we are interested of course in the number of distinct unique identifiers.
the digital action of referral
So, operating now with the assumptions that connectivity and re-identification issues are both solved, we should return to the questions of how referral affects/is affected by "ownership".
Recall: Mary belongs to Clinic P, but she is ill and the nurse at clinic P decides to refer to her to Health Center Q.
We need to eliminate complexity as far as possible, so the ownership/permissions issue cannot entail that in a referral situation there needs to be some communication between Health Center Q and Clinic P (e.g. we do not want Clinic P to have to request permission to write to the medical record).
Thus, it seems to follow that whatever permissions/ownership issues exist, they must be resolved at the point of referral.
We envisage therefore that our digital referral system must incorporate a "refer" action available to Clinic P that does all we need. As the nurse explains to Mary that she needs to go to Health Center Q, she also clicks a button which affects Mary's record in the system so that it is viewable and editable by Health Center Q .
The digital referral action should also now ensure that Mary (and her condition) immediately appears in a "Pending Referrals" list for Health Center Q. This would help in referral tracking and follow-up and can help Health Center Q if there are any particular preparations needed to treat Mary.
Note again the background assumption of connectivity. The digital action of referral needs to write something into the common database before Mary appears at Health Center Q.
NFC - near field communications
A radical digital alternative, which requires far fewer assumptions to ensure that the referral hospital has the necessary information about the referral patient, is to make use of NFC chips to carry the patient record.
An increasing number of Android devices these days are "NFC-enabled", which means they have the ability to read from and write to NFC chips, which can be embedded in stickers, key-rings, bracelets, etc. The fundamental thing of course is that the chips are portable and can be carried by the patient.
In many places, clients of the health system are already charged with carrying their medical record around - usually in an exercise book. This is in a sense a digital replacement for that, with the difference that the information is directly written to, and read from, the digital system.
For such a system to work, far fewer background assumptions are required. Connectivity is not an issue for example. Whether there is a common background database in which all patient information ultimately ends up we can leave to one side for the moment. It would be desirable from a health systems point of view, but not essential for the purposes of a successful referral.
So this alternative is feasible now and can have utility even in extremely challenging situations such as refugee crises.
How much data can be written to an NFC chip? Currently, the large chips can hold up to 4k of information, which will be sufficient, for example with some encoding of fields, for many of the contexts in which we work.
What about the security of the data? The data is no less secure than the exercise books traditionally carried around. But there are two more substantial responses to this question: (1) the data can be encrypted before being written to the chip, so without the secret code used in encrypting, the data could not be read (2) the system can be defined so that patient-identifying information is not written to the chip, so even if a lost chip could be read, the information could not be attributed to an individual.
The project we described in another page "Engaging the private sector" is making use of NFC tokens to ensure that women in Monrovia can attend their "Home Clinic" but that on the occasion of referral, sufficient information is available to the referral clinic.
Video showing device writing to NFC
Created with images by mknobil - "Regional Clinic" • CDC Global Health - "Walking through Kakuma Refugee Camp" • US Army Africa - "Masaika Clinic in Tanzania Reopened - Combined Joint Task Force - Horn of Africa - 091007-N-2420K-290" • Erik Cleves Kristensen - "Rural Clinic" • Br3nda - "20151124_183810" • Prof Ken Harper - "Liberia – By Ken Harper"