Section 19.3: Data Stewardship and Ethical Frameworks
From Technical Management to Ethical Guardianship: Upholding Patient Trust in the Digital Age.
Data Stewardship and Ethical Frameworks
Moving Beyond Technical Data Management to True Stewardship.
19.3.1 The “Why”: The Awesome Responsibility of Digital Health Data
In your pharmacy career, you have always been a guardian of secrets. The paper prescription, the patient profile screen, the label on the vial—each contains a fragment of a person’s life story, entrusted to your professional care. You instinctively know not to discuss a patient’s medication at the checkout counter or leave a sensitive prescription in a public area. This duty of confidentiality is deeply ingrained in the profession. Now, as an informatics pharmacist, this responsibility is about to expand on an exponential scale. The transition from paper records to a fully integrated EHR represents a fundamental shift in the very nature of health information. A paper chart is a physical object; it can only be in one place at one time, its use is inherently limited, and it degrades over time. Digital data, however, is ethereal, infinitely replicable, and permanent. A single data point—a diagnosis, a lab value, a dispensed medication—can be copied, analyzed, aggregated, and used in countless ways, many of which were never imagined when the data was first collected.
This transformation presents a profound dual reality: it unlocks unprecedented opportunities to improve health, while simultaneously creating novel risks to patient privacy and trust. We can now analyze data from thousands of patients to identify new drug side effects, build predictive models to flag patients at risk for sepsis, and conduct research that was once impossible. But this same data, if used improperly, could lead to discrimination, stigmatization, or a breach of the sacred trust that underpins the patient-provider relationship. Data stewardship is the formal recognition of this dual reality. It is the ethical and organizational framework that moves us beyond simple data management (i.e., keeping the servers running) to true guardianship. It asserts that health data is not merely a technical asset to be administered; it is a human-centered trust to be honored. As an informatics pharmacist, you are on the front lines of this new ethical frontier. You will be asked to extract, analyze, and interpret medication data for a variety of purposes. Your ability to navigate these requests with a strong ethical compass, ensuring that every use of data is appropriate, secure, and ultimately serves the patient, is one of the most important and defining responsibilities of your new role.
Retail Pharmacist Analogy: The Guardian of the Patient Profile
Imagine a long-time patient at your pharmacy. Her profile is a detailed tapestry of her health journey. You know she takes medication for hypertension and diabetes. You also know she takes a highly specific medication for a rare autoimmune disease, another for severe depression, and that she recently received a prescription for an opioid after a major surgery. This collection of data points is far more than a list of drugs; it tells a sensitive and deeply personal story.
- Data Management (The Basic Task): Your basic job is to ensure this data is accurate for dispensing. You check the dose, the sig, and make sure her address is correct. This is like the IT department ensuring the EHR database is backed up and running correctly. It’s essential, but it’s not stewardship.
- Data Stewardship (The Ethical Obligation): Your stewardship role comes into play in how you use and protect this information.
- Appropriate Use (Beneficence): You proactively use the data for her benefit. You see the new opioid and counsel her on the risk of constipation and sedation. You notice her A1c is still high despite her diabetes medication and recommend she speak to her doctor about intensification. This is using data for quality improvement.
- Protection (Non-maleficence): A person comes to the counter and asks, “What does my neighbor, Mrs. Smith, take? I’m just curious.” You refuse, citing patient privacy. A pharmaceutical sales rep asks if you can give them a list of all your patients on their company’s new blockbuster drug. You refuse, as this is an inappropriate commercial use of patient data. You are protecting the data from harm and misuse.
- Context and Interpretation: You understand the story behind the data. When you see the opioid prescription, you don’t just see a drug; you see a person in post-surgical pain. Your interpretation is nuanced by your clinical knowledge.
As an informatics pharmacist, you are becoming the steward of thousands of these patient stories, now digitized and aggregated. The core ethical principles are identical: use the data to help, never to harm; protect it fiercely; and always, always interpret it with the deep clinical context that only a healthcare professional can provide.
19.3.2 Defining the Roles: Owners, Custodians, and Stewards
To build an effective data governance framework, it is essential to first establish clear roles and responsibilities. Too often, organizations use terms like “data ownership” loosely, leading to confusion and a lack of accountability. A mature model recognizes three distinct, yet complementary, roles. Understanding your place in this triad is the first step toward becoming an effective data steward.
Data Owner
The “What” and “Why”
A senior organizational leader (e.g., CIO, CFO, CMO) who has ultimate executive responsibility for a specific data domain (e.g., financial data, clinical data). They are accountable for the asset but delegate operational management.
Key Responsibilities: Secures funding, sets high-level policy, assigns stewards, is ultimately accountable for breaches or misuse.
Data Custodian
The “Where” and “How”
The Information Technology (IT) department. They are responsible for the technical environment where the data lives. They manage the hardware, databases, and security infrastructure.
Key Responsibilities: Manages access controls, performs backups, ensures system uptime, implements security protocols. They don’t define what the data *means*.
Data Steward
The “Who” and “How (Ethically)”
A subject-matter expert (SME), like an informatics pharmacist, who is responsible for defining, managing the quality of, and approving the appropriate use of a specific data domain (e.g., medication data).
Your Role: Defines data elements, ensures data quality, reviews data requests, and provides clinical context. You are the guardian of the data’s meaning and integrity.
Masterclass Table: The Pharmacy Data Steward in Action
The role of the steward becomes clear when you apply it to specific, real-world scenarios. Imagine the health system wants to analyze Adverse Drug Events (ADEs). Here’s how the roles break down:
| Scenario | The Data Owner’s Role (CMO) | The Data Custodian’s Role (IT) | The Data Steward’s Role (You) |
|---|---|---|---|
| Defining “ADE” | Provides the strategic imperative: “We must reduce preventable ADEs as part of our annual quality goals.” | Ensures there is a field or system available to capture the data. | You define what data elements constitute an ADE. Is it just an allergy? Is it an ICD-10 code for poisoning? Is it a trigger from an incident reporting system? You create the official business definition and the logic for identifying one in the data. |
| Ensuring Data Quality | Approves the budget for resources needed to improve data quality. | Maintains the systems where the data is entered and stored. | You identify inconsistencies. You notice that ADEs documented in nursing notes are not being captured in the incident reporting system. You lead a project to create a more standardized documentation workflow to improve the quality and completeness of the data at the source. |
| Approving a Data Request | Sets the policy that all research requests for clinical data must be approved by the IRB and the relevant data steward. | Provides the technical service of extracting the data, but only after receiving documented approval from the steward. They are the gatekeeper of the database. | You are the approver. A researcher requests “all data on patients who had an ADE.” You review the request, ensure it has IRB approval, and apply the “minimum necessary” principle, asking “Do you need the patient’s full name and address, or can a de-identified dataset answer your research question?” You provide the final sign-off before IT can release the data. |
19.3.3 The Five Pillars of an Ethical Data Framework
A robust data stewardship program is built upon a foundation of core ethical principles. These principles, derived from the foundations of medical ethics, provide a consistent framework for evaluating any new use of patient data. As a data steward, you must internalize these pillars and use them as your guide when navigating complex data requests.
1. Beneficence: The Duty to Do Good
This principle dictates that patient data should be used to actively promote patient welfare and the public good. It is the ethical justification for all secondary data use. We collect this data not just to treat one patient, but to learn from the experiences of many to improve the care for all.
In Practice: Championing projects that use aggregated data to identify prescribing trends, measure adherence to clinical guidelines, or build surveillance tools for detecting ADEs.
2. Non-maleficence: The Duty to Do No Harm
This is the cornerstone of data protection. It requires that we take active measures to prevent the misuse, unauthorized access, or misinterpretation of data that could lead to harm, such as a privacy breach, discrimination, or clinical error.
In Practice: Enforcing strict access controls, rigorously de-identifying data sets before release, and challenging data requests that are overly broad or lack a clear, legitimate purpose.
3. Autonomy: Respect for Persons
This principle recognizes the right of individuals to have control over their own information. While consent is implied for the primary use of data in clinical care, this becomes more complex for secondary uses. It requires transparency with patients about how their data may be used and providing clear mechanisms for consent or dissent, especially for research.
In Practice: Working with the IRB and Privacy Office to ensure research protocols have appropriate patient consent procedures and being transparent in the hospital’s privacy policies.
4. Justice: The Duty of Fairness
This principle demands that the benefits and burdens of data use are distributed fairly. It requires us to be vigilant against creating or perpetuating biases in our data and algorithms. The data of all populations should be used to benefit all populations.
In Practice: Scrutinizing clinical algorithms for potential bias based on race, gender, or socioeconomic status. Ensuring that quality improvement initiatives benefit all patient populations equitably.
5. Fidelity: Upholding Trust
This is the overarching principle that binds the others together. It reflects the implicit promise made to every patient that their sensitive health information will be protected and used responsibly. Every action a steward takes must be aimed at preserving and strengthening this public trust. A single major breach can erode confidence in the entire healthcare system.
In Practice: Demonstrating unwavering commitment to privacy and security, being transparent about data uses, and advocating for the patient’s perspective in all governance discussions.
The Ethical Minefield of Algorithmic Bias
The principle of Justice has become critically important in the age of artificial intelligence and machine learning. An algorithm is only as good as the data it’s trained on. If historical data reflects existing societal or clinical biases, an algorithm will learn and amplify those biases, often with devastating consequences.
A Classic Pharmacy Example: Imagine you want to build a predictive model to identify patients at high risk of opioid misuse. You train it on historical data. However, it’s known that due to a complex mix of socioeconomic and racial factors, clinicians have historically been more likely to label patients from minority backgrounds as “drug-seeking.” An algorithm trained on this data will learn this pattern. It might then incorrectly flag a Black patient in legitimate pain as high-risk, while failing to flag a white patient with the exact same clinical profile. The algorithm doesn’t have malice; it simply reflects the bias present in its training data.
As a data steward, your role is to be the human check on the machine. When reviewing such a project, you must ask the hard questions: “What are the demographic features in the training data? Have we tested the model’s performance across different racial and ethnic groups? Is it possible this tool could worsen health disparities?” This is a new and essential competency for the modern informatics pharmacist.
19.3.4 The Spectrum of Data Use: A Framework for Approval
Not all uses of data carry the same level of risk or require the same level of oversight. As a steward, you must be able to categorize data requests to determine the appropriate approval pathway. A request for an aggregated, de-identified count of patients on a medication is fundamentally different from a request for an identified list of patients for a clinical trial. This spectrum of use is the key to creating an efficient and ethical data request process.
Masterclass Table: Categorizing and Triaging Data Requests
| Category of Use | Description & Examples | Data Level | Required Approvals | Your Role as Steward |
|---|---|---|---|---|
| Primary Use: Patient Care | Using data to directly treat the patient.
|
Identified | Consent is implied by seeking treatment. Access is governed by role-based security. | Your role here is indirect: to ensure the systems are designed to make the right data available to the right clinician at the right time, safely and accurately. |
| Secondary Use: Healthcare Operations & Quality Improvement (QI) | Using data to run the business of the hospital and improve care processes.
|
Aggregated, De-identified, or Limited Data Set | Generally covered under HIPAA as part of healthcare operations. Formal approval from a QI committee and the Data Steward is best practice. | This is a core part of your job. You review the request’s validity, ensure the “minimum necessary” data is being provided, and may even be the one to generate the report. You are the gatekeeper for operational data. |
| Secondary Use: Research | Using data to create generalizable new knowledge.
|
Identifiable or De-identified | Requires formal Institutional Review Board (IRB) approval. This is non-negotiable. The IRB is the formal committee that reviews the ethics of the research protocol and the patient consent process. | You serve as a crucial checkpoint. A researcher will bring their IRB approval letter to you with their data request. Your job is to (1) Verify IRB approval is in place. (2) Review the technical data request to ensure it exactly matches what the IRB approved. (3) Provide final sign-off before the data custodian (IT) will extract and release the data. |
| Tertiary Use: External Reporting & Commercial Use | Sharing data with external entities.
|
Varies (Identified to De-identified) | Requires the highest level of scrutiny, involving the Privacy Office, Legal Counsel, and often the C-suite. | You are an essential consultant. If a company wants to purchase pharmacy data, you will be called upon to help define the data elements, ensure the de-identification process is robust, and raise any ethical red flags about the intended use. |
19.3.5 Operationalizing Ethics: The Data Governance Committee & Request Workflow
To effectively manage the spectrum of data use, organizations need a dedicated forum and a standardized process. This is the role of the Data Governance Committee (DGC) and the formal data request workflow. The DGC is a specialized advisory group, distinct from a clinical content CAG, whose members have expertise in data analytics, ethics, privacy, and law. It serves as the central clearinghouse for complex data requests, ensuring every request is vetted against the organization’s ethical and policy frameworks.
The Data Request Workflow in Action
Lifecycle of a Research Data Request
Scenario: A cardiology researcher wants a dataset of patients on DOACs to study bleeding rates.
Protocol Development & IRB Approval
The researcher designs their study, defining the patient cohort, the specific data elements needed (e.g., demographics, DOAC type, dose, co-morbidities, lab results), and the statistical analysis plan. They submit this entire protocol to the Institutional Review Board (IRB). The IRB reviews it for ethical conduct and patient safety, and if approved, issues an official approval letter.
Formal Data Request Submission
The researcher submits a formal ticket to the IT/Analytics department using a standardized form. They attach the IRB approval letter and specify the exact data elements required, as approved in their protocol.
Data Steward Review (Your Role)
The request is routed to you as the steward of medication data. You perform several checks:
- Verification: You confirm the IRB approval is valid and matches the request.
- Feasibility: Can this data actually be extracted? Do we capture all the requested fields reliably?
- Minimum Necessary: Does the request align with the IRB protocol? Are they asking for extra data “just in case”? You push back if the request is broader than what was approved.
- Definition Clarification: You provide the exact technical specifications for the analytics team. For “DOAC,” you specify the exact NDC codes or medication classes to be queried. For “bleeding event,” you specify the ICD-10 codes to be used.
Data Governance Committee / Privacy Officer Review
For complex or sensitive requests, your recommendation is forwarded to the DGC. They provide a final check from a legal, privacy, and ethical standpoint. For routine, IRB-approved requests, the Privacy Officer may provide the final sign-off based on your stewardship review.
Data Provisioning (Data Custodian)
Only after receiving all approvals does the data custodian (the IT/analytics team) execute the query. They extract the data, de-identify it according to the protocol, and provision it to the researcher in a secure manner. An audit trail of the request, approvals, and release is logged.
The Pharmacist’s Playbook for Reviewing a Data Request
When a data request hits your queue, use this checklist to guide your stewardship review:
- What is the source of authority? Is this for QI, Operations, or Research? If Research, is there a valid, current IRB approval letter attached?
- What is the specific question being asked? Is the purpose clear and legitimate? If the request is just “I want to see all the data on Drug X,” push back for a more specific hypothesis or goal.
- Does the data requested match the authority? Does the list of data elements in the ticket exactly match the list approved by the IRB or QI committee? Challenge any discrepancies.
- Is this the “minimum necessary” data to answer the question? Are they asking for direct patient identifiers (name, MRN) when a de-identified dataset would suffice? Are they asking for 10 years of data when 2 years is enough?
- Are the data elements clearly defined? Will the analyst pulling the data know exactly what “on a DOAC” means? Provide the specific technical definitions (e.g., medication route, order status, NDC list) to prevent ambiguity and ensure the data is accurate.
- What are the risks? What is the sensitivity of this data? What is the risk of re-identification? Does the provisioning plan include appropriate security measures (e.g., secure server, data use agreement)?
Your documented answers to these questions form the rationale for your decision to approve, modify, or deny the request.