Methodology to Deliver Service Oriented Architecture

By Sandrick Melbouci
From
DSOFT Technologies


A- Introduction
The technology has become an essential basic capabilities to create value proposition that distinguish the business in the marketplace.  Enterprises need to be able to bridge between the business and the technical world.  IT infrastructure should be aligned with business structure so that it can easily adapt to meet the business needs. One way of achieving this objective is through Service Oriented Architecture, SOA.
In Order to effectively deliver standardized services, it is recommended that organizations adopt methodology and processes specific to SOA consisting of structured analysis and design.
This article outlines a methodology to deliver service oriented architecture by applying service orientation principles to shape a solution in certain way with certain goals in mind to produce a blueprint of individually distributed unit.

Let's start with some definitions on SOA.

B- SOA Definitions

- What is Service-Oriented Architecture
SOA represents an architectural model that aims to enhance the agility and cost effectiveness of an enterprise while reducing the burden on IT and on the overall organization. It accomplishes this by positioning services as the primary mean by which the solution is represented.

- What is a Service
A service is unit of solution to which service orientation principle has been applied to a meaningful extent. It is the application of service-orientation principles that distinguishes a unit as a service compared to logic that may exist as an object or component.
A Service is comprised of a set of functions and capabilities related to its context.
Service Inventory is an independent standardized and governed collection of services.
A collection of inventories create a Domain Inventory.

- What are the Characteristics of SOA

1. Business Driven
2. Vendor Neutral
3. Enterprise Centric
4. Composition Centric

- Goals Of Service-Oriented Architecture
stating the common goals and benefits of SOA and these goals must be viewed within strategic context of the organization.

1. Increase Interoperability
2. Increased federation
3. Increase Vendor Diversification
4. Increase Business and technology Domain Alignment
5. Increased ROI
6. Increased Organizational Agility
7. Reduce IT burden

- Principles of Service Oriented Design

1. Standard Service Contract
   
2. Service Loose Coupling
3. Service Abstraction
4. Service Re-Usability
5. Service Autonomy
6. Service Statelessness
7. Service Discoverability
8. Service Composition

C- How to deliver SOA
Service Oriented Architecture is an architectural style. One of the methods to deliver SOA is explained in details by Thomas Erl in [1]. we will try to summarize this methodology that is simple and can also be integrated with TOGAF, FEA or any other Enterprise Architecture Framework. However, TOGAF failed to address SOA as an architecture style, some adjustments to TOGAF first four phases are required to deliver SOA.
We will explain the delivery of SOA through two main phases:
- Service Oriented Analysis
- Service Oriented Design

Before we start on the details of the analysis and design, let's address what approach to use:

-Delivery Approach
There are two delivery approaches, top down and bottom up. When starting  SOA within an organization with an objective of business - IT alignment, we recommend Top-Down approach.
We will list the pros and cons for each method.

• Top- Down

PROS
- Advocates the completion of an inventory analysis prior to the physical design, development, and delivery of services.
- Define blueprint Service Inventory
- Reduce the burden of governance
CONS
- Increase Of cost and Effort

• Bottom Up
  

PROS
- Tactically focused in that it makes the fulfilment of immediate business requirements a priority and the prime objective of the project
CONS
- Increase Cost of Maintenance, Refactoring and versioning
- Increase Effort of Governance
- Shorter life span

- Service-Oriented Analysis
Service Oriented Analysis represents the early stage in SOA and the first phase in service delivery cycle. It is a process that often begins with information gathering. This is accomplished iteratively and usually once for each business process.
This phase is accomplished jointly by business architects and technology architects to guarantee a higher degree of business-IT alignment. Iterations through analysis and modelling result in service candidates.
These Services are classified into Service Layers:

Service Entity (Product, Customer, Service, Invoice ...)
Service Task (Order Management, Business processing)
Service Utility (Non Business Centric, )

Analysis

• Perform Service Oriented Analysis

1. Define Analysis Scope to establish the boundary of the analysis
2. Identify Affected Systems
3. Perform Service Modelling

• Define Enterprise Business Model:

1. Define the scope
2. Accurately express the functions to be implemented

• Define Technology Architecture
  

1. Define initial architecture platform
2. Identify Architecture Constraints
3. Refine the architecture for each iteration
   

• Define Service Inventory BluePrint

1. Identify service inventory boundaries
2. Produce service candidates for this inventory

Within this step, the service conceptualization starts. It identifies service capability candidates. This phase also identifies service assembled into composed services. Basically, a business process is decomposed into granular functions and then services are assessed into groups of services that are specific or agnostic to the current business process. Below are the steps to perform this phase. This phase results with final version of capabilities of service candidates.

1. Decompose Business Process
2. Filter Unsuitable Steps
3. Identify Agnostic Service Candidates
4. Identify Process Specific Logic
5. Apply Service Orientation Principles
   
6. Identify Candidate for Service Composition
7. Analyze Processing Requirements
8. Identify Utility Service Capability Candidates
9. Define Utility Service Candidates
10. Apply Service Orientation
11. Revise Candidate Service Composition
12. Revise Capability Candidate Grouping

After applying the above steps, the service capability candidates will results in the following groupings.

1. Entity Services
2. Utility Services
3. Task Services
4. Orchestrated Task Services

Service Oriented Design
All the work put into the analysis phase resulted in set of service candidates that the design phase will take as input. Every service candidate is considered as starting point for service oriented design. It is recommended that the sequence of the design goes from the most independent service to the least independent:

• Design Entity Services
• Design Utility Services
• Design Task Services
• Design Orchestrated Services

During this phase, many considerations are taken into consideration to output a service contract in support to standards, principles and constraints. It is important to remember that a single service can provide a collection of capabilities. They are grouped together because they relate to a functional context established by the service.
When building the services as Web Services, this will require a definition of an XML schema to support the data type and structures to be exchanged. A WSDL is then built around the XML schema adjusted by the application of SOA principles and design patterns.
For Orchestrated services, it involves a composition of services and outputs WS-PBEL process definition.
Service-orientation places an unprecedented emphasis on reuse. I would like to quote Thomas Erl [1] book "By establishing a service inventory with a high percentage of reusable and agnostic services, we are now positioning those services as the primary means by which the solution logic they represent can and should be accessed. we make a very deliberate move away from the silos in which applications previously existed. Because we want to share reusable logic whenever possible, we automate existing, new, and augmented business processes through service composition. This results in a shift where more and more business requirements are fulfilled not by building or extending applications, but by simply composing existing services into new composition configurations. When compositions become more common, the traditional concept of an application or a system or a solution actually begins to fade, along with the silos that contain them".

- Design Challenges
Significant amount of services within the inventory can ultimately be comprised of agnostic services capable of fulfilling requirements for multiple potential service consumers. Although this can establish a highly normalized and streamlined architecture, it can also introduce an increased level of complexity for both the architecture as well as individual service designs. We will list few challenges that the design shall address and there are many other things that should be addressed but we will not address them in this article.
- Performance requirements & scalability
- Single point of failure resulting from excessive use of a service
- Service Contract Versioning
- Authentication
- How can service logic be positioned as enterprise resource
- Service Normalization / denormalization

 It is important  to position SOA as an architecture model that is Vendor neutral or even Technology neutral. By doing, we position the enterprise to pursue and leverage on-going technology advancements. Many  SOA design patterns help address these common issues and for each SOA design principle there are set of patterns that can be applied to successfully achieve the objectives of each principle.
In the beginning of this article we listed  a list of Service Orientation Principles, that should be applied to a business capability to shape it as Service. For each of these principles, we will apply a set of SOA design patterns to satisfy it.
We will list a set of design patterns that can be applied to satisfy each principle and produce individual logic units that can be qualified as services. The design pattern are shown in ITALIC. There are off course more design patterns and each project is different, I will list the design patterns we applied in our project at DSOFT SYSTEMS.

• Standard Service Contract: Services within the same inventory are in compliance with the same contract design standards. The following design patterns needs to be applied to get a Standard Service Contract: Canonical Protocol, Canonical Schema, Canonical Versioning, Concurrent Contract, Contract Centralization, Contract Normalization, Contract De normalization, Composition Autonomy, Agnostic capability, Proxy Capability

• Service Loose Coupling: Service Contract requires a low consumer coupling and themselves decoupled from their surrounding environment. The following dessign pattern help achieve this objective: Asynchronous queuing, Decoupled Contract, Data Format Transformation, Event Driven Messaging, Service Facade, Proxy Capability
  

• Service Abstraction: Information about service is published in the contract. The contract only contains essential information about the service. Utility Abstraction, Service Perimeter Guard, Service Refactoring,  Validation Abstraction.
  
• Service Re-Usability: Services contain agnostic logic and are positioned to be re-usable enterprise resources. These design patterns help achieve this requirement: Agnostic Capability and context, Capability Composition, Consurrent Contract, Logic and Rules Centralization,  Service Layers.

• Service Autonomy: Services shall run in their own environment and exercise a control over the underlying runtime execution environment. Canonical Resource, Distributed Capability, Service Normalization, Capability Recomposition.
  
• Service Statelessness: Services shall optimize resource consumption by deferring the management of state information.  Asynchronous queuing,  Atomic Service Transaction,Service Grid, Service Instance Routing.
  

• Service Discoverability: Services comes with metadata by which they are be discovered and interpreted. Canonical Expression, Metadata Centralization.
  

• Service Composition: Service composed of sequence of other service to form a new service. The following design patterns help to guide how to achieve this objective. Decomposed capability, Agnostic capability, Brokered Authentication, Capability Composition, Data Confidentiality, Dual Protocol, Reliable Messaging.
  

Standardization
It can be a straight-forward process to create these standards to support SOA, incorporating them into an IT culture already set in its ways can be demanding to say the least. The introduction of design standards implies a need to enforce them, SOA governance and its challenges addresses how governance of SOA.


How to choose the Technology
As we apply these design patterns to achieve SOA goals expressed in the beginning of this article, we started with a list of technologies that included weblogic/Aqualogic, Mule, Spring, JBoss Enterprises Suite ...etc. We proceeded by elimination and narrowed the choice of tools and technologies to a small set that can help us achieve our objective in optimized and timely manner. For instance, for service composition, there are many vendors offering what we wanted at different costs and we narrowed it to two: Mule ESB and JBOSS ESB. We did choose JBoss ESB because it is well integrated with JBPM and JBoss rules to implement the rules centralization and achieve a higher level of orchestration.
In conlusion, I would like to insist that the choice of technology should be based on the goals that must be achieved and dictated by the business which are:

1. Increase Interoperability
2. Increased federation
3. Increase Vendor Diversification
4. Increase Business and technology Domain Alignment
5. Increased ROI
6. Increased Organizational Agility
7. Reduce IT burden

By Sadi Melbouci

References:
[1] Thomas Erl, SOA Principles of Service Design,

SOA Governance and its challenges

By Sandrick Melbouci

From DSOFT Technologies

Introduction

Service Oriented Architecture enables enterprises to pursue business and technical strategies that promote the exposure of business functionality within and between enterprises in consistent, published, secure and contractual fashion.
However, Service Oriented Architecture is not a solution that comes in tidy box. It is more about new way of design, it is more about culture then it is about technology.
To ensure success of any SOA implementation, it is necessary to include some type of governance that define the policies and practices all services should follow.

Why some SOA implementations failed?

SOA Governance is probably the most talked and most delicate topics in SOA nowadays. About 5 to 6 years ago, many organizations approached SOA as implementing a web service. There was no attention to SOA Governance. This may be explained differently, but the situation reminds me of a practice of some IT managers – just get it to work and take a look at the design later. As we all know, any temporal fix becomes a permanent solution with consequences dealt with later at higher cost.
In one of the my consulting jobs, the organization thought that SOA was a new integration technology that will magically integrate all their existing assets. One of the managers asked me to start looking at the code to perform this funny integration. When I told him what SOA meant, he got a chock of his life. Without going into details, many organizations built hundreds of services/components and run into scalability, performance, manageability and integration problems.
One of the main reasons of this type of difficulties is that service-oriented, design, implementation was not governed at all or governed with traditional software development without any clues on service orientation [1] methodologies.
In this article, we will present SOA and its Governance policies to address these problems.

What is SOA?
Multiple definitions of SOA were presented in the literature, I will summarize some of them in here. SOA is architectural style who's goal is to achieve re-usability and loosely coupling paradigm among interacting agents. Within SOA, services are mechanisms by which needs and capabilities are brought together.
SOA operates in an integrated business-technical context as opposed to traditional business-IT separation.
Anne Thomas Manes from Burton Group said, “SOA is a style of systems architecture, not integration architecture. It’s about refactoring capabilities into services, not about integrating application silos”.

What is SOA Governance?
Governance is set of rules, policies and regulations under which an organization functions as well as the processes that ensure compliance. SOA governance refers to processes that ensures that services and applications are developed so that they are aligned with :

• Best practices
• Business requirements
• Laws
• SLAs
  

SOA Governance has two main component:

• Design Time Governance also called "SOA governance framework", captures information about the services and policies.
  
• Runtime Governance or sometimes called as "Service life cycle management", enforces the policies during the execution, management and service discovery.
  

The need for enterprise governance is business oriented to integrate business initiatives (supply chain, order management,...) with IT initiatives (EAI, Web service, ...). The companies needs to move from "develop now and integrate later" to "develop for integration". To ensure business continuity, reduce cost and complexity and limit corporate liability, the companies shall define the policies and procedures early in project life cycle to allow:

• Prevention of service proliferation and promote reuse
• Define Services with the right granularity
• Utilize a formal service description model with appropriate metadata
• Develop and implement best practices for interoperability
• Approach SOA on how it will be deployed and consumed
  
• Manage and monitor service health, performance and Quality of service
• Audit and measure compliance
  
• Define and manage Policies and contracts centrally
  
• Central registry-repository to describe all services and associated metadata
• Service mediation and discovery
  

Design Time Governance (Governance Framework)
There are mainly four phases to SOA governance framework: Plan, define, Enable and Measure.

• Plan Phase, the overall business and IT requirements are understood and documented
• Define Phase, the SOA governance approach is established based on corporate, enterprise and IT governance environments
• Deploy Phase, governance mechanisms are put into place, the organization is educated, and governance policies are deployed.
• Measure Phase, policy compliance and effectiveness are monitored and audited.

Runtime Governance Compliance (Service Lifecyle management)
The runtime governance encapsulate the phases to model, assemble and deploy. These 3 phases are broken into two separate facets:

• Service Development and Delivery Management
• Support Infrastructure and Management

Service Development and Delivery Management
Service Development and Delivery addresses the essential needs to govern the services development through the established governance framework. The areas of focus are mostly:

• Change and release management - What, When and by whom a service can be changed
• Requirements and Quality Management - Ensure services are developed in compliances with business requirements and compliance.
• Design and Construction - Ensure the best practices and design principles are appied for maximum.
• Asset reuse.
• Service Versioning
• Service Retirement
  
• Process Management - Continual auditing to make sure that the process is followed

Support Infrastructure and Management

Environment

• Distributed, cross-boundary services and access present security risks
• Rapid deployment and loose coupling of services
• Performance and prioritization of services

Service Security

• Need to manage identities and access control cross multiple platform, applications, business partners and entities
• Need for E2E security architecture that can be deployed and integrated with existing and disparate security models
• Need to define encryption policies
  
• Need to consistently enforce security policies

Service Management

• Federate identity and access control
• Secure services and applications
• Consistently enforce security policy

Service Virtualization

• Support scaling infrastructure resources
• Prioritize infrastructure across multiple services and/or business processes (composite/dynamic applications)
• Accelerate application performance by distributing the composites across multiple infrastructure resources.
  

Service Registry and Repository
Service Registry contains the policies, description and metadata for each service present in the enterprise. It provides a mechanism to find services and their metadata.



Conclusion
SOA governance requires policy control and audit framework that spans the security, service definition, identity domain, service consumption and people. A SOA governance framework requires some means to consistently define some policy and managing it through its lifecycle and provisioning from central accessible policy registry and enforcing its execution across distributed systems.
Enterprises will only benefit and further improve their competitive advantage and quality of service by utilizing an automated policy governance. By doing so, the organizations will be able to leverage both their IT assets and human capital.

By Sadi Melbouci

References:
[1] SOA Design Patterns, Thomas Erl, 2009
[2] SOA-RA public Review
[3] Reference Model Service Oriented Architecture
[4] Does web service make a service for SOA

Page Rank 4 in 60 days

How to accomplish google page rank 4 in 60 days?

By Sandrick (Sadi) Melbouci

At the end of this year - 2008, I got a nice christmas surprise. My site went from google rank 0 "zero" to 4 in 60 days.

My web site, Practice Management Software, was first crawled sometime in the end of October. I decided to increase the rank of my site and traffic with a minimum budget. I laid out a plan and below, I will discuss the tasks that I executed in the sequence that they appear.

Page Header Elements

Designed the pages to be SEO friendly with modern web page build design. Paid attention to the following:

- Page title

The name of web page has the name of the title

- Page header

The title has the first H1 header in the page

- Meta description

The page description has the title in it as the first sentence.

- Meta tag keyword

3 to 4 keywords per page.

Page Design

- Usage of CSS

Take advantage of modern web page design. Styles should be defined in a CSS document that references the elements, IDs, and classes in the XHTML document.

- Page size

Google only crawls the first 100k. Kept the page to less then 50k

- Eliminate Obsolete or deprecated HTML

Use modern design techniques and used proper combination of XHTML and CSS

Link popularity

- Submitted the site to the major search engines including Yahoo, Google, Altavista, ...etc

- Submitted the site to web directories: Yahoo, DMOZ, Allweb, BOTW ...etc, submitted the site to the correct caegories. This will provide one way link to your site.

- Started a blog and wrote articles on the subject related to my site.

- I commented on other blogs related to my site

- Added an RSS feed to my site

- Made the keywords as the anchors

- Finally, I have exchanged links with other sites on the same subject domain as my site. Making sure that the anchor in the link is one of my keywords.

Keyword Density

- I focused on 3 to 4 keywords per page that were defined in the keyword meta data header element.

- I wrote the text in the body for the potential customers describing my product without repeating too much the same keywords and used bold where needed.

- Put one keyword in alt image attribute and title

- Put one keyword in name and title of the link attribute

Advertising

I have noticed that some of the ads from Google and Yahoo advertised as content (This type of ad appear on some articles related to subject described in the ad). When these sites get crawled, The search engine counted it as one way link.

I guess this might be a temporal link but counts to increase both the organic and advertised traffic.

That's all. It worked like charm.

Medical Practice Software

Download Medical Practice Software

HIPAA Compliance

In this article, I will address HIPAA as it relates to the software and tools used by clinicians to manage their practice. The congress has put a set of rules under the HIPAA law, we will explain what's this law is about and how it applies to medical software.


What is HIPAA?

The Administrative Simplification provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA, Title II) required the Department of Health and Human Services (HHS) to establish national standards for electronic health care transactions and national identifiers for providers, health plans, and employers. It also addressed the security and privacy of health data. As the industry adopts these standards for the efficiency and effectiveness of the nation's health care system will improve the use of electronic data interchange.

The Entities covered by HIPAA law are:

• Health Plans

• Health Care Providers who use certain electronic transactions

• Health Care Clearinghouses

The HIPAA provisions are summarized as:

• Transaction Standards and Code Sets
• Privacy
• Security
• National Standard Identifiers for the Provider, Employer, Health Plan and Individual

HIPAA in Practical terms

Administrative Simplification is a method of making medical practice (the billing, claims, computer systems and communication) uniform in order for providers and payers to interact with each other through each other's proprietary systems. The changes will affect such activities as:

• Enrolling an individual in a health plan

• Paying health insurance premiums

• Checking eligibility

• Obtaining authorization to refer a patient to a specialist

• Processing claims

• Notifying a provider about the payment of a claim

HIPAA Privacy Right and Security

HIPAA contains a provision that is related to Electronic Data Transactions to standardize the exchange of the data between trading partners. These transactions are mandated to be in the ANSI ASC X12 version 4010 format.
In Addition to the transactions, Software industry has introduced Electronic Medical Records. To guarantee the privacy rights and secure the access to the medical records, HIPAA provided guidlines to protect the patient's privacy.

Privacy rights

The HIPAA regulations establish standards for protecting individually identifiable health information and for guaranteeing the rights of individuals to have more control over such information. Here is the summary of these regulations:

1- Right to ask and see a copy of your records
2- Have Correction made to you records
3- Receive a notice that your information will be shared
4- Decide whether to accept that your information can be shared
5- Get a report of when and why your record is shared
6- Ask that your information shall not be shared
7- File a complaint

Security 101

The HIPAA regulations have establish standards for all health plans, clearing houses, and storage of health care information to ensure the integrity, confidentially, and availability of electronic protected health information.
The Security Rule covers only protected health information that is in electronic form and we can summarize the security standard into the following requirements.

- Administrative Safeguard
These are administrative functions that should be implemented to meet the security standards. These include assignment or delegation of security responsibility to an individual and security
training requirements.

More details on Administrative Safeguard Reference

- Physical Safeguard
These are the mechanisms required to protect electronic systems, equipment and the data they hold, from threats, environmental hazards and unauthorized intrusion.

More details on Physical Safeguard and recovery


- Technical Safeguard
These are primarily the automated processesused to protect data and control access to data. They include using authentication controls to verify that the person signing onto a computer is authorized to access that.

More details on on Technical Safeguard who has accesses what information?

Is X12 technology right for healthcare

By Sandrick Melbouci

Is X12 Format right for Healthcare.

In every corner, we hear about the rise of healthcare costs and how to reduce them. I would like to add one area where the cost can be reduced significantly.
We all agree that the cost can be reduced by automating certain procedures, such as the medical billing, electronic medical records, scheduling, reporting and so on.
The first question I asked was, what if the cost of automation is so huge that it will raise even more the costs of healthcare.
So, how can we reduce the cost of the automation.
The scheduling, automation can be accomplished at very minimal cost.
The Electronic Medical Records is specialty dependent, but there is some common data that can be defined as "standard" for each practice.
The medical billing is the big elephant in the room. The cost of its automation is significant and its implementation is complex. We will look at two aspects:

• Medical Coding
• Claim Processing

Medical Coding specialists are in high demand because of rapid growth in the number of medical tests, treatments, and procedures that will be increasingly scrutinized by health insurance companies, regulators, courts, and consumers." (See U.S. Department of Labor, Bureau of Labor Statistics.) , It is probably the fastest growing profession withing the healthcare industry. The 2005 statistics from the United States Department of Labor and Bureau of Statistics, showed the healthcare information industry is expected to grow faster than normal through 2014.

In practical terms, the medical coder adds cost to the clinician and that cost will be transferred to the patient. But this is required position that we may not be able to cut. So, where can we cut costs ?
We will look at how to reduce the cost HIPAA transactions processing.

HIPAA Transactions.
HIPAA defined a set of transactions to support Electronic data exchange:

• Health Care Claims or equivalent encounter information (837);
• Eligibility for a Health Plan (270/271);
• Referral Certification and Authorization (278 or NCPDP for retail pharmacy);
• Health Care Claim Status (276/277);
• Enrollment and Disenrollment in a Health Plan (834);
• Health Care Payment and Remittance Advice (835);
• Health Plan Premium Payments (20); and
• Coordination of Benefits (837 or NCPDP for retail pharmacy).

While many entities in the health sector have developed, or are in the process of developing, electronic data interchange (EDI) format standards, the lack of common, industry-wide standards is a major obstacle to realizing potential efficiency and savings.

The problem starts with the choice of EDI format, X12. For those who had some experience with X12, they know what I'm talking about. It is a complex format that is very hard to maintain and terribly complex to implement.

Today, the software industry offers other technologies that can actually reduce the cost of the implementation of the HIPAA transactions and HIPAA specifications. One of these technologies is XML Web services (Dont confuse it with a web site) that operates under SOAP (Simple Object Adapter Protocol) or REST.
The data for each transaction can be defined with an interface called WSDL (Web Service Definition Language) and the companies can implement the business behind each transaction independently.
This protocol is platform independent (Windows, Mac, Unix, Linux, MVS ...etc) and it can reduce the implementation costs by 500% and increase efficiency at every level of claim processing because this technology provides hooks to validate, secure, transport data. This reduction of cost in claim processing will imply reduction in insurance premiums as well as the reduction of the cost of billing systems.
Compared to EDI where the claims are submitted in batch format, the Web Service technology can submit the claims in realtime or immediate send or in batch mode. The number of errors will be reduced to under 1%.

The combination of efficient medical coding along with web services technology as the protocol of choice for HIPAA transactions will reduce the cost of claim processing by at 200%.

Conclusion

The ultimate goal is to take care of the patient at reduced cost. Many things need to come together in order to accomplish this goal. One of them is Medical Practice Management Systems implemented at reasonable cost that offers the functions that will optimize the provider time and costs. I believe that it start by applying the right technology that can help the business.

Medical Practice Management Software - EzMedPro

By Sandrick Melbouci

Introduction

With today's rising healthcare costs and the baby boomers needing care, it is important to automate medical records, billing, ...etc in the everyday provider's tasks. For patients, they want the best care. They want to get an appointment with a doctor when they are not feeling well and not wait few days for a possible care. And when they show up at the doctor's office, they want the best care.
The best care comes when the provider knows our medical history and can be accessed quickly on each visit.


How do we make the provider more efficient?
Well, we need to look at how to optimize the time the provider spends in tasks other then seeing patients.
I will try to list some that every patient may have seen:

1- Medical Records are on paper and hard to find, the doctor does not go through every pages of our record. He looks at the last visit. We need to have a way to show the medical history summary of the patient that can be seen by the provider without going through 30 pages.
2- Medical Coding is another area of headache. To put it in simple words, a visit to doctor has a code (that's a CPT code) and diagnosis is another code (that's the ICD code). These codes are used to submit the claim to the insurance company.
3- Billing is critical to raise revenue for a practice. Having a system that generates a bill for each visit and manage the receivable accounts will help the providers save time. However, I have seen that these two functions are usually managed by two different systems. EzMedProis a software that integrates these 2 functions.
4- Insurance Claims , this is an area I believe needs the most improvement. The Insurance companies make it hard for both the provider and the patient when it comes to pay a claim. Today there are two way to get a claim processed:
- HCFA form and send it by mail
- Electronic Claims
5- Scheduling is not really an issue but need to be mentioned for large practices to run reports and send reminders to the patients prior to their appointment.

The potential solution
The solution is to automate the daily tasks as much as possible. Basically we need to automate at the least the 5 tasks I listed above: Scheduling, billing, insurance claims, medical coding and medical records.
Not only do these task need automation but they need to be integrated within one system in compliance with HIPAA.

There are certain number of systems that provide some type of solution. However, for most of the providers, affordability is an issue, until now. EzMedPro is a Medical Practice Management Software that integrates all the tasks I listed above and is available for a price under $300.

The Objective is to make the provider focus on the patient. EzMedPro Software from DSOFT Systems provides the lead way for affordable software with efficiency for providers.

Add to Technorati Favorites

JCA Connector for SSH and SFTP

By Sandrick Melbouci

The Enterprise Architecture Integration (EAI) provides a common framework for integrating incompatible systems running on different platforms. Many legacy applications and custom databases are still being used and run well that there is no need to re-invent the wheel. The aim of EAI is to reduce the complexity of the IT infrastructure and improve reliability, scalability and flexibility.

This article provide a brief description of a technology that is a key in integrating the databases and legacy systems with J2EE technology. Java 1.4 came with JCA 1.5 (Java Connector Architecture) that provide the standard mechanism to store, retrieve data from EIS (Enterprise Information System). To understand how JCA fits into EAI, refer to Connect the Enterprise with JCA.

Why JCA?
J2EE container is responsible for managing the security, threading, resource pooling and so on. In order to ensure the control over their functions, the container put some restrictions on components it manages such as EJB and servlets.
One of the restrictions is on EJB and IOs in general. An EJB should not manage a file descriptors (Sockets or Files). The communication with EIS is done through Sockets. Sockets are the standard low level communication primitives that appeared in early 1970's for Unix systems. The Sockets are not serializable therefore, EJB cannot passivate them neither the servlet can put them in session. In distributed environment, EJB are distributed at runtime running on separate JVM or machines. More information about EJB restrictions may be found at EJB Restrictions .
But EJB should find a way to communicate with databases and other EIS system. JCA provides the solution where the JCA handles the low level connections with EIS and return a Handle for the connection to the J2EE middle tier components.

Before we start the implementation of a Resource Adapter to provide SSH and Secure FTP functionalities, let's list the main JCA components:

• System contracts
• Client API
• Resource adapter module

System contracts
System contracts define the connection between the application server and the EIS. The EIS side of the system contract is implemented by a resource adapter
-- a system-level software driver specific to the EIS. The application server and the resource adapter collaborate by means of the system contract to provide secure, robust, scalable access to the EIS.
Three types of system contracts are defined:
The connection management contract enables physical connections to the EIS and provides a mechanism for the application server to pool those connections.

The transaction management contract supports access to an EIS in a transactional context. Transactions can be managed by the application server, providing transactions that incorporate other resources besides the EIS, or they can be internal to the EIS resource manager, in which case no transaction manager is required.

The security contract supports secure access to the EIS. How system contracts are implemented on each side (application server and resource adapter) is not specified by JCA; they can be implemented as each vendor sees fit.

Client API
The second element of JCA is the client API. The API can be specific to the resource adapter or it can be the standard Common Client Interface (CCI) as defined by JCA. The CCI is meant to be used by vendors to provide integration tools and frameworks, making it easier for developers to access enterprise systems. It is recommended (but not mandated) that the resource adapter make use of the CCI.
Resource adapter module
The resource adapter module contains all of the elements necessary to provide EIS connectivity to applications. Specifically, the resource adapter module includes the following components:
- The Java classes and interfaces that implement the resource adapter
- Any utility Java classes required by the resource adapter
- Any EIS-specific platform-dependent native libraries
- The deployment descriptor
Application servers make use of the deployment descriptor supplied with a resource adapter to configure it to a specific operational environment.

Handling of Connections
An application component accesses the resource adapter through ConnectionFactory and Connection interfaces, which are provided by the resource adapter implementer. These interfaces can be CCI interfaces (javax.resource.cci.ConnectionFactory and javax.resource.cci.Connection) or they can be specific to the resource adapter. The classes that implement these interfaces are also provided with the resource adapter.
The connection factory is obtained through the Java Naming and Directory Interface (JNDI) so that the application need have no knowledge of the underlying implementation class. Once the connection factory is retrieved, a connection is obtained from the connection factory through the getConnection() method. At least one getConnection() method must be provided by the connection factory, though more may be provided. It is important to note that a Connection is an application-level handle to an underlying physical connection to the EIS, represented by a ManagedConnection. Once the application component is finished with the connection, it calls the close() method on the connection. A resource adapter is required to provide a method on the connection to close the connection. This method must delegate the close to the ManagedConnect ion that created the connection handle. Closing a connection handle should not close the physical connection to the EIS.

Managing Connections
The getConnection() method in the connection factory does not actually create a connection;
it calls the allocateConnection() method on its associated ConnectionManager.
The ConnectionManager interface is implemented by the application server.
It is associated with a connection factory in an implementation-specific manner when the
connection factory is instantiated. The call to the ConnectionManager allows the application
server to "hook in" to the resource adapter functionality to provide pooling, transaction,
and security services. A ConnectionRequestInfo object may be passed to allocateConnection()
to pass connection request-specific information.

The ConnectionManager, in turn, calls on a ManagedConnection to obtain the connection
handle. The connection handle is passed back through the ConnectionManager to the connection
factory and on to the application component.

Connection Pooling

The resource adapter provides a class that implements the ManagedConnectionFactory interface. The ManagedConnectionFactory class acts as a factory for both connection factory instances and ManagedConnection instances. When the application server needs to create a connection factory, it calls the createConnectionFactory() method, passing in an instance of ConnectionManager; this is the instance that is called when the application component calls getConnection() on the connection factory, as discussed previously.

The application server uses one of two ManagedConnectionFactory methods to create or request managed connections. When the server requires a new instance of ManagedConnection, it calls the createManagedConnection() method. When the server wants to re-use an existing ManagedConnection, it calls the matchManagedConnections() method. To find the right match, the server passes in a set of ManagedConnections that could possibly meet the criteria of the requested connection, along with information about the desired connection type. Internally, the matchManagedConnection() method compares this information with the candidate set to determine if a match can be made. If so, it returns the matching ManagedConnection; if not, it returns null.

So far we have talked about the outbound. JCA also supports the inflow and is implemented using ActivationSpec and Inbound Message Driven Bean.

The following depicts the design of the SSH adapter.


The code can be found at http://txconnect.sf.net


By Sadi Melbouci

References:
Connect the Enterprise with JCA: http://www.javaworld.com/javaworld/jw-11-2001/jw-1121-jca.html