Development of an information model for storing organ donor data within an electronic medical record
While approximately 25,000 people undergo transplant surgery in the United States per year, the special needs of transplant patients and of the clinicians providing their care has delayed the implementation of Electronic Health Records in this unique niche. In particular, the authors discuss problems encountered in the linking or embedding of donor data into the electronic record of the transplant recipient.
Problems include: (1) lack of standards; (2) problems linking records when the donor is deceased; (3) privacy and security issues; (4) extant stand-alone systems which reduce the impetus for integration into an EHR.
Previous attempts to include donor data in the recipient record have not been fully satisfactory. One method, utilized in LOINC codes, is to include a "donor" sub-specification within the "system" axis. While this is a straightforward solution (that has yet to involve more than about 10 laboratory tests other than Human Leukocyte Antigen (HLA) and blood bank codes), this method has the potential for "unbounded proliferation" as many of the more than 34,000 LOINC codes are duplicated to differentiate "donor" from 'recipient" codes, and then repeated any number of additional times to differentiate codes for "mother" from those of "baby," or "baby" from "father," or to differentiate any number of familial relationships. In addition to exponentially increasing the number of codes needed, there is an additional, logical difficulty in recording the exact same laboratory reading using different codes depending on the relationship of the receiving record to the tested patient.
The strategy successfully employed by the authors is to embed donor data into the recipient's record using an object model that specifies for all observations an attribute for the person on whom the test is performed ("subject") and a separate attribute for the person in whose record the observation is stored ("record-target"). This method is called "post-coordinated" to differentiate it from the "pre-coordination" required to assign a donor- and recipient-specific LOINC code at the inception of the lab test, as opposed to the choice of attributes made only when the finished lab result is actually applied to a patient record.
Though conceptually simple and consistent with the HL-7 Reference Information Model (RIM), the authors do recognize two limitations of this method. The first is the need for separate fields in the electronic record to differentiate the "subject" from the "record-target." These fields would be attributes of all lab tests, even though they would only be different in a small fraction of all lab observations. Secondly, users would need to be aware that the results they see in a patient's chart may not always be based on samples drawn from that patient. Thirdly, this method did require the creation of a few new LOINC codes for coding the "subject" field (e.g., "mother," "newborn," or "donor"). As well, the simple "donor" vs. "recipient" distinction is inadequate in those rare situations when individuals receive organs from more than one donor, or when donors may later become organ recipients. Lastly, what they describe as "legitimate security" concerns can limit the amount of donor information stored in a recipient’s record.
While approximately 25,000 people undergo transplant surgery in the United States per year, the special needs of transplant patients and of the clinicians providing their care has delayed the implementation of Electronic Health Records in this unique niche. In particular, the authors discuss problems encountered in the linking or embedding of donor data into the electronic record of the transplant recipient.
Problems include: (1) lack of standards; (2) problems linking records when the donor is deceased; (3) privacy and security issues; (4) extant stand-alone systems which reduce the impetus for integration into an EHR.
Previous attempts to include donor data in the recipient record have not been fully satisfactory. One method, utilized in LOINC codes, is to include a "donor" sub-specification within the "system" axis. While this is a straightforward solution (that has yet to involve more than about 10 laboratory tests other than Human Leukocyte Antigen (HLA) and blood bank codes), this method has the potential for "unbounded proliferation" as many of the more than 34,000 LOINC codes are duplicated to differentiate "donor" from 'recipient" codes, and then repeated any number of additional times to differentiate codes for "mother" from those of "baby," or "baby" from "father," or to differentiate any number of familial relationships. In addition to exponentially increasing the number of codes needed, there is an additional, logical difficulty in recording the exact same laboratory reading using different codes depending on the relationship of the receiving record to the tested patient.
The strategy successfully employed by the authors is to embed donor data into the recipient's record using an object model that specifies for all observations an attribute for the person on whom the test is performed ("subject") and a separate attribute for the person in whose record the observation is stored ("record-target"). This method is called "post-coordinated" to differentiate it from the "pre-coordination" required to assign a donor- and recipient-specific LOINC code at the inception of the lab test, as opposed to the choice of attributes made only when the finished lab result is actually applied to a patient record.
Though conceptually simple and consistent with the HL-7 Reference Information Model (RIM), the authors do recognize two limitations of this method. The first is the need for separate fields in the electronic record to differentiate the "subject" from the "record-target." These fields would be attributes of all lab tests, even though they would only be different in a small fraction of all lab observations. Secondly, users would need to be aware that the results they see in a patient's chart may not always be based on samples drawn from that patient. Thirdly, this method did require the creation of a few new LOINC codes for coding the "subject" field (e.g., "mother," "newborn," or "donor"). As well, the simple "donor" vs. "recipient" distinction is inadequate in those rare situations when individuals receive organs from more than one donor, or when donors may later become organ recipients. Lastly, what they describe as "legitimate security" concerns can limit the amount of donor information stored in a recipient’s record.