Retention of Data in Healthcare

Introduction

There are many methods of retaining data depending on the purpose and the type of data. Often it is thought that data migration is the only effective method. Retention of the Electronic Medical Record (EMR) needs to be differentiated from data migration. The latter is one method of retaining data.

Retention of Paper Medical Record

Retaining a paper-based record means keeping it for a desired period of time in its original composition. By ensuring that the structure is intact, the original content is also preserved.

Retention of Electronic Medical Record

Retention of an Electronic Medical Record poses peculiar problems. First of all, the structure and content of the EMR need to be more clearly defined if it is to be retained. Information systems that facilitate patient care within the Hospital/Clinical Information System are more than just Medical records. In fact, the EMR is formed by deconstructing data from the patient information database and reconstituting it. Even though many software providers name their applications as EMR, they are actually providing a system to facilitate clinicians to perform clinical care activities i.e. an application more appropriately named the Clinical Information System (CIS). No software developers in their right mind would develop systems just for the recording or documentation of events or incidents.

Read my article on CIS and EMR

The Need to Retain Data

The issue of data retention arises in the context of three instances:

  1. Continuity of Business operations
  2. Continuity of Patient care
  3. Preservation of a Historical record

Continuity of Business Operations and Patient care

From the perspective of continuity of operations, the need for data retention occurs in two circumstances:

  1. When data need to be archived
  2. When there is a change from the use of an existing system and software to a new one

Archiving Data

As the duration of operations gets longer, the database grows bigger to the extent that it becomes unwieldy. To maintain a manageable database size, older non-active or unused data need to be archived hence freeing space for new data. Archiving refers to the activity of taking out data of an operations database and placing them in a separate external database. The data is safely stored and if required can be read either by returning the data to the operations database or by using a copy of the same applications software or a data query tool to read the data in the archive.

Retention Necessitated by Change of Database and Applications

A change from the use of an existing database and aplications to a new one brings about challenges that are more difficult.

In this situation, there are three purposes for which data need to be retained:

  1. Business continuity
  2. Continuity of care
  3. Preservation of a historical record

Business Continuity

In most enterprises business continuity is the main reason for retaining data. Changes in systems may affect adversely the running of the health care facility as a business entity. The new system ought to be designed to retain good practices unless in the process of Business Process Re-engineering a better approach or method is adopted. It is important that relevant personal information regarding clients and the services they had sought earlier is brought forward for marketing purposes, ease of booking /registration etc. This can be achieved through migration of the following data:

  1. Patient Master Index
  2. Visit history
  3. Contact information (address, phone number, e-mail address)

Continuity of Care

In healthcare, continuing to provide services for the same health problem is termed as continuity of care. While the subject matter here is ensuring continuity of care in the situation when a system and/or application are changed, continuity in the instance when the same system is used is discussed first as a backdrop.

Continuity of Care during a Visit

When providing care to patients, care providers (direct and indirect) use the CIS application software as the means to enter and view patient data. Rather than presenting data as a purely chronological record of events like in paper records, the CIS uses the ability to extract and aggregate data from the database to present them in useful groups as various views to users. As such the data as read through the CIS application does not really represent the EMR in structure. For example structured data regarding a particular set of attributes  (e.g. vital signs, laboratory results) may be extracted and shown together in tabular or graphical format with time on the x-axis  (termed as the flowsheet view). Other methods include showing results as a list or tables e.g. Problem List, Task list, Allergy list etc. Indeed rather than showing the entire EMR, a summary of information regarding the patient is more useful. For example for a person not familiar with the patient (e.g. doctor or any care provider to whom the patient is referred), a summary gives an overall overview of the case. With the use of an electronic database, the case summary can be created automatically, if the data elements making up its content are defined.

Continuity of Care from Visit to Visit

Continuity of Care for a Recurrent Visit at Same Health Care Facility

For a recurrent visit at the same health care facility, the use of the same CIS and other applications of the Hospital Information System (HIS) ensures continuity of care. Data for previous visits can be made available by requesting for those acquired/recorded at the defined  time period. Accessing the entire EMR itself does not provide the user with very much added value. However, a Visit Summary would be much welcomed.

Continuity of Care for a Visit at a Different Health Care Facility

If a patient is referred to or seeks treatment for the same or related illness at another healthcare facility, then the care provider is ethically obliged to provide sufficient information to his/her counterpart to enable continuity of care. Such information is usually provided in a letter with which is attached a summary of all events, findings and results for all visits made in the referring facility. It is quite unnecessary and in fact burdensome for both parties to send/receive a full Medical Record.

Continuity of Care Subsequent to Change in the System and/or Application

In the event when there is a change in the system and/or application, the care provided must continue according to plans made earlier and take into consideration the events that happened earlier. As diseases or illnesses occur in episodes, the care for the particular episode ends when the disease is cured or no further treatment is necessary. Hence, changing a system/application does not affect the care of new patients or previous patients with new diseases or health problems. The care episode for chronic diseases is life-long. However, in most instances, the issues regarding the illness would have been worked out such that only the final diagnosis, latest progress and treatment plan need to be brought forward.

The necessity of bringing forward data varies with the type of disease and the level of completion of the clinical care process.

Bringing over the data from the previous system can be undertaken in two ways:

  • making available the pertinent data required for continuity of care in some form in the new system and application (creating a report)
  • including all data captured in the previous database into the new database and making them available via the new application software (data migration)

Method 1: Making Available Pertinent Data from Previous Database and Application in the New System as a Report

The continuity of care problem that emerges when a new system is used is similar to the situation that exists when a patient is referred to another institution where a different system is used. Similarly, when changing over to a new system, in most instances it is adequate to provide a summary of historical data regarding all events, findings and results for all visits made rather than carrying over the entire data contained in the CIS or the Medical Record. The summary is actually a report consisting of information constituted from data extracted from the previous database. It is quite possible to extract the entire data making up the Medical Record but, in practical terms, this is quite unnecessary for this purpose.

For structured data, it would be useful to present discrete data (e.g. vital signs, laboratory results) in tabular or a flowsheet view. Certain data that are cumulative in nature can be grouped and shown as lists e.g. Problem List, Task list, Allergy list, List of drugs prescribed etc.

Both the summary and the lists can be made available via a menu linked to a document titled “Data from visits when a previous system/application was used”.

Bringing over the entire data from the old system / database to the new is essential only in instances where the critical points in the clinical care process has not been completed, i.e. where  clarification of diagnosis and firming up of the treatment plan, has not been sorted out.

Method 2: Data Migration

Technically, ‘data migration’ refers to the assignment of data (entities, attributes and values) captured in the previous database to the corresponding data fields of the new database and making them available via the new  application software.

Advantages

From the user’s perspective, data migration makes it appear that the transition, from old to new, is seamless. Data from the previous system can be viewed in the new system/application as if they came from the same source. The chronological sequence for the segment of data that is migrated would appear to be maintained. Because the old and new data reside in the same database they can be manipulated using the current application.

Instances Where Data Migration is Essential

Migration of patient data is essential only for instances where clinical process transactions in the previous system/application has not been completed. The categories of patients include those with:

  • Appointments scheduled in previous system for visits on dates after the change over to the new system,
  • Plans that has not been completed, including future orders
  • Tests performed but results have not been captured in CIS Database.

It can be assumed that cases scheduled for follow up visits are active patients. A list can be created and the cases are studied to determine the type of transactions and data that needs to be carried forward. .

Situations when Data Migration is Advantageous

Data migration is especially useful for managing patients with active illness where the definite diagnosis and the definitive treatment plan had not been arrived at. The most significant value of data migration is that the data captured in the previous system can be read using the current application. Instead of just depending on a report, the care provider will then be able to view, parse and use his/her cognitive skills to analyze and interpret previous and current information as if they originate from the same source.

However as mentioned earlier, in cases where the definite diagnosis has been made and the treatment plan has been decided on, a case summary would be sufficient. It may also be perhaps more convenient since the care provider need not wade through large amount of information from various sections of the information system in order to gain an insight on what had transpired.

Limitations of Data Migration

The accomplishment of data migration may not necessarily mean data from the previous system is carried forward in exactly their original structure and content. The grouping of data, the field names and values assigned to each field in both systems are likely to be different. In attempting to fit the data into the structure of the new system the structure and content will have to be sacrificed to some extent. Not all data can be brought forward. The extent that this difference affects user’s understanding can be slight or considerable depending how the two systems differ in their database design and use of nomenclature.

Currently the efforts that need to be made to achieve migration of clinical data can be immense, requiring a lengthy process and can be very costly. For purposes of continuity of care, perhaps, providing historical data through more convenient means may prove to be just as effective.

Preservation of a Historical Record

Preservation of the Medical Record

In traditional paper records, the entire content lies within the physical limits of the material used (file folder and pages). Data entry is done by transferring ink to paper. Data is considered stored and available as long as the writing is legible. Therefore, preservation of a historical record involves maintaining the physical integrity of the material used,  the arrangement of the pages and the legibility of the writing. If necessary, the life of the medical record can be extended by making exact copies by converting it into  images via scanning and through the use of microfilm or photocopying.

When the electronic format is used, data entry is dependent on data entry tools (application). Data storage relies on a the data management system (DBMS) constructed using specific data definition language besides the use of a storage medium such as hard discs or tape. Data is then read as views made possible by data extraction tools using data query language. Primary users performing their work uses the Clinical Information System (CIS) which in turn is linked to other applications notably information systems of clinical support services like Laboratory Information System (LIS), Radiology Information System (RIS) and Pharmacy Information System (PhIS). Yet, these applications do not really represent the EMR in structure.

The term ‘EMR System’ or the ‘Clinical Documentation module’ used to describe the application concerning patient care is a misnomer because no one in their right mind would create a system just for the sole purpose of keeping a record or documentation. In fact these systems even if misleadingly named, are built to have functions for facilitating care providers to carry out their work hence better named as the CIS. The use of the term ‘EMR system’ has led people to think that preserving the entire system (application and database) is necessary rather than confining efforts at preserving the relevant data that makes up the historical record of events.

If the EMR is to be created and preserved as a document, its content and arrangement need to be defined. Then, all the relevant data captured through the CIS and other applications is extracted from the Patient Information Database and reconstituted. In data management terms, the EMR consists of reports created through query of the Patient Information Database. It is still a record of pertinent data regarding an individual patient arranged in a chronological order similar in content and structure to the record captured on paper.

Preservation of the Electronic Medical Record would be simple if it is already created for each patient at each visit. The institution where the care is given has the legal obligation to maintain a record of the care given and events that occur during entire care episode. Unfortunately, very few if any HIS have a built in facility to extract and present the EMR at the end of a visit. Most CIS (or even the so called ‘Electronic Medical Record System’) do not have this capability. Most institutions or software developers think that in order to preserve the Medical Record, the entire CIS need to be retained. It is advocated here that the EMR, being a record, need only be preserved in the form of a readable document created from a report extracted from the CIS. So, efforts should be made to define the data elements that make up the EMR, standardize its structure (sequence and arrangement) and develop the means of constructing it. The use of this approach should be accepted as a policy by the healthcare profession. If the EMR is available at the end of a visit the issue of depending on or mandating Data Migration as the means of preserving it with change in the System-Database- Application does not arise.

CIS EMR
The EMR as an Extract of the Patient Information Database

Content of the Medical Record

The content and structure of the EMR is not unlike paper medical records and follows specifications of the medical record agreed by authorities (e.g. the Ministry of Health or Medical Council) or as mandated by law.

Reference: http://www.wpro.who.int/publications/docs/MedicalRecordsManual.pdf

Core Content

The core and mandatory content of EMR is

  1. Identification data and the
  2. Chronological log of events
  3. Derived Data

The first two are the essential parts of the Medical Record.

The last portion is information derived from the Medical record depicted in two common forms:

  •  data selected and put aside for easy reference
  • data derived, manipulated and rendered in some way to provide additional meaning.

Charts of selected data and the case summary are common examples of derived data. While they are often put together with the Medical Record, they are not medico-legally essential content but serve to make it easier to understand the record. However, they are still confidential patient data and should be treated as such.

Identification Data

To link a patient to his/her record, the patient need to be first identified by his/her unique characteristics. The primary identifier is the patient’s name and photograph. His/her gender, age (date of birth) and ethnicity can be used as secondary identifiers. In most countries, this identification exercise has already been done by the national registration office and a unique national identification number and certificate or ID card is provided. This number can be used to positively identify the patient at the time of registration as a client of the institution providing the care. Alternatively, the social security number or passport number can be of similar value.

Once positively identified, the patient is registered into the Hospital Information System (HIS) and a unique system generated Identification Number (ID) is then given. This number may be used, by default, to match the patient with his/her medical record. Otherwise, another number that associates the patient with the record (the MRN) is given. For purposes of ensuring continuity of care, the same registration/system ID number and medical record number is used across visits within the institution. (Refer to article on Registration in this website.)

Giving each patient a unique identification number allows staff of the hospital to:

  • find and use the data belonging to the patient in the Hospital Information System and the medical record at each visit and encounter
  • link the  patient’s  previous visit with the current visit at all service delivery outlets including inpatient, day-care, outpatient, home care or care provided via telemedicine
  • differentiate the patient from another person of the same name or similar characteristics
Demographic Data

Demographic data such as age, gender, ethnic origin can be used as secondary identifiers as well as clinical data. Biodata such as weight, height and body mass index are variable and are collected as clinical data.

Chronological Log of Events

The core and mandatory content of EMR is a historical record arranged in a strictly chronological order regardless of the data source. A major portion of EMR data is a record of events or happenings that are either planned or unplanned. Planned events are proactive clinical care processes or interventions. These include technical as well as cognitive processes. Unplanned events can be

  1. incidents or developments that are part of the disease process,
  2. effects of interventions
  3. actions taken in response to the above two

Each event (whether planned or unplanned) needs to be described by accompanying facts such as:

  1. what happened
  2. the context
  3. when
  4. where
  5. who are involved

The basic framework of the EMR template is structured around time elements such as the episode, visit, date, time by the clock. As for paper medical records, electronic records are kept for each visit and then compiled for the entire care episode.

It is helpful to indicate the context during which the event happens. In planned events, reference is made to the part of the clinical care process being performed. Tasks, events and encounter types need to be named specifically. Incidents may be indicated as such when recorded. The care provider’s interpretation of the incident may be included in the record.

In the EMR, the context for example the encounter or process performed may be used as headings and sub-headings of the document.

Care Episode
Relationship of Events to Encounters, Visits and the Care Episode

Visits and encounters indicate the location where service is delivered. They mark the context within which planned tasks are performed or events occur. Care providers involved and the person who documents would have been identified by their log in ID when the system when data was accessed. These facts need to be captured in the EMR. As care processes follow an iterative (cyclical) pattern, headings in the EMR are also repeated until the visit ends.

Structure of the Medical Record

The Medical record for each visit is divided into segments corresponding to encounters sequenced in chronological order. The sequential order is strictly according to the time the encounter or incidents occur. In order for this to be indicated accurately, the practice of recording the ‘start’ and ‘end’ of encounters are applied in the CIS. Otherwise, the time the data was made would be used to indicate the sequence of the occurrence of events. Generally, it will follow the workflow of clinical care processes.

Transformation of Data from CIS to EMR Format

The CIS contains more data than what are usually kept as the traditional Medical Record. While data in the CIS is presented as views often as composites, data in a medical record must be presented as a log of events. However, as opposed to paper records which are written freehand, as it were, the electronic medical record is best created by converting structured data of the database into a text format. It is important is to retain the words and phrasing used by the care provider who documents the data. However, for the purpose conversion to structured text, fillers and interpolations such as conjunctions may be used. Rules regarding their use need to be spelt out and agreed by the clinicians.

The illustration below shows how data from CIS (in flowsheet format) can be transformed to chronology of events in segments corresponding to encounters.

CIS to EMR 1
Transformation of CIS Data to EMR
CIS to EMR 2
Transformation of CIS Data to EMR (contd.)

If the EMR is constructed as a report through the query of the database during the visit and completed at discharge then it can be stored in a repository. The place of the EMR in the scheme of the Hospital Information system is shown below:

HIS Concept
Place of EMR in HIS

Selected and Derived Data

Besides the chronological log of events, computerization allows for certain selected data (e.g. lists of encounters, diagnosis, allergies, and procedures performed) to be put aside and made prominent for easy reference. Some data can be data derived, manipulated or rendered in some way to provide additional meaning or for better understanding. Often what is presented is the data generated by various events rather than the events themselves and are usually already prepared as views in the CIS. Examples of derived data include:

  1. Lists of various attributes e.g.
    • Diagnosis (Problem list)
    • Allergies
    • Drugs prescribed
    • Procedures performed
    • Care Providers involved
  2. Calculated values such as
    • length of stay
    • the frequency of events (e.g. tests performed, incidences etc.)
  3. Results of tests and monitoring accumulated in the form of tables and charts
    • Monitoring charts
    • Investigation results
  4. Visit Summary which can contain
    • Selection of pertinent record of events or results extracted and put together automatically as a query of the database
    • Conclusions and Opinions made by the person who writes the summary (if any) added on to the above
  5. Episode Summary
    • All Visit Summaries combined

The content and structure of the EMR document is depicted below:

Structure and Content of EMR
Structure and Content of EMR

When the contents of the EMR are extracted from the database and arranged in chronological order as a document (in word processor format or PDF) the appearance would be like below:

Medical Record
Appearance of EMR Document

Duration of Retention of Medical Record

The institution where the patient receives treatment is obliged by various statutes or laws to keep an intact Medical Record for the prescribed duration. The principles guiding the duration include:

  1. Continuity of care
  2. Keeping it for use as evidence in litigation, criminal and civil suites in the courts of law

Retention for Purposes of Continuity of Care

The issue of continuity of care has been discussed in some detail earlier. Continuity is not an issue where the CIS is retained or data is migrated to a changed system. However, the Medical Record, if generated and retained, is sufficient for purposes of continuity of care as long as pertinent data are included in it. Clinical care providers can use the Medical Record as a reference document to guide them at current and future visits, similar to use of paper records for follow up care. The need for migration of data is obviated if the Medical Record is made available as a document created as a report of the patient information database

As a rule, the Medical Record should be made available for as long as the Care Episode has not been terminated i.e. the patient is still receiving care from the same institution.

Retention for Legal Requirements

For purposes of use as evidence in litigation, criminal and civil suites in the courts of law, the main criteria for duration of retention is the Statute of Limitations. These are are laws passed by legislative bodies in common law systems to set the maximum time after an event within which legal proceedings may be initiated [Wikipedia definition]. The period is measured from the last date of professional contact (encounter) with the patient. When the period of time specified in a statute of limitations passes, a claim might no longer be filed. The intention of these laws is to facilitate resolution within a ‘reasonable’ length of time. The period specified in the statute varies from country to country and within countries such as the United States from state to state. Within countries and states the period also varies for civil compared to criminal suites. For some crimes e.g. murder (depending on the country), there is no limit to the period where a person can be persecuted.

Certain general rules apply.

  1. A child may initiate suites after his/her age of maturity (usually 18 years of age) and for varying periods after that (e.g. three years) depending on the law of the country concerned.
  2. Duration may be different for different classes of patients e.g.
    • people taking part in a clinical trial
    • people receiving treatment for a mental disorder within the meaning of the Mental Health Act
    • people serving in the armed forces
    • people serving a prison sentence

Articles on periods of retention can be found at the following sites:

  1. UK NHS guide: http://www.nhs.uk/chq/Pages/1889.aspx?CategoryID=68
  2. US-AMA-guide: http://www.ama-assn.org/ama/pub/physician-resources/medical-ethics/code-medical-ethics/opinion705.page?
  3. US-State Comparison: http://www.healthinfolaw.org/comparative-analysis/medical-record-retention-required-health-care-providers-50-state-comparison
  4. Singapore MOH guide: https://www.moh.gov.sg/content/dam/moh_web/Publications/Guidelines/Retention%20guidelines%202015.pdf
  5. India guide: http://www.lawyersclubindia.com/experts/Retention-periods-of-medical-records-in-india-332986.asp
  6. Malaysia guide: http://www.mrpalsmy.com/?p=2565

Retention of Grouped Data

Besides the Medical Record certain grouped data, mainly Registers, containing lists of all patients and their pertinent particulars need to be retained for purposes of   satisfying statutory requirements, as evidence for civil or criminal suites or for use by the healthcare institution itself.

Vital Statistics Required by Law

These vary from country to country but usually include:

  1. Register of Births
  2. Register of Deaths
  3. Register of all Surgical Operations
  4. Register of all persons who received Immunization
  5. Information regarding donors (for Blood Banks)
  6. Register of patients who received Blood transfusion
  7. Register of dangerous (narcotic) drugs used

While statistics regarding birth and death are kept by the government Statistics department or Health authorities, healthcare institutions has to submit these statistics and therefore must keep a complete and accurate registry.

Reference NHS UK: http://systems.hscic.gov.uk/infogov/codes/lglobligat.pdf

Preservation of Other Statistics

Other grouped data statistics act as the starting point from which records of patients can be identified and searched for purposes of:

  1. presenting evidence for civil or criminal suites against the care provider and the care facility
  2. managerial and professional inquiries
  3. evidence of conformance to quality standards
  4. contribution to disease registries

The following Registers need  to be developed and made available:

  1. Register of all patients who received care at the institution (The Patient Master Index)
  2. Outpatient attendances (Total and by clinic)
  3. Inpatient attendances (Total and by ward)
  4. Inpatient discharges (Total and by ward)
  5. ICU admissions
  6. Emergency service attendances
  7. Daycare service attendances
  8. Births register
  9. Death Register
  10. Surgical Operations and Anaesthesia Register
  11. Dialysis Register
  12. Laboratory tests register
  13. Laboratory Quality Control data
  14. Imaging Procedure Register
  15. Pharmacy Outpatient Dispensed Drug Register
  16. Pharmacy Inpatient Supply and Use Register

2 thoughts on “Retention of Data in Healthcare”

  1. Salam Dr.
    Adakah HIS boleh diselaraskan bagi semua hospital atau adakah hospital yang berbeza boleh mempunyai HIS yang sama. Diperhatikan hospital di Malaysia mempunyai HIS yang berbeza-beza.

    Like

    1. Terima kasih kerana melawat laman saya.
      Selaras tidak semestinya bermaksud mengguna aplikasi yang sama. Kalau aplikasi yang sama pun, tidak semestinya sistem yang sama. Sesetengah fasiliti lebih sesuai mengguna sistem client-server konvensional dari sistem berasaskan web atau cloud.
      Aplikasi pun perlu disesuaikan mengikut keperluan setiap fasiliti (kecil besar, primer, sekunder, tertiari).

      Yang benar benar perlu menggunakan sistem dan aplikasi yang sama ialah fasiliti yang digabungkan sebagai satu kluster untuk membolehkan pesakit dijaga dan petugas bekerja secara bergilir tempat di semua fasiliti (hospital dan klinik) didalamnya. Kalau berbeza pesakit dan petugas akan menghadapi kesulitan memahami sistem. Untuk menggunakan sistem yang sama polisi dan prosedur pun perlulah sama dan semua fasiliti diletakkan dibawah satu pengurusan.

      Keseragaman dan penyelarasan yang diperlukan untuk fasiliti yang berfungsi berasingan (walaupun dibawah satu enterprise seperti KKM atau KPJ) adalah pada nomenklatur dan terminologi serta kaedah komunikasi yang setandad seperti HL7. Ini akan membolehkan data dikongsi untuk maksud kesinambungan operasi (contohnya untuk kes rujukan, plan penjagaaan pesakit sepanjang hayat LHR) atau untuk tujuan strategik seperti perkiraan beban penyakit (kadar insiden, daftar penyakit), beban kerja, kerperluan sumber (wang, peralatan, tenaga kerja db) dan perancangan masa depan..Untuk tujuan ini data dihantar dari pelbagai fasiliti untuk dikumpulkan secara berpusat dalam gudang data (data warehouse) atau sistem pengurusan data bidang kesihatan HMIS.
      Ketika ini, kita belum berjaya menetapkan kandungan data yang perlu dikongsi dan pustaka kata gunasama yang dikehendaki.

      Like

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Website and Blog of Dr. Abdollah Salleh