Anticlue

SOA EMR

Providence Health System used a service-oriented architecture to summarize information from 10 oracle dbs that support the clinical, laboratory and ambulatory care record systems. This allows them to create an emr from disparate datasources in under 3 seconds. By exploiting web-services, Providence expects to save more than $1 million annually, improve patient care, and save lives.

Find the complete article here.

Program to an interface not an implementation.

One of the tenets of the GOF is to program to an interface, not an implementation.

So what does that mean? An object's interface is the collection of methods that can be called. If you exploit a creational pattern, you will be using an interface to a an abstract class to instantiate a concrete class, instead of directly instantiate the implementation of the concrete class.

Daylight Savings Time

Just an idea for Daylight Savings Time upcoming this weekend. It might be a good idea to get all of the interfacing system owners together to review the needed events.

Also writing down the outcome may help in upcoming years for springing forward.

Abstract and Concrete classes

Before one can really get into patterns, and pattern analysis, its a good idea to understand the difference between concrete and abstract classes.

This is a basic concept of OO design and programming. Let's say you have alot of similar classes. For instance, you have a class for database administrators, client server programmers, web developers, and network specialists. If one was to group all of these under one category, they are all technicians. A web developer is a technician.

This grouping of related classes is an abstraction. The class technician is an abstract class. There are many methods of all database administrators, client server programmers, web developers, and network specialists that can be generically referred to as a technician's method. For instance all should know how to do analysis. The individual database administrators, client server programmers, web developers, and network specialists all represent a concrete class. They are specific types of technicians, but each one is a technician. The is a relationship is commonly referred to as inheritance.

Implementing BizTalk Accelerator for HL7

Health-IT World has an interesting article on implementing BizTalk Accelerator for HL7. The overall speed of records processing has increased 25% from 8 seconds to 5 seconds per message.

What's really interesting is the spin that speed of messages is a valuable factor of interface engine evaluations. Its not even mentioned in this guide to accessing interface engines.

No More Grace Period for old ICD9 codes

Its time to say adios to the 90-day grace period for billing discontinued ICD9 diagnosis codes. According to this release, for the October grouper update this year providers will no longer have a 90-day grace period for billing discontinued ICD9 diagnosis codes.

Strategies for Pharmacy Integration

Medscape has a nice article on pharmacy integration techniques found here.

The article reviews the following four choices detailing the benefits and risks.

1.) an integrated all-in-one CPOE and pharmacy system
2.) a bidirectional interface between the pharmacy system and the CPOE medication-ordering system.
3.) a unidirectional interface between the CPOE and the pharmacy system.
4.) No interface between the CPOE and pharmacy system.

New Medicare Hipaa Claims Edits

Its coming, the new edits due to the coordination of benefits claims. Find the entire report here.

Trends in ED Utilization

National Hospital Ambulatory Medical Care Survey: 2002 Emergency Department Summary report was released on March 18th. The report identifies trends in ED utilization.

In summary, for the ten year period from 1992 - 2002 ED visits are up 23 percent from 89.8 million to 110.2 million visits annually, while hospitals with open available emergency departments are down 15 percent.

Classifying Design Patterns

In reviewing Design Patterns and following Data and Object Factory's Patterns I figured I'd share a classification of the GOF design patterns.

Model View Controller Pattern

The Model View Controller Pattern is comprised of three objects. The separation of the user interface and business logic is the most important benefit of this pattern.

The Model is a model of the business logic and data processing logic.

The View is the presentation or user interface. The main view may be a combination of several sections of a page, AKA composite views. For instance a view may contain many views, one for the header, body,navigation panel, and footer of a page

The Controller maintains the reactions to user input.

For more information take a look at the Java Blue Prints Model-View-Controller.

Standardized PC or Browser for the business

One of the strategic things to look for ahead of time in implementing a content management system is a standardize PC or at least browser set up for the business enterprise.

The reasoning behind this is that the organizations pc can be configured to only use internet explorer or netscape. One can prevent having to develop an application for a browser that is 8 years old, or even be considerate of that in the development. Also if one is looking at an enterprise CMS, you can be certain that the content owners, have the ability to use the tool. This applies to developing or installing any enterprise wide application.

Setting a standard browser configuration with the latest flash, central and adobe plugins would allow this functionality to happen. It may also be worthy of time to set up a review schedule of the standard configuration, and a mechanism to push an update to all workstations.

Interfacing to a previously non-interfaced system

As systems get replaced with newer improved systems, one should always be considerate if an ADT interface is a new feature to that system. The reason behind this is that a new ADT interface will update the unique patient identifier with the information from the enterprise master patient index. So if the numbers match, but the names don't match, then any paper records previously associated with the replaced system won't match based on name. This is also true if the system being replaced didn't accept interfaces for merging patient information, A33 and A44 hl7 transactions.

Therefore it is a good idea in the project plan of the new system to add a stage early in the implementation to compare the system's patient index identifiers or medical record numbers to the enterprise master patient index. The compare should be based on whether the soundex difference of the names are different, the date of birth is different, and the sex is different between the two systems. Attempt to reconcile all differences in accordance with the MPI, if the newly added ancillary system believes its information is correct update the enterprise MPI, otherwise update the ancillary system and the paper associated with that ancillary system.

Types of Testing

Here is an attempt at a list of the various testing levels:

Concept Testing: Testing to see if the concept of the application is viable.
Functional Testing: Testing if the function that was changed/enhanced works as expected.
Unit Testing: Testing to see if the program still functions as anticipated based upon scenarios.
Data Migration Testing: If you are switching to a new system, this is a test to ensure the data from the old system migrates properly to the new system.
Integrated Testing: Testing to see if the application still functions as anticipated with other applications also based upon scenarios.
Stress Testing: Testing to ascertain the load an application can withstand
Regression Testing Testing to ensure that with the existing software, the newly added component doesn't have a negative impact. Normally scenarios are a good idea here.
Interoperability Testing: Two systems are being tested for the data passed between the systems. Again scenarios are ideal.
Usability Testing: How users interact with the application. Is it cumbersome or does it flow?
User acceptance Testing: The overall process satisfaction by the project sponsor and customers.

New Technology Evaluations

New Technology comes into play very often, but there are risks for implementing that new technology and questions that need to be addressed to help aid the decision of whether to jump in or wait a bit.

First consider the core capabilities of the new technology. Technologists should be able to convey the essential capabilities of the technology to business people and customers.

Next, determine how the technology be might be applied within an organization.

Then evaluate the impact of the technology. What opportunities will applying this technology create? Would these opportunities reflect significant or fundamental changes in the organization for business and technology.

What have early uses of this new technology by others taught us? What are the benefits of being an early adopter to the organization? If we are not early adopters, what have other early adopters experienced. Are there some types of uses that are more successful than others? What issues have been encountered? To what degree are the disappointments the result of inexperience, inferior implementations of the technology or technology immaturity rather than flaws in the technology concept.

Given the above, how should your type of organization pursue the technology? How should it be incorporated into the organization's strategy?

Interface and Interaction Design

Dartmouth has a nice list of links for Interface and Interaction found here.

Its inclusive of Web Publishing Standards for anyone arriving at their own list.

Creating a sense of Urgency

A sense of urgency is an essential component to getting a project running and finished. What's interesting is the difference in senses of urgency.

Sometimes its impossible to create the sense of urgency for a party. One could even light matches under the other party's foot, and the party would casually gaze at their foot, and then slowly move it.

Sometimes it is far to easy to make someone excitable, the person remains in fire fighting mode moving from one sense of urgency to the next.

So I find what is essential is to create the sense of urgency and a sense of focus with time to focus on the issues at hand.

Risk and Project Plans

Project Plans are notoriously difficult to derive. It is difficult to predict all of the activities needed and the timeline of those activities. Consequentially, some activity is missed. Maybe not missed, but the inspiration for the idea of the crutial activity is not forthcoming at the time of the project plan. (Basically we didn't think of it then, because the muse wasn't around) This type of risk is commonly referred to as "white space risk." White space risk is that some required activities won't be identified in advance, leaving gaps in the project plan. The other common risk is "integration risk." Integration risk is that all of the pieces won't come back together to get the desired end result. As a part of a project there are many simultaneous activities, and sometimes the group is too large and needs to break apart to achieve the desired result. The risk arises that after breaking apart it may be difficult to bring the project back to a central focus and fit the disparate parts together.