What One Needs To Know About Electronic Records Management

Below is a step-by-step, basic, electronic records management guide — to help protect those electronic records that need to be protected while allowing access to to those electronic records that need to be shared; to gain value from using various computer applications while addressing compliance and governance standards.

First, clearly define as “documents” all content generated in (for example) GoogleDocs, SharePoint 2013, Dropbox or Box.  A document is any analog or digital, formatted, and preserved “container” of structured or unstructured data / information.  A document can be word-processed or it can be a spreadsheet, a presentation, a form, a diagnostic image, a video clip, an audio clip, a template of structured data….

Second, for legal and compliance purposes, declare as “records” those “documents” in GoogleDocs, SharePoint 2013, Dropbox or Box that 1) follow a life-cycle (i.e., the “documents” are created or received, maintained, used, and require security, preservation and final disposition, such as destruction); 2) must be assigned a retention schedule; and, 3) the content must be locked once the “document” is declared a “record”.  Records are different from documents.  All documents are potential records but not vice versa.

Third, and again for legal and compliance purposes, designate all the records as either “official” records or “unofficial” records.

Official records include those documents that were generated / received in GoogleDocs, SharePoint 2013, Dropbox or Box and subsequently declared as records according to the above records characteristics.  In addition, official records 4) are created or received as evidence of organizational transactions or events that reflect the business objectives of the organization (e.g., receiving reimbursement for services provided, providing patient care); and, 5) qualify as exercises of legal and / or regulatory obligations and rights (i.e., have evidentiary and / or regulatory value).

Unofficial records include those documents that were generated / received in GoogleDocs, SharePoint 2013, Dropbox or Box and subsequently declared as records according to the above records characteristics.  However, unofficial records will NOT further organizational business and / or legal / regulatory needs if the records are retained.  Typically, unofficial records are retained only for the period of time in which they are active and useful to a particular person or department.  Often organizational retention policies allow unofficial records to be retained for x number of years after last modification, but typically no longer than official records.  Examples of unofficial records are (what are typically but erroneously called) working “documents”, draft “documents”, reference “documents”, personal copies of documents or records, and copies of official records for convenience purposes.

Fourth, retain / store all the documents and official / unofficial records in GoogleDocs, SharePoint 2013, Dropbox or Box in separate, physically, but logically-linked electronic repositories.  For example, “documents” can be stored on individuals’ hard drives.  Once documents are declared “records”, the official records (e.g., patient records [including patient-related text messages / email messages /social media entries], employee records, patient spreadsheets, etc.) must be parsed and placed into a secured electronic repository, similar to the organization’s line-of-business system / systems-of-record repositories; e.g., EHR, Vendor Neutral Archive, financial system) — with audit trails, access controls, etc.  The unofficial records (e.g., working documents, reference records, etc.) can be stored on organizational shared drives.

Managing the Complexities of Consumer-grade Enterprise Platforms

Consumer-grade services (a.k.a., enterprise platforms) vendors include Google, Microsoft (MS), Accellion, Box, Dropbox, and others. The services (or applications or tools) provided by these vendors on their platforms include but are not limited to file storage / sharing and synchronization (FSS), mobile content management,  document management, and, perhaps, most importantly, project / team collaboration.

For example, Google’s comprehensive suite of cloud-based services, Google Drive (FSS), includes but is not limited to Google Docs (collaborative office / productivity apps, now housed in Google Drive), Google Mail/Calendar, and Google Sites (sharing information on secure intranets for project / team collaboration).  Box’s suite of cloud-based services includes but is not limited to mobile content management, project collaboration, a virtual data room, document management, and integration with Google Docs.  Historically, MS’ SharePoint had been associated with on-premise document management and intranet content management.  Over the years, broader, on-premise web applications were added to provide intranets, extranets, portals, and public-facing web sites as well as technologies, which provided team workflow automation and collaboration, sharing, and document editing services.  SharePoint 2013 offers services in the cloud (and on-premise), and it includes but is not limited to Office 365 (the famous office / productivity apps, which now can be rented rather than purchased), Outlook (calendar), Exchange (mail), records management, e-discovery, and search.

I have worked with most of the above services / platforms in healthcare organizations.  Since today’s digital experience is all about connecting and collaborating with others, I strongly believe the above services / platforms are important and useful for provider organizations primarily because most of the services (or applications or tools) are not present in provider organization line-of-business systems.  For example, with Google Drive, a resident can create a patient location spreadsheet in a cloud application, such as Google Docs, share it with a colleague(s), edit it on a tablet device, and push revisions to a collaboration site.  Blocking access to these services penalizes employees by not allowing them to use robust collaboration tools.

In addition, I strongly believe the internal, organizational policies and procedures, which are developed for such services, are sub-optimal at best.   Unfortunately, most FSS services do not encrypt content, possibly exposing content to interception in violation of regulatory obligations, such as HIPAA.  Yet organizational policies that manage encryption, backup and archiving for content sent through email or FTP systems typically are not applied to the content sent through FSS services!

If provider organizations were to deploy formal information governance (IG) principles (e.g., electronic records management principles) with many of these enterprise services / platforms, onerous access blocking could be eliminated and policies and procedures could be improved.  Unfortunately, like most services (or applications or tools), deploying IG principles for enterprise services is complex.  In addition, deployment requires resources with knowledge of and experience in the information governance principles.  However, the trade-off is that provider organizations can meet other legal, regulatory, and compliance requirements, such as e-discovery, without additional resources or effort.

Currently, many of the service / platform’s configurations and capabilities are NOT intended for long-term electronic record retention and security purposes and should NOT be used as healthcare organizations’ electronic repositories of official records. For example, no comprehensive, electronic records management / document management / content management functionality exists on Google Drive.  Once the record owners leave the organization and fail to reassign ownership, the official records could be subject to automatic deletion after x number of years!  However, Google is introducing new Google Drive tools that might assist in better management of official records.

On the other hand, increasingly, cloud providers are supporting content segregation, security, privacy, and data sovereignty requirements to attract regulated industries, and they are offering service-level agreements and HIPAA Business Associate Agreements (BAAs) designed to reduce risks.  In September, Google announced a HIPAA BAA for the following Google App services:  Gmail, Google Calendar, Google Drive and Google Apps Vault.  Alternatively, Accellion has extended its reach beyond data stored in its application by integrating with enterprise content management (ECM) systems, allowing users to connect right from their mobile devices to secured, backend, typically on-premise repositories, such as MS’ SharePoint.


Cleaning Up Document Imaging’s Image

Since the late 1980s, when one of the technologies of electronic document management systems (EDMSs), document imaging technology (a.k.a., document capture technology), first was implemented in U.S. healthcare provider organizations to manage (i.e., digitize) the organizations’ massive amounts of medical, financial, and administrative analog documents, many health information management (HIM), healthcare information technology, and other related professionals did not understand that document capture technology is NOT the only technology of an EDMS.   Other EDMS technologies include:

Automatic IdentificationTechnologies – EDMS technologies that allow documents to be automatically identified.  The following are examples of EDMS automatic identification technologies:

  • Automatic / Intelligent Document Recognition (ADR/ IDR) recognizes the layout and content of generic form types.  In healthcare organization EDMSs, ADR / IDR is used to recognize digital and analog form categories.
  • Bar codes are machine-readable representations of data, typically dark ink on a light background to create high and low reflectance which is converted to 1s and 0s. Originally, bar codes stored data in the widths and spaces of printed parallel lines.  Today, bar codes also store data in patterns of dots, concentric circles, and text codes hidden within images. Bar codes are read by optical scanners or scanned from an image by special software.  In HIM department EDMSs, bar codes are used to eliminate the manual indexing of document type, patient name, provider name, and medical record number, etc., as well as medical record “separator” sheets during the digital scanning process.
  • Intelligent Character Recognition (ICR) allows different styles of hand printing and hand writing to be learned by a computer.   Most ICR software includes a self-learning “engine” (i.e., a neural network) that automatically updates the recognition database for new handwriting patterns.  In healthcare organization EDMSs, ICR is used to recognize documents’ hand printed / hand written numbers or abbreviations on analog orders, in analog progress notes, etc.
  • Optical Character Recognition (OCR) is the electronic translation of analog typewritten or printed text into machine-editable text.   Early OCR systems required system training to read specific typed or printed fonts.  Today, OCR has a high degree of recognition accuracy for all fonts.   Some systems are capable of reproducing formatted output that closely approximates the original scanned page including images, columns and other non-textual components.  In healthcare organization EDMSs, OCR is used primarily to recognize the printed text on claim forms.
  • Optical Mark Recognition (OMR or Mark Sense) is the process of capturing data by requiring a page image to have high contrast and an easily-recognizable shape.   Mark sense (OMR) is distinguished from OCR by the fact that a recognition engine is not required.  That is, the marks on a page are constructed in such a way that there is little chance of not reading the marks correctly.   One of the most familiar applications of optical mark recognition is the use of #2 pencils on paper-based, multiple choice-type question examinations.  In healthcare organization EDMSs, mark sense often is used for physician office analog super bills and charge tickets.

Enterprise Report Management (ERM) technology (formerly known as COLD: Computer Output to Laser Disk) – an EDMS technology that stores “computer output” to – and indexes “computer output” on – digital storage media.  Once stored, the computer output can be easily retrieved, viewed, printed, or distributed.  Today, “computer output” consists primarily of batch-generated computer reports with data that are report-formatted.  Electronic Health Record (EHR) batch-generated computer reports include EHR system bills / invoices and management reports.

Document Management (DM) technologies – EDMS technologies that control and organize documents.  The following are examples of EDMS DM technologies:

  • Document Assembly allows documents to be automatically retrieved in the “correct” order, based on pre-defined, user-specific rules and tables.
  • Document Version Control allows documents to be automatically assigned version numbers.  For example, this includes daily laboratory test result reports (version 1) vs. cumulative summary laboratory test result reports (version 2); preliminary radiology procedure result reports – unsigned (version 1) vs. final radiology procedure result reports – signed (version 2); transcribed operative reports (versions 1, 2) vs. signed transcribed operative reports (version 3) vs. amended transcribed operative reports (version 4).  Typically, only the most recent or last document version is accessible for view purposes.
  • Document Check-in / Check-out allows users to collaboratively review / edit shared documents without concern about who might be simultaneously updating the document and to view all the entries made to the shared document.  Clinical teams that author electronic progress notes is an example of this important DM technology.
  • Document Security consists of all the technical document tools to protect, control and monitor document access (e.g., unique user identification / authentication, audit trails, automatic log-offs, and biometric identifiers) to prevent unauthorized access to documents transmitted over a network.

Digital signature management technology – an EDMS technology that offers both signer and document authentication. Signer authentication is the ability to identify the person who digitally signed the document. The implementation of the technology is such that any unauthorized person will not be able use the digital signature. Document authentication ensures that the document and the signature cannot be altered (unless by means of showing both the original document and the changed document). As such, document authentication prevents the document signer from repudiating that fact.

Forms Processing (a.k.a., Electronic Forms Management, Automated Forms) technology  – an EDMS technology that electronically delivers paper forms for printing and completion, accepts scanned paper forms and extracts data from the boxes and lines on the forms to populate databases, and utilizes eForm templates — that look like paper forms — for online data entry / data collection.   Because patient medical records consist of hundreds of forms, even with EHRs, this EDMS component technology is important for healthcare organizations.

Workflow / Business Process Management (BPM) technology – an EDMS (or any other type of information system) technology that is the EDMS’ (or other information system’s) most important component technology!   BPM technology automates business processes, in whole or in part.    EDMS workflow / BPM technology passes documents, information, or tasks from one user to another for action according to a set of business rules.

Today, many healthcare organizations use the EDMS’ document capture component technology more than the other EDMS component technologies.  The primary reasons include the need to:

  • continue to convert existing analog documents into digitized documents
  • maintain a legal archive from which to generate the electronic document presentation as proof for exception and dispute handling (i.e., by extension, the need to have the document presentation for legal purposes and NOT an informational statement or data representation of the document, which, unfortunately, remains too common the output in today’s electronic patient record systems).

However, when ALL internal and external documents, forms, notes, letters, reports, and messages are digitally-generated, stored, and distributed, the use of the EDMS document capture component technology will be drastically reduced, perhaps eliminated, and all the other EDMS component technologies will be used frequently.

The Cost Savings Realized by Single-Platform Solutions

Medicare cutbacks, increased mergers and acquisitions, and declining revenues and margins are daily realities for healthcare provider organizations. Yet so are costly and often mandatory IT initiatives, such as replacing or implementing electronic health and financial record (EH&FR) systems, integrating and securing the next mobile form factor of computing devices, converting to ICD-10 for reimbursement purposes, and meeting the Affordable Care Act requirements.

How does a CIO not compromise on health information technology (HIT) delivery and still maintain cost containment priorities?

A well-developed, single HIT platform strategy for most applications can realize cost savings by optimizing the IT infrastructure, regardless of whether the platform resides on premise or in the cloud. For purposes of this article, a single computing platform is defined as one that provides a database and set of technologies across a set of heterogeneous applications.

However, still many provider organizations acquire and deploy heterogeneous applications that could be built on a single, common platform. Consequently, this approach continues to generate silos of systems that cannot interoperate and to burn holes in IT operating expense budgets.

Thankfully, no longer is the HIT industry faced with an abundance of best of breed EH&FR applications, typically with each sitting on top of its own proprietary computing platform. Top-selling EH&FR solution vendors finally are offering one or — at most, two — unified platforms for the myriad, structured data-based EH&FR applications.

On the other hand, today, many solutions that complement EH&FR systems remain siloed. Such solutions worth mentioning for this article include but are not limited to Picture Archiving and Communication Systems (PACS) solutions for the storage of image-generating “ology” applications and Natural Language Processing (NLP) solutions for applications such as speech recognition, computer-assisted coding (CAC), and business intelligence (BI). By deploying a single storage platform for PACS solutions or a single NLP platform for speech, CAC and BI applications, chances are that the platform will be around longer than any application an organization has today.

For example, when developing a strategy for managing all the image-generating “ology” applications in the enterprise, it behooves the provider organization to consider a vendor-neutral archive (VNA). This poor choice of name for a storage platform (a more appropriate name might be a PACS-neutral or image file-neutral archive) stores all the heterogeneous, enterprise modality images (DICOM and non-DICOM) in a single, replicated archive. This eliminates the need for each costly, siloed PACS archive and, more appropriately, changes the “A” In PACS from “Archiving” to “Accessing.”

Typically, the platform includes tools to help manage all the different lifecycles of the image data (e.g., retention scheduling and purging mechanisms). And, perhaps the biggest benefit to clinicians is that this platform allows for the creation of an aggregated, patient-centric record of all the enterprise images.

A VNA platform is expensive, requiring a large, complex, capital-intensive project. But well thought out strategies for deploying this platform over time have proven that significant cost savings are realized. Eliminating the organization’s most costly departmental PACS operating expense — recurring migrations with storage media migrations typically occurring every three to four years and PACS replacements requiring massive proprietary data migrations, typically occurring every five to seven years — alone cost justifies this single platform solution.

When developing a strategy for deploying diverse yet complementary EH&FR applications such as speech recognition, CAC software, and BI, it behooves the provider organization to leverage a single NLP platform product that manages each of these technologies well. All NLP engines perform some type of pattern matching, and  to varying degrees, incorporate both rules-based and statistics-based techniques. That means that a plethora of applications can be developed using a single NLP platform.

These applications include but are not limited to speech to text (dictation systems), text to code (medical coding), data analytics (data warehouse systems), foreign language translation (Google Translate), question and answer (IBM’s Watson playing Jeopardy), document classification (Outlook’s spam filtering), candidate identification for clinical trials (determining eligible candidates), adverse events (patients with gunshot wounds), core measures (patients who already had been treated), geographic disease epidemiology, and on and on.

At HIMSS13, several complementary EH&FR application vendors were demonstrating more than one heterogeneous application using a single NLP platform. Currently the challenge is that not one vendor offers most of the above applications or even the same applications. Where one vendor might offer medical coding and data analytics using a single NLP platform, another vendor might offer data analytics and candidate identification using a single NLP platform.

For cost justification and interoperability purposes, it behooves provider organizations to strategically look under the hood and determine where a single NLP platform can be deployed.

Originally published at: http://histalk2.com/2013/04/12/readers-write-the-cost-savings-realized-by-single-platform-solutions/

Formal HIT Education

For the past two years or so, I have been researching four-year baccalaureate degree programs in health information technology (HIT), where I expected students in such programs to earn a BS degree, a Health Information Technologist title, and, perhaps be ready to sit for a rigorous certification exam.

No such programs exist in US colleges and universities – online, on-campus, or combination – as far as I know, except perhaps one at Miami (Ohio) University’s regional campuses. (NOTE: I am not referring to four-year baccalaureate degree programs in health information management or HIM, which are complementary to but different from four-year baccalaureate degree programs in HIT.  I know, because I am both an HIT and HIM professional.)

Largely due to 2009 ARRA/HITECH dollars (workforce training), many two-year, community college-based HIT programs existed (before the dollars ran out), where students earned an AA degree (or similar), a Health Information Technician title, and were ready to sit for the Department of Health and Human Resources’ (former) HITPro exam. (A certification was not conferred upon successfully passing the HITPro exam.) Unfortunately, contrary to expectations and because of lack of experience, most of these students did not find jobs.

Many excellent one-to-two-year, post-baccalaureate degree programs exist in health informatics, whereby graduate students (typically clinical) earn either a MS degree or similar or a certificate, allowing the student to officially wear the Health Informaticist title (Nurse Informaticist, MD Informaticist, etc.).

As a college undergrad, I earned a BS degree in medical record science (today, health information management). My program in medical record administration was part of the university’s Allied Health Professionals Division.   General Arts and Sciences Division requirements (English composition, sociology, chemistry, biology, etc.) plus anatomy and physiology consumed our freshman and sophomore years.    Many of our junior and senior year courses were shared with the Allied Health Professionals Division’s undergrad nurses, pharmacists, lab technologists, dietitians, etc. The remaining courses were specific to HIM (ICD coding, records management, etc.). All Allied Health Professionals Division students experienced a minimum of four months practice in a hospital in the nursing, lab, pharmacy, dietary, and medical records departments.

I graduated the university with a Medical Record Administrator title and was prepared to sit for a rigorous exam that, upon passing, allowed me to be certified as a Registered Record Administrator (today, Registered Health Information Administrator – RHIA). Similarly, my fellow student nurses, pharmacists, lab technologists, dieticians,etc., became RNs, RPhs, RDs, etc.  In general, we went directly into good-paying jobs as entry-level — but at least semi-experienced — healthcare professionals.

As a graduate student, I had few options except to pursue a masters degree in Health Services and Hospital Administration (or similar), which I do not regret. However, today, those with BS degrees in the healthcare professions can pursue advanced degrees in health informatics, highlighting advanced skills, knowledge, and experience in healthcare and in IT.

Consequently, I am proposing that four-year colleges and universities, working with or without existing two-year college HIT programs promoting Health Information Technicians, consider offering sorely-needed, workforce HIT programs promoting Health Information Technologists (like lab technologists). Subsequently, graduating students could sit for certification exams and become registered.

These healthcare information technologist programs would allow the BS-degree’d, graduating Health Information Technologist (registered or not) to gain required experience in the HIT industry and, if interested, to choose an HIT advancement and graduate path in health informatics.

In addition, I propose that these four-year, baccalaureate degree programs be incorporated into universities’ existing four-year, Allied Health Professional Divisions. Unfortunately, I learned from one public university with such a division that it is difficult to get the right parties to agree to offer new degree programs at the undergraduate level. I learned from one private university with such a division that undergraduate programs do not generate enough revenue to justify adding new programs, and only post-graduate programs do. Perhaps an accredited online university that is willing to keep the cost reasonable and can quickly establish a program also should be proposed, although program quality might be a concern.

Who or what entity is willing to take me up on my proposal?

Originally published at: http://histalk2.com/2012/11/14/readers-write-111412/

Structured and Unstructured Data, I Adore You Both

Calling all electronic patient record systems (EPRS) structured data! Yes, all you electronic health / medical, administrative, and financial systems’ data elements that are binary, discrete, computer-readable, and, typically, are stored in relational databases with predefined fields … you tidy, typically core, transactional and mined elements. Hello? I’m talking about all you digital, patient demographic, financial, and clinical health data that are sitting in master patient indices, insurance claims, clinical histories, problem lists, orders, test results, care plans, and business intelligence reports — to mention just a few.

Meet unstructured data! Yes, all you EPRS data that are non-binary, non-discrete, sometimes only human-readable, and sometimes not stored in relational databases. This means all you digital, bit-mapped images, text, videos, audios, and vector graphics that are harnessed in word-processed summary reports, electronic forms, diagnostic radiology images, scanned document images, electrocardiograms, medical devices, and web pages – again, to mention just a few.

I know this might be an awkward introduction. However, I’m really happy to finally get you two data formats together. And, while this might be jumping the gun a bit, I really hope one day you two will get married! I know, I know. That is, after you’ve carefully sorted out all your differences and learned how to live together in peace and harmony for the betterment of patient care.

After all, I’m certain you heard the rumor that the “adoption” and “Meaningful Use” of “certified” diagnostic image-generation and management systems, such as a PACS for one or more of the “ologies”, might be included in Stage 2. In addition, heaven help if, given the revised Federal Rules of Civil Procedure Governing Electronic Discovery that became effective December 1, 2006, a patient’s electronic health/medical, administrative and financial episode-of-care records (I mean x-rays, bills, ECGs, orders, progress notes – the works!) are subpoenaed for that Weird News Andy case we recently read on Mr.HIStalk! So, don’t you think it’s time at least to begin acknowledging one another in public?

Who am I, you ask, to be so bold to introduce you to the other? I’m just one, frustrated HIT professional who specializes in most of the EPRS unstructured data and who observes that these data are rarely considered in EPRS strategies and purchases … until after the fact. Once considered, they divide provider organization departments right down the middle; those working with you, structured data, vs. those working with you, unstructured data. Don’t even get me started about integration and usability issues!

Come close, structured data, so I can tell you that I do adore you – especially when I search a database for one or more of you, and, quickly and easily, the search engine finds, retrieves, and even manipulates parts or all of you. On the other hand, what often makes me want to delete you is when you insist on snubbing unstructured data. I’ve even watched you try to convert some unstructured data, such as rich-text or video data, to your popular religion, using pretty-good-but-not-perfect artificial intelligence and recognition tools … just so that you can brag about how you were able to generate the complete health story with your qualities.

Unstructured data? After so many years working with you, you know that I love being able to retrieve your gorgeous, bit-mapped, raster images generated by that digital chest x-ray or computed tomography (CT) scan stored in a diagnostic image management system; or, listen over and over to your brilliant sound bytes generated by that digital stethoscope; or, fast forward your streaming videos / frames generated by that important cardiac catheterization study; or, admire the perfect lines connecting the series of points plotted by that fetal trace recording. On the other hand, what I can’t tolerate is when I am required to search, for example, a valuable narrative text for one or more of you, and after hours I still can’t find you!

Today there is no complete electronic patient health / medical, administrative or financial record system without both of you. Let me see a hand shake.

(Originally posted at: http://histalk2.com/2011/11/14/readers-write-111411/)