Some Personal EHR Stories

I am a patient at two separately owned and operated healthcare provider organizations that are within walking distance of one another. Fortunately, both organizations use the same “core” EHR system.  Unfortunately, the EHRs currently do not talk to one another or even look or act alike.

Because also I am a health information management and health information technology professional, I’ve found several flaws in these providers’ EHR systems. The organizations either do not know how to correctly configure their EHR systems or have failed to do so properly.

Flaw 1: Male with Cancer

I requested the release of my medical record from one of the organizations. The transcribed procedure report header listed my correct name, date of birth, and medical record number. However, the report body included two pages describing me as a male and having cancer. Neither is accurate.

This kind of mistake is common. Either the provider mistakenly dictated on the wrong patient under the correct header information sent by the EHR system, or the transcriptionist mistakenly keyed the wrong patient information under the correct header information.

Flaw 2: Updating Orders

One of my care providers repeatedly ordered the same lab work, even though the lab work had been performed months ago and the results were stored in my EHR. Deleting the order and updating the EHR with the previous lab results required several handwritten notes, photocopies, and telephone calls to the provider.

Flaw 3: Duplicate Tests

EHR systems should be configured to alert providers of all tests performed in the past. Recently, when one organization’s physician ordered a routine TB test, there was nothing in the EHR system to alert the provider that the same test was performed at the organization seven months earlier. Consequently, the test was unnecessarily repeated seven months later, costing an additional $398.

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.


The Case for One Source of Truth

The notion of managing and being accountable for the health status of defined populations requires much more sophisticated clinical data collection methods and skills than most healthcare organizations have today.  However, for decades, numerous coded systems have been used to successfully capture clinical data for reporting purposes, such as quality initiatives and outcome measurements, as well as for reimbursement and other, myriad purposes.


Such coded systems, which health information professionals categorize as either clinical classification systems[1] or clinical terminology systems[2], can continue to be used to assist in determining prospective, pre-emptive care management on covered populations.  However, no single classification system meets all use cases.  ICD-9 CM does not contain medications.  ICD-10 CM does not address functional status.  In addition, no single terminology system meets all use cases.  LOINC is used to encode laboratory data.  SNOMED CT is used to encode clinical care data.  RxNorm is used to encode medications.


Consequently, using the existing or newer coded systems to meet any of the fast-growing, clinical data collection and analysis initiatives presents a significant challenge:  too many systems from which to choose, hindering any efforts to change the collection of the data into actionable information for interoperability and health information exchange.  To resolve this challenge, one “one source of truth” or one central authority platform (CAP) for all clinical data capture systems, existing and new, allows all coded systems to be used to capture and exchange information.


With one CAP, healthcare organizations need not be concerned about when to use which data collection system for which purpose.  Organizations are able to capture required clinical, financial and administrative data once and use it many times, such as for adjudication and information governance purposes.  In addition, organizations are able to compare the data for data integrity purposes.  More importantly, organizations are assured that electronic healthcare data input by different users is semantically interoperable – i.e., that the data are understood and used while the original meaning of the data is maintained.


For example, for typical diabetic patients, Reference Lab #1 might denote glycohemoglobin within the chemistry panel, Physician Office Lab #2 might denote glycohemoglobin as an independent test: HgbA1c, and Hospital Lab #3 might use the embedded LOINC code: 4548-4.  The central authority platform recognizes each of the three laboratory information system inputs representing the same value — glucose level.  Subsequently, the healthcare organization’s electronic health record (EHR) or business intelligence system makes use of the common meaning and, for example, generates a trend analysis of the patient’s glucose readings over time.


Developing a CAP requires considerable effort.  The platform must be able to store all coded values, metadata, and all the content / terms.  It must be able to normalize and catalog all the content / terms.  It must be able track all changes in content identifiers, watches for differences in terms, cross-maps the content, route the content while preserving the data and context, and regenerate the data and content as it was stored.  Finally, it must be able to manage all the content updates / releases.  Today both the public and private domains have been moderately successful in developing the platform.


The Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare & Medicaid Services (CMS) collaborated with the National Library of Medicine (NLM) to provide the Value Set Authority Center (VSAC).  VSAC is to become the public domain, central authority platform for the official versions of the value sets that support Meaningful Use’s 2014 Clinical Quality Measures (CQMs).  However, currently VSAC does not go far enough to cover all use cases.


In the private domain, several health information technology vendors provide most of the required capabilities of the CAP.  Interestingly, these vendors collaborated with clinical professionals to create different categories of coded systems to describe their products than those categories created decades ago by health information professionals.  For example, the vendors refer to any coded system used for capturing and exchanging data as a “terminology” system, even though some of these systems are categorized by health information professionals as classification systems.  In addition, the vendors categorize all “terminologies” as either standard[3] or local terminologies[4].  Some of these vendors go even farther in categorizing all “terminologies” as either retrospective or point-of-care terminologies[5].  Consequently, today not only are there too many coded systems for data capture and exchange from which to choose, but too many categories of coded systems to make sense of it all.


Assuming that both public and private domain CAP options will prevail, healthcare organizations can expect widespread use of the platforms, allowing EHRs and other electronic records, such as financial records, to incorporate multiple coded systems for specified needs.  In addition, workforce demands for the clinical informatics skills needed to manage all the coded data will continue to remain strong.



[1] Clinical classification systems, such as ICD-9-CM, ICD-10-CM, and ICD-10-PCS derive from epidemiology and health information management.  These systems group similar diseases and procedures based on predetermined categories for body systems, etiology or life phases.  As such, they organize related entities for easy retrieval.  They are considered “output” rather than “input” systems and were never intended or designed for the primary documentation (or input) of clinical care.


[2] Clinical terminology systems (a.k.a., nomenclature or vocabulary systems), such as SNOMED CT and RxNorm derive from health informatics.  These systems are expressed in “natural” language, and, typically, codify the clinical information captured in an electronic health record (EHR) during the course of patient care (because the number of items and level of detail cannot be effectively managed without automation).  As such, they are considered “input” systems.


[3] Standard terminologies consist of “administrative” terminologies, such as ICD and CPT, and “reference” terminologies, such as SNOMED, LOINC, RxNorm, and UMLS.


[4] Local terminologies are those that healthcare providers, such as laboratories or physicians, use on a daily basis in their records, on the telephone, etc., to describe specific diagnoses and procedures.


[5] Retrospective terminologies consist of all standard terminologies (administrative and reference) and local terminologies, while point-of-care terminologies are those that are healthcare provider-friendly and used for specific documents.

Accent on Objects

It has been many years since I acknowledged patient record subpoenas for medical malpractice lawsuits and other legal actions as an HIM professional and designated custodian of records (COR). But the process was memorable.

During the 1970s, one was not able to reproduce analog paper and photographic film or send records by postal mail or courier to the courts.  Rudimentary paper and film photocopy machines only recently were introduced into healthcare organizations, and the courts required the personal delivery of “original” source documents and records by a COR.  Consequently, upon receiving patient record subpoenas, I took a large cardboard box and collected from each department the “original” source documents required by the subpoenas. The contents included the patient’s paper financial and medical records.  The medical records also included all film-based diagnostic images, tape-based medical dictation, cine-based ECGs, and pathology slides.

During the 1980s, when I established my related career in HIT and because of my COR experiences during the “analog” years, I knew well that electronic patient records consisted of more than just the structured data typically found in electronic patient financial and medical records. (Structured data are the record’s binary, discrete, and computer-readable data elements that, typically, are stored in relational databases with predefined fields.)  Electronic medical records (EMRs) also consisted of digital diagnostic images, audio file-based dictation, and ECG waveforms. In fact, such unstructured data make up at least 75% of all the data in a typical patient’s EMR.  (Unstructured data are the record’s non-binary, non-discrete, and often human-readable data elements that, typically, are contained in text-based reports, emails, and web pages and include symbols, images, video clips and audio clips.  In some vertical markets, unstructured data are referred to as a record’s intellectual substance or content.  In technical arenas, unstructured data are referred to as “objects”.)

Just like healthcare organizations, the courts finally have entered the digital age. Today, secured electronic files of “original,” electronic source documents and records as well as “copies” of original, electronic source documents and records are admissible in courts as long as the healthcare organization can substantiate (1) the trustworthiness of the system(s) used to store and retrieve the documents and records; (2) the accuracy of the organization’s records management policies and procedures; and (3) the documents and records were not created (or altered!) just for a court case. (NOTE:  Always one must verify the courts’ acceptance of digital records on a state-by-state basis.)

Large cardboard boxes have been replaced by EMR (or other system) features that promote single points of personalized access through which to find and deliver electronic information, applications, and services. As such, in either hybrid or full EMR environments, designated CORs, Release of Information professionals, and even patients—after rigorous authorization and authentication processes—merely click on hyperlinks and instantaneously retrieve “original” electronic source documents and records required by subpoenas or other requesters.

While our industry continues to pursue the best “highways” to securely transmit the documents to and acknowledge receipt from requesters, today’s day-to-day challenges involve the current mechanisms used to transmit unstructured data and the shameful output of structured data generated by most EMR systems.

For example, the transmission of the large and ever-growing number of patient diagnostic images (primarily radiology images), which remain hand-carried or sent by postal mail or courier from hospitals, physicians / groups, specialty (e.g., cancer) centers, etc., to other hospitals, physicians / groups, and specialty centers on CD storage media, is completely unmanageable. Many of the CDs containing (e.g., radiology) diagnostic images cannot be imported into the receiving Radiology PACS due to the way the images were burned into the CDs.  Although most of the CDs include the senders’ viewers for measuring, window / leveling, etc., often the CD files arrive corrupted.  Frequently the CDs are misfiled and / or lost.  Consequently, transmitting diagnostic images on CDs has lead to duplicate testing with more patient exposure to radiation.  In addition, when the CDs contain diagnostic images other than radiology images, often the receivers have no corresponding PACS for these other, “ology” images.

Thankfully, popular, standard, inbound (i.e., CD ingestion and electronic receipt of diagnostic images) and outbound (i.e., report and image distribution to referring physicians, referral centers, etc.) image sharing solutions exist.  However, most are too expensive for the healthcare provider masses.  In addition, few, if any, non-standard image sharing solutions exist, whereby direct connections are established between two or more organizations for readings, consultations, and 2nd opinions and inbound and outbound electronic reports accompany the images.

Also, there is not a healthcare professional that has not experienced the reams of paper output generated by EMR systems because the systems’ structured data are not report-formatted for output. This is one reason why a patient still cannot receive his/her entire patient record from a portal!  Not that I promote hard copy printing; however, healthcare providers still must maintain a legal archive from which to generate the electronic document presentation as proof for exception and dispute handling.  In other words, providers must have the document presentation for legal purposes and NOT an informational statement or data representation of the document, which, unfortunately, remains common in today’s electronic patient record system output.

Quality Information For Quality Healthcare

I promise not to provide another comment regarding the “Meaningful Use” of the electronic health record (EHR).  That’s because I strongly believe that health professionals should be more concerned about the meaningful use of the health information than of the EHR.

Patient health information comes from a multitude of sources – hospitals, physician offices, pharmacies, off-site laboratories, radiology facilities, long-term care facilities.  Therefore, instead of raising questions regarding the meaningful use of implemented EHRs, health professionals must raise other questions that need immediate answers, such as how will all this information be compiled? Who will be ultimately responsible for this information’s maintenance and storage?

More importantly, health professionals must find ways to achieve quality data in the EHR, because only with quality data can health professionals develop quality measurements and clinical quality indicators. For example, did the procedure shorten the length of the patient’s stay? Or, did the procedure cause the patient to have more doctors’ office visits at the end of the organization’s episode of care?  When such questions are answered and realized across the continuum of care can one implement the systems to capture and meaningfully use the information as well as produce better information for better decision-making.

One suggestion to accomplish this is to begin standardizing on terms, categories, and practices, at least within the organization.  An organization can get assistance from the National Quality Forum’s Healthcare Information Technology Expert Panel, which is directing its non-profit efforts on a next generation quality data set with a universal terminology for the design of quality measures.  Another suggestion is to vigilantly monitor the EHR’s common problems, including but not limited to user input errors, abuse of default settings, and abuse of the copy / paste function.

In my thirty year healthcare career, the first half debated whether or not quality could be defined.  The second half debated about whether or not quality could be measured.  I hope the debate now will focus on whether or not the information generated for quality purposes will be accurate.



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:

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:

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: