Showing posts with label EMR. Show all posts
Showing posts with label EMR. Show all posts

Tuesday, June 22, 2010

The Promise of Information Technology in Electronic Health Records


This blog is written by and largely viewed by IT professionals, 5,217 visits from 106 countries according to Google Analytics at last count. While the [technical] subject matter herein applies to many fields, its application to electronic heath records (EHR) has been a large part of my focus.

So, to add balance to this blog, I've provided below several links to material written by medical professionals within the healthcare industry who are concerned with these same subjects.

The Promise of Information Technology in Electronic Health Records (EHR)

Information Technology Tools to Support Best Practices in Health Care

Microsoft HealthVault Platform

Electronic Medical Records (EMR) and The Prospect of Real-Time Evidence Development


Executive Summary

Evidence-Based Medicine and the Changing Nature of Healthcare


Wednesday, February 24, 2010

Business Process Management and Service Oriented Architecture

Business Process Management (BPM) is used to model, simulate, automate, manage, and monitor processes, in order to coordinate operations with dynamic business priorities.

With BPM, workflows (both human and automated) are determined in real-time by events and/or outcomes within the process, and effective knowledge transfer is made possible as processes become well-documented business artifacts on which staff members can be trained.

To enjoy the full benefits of BPM, processes must integrate with existing applications and systems (e.g., hospital EHR and EMR, to name a couple of areas currently being funded by the Obama administration in the U.S.). This is where Service Oriented Architecture (SOA) - the subject of earlier posts - comes in. BPM and SOA are a natural match. There are links to a few of my early articles on SOA, in the bibliography at the bottom of this blog.

In preparation for my next post to this blog, I'd like to cite the following book:



This book shows the reader how to fill the semantic gap between the process model and the applications:

Modeling business processes for SOA and developing end-to-end IT support has become one of the top IT priorities. The SOA approach is based on services and on processes. Processes are focused on composition of services and in that sense services become process activities.

Experience has shown that the implementation and optimization of processes are the most important factors in the success of SOA projects. SOA is so valuable to businesses because it enables process optimization. In order to optimize processes, we need to know which processes are relevant and we have to understand them – something that cannot be done without business process modeling. There is a major problem with this approach – a semantic gap between the process model and the applications.

This book will show you how to fill this gap. It describes a pragmatic approach to business process modeling using the Business Process Modeling Notation (BPMN) and the automatic mapping of BPMN to the Business Process Execution Language (BPEL), which is the de-facto standard for executing business processes in SOA. The book will also cover related technologies like Business Rules Management and Business Activity Monitoring which play a pivotal role in achieving closed loop Business Process Management.

From http://www.packtpub.com/business-process-driven-SOA-using-BPMN-and-BPEL/book

Friday, November 20, 2009

Biometric and Other Identification Technologies


In my November 17 post, I began a discussion of the [proposed] unique patient identification numbers by looking at a de facto proxy, the Social Security number (SSN). In the present post, I will continue with a look at a few of the technologies available for getting information such as someone's identification into or out of a computerized system such as, but not limited to, those used to implement electronic health records (EHR).


Biometric Applications

Biometric verification is a technology which uses unique characteristic features of an individual to automatically identify a person. There are several biometric technologies including fingerprint, hand geometry, and retinal scan. Each of these verification techniques claims to provide positive identification of individuals. What's more, these forms of ID cannot be transferred, forgotten or lost. Anywhere personal identification is required (such as PIN numbers at financial institutions), biometric verification can be used.

The hardware needed for biometric verification is frequently installed at the entrance of a building or secured area and are the "keys" for entry. Fingerprint verifiers, for example, generally allow any finger on either hand to be used for positive identification. Usually an alternate finger is also chosen as a backup in case of injury (cut, scrape, etc.) to the first. Multiple fingerprint templates can be stored locally inside the fingerprint terminal or through a network on a host computer (e.g., in a database). Most vendors also include software that supports common security access features such as unauthorized overtime or early clocking in. In addition, many of these systems can be integrated with existing software packages. Therefore, usually, separate systems do not have to be maintained in order to record and restrict access.

Biometric applications are highly specialized and costly to install when compared to card recognition and other access systems. In addition, if a biometric unit such as a terminal goes down, the manufacturer is often the only source for replacement or repair. With other technologies, such as magnetic stripe, input devices are readily available and can be purchased from a variety of vendors. Biometric Identification, however, does have its benefit. When ultimate security is vital, biometric identification is sometimes proven to be the best solution. But, caveat emptor: as shown later in this post, errors do occur.

Voice Recognition

Although technically, voice recognition is part of biometric verification, its widest application is to convert speech into text and not principally for security or access control. Voice recognition has many advantages, most notably allowing people to keep their eyes and hands free while "voicing instructions" to the computer. Voice recognition is used in many professional fields including healthcare.

For a discussion of using the human voice for verification, see my article "Speech Authentication Strategies, Risk Mitigation, and Business Metrics" in the bibliography at the bottom of this blog.

http://www.developer.com/security/article.php/3684921/Speech-Authentication-Strategies-Risk-Mitigation-and-Business-Metrics.htm

For readers with a background in mathematics and statistics, see the papers

"Comparing Human and Automatic Face Recognition Performance" at

http://myslu.stlawu.edu/~msch/biometrics/papers/adler-schuckers-Human-Automatic-FR.pdf

and

"Statistical Evaluation and Estimation of Biometric-based Classification" at

http://myslu.stlawu.edu/~msch/biometrics/papers/SchuckersTIFSCorrelationStructurev3.pdf

Among the topics discussed here are

(1) false accept rate
(2) false reject rate
(3) false match rate
(4) false non-match rate
(5) biometric authentication,
(6) effective sample size
(7) confidence intervals

Note 1: A video in the right-hand column of this blog presents a brief introduction to confidence intervals.

Note 2: If 99.9% were good enough

• There would be a major plane crash every 3 days
• 12 babies would be given to the wrong parents each day
• There would be 37,000 ATM errors every hour

Nonetheless, technology-based systems in use today do yield the expected outcome less than 100% of the time.

So, it's important that you understand that, like their human counterparts, technologically-based methods are error prone. At the same time, it's also important that you know the cost of these errors to you (and those you serve) in the methodology you choose to use.

Optical laser Cards

These cutting-edge cards transform CD-ROM technology into a credit card form, capable of securely storing megabytes of personal information. For example, a patient ID card could hold an image, health care history, vaccination record, X-rays and more.

Card Based Access System

Controlling entry security to your facility (or computer system) is of vital importance, whether your facility is a high security area such as a hospital, airport, or bank, or even if it is an everyday situation such as an insurance office, school, or department store.

Visual Identification

The simplest access control systems use portrait ID or membership cards, which rely on a receptionist or colleagues at work to recognize interlopers by the absence of a valid, matching portrait card. Such systems require the printing of clear, easily visible, portrait cards. Unfortunately however, that alone is not enough, because with current PC and scanner technology, creating fake or counterfeit cards is all too easy.

Even simple door entry control systems need to use an anti-counterfeiting system which provides an overall security "watermark" feature which is proof against all attempts to copy it.
This type of access control is extremely cost-effective, and it may be all that many facilities need to achieve the security level they require.

Swipe Card Door Access Control Systems

If you need controlled access without relying on the presence of guards or reception staff, you may need to add swipe card readers and electronic locks to your controlled entrances. A higher level of security can be achieved by using mag-stripe readers.

Proximity Cards / Prox Card Access Control Systems

Proximity Cards, or "Prox" as they are often called, are standard size plastic ID cards which contain a coil antenna and a pre-programmed micro chip containing a unique code. When the prox card is within a foot or so of the Prox reader, the radio signal from the reader is picked up by the card antenna and used to power-up the micro chip which then replies with its own unique code.

The reader and its associated processor compare the code with a list of authorized entrants, and if it's OK, the door is opened and a record of entry is logged.

Prox cards must always be "personalized" with a portrait ID to eliminate the misuse of "loaned" or stolen cards.

Reference Books

For a good summary of the sources of problems (errors) and biometric performance, see



This book includes very readable material on

(1) Legal aspects of biometric technologies
(2) Selected technology error rates
(3) Resistance of the system to forgeries
(4) RFID applications
(5) Economics

and much else.

For a comprehensive introduction to RFID, see



Click here
for a preview look at this book.

RFID and Bar Codes

For a discussion of the pros and cons of using RFID and bar codes for the identification of patients, staff and medications, in different use cases, see

http://geekdoctor.blogspot.com/2007/11/bar-codes-rfid-and-patient-safety.html

You will find there a summary of early work at Beth Israel Deaconess Medical Center in Boston to establish positive patient identification:

"For identification of most patients, we believe linear and two dimensional bar codes on wrist bands is robust, cost effective and standardized. For staff badges, linear bar codes work well. For NICU babies passive RFID enables scanning of swaddled infants without disturbing them.

For identification of medications, we believe linear bar codes of NDC numbers on heat sealable plastic bags provides a practical means to positively identification medications.

For identification of equipment, specifically for tracking location in real time, active RFID works well. Because of the size and expense of tags, we do not believe active RFID should be used for patient identification at this time.

Thus, a combination of bar codes, passive RFID and active RFID is working well in our various pilots. No one technology meets the needs of all use cases. Although we favor bar codes over passive RFID in the short term, we do expect to eventually replace bar codes with RFID once the technology is more robust, standardized and cost effective."

Tuesday, November 17, 2009

Unique Patient Identification Numbers, Electronic Heath Records (EHR), Electronic Medical Records (EMR), and Social Security Numbers (SSN)


Creating a unique patient identification number for every person in the United States would help reduce medical errors, simplify the use of electronic medical records, increase overall efficiency, and protect patient privacy, according to a recent RAND Corp. study.

Creating such an ID system could cost as much as $11 billion, but the effort would likely return even more in benefits to the nation's healthcare system, said researchers from RAND Health, a nonprofit research organization.

As adoption of health IT expands nationally and more patient records are computerized, there have been increasing calls to create a system that would include such an ID.

So, as segue to an upcoming post here on the challenges presented by an electronic health records system based on a unique patient identification number, let’s take a brief look at the closest thing to it in the U.S.: The Social Security Number.

Introduction

The Social Security Number (SSN) was created in 1936 as a nine-digit account number assigned by the Secretary of Health and Human Services for the purpose of administering the Social Security laws. SSNs were first intended for use exclusively by the federal government as a means of tracking earnings to determine the amount of Social Security taxes to credit to each worker's account. Over time, however, SSNs were permitted to be used for purposes unrelated to the administration of the Social Security system. For example, in 1961 Congress authorized the Internal Revenue Service to use SSNs as taxpayer identification numbers.

In response to growing concerns over the accumulation of massive amounts of personal information, Congress passed the Privacy Act of 1974. Among other things, this Act makes it unlawful for a governmental agency to deny a right, benefit, or privilege merely because the individual refuses to disclose his SSN.

Section 7 of the Privacy Act further provides that any agency requesting an individual to disclose his SSN must "inform that individual whether that disclosure is mandatory or voluntary, by what statutory authority such number is solicited, and what uses will be made of it." At the time of its enactment, Congress recognized the dangers of widespread use of SSNs as universal identifiers. In its report supporting the adoption of this provision, the Senate Committee stated that the widespread use of SSNs as universal identifiers in the public and private sectors is "one of the most serious manifestations of privacy concerns in the Nation." Short of prohibiting the use of the SSN outright, the provision in the Privacy Act attempts to limit the use of the number to only those purposes where there is clear legal authority to collect the SSN. It was hoped that citizens, fully informed where the disclosure was not required by law and facing no loss of opportunity in failing to provide the SSN, would be unlikely to provide an SSN and institutions would not pursue the SSN as a form of identification.

Large amounts of personal information, including tax information, credit information, school records, and medical records, is keyed to your Social Security Number. Because this data is often sensitive, you should keep it private.

The Structure of the SSN

The SSN is not entirely randomly-generated. Although the procedures for issuing SSNs have changed over the years, a SSN can reveal an individual's relative age and place of origin. The first three numbers (area number) are keyed to the state in which the number was issued. The next two (group numbers) indicate the order in which the SSN was issued in each area. The last four (serial numbers) are randomly generated.

The SSN and Privacy

Today, the Social Security Number plays an unparalleled role in identification, authentication, and tracking of Americans. Because the identifier is used for many purposes, it is valuable to those who wish to acquire credit, commit crimes, or masquerade as another person.

The SSN has been increasingly used in the private sector. The SSN is the record locator for many private-sector profilers, credit bureaus, and credit card companies. It is also used extensively outside the financial services sector. And, while some businesses use the SSN to identify individuals, others use the SSN as a password. This means that the SSN is widely used both as an identifier and as an authenticator. Serious security problems are raised in any system where a single number is used both as identifier and authenticator. It is not unlike using a password identical to a user name for signing into e-mail. Or like using the SSN as a bank account number and the last four of the SSN as a PIN for automated teller machines.

The SSN as National Identifier

The issuance of a single, unique number to Americans raises the risk that the SSN will become a de jure or de facto national identifier. This risk is not new; it was voiced at the creation of the SSN and has since been raised repeatedly. The SSN was created in 1936 for the sole purpose of accurately recording individual worker's contributions to the social security fund. The public and legislators were immediately suspicious and distrustful of this tracking system fearing that the SSN would quickly become a system containing vast amounts of personal information, such as race, religion and family history, that could be used by the government to track down and control the action of citizens. Public concern over the potential for abuse inherent in the SSN tracking system was so high, that in an effort to dispel public concern the first regulation issued by the Social Security Board declared that the SSN was for the exclusive use of the Social Security system.

In passing the Privacy Act of 1974, Congress was specifically reacting to and rejecting calls for the creation of a single entity for the reference and storage of personal information. A 1977 report issued as a result of the Privacy Act highlighted the dangers and transfer of powers from individuals to the government that occur with centralization of personal information:

In a larger context, Americans must also be concerned about the long-term effect record-keeping practices can have not only on relationships between individuals and organizations, but also on the balance of power between government and the rest of society. Accumulations of information about individuals tend to enhance authority by making it easier for authority to reach individuals directly. Thus, growth in society's record-keeping capability poses the risk that existing power balances will be upset.

Many medical providers are using the SSN as a patient identifier, thus hardening the number as a de facto national identifier. As David Miller noted in testimony before the National Committee on Vital Health Statistics:

"It should be noted that the 1993 WEDI [Workgroup for Electronic Data Interchange] Report, Appendix 4, Unique Identifiers for the Health Care Industry, Addendum 4 indicated 71% of the payers responding to the survey based the individual identifier on the Member's Social Security Number. However 89% requested the insured's Social Security Number for application of insurance. Clearly the Social Security Number is the current de facto identifier..."

But individuals and companies are resisting such use of the SSN. Acting on employees' suggestions, I.B.M. has requested that health companies stop using the SSN on insurance cards. According to IBM, fifteen insurers, which cover about 30,000 of the company's 500,000 employees worldwide have either not responded or indicated that they will not comply with the request.

The SSN and Identity Theft

The widespread use of the SSN as an identifier and authenticator has lead to an increase in identity theft. According to the Privacy Rights Clearinghouse, identity theft now affects between 500,000 and 700,000 people annually. Victims often do not discover the crime until many months after its occurrence. Victims spend hundreds of hours and substantial amounts of money attempting to fix ruined credit or expunge a criminal record that another committed in their name.

Identity theft litigation also shows that the SSN is central to committing fraud. In fact, the SSN plays such a central role in identification that there are numerous cases where impostors were able to obtain credit with their own name but a victim's SSN, and as a result, only the victim's credit was affected. In June 2004, the Salt Lake Tribune reported: "Making purchases on credit using your own name and someone else's Social Security number may sound difficult -- even impossible -- given the level of sophistication of the nation's financial services industry. But investigators say it is happening with alarming frequency because businesses granting credit do little to ensure names and Social Security numbers match and credit bureaus allow perpetrators to establish credit files using other people's Social Security numbers." The same article reports that Ron Ingleby, resident agent in charge of Utah, Montana and Wyoming for the Social Security Administration's Office of Inspector General, as stating that SSN-only fraud makes up the majority of cases of identity theft.

Because creditors will open new accounts based only on a SSN match, California has passed legislation requiring certain credit grantors to comply with heightened authentication procedures. California Civil Code § 1785.14 requires credit grantors to actually match identifying information on the credit application to the report held at the credit reporting agency. Credit cannot be granted unless three identifiers from the application match those on file at the credit bureau.

Saturday, October 24, 2009

Electronic medical records systems are not classified as medical devices -- This may have serious consequences.


This is an interim post. The promised post on ontologies that benefit from fuzzy or probability-based logic is coming.


"We wouldn't want to go back, but Electronic Health Records (EHR) are still in need of significant improvement."

-Christine Sinsky, an internist
in Dubuque, Iowa, whose practice implemented electronic records six years ago.

More than one in five hospital medication errors reported last year -- 27,969 out of 133,662 -- were caused at least partly by computers, according to data submitted by 379 hospitals to Quantros Inc., a health-care information company. Paper-based errors have caused 10,954 errors, the data showed.

Between 2006 and 2008, computer errors also contributed to 31 deaths or serious injuries -- twice as many as were caused by paper errors, although numbers of these serious cases were decreasing, Quantros said.

Legal experts say it is impossible to know how often health IT mishaps occur. Electronic medical records are not classified as medical devices, so hospitals are not required to report problems. In fact, many health IT contracts do not allow hospitals to discuss computer flaws, according to Sharona Hoffman, a professor of law and bioethics at Case Western Reserve University in Cleveland.

"Doctors who report problems can lose their jobs," Hoffman said. "Hospitals don't have any incentive to do so and may be in breach of contract if they do. That sort of secrecy puts the patient at risk."

Click here to see the complete Washington Post article

Monday, August 24, 2009

Reasoning for Ontology Engineering and Usage and The Challenges of Modern Medical Ontologies

In my August 6 post, I briefly introduced ontology editor Protégé 4.0 with the reasoners FaCT++ (implemented using C++) and Pellet (Java based). Today's post picks up this story and adds the RacerPro (commercial) reasoner to the mix. You can -- and I recommend that you do -- download your own copies of the latest versions of these tools. Links that enable you to do so are located at the end of this post.



Protégé 4.0 with three reasoner added-ins

A
reasoner is a piece of software able to infer logical consequences from a set of asserted facts or axioms. In the present context, a reasoner makes inferences about classes and individuals in an ontology, tasks that are beyond the Web Ontology Language (OWL) model alone.

Ontologies, as described in prior posts, are formal vocabularies of terms, often shared by a community of users, and, as such, ontologies play an important role in semantic interoperability and Web 3.0. One of the most prominent application areas of ontologies is medicine and the life sciences. For example, the Systematised Nomenclature of Medicine Clinical Terms (SNOMED CT) is a clinical ontology. Another example is the OBO Foundry -- a repository containing about 80 biomedical ontologies.

These ontologies are gradually superseding existing medical classifications and will provide the future platforms for gathering and sharing medical knowledge. Capturing medical records using ontologies will reduce the possibility for data misinterpretation, and will enable information exchange between different applications and institutions.

Medical ontologies are strongly related to description logics (DLs), which provide the formal basis for many ontology languages, most notably the W3C standardised OWL. All the above mentioned ontologies are nowadays available in OWL and, therefore, in a description logic. The developers of medical ontologies have recognised the numerous benefits of using DLs, such as the clear and unambiguous semantics for different modelling constructs, the well-understood tradeoffs between expressivity and computational complexity, and the availability of provably correct reasoners and tools (discussion to follow).

The development and application of ontologies crucially depend on reasoning. Ontology classification, i.e., organising classes into a specialisation/generalisation hierarchy, is a reasoning task that plays a major role during ontology development: it provides for the detection of potential modelling errors such as inconsistent class descriptions and missing sub-class relationships. For example, about 180 missing sub-class relationships were detected when the version of SNOMED CT used by the NHS was classified using the DL reasoner FaCT++. Query answering is another reasoning task that is mainly used during ontology-based information retrieval; e.g., in clinical applications query answering might be used to retrieve "all patients that suffer from nut allergies".

Despite the impressive state-of-the-art, modern medical ontologies pose significant challenges to both the theory and practice of DL-based languages. Existing reasoners can efficiently deal with some large ontologies, but many important ontologies are still beyond the reach of available tools (i.e., they are unable to classify some widely used ontologies).

Applications currently need to work around these limitations, e.g., by using subsets of ontologies that can be successfully processed. For example, the version of
GALEN typically used in practice contains only about 20% of the axioms of the full version; this reduces the interaction between concepts and thus makes the ontology "processable". This is, however, highly undesirable in practice, because it reduces coverage, weakens the conceptualisation of the domain and may prevent the detection of modelling errors.

Furthermore, the amount of data used with ontologies can be orders of magnitude larger than the ontology itself. For example, the annotation of patients' medical records in a single hospital can easily produce data consisting of hundreds of millions of facts, and aggregation at a national level might produce billions of facts. Existing reasoners cannot cope with such data volumes, especially not if ontologies such as
GALEN and FMA are used as schemata.

Having forewarned you about these limitations, I'd like to recommend the following video on reasoners -- free and commercial.

http://videolectures.net/iswc08_moller_itsr/

Some readers of this blog might not be familiar with terms that appear in the video, starting with ABox and TBox.



For those readers especially, the following links for accessing the Protégé, Pellet and Racer sites could be used to install and examine this software (and accompaning documentation) before watching the videos.

Protégé http://protege.stanford.edu/

Pellet http://clarkparsia.com/pellet/

RacerPro http://www.racer-systems.com/

Then, as you watch the video, you could follow along using your own running code. For some, this will require more than a single session.

Recommended reading - basics of description logics:
www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-01.pdf
www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-02.pdf
http://www.cs.man.ac.uk/~horrocks/Slides/IJCAR-tutorial/Print/p1-introduction.pdf

Monday, August 3, 2009

The game is sometimes rigged in favor of the house

High-speed trading: some institutions, including Goldman Sachs, have been using superfast computers to get the jump on other investors, buying or selling stocks a tiny fraction of a second before anyone else can react. Profits from high-frequency trading are one reason Goldman is earning record profits and likely to pay record bonuses.

And there’s a good case that such activities are actually harmful. For example, high-frequency trading probably degrades the stock market’s function, because it’s a kind of tax on investors who lack access to those superfast computers — which means that the money Goldman spends on those computers has a negative effect on national wealth.

So, what's this got to do with information technology in healthcare? Possible, nothing. Remember, however, that one of the stated goals of EHR is to deliver better healthcare at lower cost.


I believe that we should keep in mind that technology - not high-speed computers per se - doesn't always benefit society. As I mention - without much elaboration - in my July 22 post, "EHR / EMR has the potential to facilitate the execution of today's healthcare scams. So, for the time being, we might well have a reason to temper our enthusiasm for the inevitable computerization of our still-largely-paper-bound healthcare records systems."

Wednesday, July 22, 2009

Electonic Health Records / Electronic Medical Records - Scams


Dr. David Scheiner, an internist based in the Chicago neighborhood of Hyde Park, was President Obama’s doctor for twenty-two years, from 1987 until he entered the White House but has publicly opposed Obama’s health plan, calling for a single payer system (see the text and video in my May 13, 2009 post for an introduction to the current debate over single payer).

In a recent interview, Dr. Scheiner said, "President Obama believes that when we have electronic records, somehow night will change into day. That won’t happen. First of all, it’s extremely costly. It will become even easier to scam the health insurance companies and Medicare when you have a cursor that can go over all the things that you perhaps didn’t do, but look good on paper, and you can code much higher."

I post this quote simply to remind us all that while electronic health records / electronic medical records will automate and, in all likelihood, improve many aspects of the delivery of healthcare, at the same time EHR / EMR has the potential to facilitate the execution of today's healthcare scams. So, for the time being, we might well have a reason to temper our enthusiasm for the inevitable computerization of our still-largely-paper-bound healthcare records systems.

Wednesday, June 17, 2009

Electronic Health Records (EHR) – Interoperability of Disparate Systems – Political

The top box in the figure below (adapted from the first figure in my June 16 post) contains the label "Political," and the video in my May 13th post (repeated below) shows excerpts from a recently held hearing in the United States Senate Committee On Finance, chaired by Senator Max Baucus. The latter motivated the former. But, I've had additional reasons to think about the influence of national politics upon the architecture of the upcoming IT-based EHR system.










Montana Senator Baucus is the Senate’s point man on healthcare reform. A new article in the Montana Standard finds that Senator Baucus has received more campaign money from health and insurance industry interests than any other member of Congress. The article says, “In the past six years, nearly one-fourth of every dime raised by Baucus and his political-action committee has come from groups and individuals associated with drug companies, insurers, hospitals, medical-supply firms, health-service companies and other health professionals.”

Moreover, it’s hard for even the most casual follower of the daily news to avoid finding his or her own reason to believe that national politics will play a major role in the rollout of our EHR system.

The vast majority of the funds within the HITECH Act (the health IT component of the American Recovery & Reinvestment Act) are assigned to payments that will reward physicians and hospitals for effectively using a robust, connected EHR system. Few should doubt that how these billions of dollars are distributed will have a profound impact on the shaping of our national EHR system.

In addition to funding EHRs (also called electronic medical records, or EMRs), HITECH adds some privacy-enforcement teeth to HIPAA, which has long been criticized for loopholes’ allowing the release of medical record information to health care vendors for marketing purposes. Pharmaceutical companies, for instance, have frequently used prescription information from these records to target their mailings for new or alternative drugs and treatments. HITECH now mandates that individual patients’ consent be obtained before releasing any information to vendors -- or to anyone not in the immediate health care loop that includes physicians and hospitals as well as insuring and billing entities (for a scary look at how easily this loop can expand, read “Health Privacy—The Way We Live Now”). The new provisions also require voluntary and affirmative disclosure of any breaches or violations of private records. However, as the final stimulus package wended its way through Congress, so many loopholes (five pages’ worth) were added that just about any group with political connections, or with loose medical affiliations, could gain access to everyone’s personal EHR just by asking for it or by paying for it.

While there are workgroups and committees of experts working diligently to shape an EHR that helps bring about a better healthcare system for the nation, the members of these groups don’t control the purse strings. Politicians do. Stay tuned.

Monday, June 15, 2009

Electronic Health Records (EHR) & “Meaningful Use” survey results & Speech Recognition Technology


Electronic health records (EHR) have been recognized as a core component to national healthcare reform in the United States. Beginning in 2011, physicians and hospitals can receive bonus payments under Medicare and Medicaid, but only if they are found to be “meaningful EHR users.” Nuance Communications, Inc., a leading supplier of speech solutions that are expected to help with the transition to and utilization of EHR, surveyed physicians to better understand how “meaningful use” should, from their point of view, ultimately be defined.

A couple of my prior posts were about speech recognition and another couple of my prior posts were about electronic health records. So, I was interested in the results of this survey.

The EHR Meaningful Use Physician Study shows —

93 percent of doctors “disagree” or “strongly disagree” that using an EHR has reduced time spent documenting care.

When asked what doctors consider an “incentive to drive national EHR adoption,” 75 percent of the physicians surveyed said they consider “access to tools that would help doctors to better document within an EHR (beyond the keyboard), such as speech recognition” an incentive; whereas 69 percent cited “stimulus money.”

When asked about qualifications that the federal government should measure as part of pay-outs associated with EHR meaningful use, physicians cited the following:

  • 90 percent said “access to medical records faster without waiting for records to come out of transcription,” was “important” or “very important.”
  • 83 percent said “more complete patient reports, with higher levels or detail on the patient’s condition and visit,” was “important” or “very important.”
  • 83 percent said “better caregiver-to-caregiver communication based on improved reporting that is more accessible and easily shareable,” was “important” or “very important.”
  • 79 percent said, “improved documentation by pairing the EHR point-and-click template with physician narrative,” was “important” or “very important.”

When asked about the importance of various EHR components, physicians identified the following as the five most important:

    • Lab test results reporting and review
    • Documentation tools that allow doctors to speak the physician narrative into the EHR
    • E-Prescribing
    • Secure health messaging between caregivers
    • Keyboard support via speech recognition for data entry into the EHR

    74 percent of the doctors surveyed said “EHR cookie cutter templates” and “patient notes with no uniqueness” are challenges to realizing the full value of EHRs.

    93 percent of doctors surveyed either “agree” or “strongly agree” with the following statement, “I think capturing physician narrative as part of the documentation process is necessary for complete and quality patient notes.”

    67 percent of the doctors surveyed cited “time associated with reliance on keyboard and mouse to document within an EHR” as a major hurdle.

    My thoughts, after perusing these findings: On the one hand, this is a self-serving report created by a vendor of speech recognition products; On the other hand, this report suggests that there could be a good deal of resistance to EHR by physicians and hospitals if speech recognition technology is not successfully integrated into the coming EHR system(s). Stay tuned.



    Saturday, May 30, 2009

    Speech Recognition Software - The Case For Using A Medical Vocabulary And Language Model In The Generation Of EMR/EHR Documents


    Dragon NaturallySpeaking (DNS), the most widely used front-end speech recognition software application, comes in several different versions. They have many basic features in common, a number of which I’ll discuss in this post. One version, the medical version, has a set of specialized vocabularies (shown in list below) that make it uniquely suitable for use throughout the healthcare industry.



    This post will touch upon a number of the features that all of the versions of DNS have in common as well as some of the special capabilities of the medical version.

    Because every person's voice is different, and words can be spoken in a range of different nuances, tones and emotions, the computational task of successfully recognizing spoken words is considerable and has been the subject of many years of continuing research work around the world.

    A variety of different approaches are used, with the most widely used underlying technology being the Hidden Markov Model (discussed briefly below). These techniques all attempt to search for the most likely word sequence given the fact that the acoustic signal will also contain a lot of background noise. The task is made easier if the system can be trained to recognize one person's voice pattern rather than that of many people, and it is also easier if isolated words are to be recognized rather than continuous speech. Similarly, the task is easier if the vocabulary is small, the grammar constrained and the context well-defined.

    The complexity of these problems has meant that most of the voice recognition systems developed to date cannot recognize continuous speech from a wide variety of people and with a wide vocabulary as successfully as any human listener.

    Nonetheless, despite these challenges, the present technology for speaker-dependent large-vocabulary speech recognition systems now works quite well on a PC. And, today, many healthcare-industry applications are well suited for use with this technology. For example, speech recognition is being implemented in both the front-end and back-end of the medical documentation process.

    Front-end speech recognition (SR) is where the provider dictates into a speech-recognition engine, the recognized words are displayed right after they are spoken, and the dictator is responsible for editing and signing off on the document. It never goes through a medical transcriptionist (MT)/editor.

    Back-end SR or deferred SR is where the provider dictates into a digital dictation system, and the voice is routed through a speech-recognition machine and the recognized draft document is routed along with the original voice file to the MT/editor, who edits the draft and finalizes the report. Both front-end and back-end SR are being used widely in the healthcare industry today.

    Many electronic medical records (EMR) applications are more efficient when deployed along with a speech-recognition engine. That is, searches, queries, and form filling may all be faster when data is inputted by voiced rather than by keyboard.



    Average data-entry times for a paragraph using various input mechanisms

    The next figure shows an EHR system with both front-end and back-end capabilities. In this post, I’ll focus on the former.




    Before proceeding, here is a review of a few of the basic terms used in any discussion of speech recognition:

    * Homophone
    * Phoneme
    * Acoustic model
    * Vocabulary
    * Language model
    * Bi-gram, tri-gram and quad-gram

    * Hidden Markov Model (HMM)
    * Health Level 7 Clinical Document Architecture (HL7CDA)

    A homophone is a word that is pronounced the same as another word but differs in meaning. The words may be spelled the same, such as rose (flower) and rose (past tense of "rise"), or differently, such as carat, caret, and carrot, or to, two and too. Homophones that are spelled the same are also both homographs and homonyms. The term "homophone" may also apply to units longer than words, such as letters or groups of letters that are pronounced the same as another letter or group of letters.

    DNS doesn’t apply any rules of English Grammar when attempting to “understand” your dictation. It does, however, use the statistical probability of words occurring together in the English language.

    A phoneme is the smallest linguistically distinctive unit of sound. Phonemes carry no semantic content themselves.

    In effect, a phoneme is a group of slightly different sounds which are all perceived to have the same function by speakers of the language in question. An example of a phoneme is the /k/ sound in the words kit and skill. In English spelling there is a very poor match between spelling and phonemes.

    When you dictate into DNS, it compares your utterances to the acoustic model that contains your pronunciation of words (phonemes) set up by reading the enrollment passage(s). The phonetic equivalents are then sent to the vocabulary that contains not only words and phrases but also their phonetics. Finally homophones and near homophones are resolved using the language models. These look at the statistical probability of the phonetics of words appearing together in the installed language. The models look at pairs, e.g. “right away”, triplets, e.g., “write a letter”, and quadruplets in DNS. The language model is looking at the phonetics making up the words.

    Accurate transcription requires a good acoustic model (i.e. a good microphone and sound card) and clear enunciation by the user. Local “dialect” can obviously produce inaccuracy. For example, in both the U.S. and U.K., some regional “dialects” will miss the “g” from the end of a word as in “beginning’ “ -- DNS, without training, is likely to transcribe “begin in”.

    Assuming the acoustic component is clear, the language model provides the most likely words for the phonetic equivalents according to the statistical probability of “words” occurring together. Initially the Dragon language models (produced by professional linguists) will be based on “standard” grammatical English (or other language). The language model is modified by correcting “misrecognitions” consequently, in time, you can develop a more accurate one.

    The bi-gram, tri-gram and quad-gram models look at associations in a single utterance. Hence you could also possibly improve your recognition accuracy by choosing to dictate in shorter phrases. Normally this would not be the best way to dictate as accuracy increases (for "standard English) when you use complete sentences or even full paragraphs.

    How Medical Specialty Vocabularies Provide a Better Experience

    The greatest determinant of speech recognition accuracy is the appropriateness of the vocabulary and language model. To demonstrate the difference between Dragon Medical and Dragon Professional, here’s a comparison of how the two vocabularies handle the word “embolism.”



    Dragon Professional is far more likely to translate “embolism” as the word “symbolism”, because “symbolism” rates higher than “embolism” -- it’s far more commonly used by business professionals. Dragon Medical has “embolism” by contrast, statistically rated much higher because the statistical likelihood of “embolism” occurring in medical dictation would be higher than in Dragon Professional.

    Adding Medical Terms to Non-Medical Recognizers Won’t Bridge the Accuracy Gap

    Simply having clinicians train and add hundreds of medical terms to Dragon will not adequately raise its accuracy for use in medical settings. Without the additional benefit of Dragon Medical’s language model, which carries the knowledge of the relative frequency of use of both individual words and phrases, a non-medical speech recognizer will not have the added benefit of recognizing the context of the words which provides that additional boost in accuracy.

    Were “cerebral embolism” and not just “embolism” spoken by a clinician, Dragon Medical is far more likely to recognize the phrase than Dragon Professional because it would recognize the context in which ‘embolism’ was spoken. Because the language models take into account not only the frequency of words but the frequency of multi-word phrases, Dragon Medical is significantly more accurate for medical dictation.

    Other examples of phrases having far better recognition by Dragon Medical are below.



    EHR and speech recognition can also help with the standardization of content within a clinical document. Physicians often use different words that have the same intent; for example; they may dictate history or HPI or history of present illness, or they may refer to findings or results. DNS allows the health care provider to implement best practices by coding all common terms alike to normalize the sections or subsections of the medical report and to enable a comprehensive retrieval of this information.

    Note: Health Level 7 Clinical Document Architecture (HL7CDA) is a way to have commonality of terms within a document, and serves as the basis to enlarge and enrich the flow of data into the EHR.

    The Vocabulary Editor shows you all the active words (the most commonly used words) in the Dragon Medical vocabulary. You can open Vocabulary Editor to find out whether a word is in the active vocabulary. If it’s not there, you can add it. If it is, you can create a different spoken form.

    To overcome many of these shortcomings, you can use DNS’s Vocabulary Editor to

    * Add words that are spoken one way but written a different way. This feature lets you add a word that, for example, types your phone number whenever you say “phone number line.” (Discussed below)

    * Change the formatting properties of a word, such as whether Dragon Medical should type a space before or after the word. You can do this by using the Word Properties dialog box. (Discussed below)

    The next three figures illustrate the use of the Vocabulary Editor and training that enabled me to speak “Code44” and watch “Halitosis” appear in a Microsoft Word document.







    Note: The red underlining in the figure above was put in by me after the fact, using the Windows Paint application.

    However, this trivial example of one-to-one translation can be extended to one-to-many translation: That is, in a matter of seconds, you could “program” Dragon Medical to type out a whole sentence in response to your speaking just a single word or code into the microphone. And, vice versa: you could “program” Dragon Medical to type out just a single word or code in response to your speaking a whole sentence into the microphone.


    In addition, you can use this dialog box to view and customize the formatting properties of words even more in your active vocabulary. Click here for further details.

    Before continuing, here’s a very brief overview of the anatomy and physiology of speech production and the models and technology used in speech-to-text translation.




    The figure below, from an M.I.T. Lincoln Labs – Nuance Communications, Inc. presentation, shows a display of this output spectrum as a function of time.


    Now for an overview


    Audio input: A microphone is used as the hardware for providing audio input. The microphone captures the spoken words as sound waves and these are to be converted from analog to digital format. The microphone is connected to a computer with a sound card installed. Digital voice recorders do not require the use of a sound card. The spoken words are processed to remove any noise. The microphone used may also influence the recognition rate depending on the quality, and a good microphone should cancel out ambient noise.

    Speech engine: There are two speech engines, one for recognizing speech and the other one converting text to speech. Converting text to speech is called speech synthesis.

    Language model: This is a very large list of words used in voice recognition. The language model contains a list of the words and their probabilities when used with voice recognition application. A language model is sometimes called a dictionary or lexicon. For example, a radiology language model contains all the words most likely to be used when doing a radiology report. Examples of other models are Cardiology and Pathology.

    Grammar: In a speech recognition system, a grammar file consists of a list of words or phrases which are recognized by the speech engine and are used to drive the application. Grammars are used to constrain what users can say in a voice recognition application. For example, grammar can be used for voice commands which can let the user save a radiology report, print a radiology report and close the application.

    Acoustic Model: When voice is captured by a microphone, the analog signal is converted into a digital signal. Using digital signal processing, the signal is converted into speech frames of 10ms (illustrated in a figure above). These frames are analyzed by using an acoustic model. The model will make a comparison in order to obtain probabilities that a certain word has been spoken by a user. There are a number of acoustic models which can be used for speech recognition but the majority of speech engines available today use the Hidden Markov Model (HMM).

    The HMM is a statistical model and is favored more because it is easy to understand, easy to implement, it's faster and it requires less training compared to other models. Some speech recognition systems use a hybrid combination of the various models used in speech recognition. An example would be the Hidden Markov Model and the Artificial Neural model (ANN). The ANN model is loosely based on the biological model of the human neural system

    Hidden Markov Model

    * Chain of Phonemes that make a word
    * Used first on words and then on sentences
    * Statistical analysis based on previous phrases (similar to predictive text messaging on cell phones)

    A Guide To Using DNS Medical

    DNS 10 Medical is a very powerful tool that can help its users deliver better healthcare at lower cost. But, its users have to know how to take care of it before they can benefit - long term - from this resource.

    Failing to observe good practices with any computer application is like failing to perform regular maintenance on your car, such as changing the oil, getting regular tune-ups, maintaining the proper inflation of your tires, etc. If you don't do this, the chances are very good that your car won't last longer than 50,000 miles at best. The same applies to DNS.

    Over the course of a day of continuous dictation your voice, your dictation style, your enunciation, and other factors that affect the performance of DNS change. We don't start out in the morning dictating in one manner and end the day dictating in the same manner. These changes affect how well DNS recognizes what you say.

    There are several features in DNS that were introduced in DNS 9 that affect overall accuracy over time. These are the PelAudio Acoustic Scale Score and a feature called SilentAdapt which uses the PelAudio Acoustic Scale Score to analyze your dictation during the course of any dictation session, whether it be short or long. These can have a positive effect on your accuracy, but they can also have a negative impact.

    Every time you dictate anything, DNS analyzes what you say using the PelAudio Acoustic Scale Score and assigns a confidence level. That is, it determines how frequently you say the same things in the same way consistently and assigns a score to each set of words and utterances. The positive effect is that, via the SilentAdapt feature, DNS learns to repeatedly recognize what you say based on the assignment of PelAudio Acoustic Scale Scores. The other positive effect is that DNS learns, from your dictation via the same methodology and functions/features, to ignore those words or phrases that you do not use frequently. For example, if you add a word or phrase to your vocabulary via the Vocabulary Editor, but don't use it again for a predetermined period of time, DNS learns to ignore it. This methodology is used to avoid misrecognitions that might otherwise occur during the course of dictation.

    The negative effect is that if you don't perform corrections and simply dictate for hours leaving your corrections to the end of your dictation session, DNS will tend to place a higher PelAudio Acoustic Scale Score on misrecognitions, thus tending to repeat them rather than making the correct recognition. This does not occur immediately, but it does occur frequently over time because of these features/functions. Therefore, it behooves all users to proofread what they have dictated at reasonable intervals and make appropriate corrections along with training such.
    Proofreading documents dictated using DNS is different from standard proofreading. DNS does not make spelling errors. All the words that DNS recognizes are spelled correctly even in the case where the overall recognition is not correct. Therefore, it's important to learn how to recognize grammar and context errors, as well as how to properly train DNS to correct them. Users frequently pick up misrecognized words and phrases when proofreading. One way of dealing with this issue is to make frequent use of DNS's "playback" feature that plays back what you said exactly the way you said it so that you can compare it to the actual recognize text. This is often helpful to inexperienced users in terms of learning how to proofread dictated documents by teaching them how to recognize these types of dictation errors.

    You shouldn't dictate for many hours without closing and saving your user profile, followed by relaunching it. Over time, the active user profile which you are using stores volumes of information about your dictation, corrections, and other data that is used by DNS to improve your accuracy. Dictating using a single user over many hours can cause "bloat" that needs to be cleared by periodically closing and saving your user profile. Unnecessary information is stored in your user profile and removed from memory leaving your user profile relatively clean and current. Obviously, running DNS's Acoustic and Language Model Optimizer does a better job of optimizing your user profile. However, periodically closing and reopening your user profile has a moderately similar effect on overall performance.

    We all normally adjust to the changes in our dictation style and voice. While we generally don't detect these changes simply because of the way that the human brain works, DNS is particularly sensitive to such changes and this sensitivity is what generally causes much of the degradation in accuracy that users experience when using their user profiles over a long period of time. In addition, putting the microphone to sleep does not turn it off because DNS continues to listen to anything coming into the microphone while waiting for wake-up command. Although this generally does not have a negative impact, it can, depending upon what DNS is hearing. So, it is generally better to turn the microphone off rather than leaving it on/asleep for any length of time, particularly if there is significant background speech and/or noise. Nevertheless, it is always a good idea to rerun the Audio Setup Wizard whenever you begin to detect an increase in the number of misrecognitions. This readjusts the microphone settings based on both the current environment (background) as well as any changes in your voice or manner of dictation. In short, this readjusts the microphone settings to reflect anything that may impact on recognition accuracy, particularly if there is any significant difference between the settings used when you first start dictating in the morning and the current status of your voice, dictation style, etc.

    Lastly, remember that constant use of your system in terms of opening and closing applications, dictation using DNS, and other interactive factors occurring in the background during the course of a day have an impact on Windows performance and resources. Periodically reboot your system. This cleans memory entirely and lets you start over again from square one with full access to all the Windows resources and memory. This may seem like a pain, but it is, from time to time, essential to the proper performance of DNS, as well as the proper performance of Windows itself. Remember that as goes Windows, so goes DNS. Not the other way around.

    A Recap

    NaturallySpeaking and the Acoustic Model

    The way you speak is totally distinctive, and no-one on earth sounds exactly the same way as you do. Dragon NaturallySpeaking relies on this individuality to create a unique mathematical model of your voice's sound patterns.

    NaturallySpeaking analyses each sound you make and compares it to a database of thousands of possible syllables in the English language. As it becomes more familiar with your speech patterns (a process greatly enhanced by training the application when creating a new user profile), it becomes more accurate in identifying individual sounds. For example, the way you pronounce a “th” sound changes how Dragon NaturallySpeaking responds to any word with that sound in its pronunciation.

    As the acoustic model recognizes sounds, it’s the vocabulary’s task to relate those sounds to actual words.

    NaturallySpeaking and vocabularies

    A vocabulary in Dragon NaturallySpeaking is compiled from a body of information that typically includes a word list and a language model. The word list adds words to the Dragon NaturallySpeaking’s active vocabulary (which is loaded into RAM and allows instant recognition) and backup dictionary (which has an expanded number of words for correction purposes) to improve the language model and recognition accuracy when the vocabulary is compiled. The language model contains usage and context information about all the words.

    Therefore, Dragon NaturallySpeaking uses a vocabulary to recognize words correctly based not only on the sounds of the words, but also on the context of those words within your current document.

    All words in the vocabulary have an initial set of pronunciations. The acoustic model uses these pronunciations to decide which words most closely match what was spoken. A word may have more than one pronunciation assigned to it, such as the word "either," which may be pronounced "EE-ther" or "EYE-ther; and in turn a pronunciation may have more than one word assigned to it, such as the words “to”, “too” and “two”. In this case, Dragon NaturallySpeaking’s language model assesses the context of the word within the sentence to determine which word is most correct.

    Narrative Paradigm

    There is often a considerable difference between what is typed or hand written into a report and what is put into a report that's created by a speech recognition system. The latter is often narrative based, capturing important nuances in addition to the bare facts.

    A note on full-URL links vs. compressed links

    I've been asked why I didn't used link-shrinkers in earlier posts. Here's why:

    First, I should say that there are some things I like about link compression: Some link-shrinkers let you personalize the new address with a unique phrase such as your name, or show you how many people click the link after you've posted it. Furthermore, link compression is just the beginning. More and more of these outfits allow users to see all sorts of details like where a link is showing up around the Web and where the people clicking on it are located.

    However, this convenience may come at a cost. The tools add another layer to the process of navigating the Web, potentially leaving a trail of broken links if a service suddenly closes shop. They can also make it harder to tell what you're really clicking on, which may make these Lilliputian links attractive to spammers and scammers.

    But popularity and convenience don't eliminate the potential risks of these link loppers. If so many services are springing up, chances are some will just as quickly disappear. And if a URL shortening service goes down, the links created with it could lead nowhere.

    Another worry is that you're not likely to know exactly where a truncated link will take you. So you could be directed to unsavory or illegal content or something malicious like a computer worm. This means URL shortening services need to keep an eye on the kinds of sites their users are linking to.

    Friday, May 1, 2009

    Speech recognition software and new security rules for electronic medical records (EMR)


    The Stimulus Package includes new HIPAA Security Rules that require practices to post information about security breaches if a breach affects 10 or more patients. If a security breach affects 500 or more patients, practices must notify all of their patients, a local media outlet, and the HHS secretary. And, of course, there’s always the chance of a law suit brought against individuals or organizations when only a single breach occurs.

    The new legislation also calls for beefed up enforcement rules and a new aggressiveness in assigning fines. Fines for security breaches start at $100 and can go as high as $1.5 million. In addition, the legislation empowers state attorneys general to enforce some HIPAA elements and gives them the authority to bring class action suits.


    These requirements are very similar to those in a lot of states that have laws against identity theft.

    So, many of the discussions about this new legislation, especially media reports, center around patient records that have been misplaced, stolen, or hacked from storage in databases, PDAs and the like.

    In this post, however, I’ll be concerned only with some security risks that can arise in the very front end of the health information system.

    “A journey of a thousand miles must begin with a single step.”

    ...... - Lao-Tsu

    The front end

    Voice recognition software and Dragon NaturallySpeaking Medical (DNS) in particular are a great companion to an EMR implementation (and, ultimately, an EHR implementation). You can see what I mean in the following video that shows DNS combined with a Microsoft Word macro automating ICD-9 look up (as it can with any other codes).



    And, click here for a video that shows DNS used to dictate a patient history in PatientOS, a free, open source (GPL) healthcare information system (starting at about one minute into this 10 minute demonstration). Note: After watching the video, click the "Back" button of your browser to return to this page.



    The figure above shows a very simple EMR system for speech-to-text form generation. Virus attacks (control) of Word itself, as opposed to attacks (control) of its macros, wireless (802.11) breaches, and the like are not considered.

    Macros, small programs that run within the application, are of special interest because they can add functionality -- such as laying out a form or, as shown in the video above, automating code look up -- that make the creation of voice-generated EMR forms efficient.

    The figure shows a worst case scenario: a speech-to-text process starts with the user speaking into a wireless microphone and finishes with the creation of a Word document. But, Bluetooth (the technology used between the wireless headset and the laptop running speech recognition software) and the macros (VBA) used by the word processor are compromised.

    Normally, this implementation is safe, but you should check to assure that it is in your organization.

    Bluetooth headset - dongle packages like the one shown in the figure are usually factory paired to each other and safe. However, if you have purchased them separately, or if you wish to use a replacement headset with your existing dongle, you must pair the units. For this, you could use an application like Logitech SetPoint -- one of many -- whose dialogs are shown in the slide show below.

    I've laid out these dialogs not as a tutorial but as a reference for you to use as you watch the video that's located immediately above the slide show. In the video, a stealth connection is established between a Bluetooth headset and a hacker standing out of site. The video also shows this task being accomplished using text commands entered in a Linux terminal. The SetPoint dialogs provide a more user-friendly way to enter the same commands: via a Windows GUI.

    Neither the video nor the slide show note that, under special conditions, even when a Bluetooth device is not discoverable, a hacker may manage to discover it. Click here for more information on this topic. Note: After visiting the site, click the "Back" button of your browser to return to this page.

    The majority of attacks that succeed are simply let through by us users. So, you might consider keeping your device’s Bluetooth turned off or hidden if it isn’t needed. And, never accept any incoming connection requests you don’t recognise.






    Of course, you can bypass any and all security risks associated with Bluetooth technology simply by using a wired headset for the creation of your EMR.

    Once speech has been translated into Word text, it's accessible by VBA, Microsoft's built-in scripting language. Unfortunately, VBA scripts are prone to viruses.

    Click here for a discussion -- one of many -- on macro virus detection. As you will read, this is a complicated business. So, if you're not afraid of being accused of throwing the baby out with the bathwater, you could always disable scripting commands in order to block VBA viruses, by using the Word dialog shown in the next figure. There may be, however, compelling reasons for you not to take this step.



    Bottom line: Modern information technology is employed to deliver better healthcare at lower cost. However, it can sometimes be responsible for bad outcomes. It's up to you assure that IT serves its intended purpose.

    You can view this post as the ranting of a doomsayer or simply a reality check. Your call! For the sake of full disclosure, I should add that I use Bluetooth technology, Word macros, and even eat junk food occasionally.

    Anecdotes

    After DNS 10 Medical was released, I installed it on a fairly high end PC running the 32-bit version of Windows Vista, put on the wire headset that came in the box and started speaking before I had read any of the manuals or knew any of the suggested first steps.

    I didn't check my audio settings:

    (1) Correct positioning of microphone
    (2) Microphone volume check
    (3) Microphone and sound system quality check


    And, I skipped the suggested general training session.
    And, I skipped using the vocabulary optimizer.
    And, I didn't move the Speed vs. Accuracy Slider away from its midway position


    I then read out loud a paragraph from the product description literature and watched my every spoken word - save one - appear correctly in Microsoft Word. That one word, oddly enough, was "Plantronics," the manufacturer of the headset that came with DNS 10. A subsequent session of only a few seconds with the DNS voice trainer corrected this result.

    Finally, using only the General Medical vocabulary, i.e., not the DNS vocabulary for one of the medical specialties, I read from the opening paragraph of a recent New England Journal of Medicine article. DNS 10 Medical produced the text with no errors whatsoever.




    32- and 64-bit versions of Dragon NaturallySpeaking

    Recently, 64-bit PCs have been increasingly introduced to the mainstream personal computer arena, previously dominated by 32-bit systems. (In fact, the Microsoft Vista 64-bit operating system now ships on almost 1/3 of all new computers at some retailers.)

    The benefit for PC users is that 64-bit versions of the Windows operating system can utilize more memory than 32-bit versions of Windows. In addition to overall program performance, 64-bit PCs can offer added responsiveness when running a lot of applications at the same time.

    This higher level of performance is exploited by a new 64-bit version of DNS.