Hospital Information Systems

Chapter 8
Data Management, Warehousing and Information Quality

Post Graduate Program in Health Care Management
Hospital Information Systems   •   Post Graduate

Data Management, Warehousing and Information Quality

Introduction

Health care organizations depend on data for clinical decision-making, operational coordination, financial management, public-health surveillance, research, quality improvement and regulatory accountability. Yet data do not become useful merely because they are collected or stored electronically. A hospital may possess millions of laboratory results, medication orders, diagnoses, images and administrative transactions while still being unable to answer a basic management question reliably. The central challenge is to transform distributed, heterogeneous and time-sensitive observations into information that is accurate, interpretable, secure and fit for a particular use.

Data management in health care therefore extends beyond database administration. It includes the design of data capture, validation, classification, storage, integration, metadata, master data, longitudinal records, warehousing, retention and quality assurance. These activities must be aligned with clinical workflows and organizational purposes. Poorly designed data processes can create clinical risk, duplicate patients, incorrect performance indicators, inequitable decisions and non-compliance with privacy obligations.

This chapter examines data as an organizational and socio-technical resource. It distinguishes operational records from analytical repositories, explains the role of metadata and master data, develops a framework for information quality, and applies these ideas to a hospital case.

Learning Objectives

By the end of this chapter, the reader should be able to:

  1. Design appropriate approaches to data capture, validation and storage in health care settings.
  2. Explain the functions of metadata, master data and longitudinal patient records.
  3. Distinguish operational databases, data marts, data warehouses, data lakes and lakehouses.
  4. Evaluate completeness, accuracy, timeliness, consistency and fitness for use.
  5. Propose data-quality controls, governance arrangements and retention policies.
  6. Assess managerial, ethical, privacy and regulatory implications of health-data practices.

1. Data as a Managed Health-Care Asset

A useful distinction is between a datum, information and knowledge. A datum is a recorded value, such as a temperature of 38.4 °C. Information is that value interpreted in context—for example, a fever recorded at a specified time for a particular patient. Knowledge combines information with clinical or managerial understanding, such as recognizing a possible infection pattern when fever is associated with other observations.

The value of data is relational rather than absolute. A blood-pressure value may be appropriate for clinical care but insufficient for a population study if measurement time, position, device and patient context are absent. Thus, a data element should be assessed in relation to its intended use, users, time horizon and risk.

Health-care data have several distinctive characteristics:

  • Multiplicity: data arise from electronic health records, laboratory systems, imaging systems, pharmacy systems, claims, devices, surveys and external registries.
  • Heterogeneity: formats, coding systems, units, terminology and levels of detail vary across systems.
  • Temporal sensitivity: the value of information often declines when it is delayed; medication and bed-status data may become obsolete within minutes or hours.
  • High consequence: errors can affect diagnosis, treatment, resource allocation, reimbursement and public trust.
  • Relational and longitudinal structure: the same person may appear across encounters, facilities and years, requiring reliable identity management.
  • Regulatory sensitivity: health data commonly include identifiable, confidential or specially protected information.

Data management is consequently a governance discipline as well as a technical one. It requires explicit ownership, standards, controls, accountability and continuous improvement.

2. The Data Life Cycle

A health-data life cycle normally includes planning, capture, validation, storage, use, sharing, archival and disposal. These stages are not strictly linear. Quality feedback from analysis may require changes to data capture, while a legal investigation may require preservation of records that would otherwise be deleted.

2.1 Data capture

Capture begins with defining the purpose of a data element. A well-designed specification identifies its name, definition, permissible values, unit, source, responsible role, requiredness, timing and sensitivity classification. For example, “discharge date” should not be confused with “date discharge was planned” or “date the discharge summary was signed.”

Capture methods include structured forms, barcode scanning, device integration, natural-language documentation, imports from external organizations and manual transcription. Structured capture generally supports validation and analysis more effectively, but excessive structure can burden clinicians and encourage workarounds. Free text preserves nuance and narrative reasoning, but it is more difficult to standardize and analyze.

The design principle is capture once, use many times. Re-entering the same information into multiple systems increases transcription error and creates inconsistent versions. Interfaces, reusable clinical documentation and standardized identifiers reduce this problem.

2.2 Validation

Validation checks whether data conform to defined rules. Common controls include:

  • Type checks: a date field must contain a valid date rather than arbitrary text.
  • Range checks: a physiological measurement must be within a plausible range, while allowing exceptional values to be reviewed rather than automatically discarded.
  • Format checks: an identifier must follow an approved pattern.
  • Referential checks: a medication administration must refer to an existing patient, encounter and medication concept.
  • Completeness checks: required data should be present at the appropriate workflow stage.
  • Temporal checks: a specimen collection time should not occur after its result time; a discharge should not precede admission.
  • Cross-field checks: a pregnancy-related field may require a compatible demographic or clinical context, while such rules must be designed carefully to avoid discriminatory assumptions.

Validation should distinguish a syntactically invalid value from a clinically unusual value. A temperature of 45 °C may be implausible and require confirmation, but silently deleting it may conceal a device or documentation problem. Hard stops are appropriate for high-risk errors; warnings or deferred review are often better for unusual but possible observations.

2.3 Storage and integration

Storage design should reflect workload, security, availability, recovery requirements and analytical needs. Transactional systems prioritize reliable, concurrent recording. Analytical systems prioritize integrated historical queries. A single architecture rarely optimizes both purposes.

Integration depends on shared identifiers, interface standards, terminology mapping and reconciliation processes. Common interoperability approaches include message-based exchange, application programming interfaces and standardized clinical resources. Technical interoperability, however, does not guarantee semantic interoperability: two systems may exchange a code while assigning it different meanings.

3. Database and Repository Architectures

Operational databases

Operational or online transaction-processing systems support day-to-day activities such as registration, order entry, medication administration and billing. They typically use normalized structures to reduce unnecessary duplication and preserve transaction integrity. Their data are current but may be fragmented across applications and unsuitable for complex historical analysis.

Data warehouses and data marts

A data warehouse is a governed repository that integrates data from multiple sources, preserves historical information and is optimized for reporting and analysis. A data mart is a subject-specific subset, such as a finance or emergency-department repository. Warehouses usually apply transformation and quality rules before data are made broadly available.

A common dimensional model contains:

  • Fact tables, which record events or measurements, such as admissions, laboratory results or medication administrations.
  • Dimension tables, which describe analytic perspectives, such as patient, department, provider, date and diagnosis.

The choice between a normalized enterprise model and a dimensional model depends on the use case. Dimensional models are often easier for analysts and dashboard tools; normalized models may better represent complex relationships and reduce duplication.

Data lakes and lakehouses

A data lake stores large volumes of raw or lightly processed data, including text, images, device streams and structured records. It can support exploratory research and machine learning but may become a “data swamp” if metadata, ownership and quality controls are weak. A lakehouse seeks to combine the flexibility of a lake with stronger table management, governance and analytical reliability.

These architectures are not interchangeable. The appropriate choice depends on latency, governance, data structure, users, cost, privacy risk and the degree of transformation required.

4. Metadata and Master Data

4.1 Metadata

Metadata are data about data. They make records interpretable, discoverable and governable. Important categories include:

  • Business metadata: definition, purpose, owner and approved use.
  • Technical metadata: data type, table, field length, interface and transformation logic.
  • Operational metadata: creation time, update time, source system and processing status.
  • Clinical metadata: measurement method, unit, reference range and clinical context.
  • Governance metadata: sensitivity class, retention period, access restrictions and legal basis.
  • Provenance metadata: origin, transformations, users and downstream products.

A data catalogue should allow a manager to discover not only that a field called LOS exists, but whether it means length of stay in hours or days, whether observation stays are included, and how missing discharge times are handled. Without such information, dashboards can give an appearance of precision while embedding unknown assumptions.

Data lineage is especially important. Lineage documents how a value travels from source capture through interfaces, transformations, warehouse tables and reports. It supports audit, troubleshooting, impact analysis and defensible interpretation of indicators.

4.2 Master data

Master data are relatively stable, shared entities used across processes. In hospitals these may include patients, providers, departments, facilities, clinical products, suppliers and terminology concepts. Master data management establishes authoritative definitions, identifiers, stewardship and synchronization rules.

Patient identity management is a high-risk example. Duplicate records can fragment a patient’s history; overlays can combine two people’s records and create serious clinical danger. Controls may include demographic matching, enterprise master patient indexes, duplicate detection, human review, merge governance and an auditable reversal process. Automated matching should support—not replace—appropriate human oversight, particularly where names, addresses or demographic patterns are culturally variable.

Reference data are controlled values used to classify data, such as sex and gender categories, encounter types, units of measure or discharge dispositions. Reference-data governance should document version changes, because a category’s meaning may change over time.

5. Longitudinal Health Records

A longitudinal record represents a person’s health-related information across encounters, providers and time. Its usefulness depends on accurate identity, temporal ordering, provenance and context. A longitudinal view should preserve both the clinical event and the fact that the record may have been entered, amended or corrected later.

Important design principles include:

  1. Event time versus record time: the time care occurred may differ from the time documentation was entered.
  2. Versioning: amendments should preserve the original record and identify the author, time and reason for change.
  3. Provenance: users should know whether a value came from a clinician, device, patient, external organization or inferred algorithm.
  4. Uncertainty: unknown, not applicable, not asked and missing should not be collapsed into one blank value.
  5. Interoperability: clinical concepts should be represented using agreed terminologies and units.
  6. Minimum necessary access: a longitudinal record should not imply unrestricted access by every employee.

A record is not simply a chronological list. It is a curated representation of encounters, observations, assessments, orders, procedures, results, communications and administrative events. The design must support both immediate clinical use and later secondary uses without compromising the original clinical meaning.

6. Information Quality: Dimensions and Measurement

Information quality is multidimensional. No single quality score can substitute for understanding the purpose and risk of a dataset. The following dimensions are especially important.

Completeness

Completeness concerns whether required data are present. A simple field-completeness measure is:

C = (npresent ÷ nexpected) × 100%

Here, C is completeness percentage, npresent is the number of records containing an acceptable value, and nexpected is the number of records for which the value should have been recorded. The denominator must be defined carefully. A field may be legitimately not applicable, so “not applicable” should not automatically be treated as missing.

Completeness can be measured at field, record, encounter, population or process level. A 98% completion rate may conceal that the missing 2% are concentrated in a vulnerable population or a high-risk clinical unit.

Accuracy

Accuracy is the degree to which a recorded value represents the real-world attribute or event. It may be assessed against a trusted source, a validated instrument, clinical review or a reconciliation process. Accuracy differs from precision: a value can be recorded consistently but be consistently wrong.

Timeliness

Timeliness concerns whether information is available within the period required for its use. A laboratory result delivered after a clinical decision may be accurate but not timely for that decision. Timeliness should therefore be expressed relative to a service-level expectation, such as the proportion of urgent results available within a specified interval.

Consistency

Consistency means that related representations agree according to defined rules. Examples include the same patient identifier across systems, compatible units, and an admission date that precedes discharge. Consistency is not always uniformity: legitimate clinical differences may exist, but they should be explainable.

Validity and uniqueness

Validity is conformity with permitted structure, domain and business rules. Uniqueness means that entities or events are not duplicated inappropriately. A database can be 100% valid in format and still inaccurate in substance.

Fitness for use

Fitness for use is the most important integrative concept. Data are fit for a purpose when their quality, granularity, context, access and timing are adequate for the intended decision. Data suitable for staffing forecasts may not be suitable for clinical research or individual treatment decisions.

A useful quality-assessment matrix identifies the use case, decision risk, required dimensions, threshold, measurement method and remediation owner. Quality thresholds should be risk-based rather than arbitrary. A minor formatting defect in a low-risk report does not carry the same consequence as an incorrect allergy or patient identity.

7. Quantitative Quality Indicators

Quality indicators should be interpretable and accompanied by definitions. For example, a duplicate rate can be expressed as:

D = (nduplicaterecords ÷ ntotalrecords) × 100%

where D is the duplicate percentage. The calculation assumes that duplicate records have been identified using a defined detection method and that the denominator is clearly specified.

For a binary quality test across records, a basic validity rate is:

V = (nrecordspassingrule ÷ nrecordstested) × 100%

Neither indicator proves that all unobserved errors are absent. Sampling, false positives and false negatives must be considered. In high-stakes settings, organizations should report confidence limitations, stratify by department or population, and examine trends rather than relying on a single aggregate value.

Worked example

An outpatient service expects allergy status to be documented for 1,200 encounters. Acceptable values are “no known allergy,” a specific allergy, or a documented unknown status. Of these encounters, 1,140 contain an acceptable value.

C = (1,140 ÷ 1,200) × 100% = 95%

The result is 95% completeness. Management should not conclude that the remaining 5% are random. Further analysis should determine whether missingness is concentrated among particular clinics, shifts, age groups or registration pathways. The corrective intervention might be workflow redesign rather than simply adding a mandatory field.

8. Data Warehousing and Analytical Governance

A warehouse project begins with decisions and questions, not with technology. Leaders should identify the decisions to be improved, measures required, populations covered, acceptable latency and accountability for definitions.

A typical extract-transform-load or extract-load-transform process includes:

  1. extracting data from source systems;
  2. profiling structure, distributions and anomalies;
  3. standardizing identifiers, units and terminology;
  4. transforming data according to documented rules;
  5. validating counts, totals, relationships and quality thresholds;
  6. loading curated warehouse structures;
  7. publishing metadata, lineage and access controls; and
  8. monitoring failures, changes and downstream reports.

A warehouse should preserve source data or an auditable representation of it. Transformation rules must be versioned. If a definition of “readmission” changes, users should be able to determine which reports used the old and new definitions.

Clinical and managerial data products should distinguish descriptive, diagnostic, predictive and prescriptive uses. Predictive models require additional attention to training data quality, outcome definitions, missingness, bias, drift and explainability. A model cannot correct fundamentally unreliable source data merely by using sophisticated algorithms.

9. Retention, Archiving and Disposal

Retention is a lifecycle decision balancing clinical continuity, legal requirements, research value, operational needs, storage cost and privacy risk. A retention schedule should specify the record category, responsible owner, minimum retention period, legal hold procedure, archive format, access conditions and disposal method.

Retention does not mean keeping everything forever. Excessive retention increases the attack surface, complicates discovery and may preserve outdated or misleading information. Conversely, premature deletion can harm continuity of care and violate legal obligations. Records subject to litigation, investigation or audit must be placed on legal hold and protected from routine deletion.

Archival systems should preserve authenticity, readability, provenance and access controls. Disposal should be secure and documented, including deletion from replicas, caches and backups where technically and legally appropriate. De-identification for secondary use must be assessed for re-identification risk; removing names alone is rarely sufficient when dates, locations and rare conditions remain available.

10. Governance, Ethics and Regulation

Data governance defines who may decide, who is accountable and how decisions are enforced. A practical governance structure commonly includes:

  • an executive sponsor who aligns data strategy with organizational priorities;
  • data owners responsible for business meaning and acceptable use;
  • data stewards who maintain definitions, quality rules and issue resolution;
  • information-security and privacy officers;
  • clinical representatives who assess safety and workflow effects; and
  • technical custodians who operate systems and controls.

Ethical governance requires more than legal compliance. Core concerns include confidentiality, informed and meaningful use, fairness, transparency, proportionality, patient autonomy and accountability. Access should be role-based and limited to legitimate purposes. Audit logs should record access and changes, and unusual access patterns should be investigated.

Secondary uses such as research, quality improvement and artificial-intelligence development should have a documented purpose, appropriate authorization, data minimization and safeguards. Algorithms trained on incomplete or historically biased data may reproduce inequities. Governance should require subgroup performance assessment, human oversight and a process for contesting harmful outcomes.

11. Illustrative Case: Integrating Emergency-Department Data

Background

A fictional regional hospital operates an electronic health record, laboratory system, radiology system and separate patient-flow application. Executives report that emergency-department length of stay differs substantially across dashboards. Clinicians also report occasional duplicate patient charts.

Problem

One dashboard calculates length of stay from registration to discharge order, another uses arrival to physical departure, and a third excludes patients who leave before treatment. Source systems use different patient identifiers and record times in different time zones. Missing departure times are interpreted as zero in one extract.

Analysis

The data team first creates a data catalogue defining arrival, registration, treatment start, disposition and departure. It maps each field to its source, event time, record time, unit and transformation rule. A comparison of 500 encounters identifies 28 missing departure times and 17 probable duplicate patient identities. The team also finds that the dashboard’s denominator excludes left-without-being-seen cases without stating this limitation.

Approach and solution

The hospital establishes an enterprise patient identifier and a governed matching process. It separates event time from documentation time and retains the source timestamp. A dimensional warehouse is built with an encounter fact table and date, patient, provider, location and disposition dimensions. Length of stay is defined explicitly for each approved use case.

For encounters with valid arrival and departure times, elapsed duration is calculated as:

LOS = tdeparture − tarrival

where LOS is length of stay and both times use the same time zone and time unit. Encounters without a valid departure time are reported separately rather than assigned a zero duration. The data catalogue documents inclusion and exclusion rules, and the dashboard displays a quality warning when completeness falls below the agreed threshold.

Outcome

After three reporting cycles, dashboard differences are reduced because all products use the same governed definition. Duplicate charts decline through improved registration matching and human review. Managers discover that the apparent performance improvement was partly caused by excluding patients who left before treatment. The revised report supports a more honest operational discussion and prompts a workflow intervention for delayed discharge documentation.

Learning points

The case demonstrates that data quality is not solved by a warehouse alone. Definitions, identity management, timestamp governance, missing-data treatment, lineage and accountable users are equally important. It also shows why a metric must disclose its denominator and business rules.

12. Implementation Best Practices and Limitations

Effective programs generally adopt the following practices:

  1. Start with high-value, high-risk data domains such as patient identity, allergies, medications, diagnoses and emergency timestamps.
  2. Assign named owners and stewards for critical data elements.
  3. Create a business glossary and searchable catalogue before scaling analytics.
  4. Design validation within workflow, using warnings and escalation proportionate to risk.
  5. Measure quality by population, location, time and use case rather than only overall averages.
  6. Preserve source values, transformation rules, versions and lineage.
  7. Separate operational transaction processing from analytical workloads when necessary.
  8. Treat “unknown,” “not applicable,” “not asked” and missing as distinct states where meaningful.
  9. Include clinicians, patients, privacy specialists and operational users in design and evaluation.
  10. Monitor data pipelines and analytical models after implementation; quality is continuous, not a one-time project.

Important limitations remain. Quality measurement can itself be biased when only observable records are assessed. Standardization may remove clinically meaningful nuance. Data integration can create false confidence if matching is uncertain. More data can increase privacy risk without improving decisions. Finally, governance structures may become bureaucratic if they focus on approval rather than enabling safe, useful data.

Contemporary Developments

Cloud platforms, interoperable clinical resources, real-time streaming, patient-generated data and artificial intelligence are expanding the volume and velocity of health information. These developments increase the need for metadata, consent management, provenance and monitoring. Natural-language processing can extract information from clinical notes, but extracted concepts require confidence assessment and clinical validation. Generative AI may summarize records, yet summaries must remain traceable to source evidence and must not obscure uncertainty or contradict the authoritative record.

Real-time architectures support alerts and operational command centers, but low latency does not guarantee quality. Streaming data may arrive out of order, be duplicated or be revised later. Organizations should therefore define event-time handling, late-arriving data rules and correction processes. The strategic direction is not simply toward more data, but toward trustworthy, explainable and purpose-sensitive data products.

Chapter Summary

Health-care data management encompasses capture, validation, storage, integration, metadata, master data, longitudinal records, warehousing, retention and disposal. Data quality is multidimensional: completeness, accuracy, timeliness, consistency, validity, uniqueness and fitness for use must be assessed in relation to a defined purpose. Operational systems support transactions, while warehouses and related analytical repositories integrate historical data for reporting and analysis. Metadata and lineage make data interpretable and auditable; master data management supports consistent identities, providers, locations and terminology. Longitudinal records require reliable identity, temporal context, provenance and version control. Quality programs work best when they combine technical rules with workflow redesign, governance, ethical safeguards and accountable stewardship. Contemporary technologies increase analytical capability but also intensify the need for privacy, bias control, transparency and continuous monitoring.

Key Terms

Data governance: The authority, policies, roles and processes used to direct and control data management.

Data quality: The degree to which data meet requirements for a defined use.

Completeness: The extent to which expected, applicable data values are present.

Accuracy: The degree to which a recorded value represents the real-world attribute or event.

Timeliness: The availability of data within the period required for a decision or process.

Consistency: Agreement among related data representations under defined rules.

Validity: Conformity to permitted formats, domains and business rules.

Metadata: Data describing the meaning, structure, origin, use and governance of other data.

Data lineage: Documentation of data origin, movement and transformation.

Master data: Shared, relatively stable entities used across organizational processes.

Reference data: Controlled classification values, such as encounter types or units.

Enterprise master patient index: A managed index linking patient identities across systems.

Longitudinal record: A person-centred record spanning encounters and time.

Operational database: A system optimized for routine transaction processing.

Data warehouse: An integrated, historical repository optimized for reporting and analysis.

Data mart: A subject-specific analytical subset of a warehouse.

Data lake: A repository for large volumes of raw or lightly processed data.

Data retention: The controlled preservation of records for defined periods and purposes.

Fitness for use: Adequacy of data quality and context for an intended purpose.

Provenance: Evidence describing the source, history and transformations of data.

Review Questions

Short Answer Questions

  1. Why can accurate data still be unfit for a particular use?
  2. Distinguish metadata from master data.
  3. What is the difference between event time and record time?
  4. State two validation checks that may be used in a hospital information system.
  5. Why should “unknown” and “not applicable” not automatically be treated as the same as missing?

Long Answer Questions

  1. Explain the major stages of the health-data life cycle and the governance responsibilities associated with each stage.
  2. Compare operational databases, data warehouses, data marts and data lakes in terms of purpose, structure and users.
  3. Discuss how patient identity management affects the safety and analytical value of longitudinal records.
  4. Explain the principal dimensions of information quality and how they should be evaluated in a hospital.
  5. Evaluate the ethical, privacy and regulatory issues involved in retaining and reusing health data.

Analytical / Application Questions

  1. A hospital dashboard reports a sudden fall in average length of stay. Design an investigation that tests whether the change reflects improved performance, altered definitions, missing data or a pipeline error.
  2. Design a data-quality scorecard for medication administration data. Specify dimensions, indicators, denominators, thresholds, responsible owners and corrective actions.
  3. A health system plans to train an AI model using five years of electronic health-record data. Propose a governance and quality-assurance plan addressing provenance, missingness, bias, privacy, validation and post-deployment monitoring.

Multiple Choice Questions with Answers

Question 1

Which data-quality dimension asks whether information is available within the period required for a decision?

A. Accuracy

B. Timeliness

C. Uniqueness

D. Validity

Correct Answer: B. Timeliness

Question 2

What is the principal purpose of metadata in a health-data environment?

A. To replace data-quality testing

B. To describe meaning, structure, origin and governance of data

C. To eliminate the need for data stewardship

D. To store only unstructured clinical notes

Correct Answer: B. To describe meaning, structure, origin and governance of data

Question 3

Which repository is primarily optimized for integrated historical analysis and reporting?

A. Operational transaction database

B. Data warehouse

C. Temporary registration form

D. Device buffer

Correct Answer: B. Data warehouse

Question 4

A service expects 1,000 applicable records and 920 contain acceptable values. What is the completeness percentage?

A. 8%

B. 80%

C. 92%

D. 108%

Correct Answer: C. 92%

Question 5

Which practice best reduces the risk of fragmented patient histories across systems?

A. Using a separate identifier for every encounter

B. Enterprise master patient index governance

C. Deleting older demographic records

D. Allowing unrestricted manual merges

Correct Answer: B. Enterprise master patient index governance

Question 6

Why should a clinically unusual value not always be automatically deleted?

A. It may reveal a real clinical, device or documentation problem

B. Unusual values are always correct

C. Deletion improves provenance

D. Validation rules cannot be used in clinical systems

Correct Answer: A. It may reveal a real clinical, device or documentation problem

Question 7

In the chapter’s illustrative case, why were missing departure times not assigned a zero duration?

A. Zero is never a valid number

B. It would falsely imply no time was spent in the emergency department

C. Warehouses cannot store zero values

D. Departure times are metadata only

Correct Answer: B. It would falsely imply no time was spent in the emergency department

Question 8

Which statement best describes master data?

A. Raw data retained without structure

B. Shared entities such as patients, providers and facilities

C. Temporary error logs only

D. A measure of dashboard timeliness

Correct Answer: B. Shared entities such as patients, providers and facilities

Question 9

If 50 records are identified as duplicates among 2,500 total records, what is the duplicate rate?

A. 0.2%

B. 2%

C. 5%

D. 20%

Correct Answer: C. 5%

Question 10

Which principle is most appropriate for health-data retention?

A. Keep every record indefinitely regardless of purpose

B. Delete all records as soon as a report is produced

C. Balance clinical, legal, operational, privacy and security requirements

D. Retain only data that are already public

Correct Answer: C. Balance clinical, legal, operational, privacy and security requirements

Hospital Information Systems
Chapter 8 of 15