Showing posts with label electronic health record. Show all posts
Showing posts with label electronic health record. Show all posts

Tuesday, July 13, 2010

Epocrates Mobile Electronic Health Record

Health care delivery is now moving away from a specific location and into a virtual care space, where patient medical records and real-time clinical data will reside.

There has also been a revolution in access to clinical reference material, and physicians and other care providers are moving core scientific knowledge from books to apps. Today’s doctors are no longer what they can memorize.

Throughout this blog, I've been discussing many of the components of Electronic Health Record (EHR) systems that will likely be used in the larger systems installed throughout entire hospitals and regions. However, 50 percent of physicians in the US work in small or solo practices.

The Epocrates EHR is specifically targeting the solo practitioner and the small physician groups, which have different needs from the larger enterprise care facilities that so many EHR providers are pursuing. To that end, Epocrates says that it has "teamed up with a very well known” but still undisclosed practice manager partner, whose software will be integrated into the Epocrates EHR for calendaring, scheduling, appointments, billing and more.

The as-yet-not-released Epocrates EHR app will include the company's drug and safety content and will, they say, meet “meaningful use” and HIPAA compliance requirements.

There are offerings from other vendors such as Microsoft and Symantec too, but I've decided to look at Epocrates Mobile EHR because Epocrates was the first company to introduce a medical app for the iPhone. Furthermore, as seen in the image below, their app is now available for many of the popular hand-held smart devices.











Their fully functioning mobile EHR app will work both when connected and disconnected. It’s not enough to just have a mobile EHR, of course, and it is also a fully featured, web-enabled desktop application, too.

The mobile and desktop versions may have the same functionalities, but the different form factors will likely lead to certain applications being favored on each.

There is a functional parity between their mobile and web interface. The information will be delivered differently and the iPhone version will be used for some use cases more often than the desktop version and vice versa. These two platforms are complementary, so Epocrates is not necessarily "leading" with mobile.

Unlike some mobile “portals” to EHR systems, Epocrates offering is a native app with patient data stored in it.

One differentiator between the Epocrates mobile EHR app and some others is that theirs will be a native app and it will store patient data on the device. Users will interact with the EHR differently from a mobile device vs. a desktop client. The iPhone interface is not ideal for text entry, so they are looking for other ways to get information into the device. The iPhone interface will be used more for things like dictation, while the desktop interface won’t be used for that as much. From a task perspective, though, they are not looking to hobble the handheld interface in any way.

Click here to see new apps from Epocrates

Click here to see the Dragon speech-to-text application on a hand-held device

Epocrates is launching an EHR offering now because of the increase in EHR adoption because of the ARRA deadlines for stimulus fund incentives payments. These external deadlines are encouraging physicians to adopt EHR, making it an ideal time to enter the market.

There are also drivers from the technology perspective as well. It’s a good time to enter the market with a mobile EHR because more clinics have a high penetration of smartphone users. Also, 3G wireless networks now have higher bandwidth – enough to support these kinds of applications. Physicians rarely take note of [mobile] Internet connectivity issues anymore. Note: I've also talked a little about the less-ubiquitous 4G (WiMax) networks in earlier posts.

Epocrates plans to integrate the features of the iPhone, such as the camera, as well as dictation directly into the app, an interesting feature especially in light of the recent announcement by Nuance that they will be shipping a medical transcription application for the iPhone.

Epocrates will also utilize the iPhone’s Push Notification Service to alert doctors of important or timely information (and hopefully not overuse it). Given Epocrates’ depth of knowledge of pharmaceutical formularies, e-prescribing will be built in.

Although the mobile application will synchronize with the web application, it will continue working even when there is no internet connection. Data will be stored on the handheld device in a secure, encrypted manner and synchronize when a connection is available, a real issue for hospitals where there are many “dead” zones. And, there will be condition-based templates for easy entry of clinical information.

There will also be integration with a revenue-cycle platform so physicians can charge and submit codes, through a partnership with a “known” company. Epocrates anticipates they will achieve Certification Commission for Health Information Technology (CCHIT) certification by the time of release. The EHR will be delivered as a software-as-a-service (SAAS) model, meaning the physician will effectively lease, not purchase it.

This could be an attractive low-cost product for solo or small group physicians who do not have complex office staff EHR integration needs. In particular, for the physician who already uses their smart phone for many work activities, the potentially painless transition to using it as the primary interface into their office EHR may be very appealing.

Stay tuned.

Click here to see Epocrates executives at HIMSS 2010

Click here to see Andy Wiesenethal, Kaiser Permanente at HIMSS 2010

As an aside, I'd like to note that when Epocrates Online can be accessed with a browser on which Google's (or other) translation app has been installed, as shown in the image below.

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

Saturday, August 1, 2009

Metcalfe's law vis-à-vis the value of semantic interoperability

A new economic model

Metcalfe's law states that the value of a network is proportional to the square of the number of connected users of the system (n**2).

Metcalfe's law characterizes many of the network effects of communication technologies and networks such as the Internet, social networking, and the World Wide Web. It is related to the fact that the number of unique connections in a network of a number of nodes (n) can be expressed mathematically as the number n(n − 1)/2, which is proportional to n**2 asymptotically.



The law has often been illustrated using the example of fax machines: a single fax machine is useless, but the value of every fax machine increases with the total number of fax machines in the network, because the total number of people with whom each user may send and receive documents increases.

Metcalfe's law is more of a heuristic or metaphor than an iron-clad empirical rule. In addition to the difficulty of quantifying the "value" of a network, the mathematical justification measures only the potential number of contacts, i.e., the technological side of a network. However the social utility of a network depends upon the number of nodes in contact. For instance, if Chinese and non-Chinese users don't understand each other, the utility of a network of users that speak the other language is near zero, and the law has to be calculated for the two sub-networks separately.

When considering electronic health record (EHR) interoperability, two nodes are in contact in a meaningful way if the nodes themselves, not just human beings sitting at those nodes, can understand the content of a message from the other node in an unambiguous way. In other words, semantic interoperability is what counts.

Apropos of EHR, Rod Beckstrom, the recently appointed president of the Internet Corporation for Assigned Names and Numbers (Icann), has used his address to the Black Hat USA 2009 conference to propose a new economic model for valuing computer networks and the internet.

"Who cares how many nodes there are?" Beckstrom said. "If you look at a value of the network, focus on the transactions. The value of the network equals the net value added to each user's transactions, summed for all users."

For example, some networks grow the number of users but become less valuable since the value of their transactions is so small.

Microsoft chairman Bill Gates dropping his Facebook account in July was a case in point, Beckstrom said. The number of 'friends' became so great that the network lost its value.

Friday, July 17, 2009

Electronic Health Record Interoperability: Specifications, Standards, and Working Groups

{Prelude to upcoming post - semantic interoperability}

The American Recovery and Reinvestment Act of 2009 (ARRA) states that the
HIT Policy Committee shall make recommendations on standards and implementation specifications, among other tasks.

The
Healthcare Information Technology Standards Panel (HITSP) EHR-Centric Interoperability Specification consolidates all information exchanges that involve an Electronic Health Record (EHR) System within any of the thirteen HITSP Interoperability Specifications existing as of February 13, 2009, the enactment date of the American Recovery and Reinvestment Act (ARRA).

Reading these two statements and others like them requires an understanding of terms such as

*
recommendation
* specification
*
standard, and
*
working group

Each of these bullets is linked to its Wikipedia entry.



Given that many of the readers of this blog (from 42 countries so far) are interested in the information technology aspects of The American Recovery and Reinvestment Act , electronic health record interoperability and the like, it may be easier for them if I elaborate on the four terms listed above by using the example of cascading style sheets (CSS), a simple language that allows you to declare how documents are displayed by Web browsers. By so doing, I’ll be introducing additional expressions with which these members of the IT community are already familiar.

The Cascading Style Sheets language was created through a collaborative effort between Web developers and browser programmers under the auspices of the
World Wide Web Consortium (W3C for short).

The W3C is an international industry group that comprises over 500 companies, research institutions, and Web development organizations that issues technical specifications for Web languages and protocols.

W3C specifications are called "recommendations" because the W3C is technically not a standards-issuing organization, but in practice this is usually an issue of semantics.

Recommendations are taken as defining a standard form of a Web language, and they are used by Web developers, software tools creators, browser programmers, and others as a blueprint for computer communication over the Web. Examples of W3C Recommendations include Hypertext Markup Language (HTML) and Extensible Markup Language (XML).

The CSS Specifications

The W3C Recommendations issued by the Cascading Style Sheet working group compose the official specification for the CSS language. The CSS working group consists of a number of experts in Web development, graphic design, and software programming, representing a number of companies, who all work together to establish a common styling language for the Web.

CSS Level 1

The Cascading Style Sheets Level 1 (sometimes called CSS1 for short) was officially issued as a W3C Recommendation in December 1996. The URL for this specification is
http://www.w3.org/TR/REC-CSS1.

If you try to read the W3C Recommendation for CSS1, you may end up confused. That's because W3C documents aren't written as a general introduction to a subject but rather as precise language definitions for software developers. Most W3C Recommendations are quite opaque to most normal people, although the CSS1 specification isn't too bad compared with some. Being able to refer to the official specification is quite useful, though.

Optional note for programmers - Classes and IDs

In addition to setting styles based on HTML elements, CSS allows for rules based on two optional attributes in HTML: class and id. Each of these can serve as the selector part of a CSS rule and can be set on any visible HTML tag.

The div and span elements really come into their own with class and id selectors. Through the use of class and id attributes, div or span tags can be made to have nearly any effect and presentation, which is often good but sometimes bad. Care must be taken to avoid using class or id selectors that you're not ignoring more appropriate markup, which has understood semantics. In other words, a div with a class of bldtxt has no specific meaning in the context of HTML, but a strong tag definitely does. Before using div or span, consider if another tag would make more sense.

The mention above of the word "semantics" is meant to be a segue to the subject of a later post, semantic interoperability.



Tuesday, June 30, 2009

Electronic Health Records (EHR) & the Need for Cross-Browser Compatibility

Cross-Browser Problems/Solutions

Back when I did software development work (secure, data-intensive, interactive Web applications -- .NET and J2EE), I would finish debugging a project on my PC and then deploy the app to a test server from which it would be downloaded by every manner of user. Most of them were running Internet Explorer, some Firefox or Safari, and a few were running some other browser. The problem was that some of these users, users not using the same browser as me, discovered that the app didn't render as expected.

Today, unfortunately, writing dynamic web applications is still a tedious and error-prone process; some developers spend up to 75% of their time working around subtle incompatibilities between web browsers and platforms.

With the widespread adoption of Electronic Health Records (EHR) imminent, the likelihood that a given Web app will be downloaded by someone using a browser other than the one(s) used to develop and test the app will only increase.

But help may be on the way: cross browser Web development may be getting easier and more efficient with the upcoming version of Google Web Toolkit (GWT) version 2. Google claims that GWT applications will automatically support Internet Explorer, Firefox, Mozilla, Safari, and Opera with no browser detection or special-casing within your code in most cases.

Shown in the figure below is the GWT implementation of an app that would not be expected to render exactly the same in Internet Explorer and Firefox.

Note: A few examples of cross-browser incompatibility appear in the figures of my 2005 article ASP.NET & Multiplatform Environments (a link to it is provided in the bibliography at the bottom of this blog).



GWT is an interesting platform that allows you to write Java code that automatically gets converted into JavaScript by the GWT compiler. This allows for a simple way to create AJAX apps, using Java. Google also created a plug-in for Eclipse to make debugging and deploying very easy.

With Ajax, Web applications can retrieve data from the server asynchronously in the background without interfering with the display and behavior of the existing page. The use of Ajax has led to better quality of Web services [see my June 28 post] due to the asynchronous mode.

The core language of the World Wide Web


Until recently, most simple browser applications were created in HTML 4.1, which could be enhanced with JavaScript and CSS. For Web applications that were as rich as desktop applications, developers had to embed Adobe Flash or, more recently, Microsoft Silverlight apps in their HTML code. But, a new version of HTML, HTML 5, which is the fifth major revision of the core language of the World Wide Web, is bringing this same rich functionality to the browser without the need for Flash or Silverlight.

A good summary of the major features of HTML 5 is in Tim O'Reilly's blog post about it.

http://radar.oreilly.com/2009/05/google-bets-big-on-html-5.html

However, there is still a problem. Currently HTML 5 compliant browsers are only 60% of the market. Quite a few enterprises are still on Internet Explorer 6. So, Flash, which has the distinct advantage of working on older browsers and has about a 95% market penetration, is still very popular. However, some expect that HTML 5 will be as popular as Flash by 2011.

Even though HTML 5 is not yet a finished standard, most of it is already supported in major browsers: Firefox 3, Internet Explorer 8, and Safari 4. This means that you can create a HTML 5 application right now!

Note: Flex, like ActiveX, Silverlight, and Java Applets before them are, in a sense, replacements for the browser. But, each replaces the web browser in a proprietary way.

HTML 5 is right around the corner

While the entire HTML 5 standard is years or more from adoption, there are many of its powerful features available in browsers today. In fact, five key next-generation features are already available in the latest (sometimes experimental) browser builds from Firefox, Opera, Safari, and Google Chrome. Microsoft has announced that it will support HTML 5, but as Vic Gundotra, VP of Engineering at Google has noted, "We eagerly await evidence of that."

GWT meets HTML 5

Google Web Toolkit is a really good way to "easily" design a flashy HTML/CSS/JavaScript application that works as expected across different browsers and operating systems.


{click for larger view}

Sunday, June 28, 2009

Technical Interoperability of Disparate Systems - An Electronic Health Record (EHR)-Centric System Implemented with a Service-Oriented Architecture


The independent organizations (a.k.a. silos) shown in Figure 1 typically implement their business processes on different computer systems (Unix, Windows, mainframes), on different platforms (J2EE, .NET) and with different vocabularies. Yet, they all need to communicate in a way that serves, in this case, a trauma victim at the time of his or her emergency, researchers who will later study cohorts of this trauma victim, and sundry others (most of whom are not shown in the simplified model).

This post will discuss an Electronic Health Record (EHR)-centric system implemented with a Service-Oriented Architecture (SOA) -- the business industry’s de facto standard for interoperability. The functions of this system are data collection, management and distribution for both the immediate situation and long term health care experiences.

I’ll address some of the challenges (and opportunities) of technical interoperability, holding off ‘til later posts any discussion of semantic interoperability.

Note: This rather lengthy post is not and is not meant to be a palimpsest on SOA. But, I have included a number of references (links to references) for anyone looking for a more detailed account of this topic.

Figure 1

Figure 2 shows a traditional implementation of the system shown in the use case drawn in Figure 1. When a change -- virtually any change -- is made in one part of this interconnected system, the overall system usually stops working, until system-wide adjustments are made. In short, the figure below shows a system that’s “hard wired.”

Note: For simplicity, these figures and this discussion omit a number of real-world details: for example, the voice communication often employed by police and EMS teams.


Figure 2

To remedy this problem, a new architecture, that of Service-Oriented Architecture (SOA), was devised. An SOA implementation of the system shown in the use case is outlined in Figure 3. At first glance, the SOA-based system might seem more complicated than the system shown in Figure 2. But, as the following discussion will attempt to show, it isn’t.



Figure 3

Note: The major part of this post will be based on a Web services implementation of SOA. However, before concluding this post, I’ll address the oft-heard view that SOA is now “dead.” SOA is indeed alive and kicking in many organizations.

The system in Figure 2, if fleshed out, would move toward becoming the fully connected system shown below (in practice, very few systems are fully connected). In such a system of computer applications, when one node is changed, all other nodes that connect to it would need a new interface to the changed node.



As shown, in a fully connected network with n nodes, there are n x (n-1) / 2 direct paths. That means 15 connections for 6 nodes, 45 connections for 10 nodes, etc.

In contrast, each node in the system in Figure 3 has only one connection – that to a bus, as represented in the figure below.



Service-Oriented Architecture

SOA relies on services exposing their functionality via interfaces that other applications and services can read to understand how to utilize those services.

This style of architecture promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to – and usage of – existing IT (legacy) assets.

Designers can implement SOA using a wide range of technologies, including SOAP, REST, DCOM, CORBA, or Web Services. (I gave a brief overview of DCOM, CORBA and Web Services in my June 16 post and will discuss REST below.) The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.


Albeit in the distant past, I’ve used the Oracle SOA Suite to federate a unified system out of the disparate systems shown in the figures.


This suite, which includes JDeveloper, a robust Java IDE, is by no means the only solution; there are others, both proprietary and open source! For example,

Proprietary:
http://i.zdnet.com/whitepapers/cape_clear_Principles_of_BPEL.pdf

Open source:
http://orchestra.ow2.org/xwiki/bin/view/Main/

However, the Oracle SOA Suite is a complete set of service infrastructure components for creating, deploying, and managing services. It enables services to be created, managed, and orchestrated into composite applications and business processes. Additionally, you can adopt it incrementally on a project by project basis and still benefit from the common security, management, deployment architecture, and development tools that you get out of the box.

This Suite is a standards-based technology suite that consists of the following:

* Oracle BPEL Process Manager to orchestrate services into business processes
* ESB to connect existing IT systems and business partners as a set of services
* Oracle Business Rules for dynamic decisions at run time that can be managed by business users or business analysts
* Oracle Application Server Integration Business Activity Monitoring to monitor services and disparate events and provide real-time visibility into the state of the enterprise, business processes, people, and systems.
* Oracle Web Services Manager to secure and manage authentication, authorization, and encryption policies on services that is separate from your service logic
* UDDI registry to discover and manage the life cycle of Web services.
* Oracle Application Server that provides a complete Java 2, Enterprise Edition (J2EE) environment for your J2EE applications.

For an overview of the soon-to-be-released Version 11, see

http://www.oracle.com/technology/products/ias/bpel/techpreview/2008-05-01-whats-new-in-oracle-soa-suite-tp4.pdf

Business Process Execution Language (BPEL)

One of the key standards accelerating the adoption of SOA is Business Process Execution Language (BPEL) for Web Services. BPEL enables organizations to automate their business processes by orchestrating services (thus enabling developers to build end-to-end business processes spanning applications, systems, and people in a standard way). Existing functionality is exposed as services. New applications are composed using services. Services are reused across different applications. Services everywhere! For an account of Orchestration versus Choreography, see
http://www.oracle.com/technology/pub/articles/matjaz_bpel1.html

BPEL has emerged as the standard for process orchestration enabling you to build end-to-end business processes spanning applications, systems, and people in a standard way.

In the next figure, I show two pallets of drag-and-drop components available in version 10.3 of the SOA Suite for the development of a BPEL process. Version 11 will be availability shortly.


Introduction to the JDeveloper BPEL Designer

http://download-west.oracle.com/docs/cd/B31017_01/core.1013/b28938/design.htm#CHDIJCGH

Enterprise Service Bus

An Enterprise Service Bus (ESB) is an architectural pattern, not a software product. Different software products can form an ESB. In some cases, companies use multiple products in different areas, leveraging specific functionality to meet their unique requirements. These different products can be federated together as the realization of the ESB pattern.




In the next figure, I show two pallets of drag-and-drop components available in version 10.3 of the SOA Suite for the development of an ESB. As I mentioned earlier, Version 11 will be availability shortly.




Introduction to the JDeveloper ESB Designer

http://download-west.oracle.com/docs/cd/B31017_01/core.1013/b28938/design.htm#CHDIBCCC

Figure 3 introduced Business Activity Monitoring (BAM) and Business Rules to the architecture

Business Activity Monitoring – BAM satisfies a growing need to enable health care executives, and more specifically operations managers, to improve their decision-making processes by first getting a real time view of the business events occurring in their enterprise, and second using the derived intelligence to analyze and improve the efficiency of their business processes.

Understanding Business Activity Monitoring in Oracle SOA Suite
http://www.packtpub.com/article/business-activity-monitoring-in-oracle-soa-suite

Business Rules – Business Rules is one of the newer technologies (typically run from an application server) and is designed to make applications more agile. A business analyst can change business policies expressed as rules quickly and safely with little or no assistance from a programmer

Using Business Rules to Define Decision Points in Oracle SOA Suite

Part 1.
http://www.packtpub.com/article/business-rules-define-decision-points-oracle-soa-suite-part1

Part 2.
http://www.packtpub.com/article/business-rules-define-decision-points-oracle-soa-suite-part2

For detailed coverage of the Oracle Service Bus, BPEL Process Manager, Web Service Manager, Rules, Human Workflow, and Business Activity Monitoring. See

Oracle SOA Suite Developer's Guide
http://www.packtpub.com/developers-guide-for-oracle-soa-suite-10gr3/book

and

Getting Started With Oracle SOA Suite 11g R1 – A Hands-On Tutorial
http://www.packtpub.com/getting-started-with-oracle-soa-suite-11g-r1/book

When designing an SOA solution, it's not always clear whether you should use a Web services BPEL process or an ESB mediation flow (or both).

http://www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html

Building Event-Driven Architecture with an Enterprise Service Bus

http://www.oracle.com/technology/pub/articles/jellema-esb.html

Software frameworks

You should keep in mind that interoperability issues between platforms can arise when switching from one protocol to another and one software framework to another. Some examples include SOAP, REST, the .Net Framework, Enterprise Java Beans (EJB), and Java Messaging Service (JMS).

.Net Web services running over HTTP can be called in three different ways: HTTP GET operation, HTTP POST operation, and SOAP. The GET and POST operations are useful if you need to call a Web Service quickly and no SOAP client is readily available. You can use REST to perform GET, POST, PUT, and DELETE operations over the HTTP in a Perl script. In this script, you can specify SQL queries and simple message queues.

For a discussion of SOAP/REST in the .NET (Visual Studio 2008 SP1) ecosystem, see

http://www.pluralsight.com/community/blogs/scottallen/archive/2008/08/11/visual-studio-sp1-and-the-metification-of-rest.aspx

and

http://msdn.microsoft.com/en-us/library/dd203052.aspx

Often, services within an organization’s firewall are REST-based, while 3rd party partners use a mix of SOAP and HTTPS protocols to access their public services. By using REST for internal services, organizations are avoiding some of the overhead that the WS-* standards introduce.

If the SOAP client is available, here's how to make a simple choice between REST and SOAP. If the application is resource-based, choose REST. If the application is activity-based, opt for SOAP. Under REST, a client might request that several operations be performed on a series of resources over the HTTP. For SOAP-based requests, only one invoke operation is needed for each activity-oriented service that a client might request be performed.

REST requests do not depend on WSDL as SOAP requests do. Yet, REST and SOAP can co-exist as requests from a composite Web service application to an external Web service.

When to use REST based web services?

http://oracled.wordpress.com/2009/03/11/when-to-use-rest-based-web-services/




When Web services are outside the control of the organization (as in the figures at the top of this post), you need to ensure that they can interoperate externally with one another with respect to shared semantics and contractual obligations. Semantic misunderstandings and contractual loopholes contribute to interoperability problems between external enterprise Web services. Future posts will focus on these aspects of interoperability.

For presentations that includes the pros and cons of different protocols (SOAP and HTTP) and software frameworks (.NET and J2EE), see

http://www.esri.com/events/devsummit/pdfs/keynote_chappell.pdf

and

http://www.esri.com/events/devsummit/sessions/keynote.html

The oft-heard view that SOA is now “dead”

Once thought to be the savior of IT, SOA instead turned into a great failed experiment -- at least for many organizations. SOA was supposed to reduce costs and increase agility on a massive scale. In many situations, however, SOA has failed to deliver its promised benefits.

Yet, although SOA is understandably purported to be dead by many, the requirement for a service-oriented architecture is stronger than ever.

Adopting SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change.

Note: As of 2008, increasing numbers of third-party software companies offer software services for a fee. In the future, SOA systems may consist of such third-party services combined with others created in-house.

More on this can be found in “WOA: Putting the Web Back in Web Services.”

http://blogs.gartner.com/nick_gall/2008/11/19/woa-putting-the-web-back-in-web-services/

Also, here’s a link to one of my earlier articles on SOA

“The Economic, Cultural and Governance Issues of SOA”

http://www.cioupdate.com/reports/article.php/11050_3652091_1/The-Economic-Cultural-and-Governance-Issues-of-SOA.htm

Tuesday, June 16, 2009

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


As the title suggests, this post, the first in a series of continuations of my June 13 post, is about the technical aspects of interoperability. For your convenience, I’ve copied the figure below from the earlier post.




The word "interoperability" means different things to different people. To DBAs, for example, the ability of SQL Server, Oracle and DB2 to recognize each other’s commands is a sign of the interoperability of these databases. In the current post, however, I'll focus primarily on a distributed computing model that is capable of cross-platform and cross-programming language interoperability, Web services. In the process, I'll compare Web services with a couple of its predecessors, CORBA and DCOM, which are still being used widely.

Why CORBA and DCOM success is limited


Although CORBA and DCOM have been implemented on various platforms, the reality is that any solution built on these protocols will be dependent on a single vendor's implementation. Thus, if one were to develop a DCOM application, all participating nodes in the distributed application would have to be running a flavor of Windows. In the case of CORBA, every node in the application environment would need to run the same ORB product. Now there are cases where CORBA ORBs from different vendors do interoperate. However, that interoperability generally does not extend into higher-level services such as security and transaction management. Furthermore, any vendor specific optimizations would be lost in this situation.

Both these protocols depend on a closely administered environment. The odds of two random computers being able to successfully make DCOM or IIOP calls out of the box are fairly low. In addition, programmers must deal with protocol unique message format rules for data alignment and data types. DCOM and CORBA are both reasonable protocols for server-to-server communications. However, both they have severe weaknesses for client-to-server communications, especially when the client machines are scattered across the Internet.

CORBA overview

Common Object Requesting Broker Architecture (CORBA) provides standards-based infrastructure for interactions between distributed objects. It allows software components running on dissimilar hardware, hosted on different operating systems, and programmed in different programming languages to communicate, collaborate, and perform productive work over a network.

A CORBA system accomplishes this magical task by confining the interaction between objects to well-defined interfaces. To use the service of a distributed object, you must interact with it through the interface. How the interface is implemented -- or even where it is implemented -- is not known and doesn't have to be known by the client. The figure below illustrates the workings of a typical CORBA system.

Object interactions in CORBA





Achieving location transparency


In this figure, the client code makes use of a server object through its interface. In fact, the interface is implemented by a stub object that is local to the client. As far as the client can tell, it's only interacting with the local stub object. Under the hood, the stub object implements the same interface as the remote server object. When the client invokes methods on the interface, the stub object forwards the call to a CORBA component called the Object Request Broker (ORB). The calling code in the client does not have to know that the call is actually going through a stub.

DCOM overview

Distributed Component Object Model (DCOM) is a Microsoft proprietary technology for software components distributed across several networked computers to communicate with each other. However, it has been deprecated in favor of the Microsoft .NET Framework, which includes support for Web services.

Internet poses problems for CORBA and DCOM

DCOM was a major competitor to CORBA. Proponents of both of these technologies saw them as one day becoming the model for code and service-reuse over the Internet. However, the difficulties involved in getting either of these technologies to work over Internet firewalls, and on unknown and insecure machines, meant that normal HTTP requests in combination with web browsers won out over both of them.

Web services overview

Web services specifications such as SOAP, WSDL, and the WS-* family are currently the leading distributed computing standards for interfacing, interoperability, and quality of service policies. Web services are often called "CORBA for the Web" because of their many derivative concepts and ideas.

There are several ways to think about Web services when building applications. At the most basic level it is an advanced communications protocol family allowing applications to talk to each other. This level has progressed quite significantly over the past few years with many tools (e.g., Oracle’s JDeveloper and Microsoft's Visual Studio) that allow software developers to write interacting Web services and build complex applications. This level is often characterized by direct one-on-one interactions between services or relatively few services interacting with each other.

SOA overview

However, just using Web services as a communications protocol belies its true power, that of the service-oriented architecture (SOA). The SOA describes an entire system of services dynamically looking around for each other, getting together to perform some application, and recombining in many ways. This model encourages the reuse of technology and software that evolves the way applications are designed, developed and put to use. It brings the world of distributed computing to a closer reality. At this level software developers need to think of the SOA model and design their distributed application across the model. This level is characterized by the use of technologies to allow distributed communications of services such as the use of an Enterprise Service Bus (ESB), which is a common distribution network for services to work with. More on ESB in an upcoming post.

Finally, the highest level is to look at this SOA model and the many component services as building blocks that can be assembled in whole sections into full applications instead of the traditional method of writing line after line of code. By examining the connecting interfaces, we can build whole applications without ever really writing code. For that matter direct code may even get in the way since the services may be written in numerous different languages and platforms. The blocks can be put together into a workflow of operations that define how the application performs, and other tools can be used to monitor the effectives of the workflow at each service or group of services. At this level, developers can put away the use of regular programming languages and work in a Model-Driven Architecture that helps them to build applications more accurately to a design. More on workflow in an upcoming post.

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.