Money (benefit???) is here….. RCM!

Healthcare as a business is evolving rapidly, partly driven by  changing reimbursement models. Health information professionals expected to be on the front lines of initiatives aimed at improving population health, increasing patient engagement and reducing overall healthcare costs.

That, in turn, is having a profound effect on payments and governance. As providers adjust their processes in reaction, it is important for the revenue cycle to keep pace with value-based models that increasingly tie reimbursements to payer definitions of quality and clinical appropriateness.

Healthcare revenue cycle management solutions can also help practitioners ensure they receive incentive payments for participating in government programs such as the Physician Quality Reporting System and E-Prescribe, further increasing a practice’s revenue. Other coming advances in revenue cycle management include charity screenings and propensity to pay. These measures can help physicians decide how to handle patients who may be unable or unlikely to pay their medical bills without compromising the financial success of practices. Outsourcing this process makes it more cost-effective to provide these services, as administrative staff does not have to spend their billed hours dealing with these tasks. Thus, RCM systems, methodologies, and technologies provide viable solutions to all players involved.

Data Modeling Standards and Guidelines

Logical data models and database models are essential components of technology today. The following lists data modeling standards and guidelines in addition to outlining some data modeling principles.

Conceptual Data Modeling (CDM)

  • CDM consists of data entities and their relationships.
  • CDM describes key business information by subject area from a data perspective.
  • CDM should be divided into subject areas of manageable size. In practical terms, this means a model usually has between 4 and 15 entities per subject area.
  • Every subject area must have a unique title.

Logical Data Modeling (LDM) Standards and Guidelines

  • A corresponding logical data model also has associative classes to resolve many-to-many relationships, is fully attributed, and is normalized to Third Normal Form (3NF).
  • If a CDM was used as a foundation for adding details to develop a logical data model, then the non-specific relationship line between entities will be replaced with identifying or non-identifying relationships.
  • A LDM also shows all native (that is, non-foreign key) primary key attributes and non-key attributes in the attribute area.
  • A fully attributed logical data model will be in Third Normal Form (3NF). This means that each entity instance has exactly one unique record. All non-key attributes fully depend on primary key attributes, and no non-key attributes depend on any other non-key attributes.
  • Depending on the particular logical data modeling methodology and tool used, there are a number of acceptable ways to indicate cardinality or multiplicity on the ends of relationships between two equally important entities.

Physical Data Model (PDM) Standards and Guidelines

  • Designate a unique primary key column for every table.
  • Each column name should contain all of the elements of the logical attribute from which it was derived, but should be abbreviated to fit within the maximum length.
  • Do not use hyphens in table or column names because some programming languages interpret hyphens as subtraction operators.
  • Implement table and column names in a way that is supported by all target DBMS tools.
  • The physical model will assign lengths and data types to all columns. Data types should be specific to the target DBMS tool.
  • The physical data model will, at a minimum, provide examples of possible values for identifier, indicator, and code columns.
  • A certain amount of demoralization is usually necessary when implementing the physical data model.
  • Estimate the expected storage requirements for each table based on the size of each row, expected growth, number of rows, and archiving requirements.
  • Understand the capabilities of the specific database product. Performance improvements may be realized by taking advantage of features such as clustered indices, caching, and index optimization.

Top 8 Considerations of Data Modeling

Recently, we published a whitepaper on the Data Modelling approach and processes involved. There, we had discussed the top eight considerations of standard and logical data models. The following is a summary of the important data modelling guidelines.

Data Modelled Well:

  1. Aligns with business very well
  2. Connects with data and scales for the future
  3. Enables good governance and integrity of data across the organization

The following diagram shows the top eight considerations:

 Data Modeling v1

Model Correctness:

    • Ensure that the model accurately captures the material. the material?
    • Make sure that the design represents the data requirements.
    • Ensure the correctness of data elements with different formats than industry standards.
    • Fix incorrect cardinality and keys defined incorrectly


  • Model Completeness:
    • Does the scope of the model exactly match the requirement?
    • Can a model be complete yet incorrect? Incomplete yet correct?
    • If relationships are not shown, then they shouldclarify any ambiguously defined terms.


  • Model Structure:
    • Standard modeling practices, independent of content
    • Entity Structure Review
    • Data Element Review
    • Relationship Review


  • Model Flexibility
    • Ensures that the correct level of abstraction is applied to capture new requirements.
    • Achieves the right level of flexibility.
    • Proves there is value in every abstraction situation.


  • Modeling Standards & Guidelines
    • Ensures correct and consistent enterprise, conceptual, logical, and physical level as per standards & guidelines.
    • Uses the correct names and abbreviations


  • Model Representation
    • Optimal parent and child entities placement
    • Intelligent use of color in grouping or highlighting entities
    • Proper relationship lines crossing each other or through unrelated entities
    • Optimal use of subject area
    • Maximizes readability and understanding


  • Physical Design Accuracy:
    • Ensures that the design is for the real world & also specific to application
    • Considers null values
    • Uses partitioning
    • Utilizes proper indexing and space
    • Considers denormalization


  • Data Quality:
    • Ensures that the design and actual data are in sync with each other.
    • Determines how well the data elements and their rules match reality.
    • Avoids costly surprises later in development.

Is Interoperability the new bubble?

The EHRs developed in past decades are expected to be interoperable – is this is a “huge expectation” or is this  “just another wish” or is there “nothing so great about it”?

We have become so accustomed to carrying medical records from one hospital/physician to another and going through  grueling rounds of medical tests and reports that we never questioned the status quo.

Why didn’t my current physician share my medical records electronically with my new physician? – Are the EHRs not scaled  to share data? Or is there some hidden secret of not sharing data between eligible entities? Are the standards to be blamed for not accommodating this feature ?

I think these barriers will surely be overcome in the near future. Multiple initiatives or approaches are being taken to resolve the medical records interoperability issue. Among them, a few are:

  • HIPAA compliance makes it mandatory to make healthcare data portable.
  • At the same time, hospitals start seeing the benefits they receive by being interoperable.
  • An angle added to the benefits is that the hospitals will not get monetary benefits if they aren’t interoperable in terms of reimbursement.
  • The claims denial from insurance companies if the same tests are prescribed by multiple physicians. Insurance companies may deny claims if the same tests are prescribed by multiple physicians.
  • Acceptance of tests conducted by hospitals in the ACOs.

Healthcare Revolution

I am confident that the Medicare and Medicaid EHR Incentive Programs for the meaningful use of certified EHR technology will take the exchange of medical records to the next level.


Creating Responsive UI in Cross Platform

This blog will elaborate the means of  creating a responsive UI during cross platform app development.. As we know, cross  platform or multi-platform applications are developed to reuse code on different platforms.

Adaptive web design involves using framework CSS for a responsive UI design. As the platform varies, it introduces different screen sizes where your developed HTML runs. A mobile device comes in different sizes and one cannot predict all ranges of the device screen size and do the HTML coding accordingly. In such scenarios, in which  you don’t know the screen size of device to run on, responsive design comes into picture. The term responsive design itself indicates that HTML will have the same look and feel on all devices, bringing a consistent user experience for all mobile OS platforms.

When developing Cross platform applications, one should take care of the below points while creating an HTML UI for the application. One should also follow the below guidelines while creating CSS classes.

Do not Give Hardcoded Sizes for HTML Elements

Never give hardcoded height and width to any HTML element. Consider a scenario in which you develop an application for a device size of 360×480 pixels. You define CSS with width 360px and deploy it on the same device. However, when you deploy the same application on a device with a different screen size, your HTML element won’t fit on screen and your UX goes for a toss.

Instead, create a CSS class in which you give size in terms of percentage for an HTML element. This class will be manipulated as per the required size of the element on screen. For example, if I create an HTML element that needs to fit to the complete width of the device, I will set the width as 100%, which will runtime calculate 100% of available screen space and will bring the same user experience on all devices.

Have Control on Your Margins

Always try to set margins in percentages instead of pixels. Many times, it collapses the responsive width and height of HTML components and makes the element  go out of screen bounds. For example, consider a case in which you create an HTML element with width equaling screen size and with margin of five pixels. This  will cause the element to move out of bounds and will add an unnecessary scroll to the UI.

Instead, divide the element space in terms of 100%;   set size and margin to sum to 100, so that it will fit on screen.

Make Images Flexible

When images are added onto an HTML UI, try to make them more comfortable with screen size. A hard code sized image can vary the feel on different screen sizes.,  In such a case, to make the look and feel consistent, give the image a CSS class. This makes it comfortable to fit on screen. The CSS for an image should give the height and width of the image as a  percentage.  This will make the image more flexible in case of screen size and orientation changes.

Set  Font According to Screen Size

Font size in pixels varies when pixel density of the mobile device changes. A font that looks perfect on one screen can look very small  other screens with a high pixel density. In such scenarios, set the font size either in EMS. Otherwise, considering a smaller screen size targeted for applications, give the minimum font size in EMS and give the font size in pixels. For example, CSS class for label should be like:

.label class

{min-font-size: 10px; font-size: 9 %;}

Use of Media Queries

Use media queries when you want to have different responses for different screen sizes. Consider an application that runs on tablets and on smartphones and needs a different UI for tabs and phones. In  such cases, media queries bring up a great deal of handling UI. Media queries are like writing if/else condition and telling the browser how to render UI on different screen sizes.

For example

@media screen and (max-width 700px)




Height: 90px;             font-size: 15px;



@media screen and (max-width 400px)




Height: 50px;             font-size: 10px;



Performance of Cross Platform Application

In this blog, we will introduce you to the measures of improving the performance of cross platform mobile applications. Before moving ahead, let me first demonstrate the cross platform application. Mobile cross platform applications are applications which are developed using HTML5 and JavaScript, and have the capability to run on multiple mobile operating systems.

In multi-platform application development, it is very important to ensure a responsive UI design. It is necessary to make your applications design responsive, for example in the case of optimal adaptive web design and an intelligent mobile responsive design.

The architecture below explains the working of cross platform mobile applications and can help in improving performance of cross platform apps:

 Performance of Cross Platform Applications v2

The architecture showcased above demonstrates the performance of cross platform applications. Response time for the application increases with the hardware acceleration needed. In addition, increases in the script load imply more time to get a response from the application. .The user experience is therefore degraded if cross platform apps are  not architected and developed according to the best practices of performance.

The below mentioned guidelines can be helpful in improving the performance of cross platform mobile applications and can achieve a better user experience:

  1. Write minimal Script code: Write a small amount of script code for UI and data processing. This is because if the script load is increased, it will consume more time to execute and load scripts. Always have JavaScript optimized for the cross platform applications.
  2. Load Scripts Runtime: Do not give static reference to script files using the <script> tag. As the number and size of the script files increases, it will increase the load time of the application page. Always load the script runtime once the basic HTML page and body is loaded on the browser. Using JavaScript, create the Script DOM element and the setting resource of the Script file. It will reduce the launching time of the application and can result in a better user experience.
  3. Optimize your HTML UI
  • Do not add any script loader tags in HTML. When the required HTML is loaded, it will also load the script specified in the HTML UI component, resulting in increasing UI response time.
  • Never have a ladder of multiple <DIV> tags. Use the minimum hierarchy of HTML DIV.
  • Do not specify any inline CSS tags. Have all your CSS in a separate CSS file.
  • Never load the generated UI components from the server. Instead, write a script to create the UI from server responses and append it on your HTML page.
  • Always have a single HTML page (divided into subpages) in your application, instead of creating a separate HTML page for each application page.

4  Have your CSS optimized

  • Create a reusable CSS classes for UI components.
  • Use CSS gradients instead of images for the background, as the images require a large amount of application memory, and consume time to load.
  • Never use fixed sized elements at the bottom of the page, as these take more time to move when mobile device orientation is changed. When required, specify absolute positioned CSS for elements at the bottom.
  • Use as few fixed position elements as possible, as these elements require more time to move in case of orientations and causes UI flicker.
  • Always load CSS files runtime using a loader script, as this will reduce the application response time.

5   Use customized UI components instead of jQuery mobile: jQuery mobile has a wide range of UI components. This, however, has its own drawbacks of flickering and low performance, and cannot be customized easily. Instead of jQuery mobile, create your own customized UI component with the help of CSS and HTML DIV. This can help in creating customized UI components as per application requirements, and one can create optimally performing UI components.

6   Hardware interaction: For hardware interaction, write a plugin to interact with the device’s API layer. Accomplish this with minimum script and optimized native code. Use PhoneGap 3.0 and include only required plugins as it will help in getting reusable plugins and these will have a better performance.

Why Cross Platform Applications?

In this article, we will discuss n why one should go for cross platform application development. Before diving in,  discussion let me just go through what we mean by cross platform applications (Hybrid applications).

Cross platform applications (Hybrid applications)

Hybrid apps are part native apps, part web apps. (Because of that, many people incorrectly call them “web apps”).  Like native apps, they live in an app store and can take advantage of the many device features available. Like web apps, they rely on HTML being rendered in a browser, with the caveat that the browser is embedded within the app.

Often, companies build hybrid apps as wrappers for an existing web page. In this way, they hope to build a presence in the app store, without spending a significant effort for developing a different app. Hybrid apps are also popular because they allow cross-platform development: that is, the same HTML code components can be reused on different mobile operating systems, significantly reducing development costs. Tools such as PhoneGap and Sencha Touch allow people to design and code across platforms, using the power of HTML.

The app  is usually written in a web-based code such as JavaScript, CSS and HTML, like a Web application. However,  it runs on the device, rather than on a Web page, making use of a device’s browser engine without using the browser itself. What makes this work is that the platform’s native APIs are shown to a hybrid app as if they were in JavaScript. This allows a hybrid app not only to be accessible on different platforms, but also to be able to get the most out of each of those platforms’ capabilities.

Now, let’s come back  to the topic of why we should choose cross platform applications. The following are some parameters that help in defining our agenda of this article:

  1. Device features: Unlike webapps, hybrid applications can access many native features of the device based on the applications requirement.
  2. Installation: The process of installing hybrid applications is similar to Native apps installation.
  3. Platform Independence: While different browsers may support different versions of HTML5, if platform independence is really important to you, you definitely have a better chance of achieving this by using hybrid applications.
  4. Development cost: It is arguably cheaper to develop hybrid apps, as these require skills that build up on previous experience with the web.
  5. User Interface: A rich user interface can be developed using the power of CSS and HTML5.
  6. Maintenance: Maintaining a native app can be complicated not only for users but also for developers (especially if they have to deal with multiple versions of the same information on different platforms). Changes have to be packaged in a new version and placed in the app store. On the other hand, maintaining a hybrid app is much easier.

Based on the above points, we can conclude that hybrid applications are the future of mobile applications where the mantra is “write once, deploy on multiple platforms”.

Security in Mobile Application

Mobile Application Security – An Introduction

Mobile phones are  becoming an integral part of day-to-day activity.  The  corporate world is moving towards mobiles to facilitate the continuous availability of data  onto mobile devices. Therefore, mobile application security is becoming a core part of  protecting users’ and enterprises’ private data  from various security threats. In this article, we will have a look at how we can achieve security in cross platform mobile applications.

Our Approach

  1. In-app Security: Many times, it is required for mobile applications to have data stored onto devices in a local database or any local file. These local files and databases can be easily retrieved from the device by rooting or jail-breaking the devices, which in turn results in leakage of data into a hacker’s hand. This can cause misuse of personal as well as enterprise data. Therefore, securing local data becomes a major action in mobile application development. The actions that can be taken  are described below:
    1. Use of SQLCipher: SQLCipher is an alternative to SQLite. It has the same functional support to mobile application for storing data onto a local database, but with encryption of data. It uses the SHA 256 algorithm to encrypt and decrypt the data to be stored into local database. This can protect local data as it is encrypted, which enables data security.
    2. Local database encryption: Other ways to encrypt and decrypt the data with strong encryption techniques are defined below:
      • Using Encryption Algorithms: One of the basic techniques to hide data is by encrypting the data with secure algorithms such as SHA-256, AES with a private key to encrypt data when it is stored on a local database and to decrypt it whenever it is used.
      • Password-based encryption: One of the disadvantages of the encryption algorithm with a local key is the chance of breaking the key by hackers either from code, when key is available is code. In the password-based approach, the user has to enter a password each time he opens the application or accesses sensitive data. This password is set to database as database password or it is used as a key to encrypt/decrypt data with a secure algorithm. This approach will have extensive data security. It will vary from user to user and won’t have an encryption key stored locally.
      • Registration ID/Device ID-based security: This approach can be used when the application has to enable push notifications. It includes encrypting/decrypting data with a registration/device ID as the key. The device registration is a unique combination which results in a non-breakable key for hackers.
      • Storing data as Objects: This approach can be used with databases such as Mongo DB, ORM, etc. This approach involves storing data in a database as runtime objects instead of storing it as a normal programing entity such as a string, integers.  This approach with encryption technique enables the data not to be decrypted by hackers. This type of approach can be very useful in cross platform applications where objects are runtime identified.
      • Security of local files: Many times, it is required for an application to download, create, capture documents, images, videos which have sensitive data. An application should have the capability to delete these local data files as long as they is not needed or it should be protected by encrypting them. One more approach that can be enabled when downloading a file from the server is not to have the extension to the locally stored file. This  will make app data files inaccessible to other apps.
    3. Data Transmission Security: Data transmission security is important when an application sends data to a remote server. The data that is being transmitted to the server can be easily hacked. So, the data that is being transmitted should be protected. The techniques below can be used for protecting data that is transmitted over the air.
      1. Authentication: Authentication provides a way to send authorized data by an authorized user with an authorized device only. In this approach, the mobile application uses the server’s login service with user and device details. On authentication, the authenticate server sends an authentication token to the device which in turn is sent to the server with all  the requests that are made to server. The server verifies this token and validates the request.
      2. Data Encryption: In data encryption, all data that is sent to the server or received from the server should be in an encrypted format. Encryption of data should be implemented using security algorithms. One of the ways to secure data is by using a Triple Encryption Algorithm for data transmission. In this approach, we use private and public key into app. When the server sends data to a mobile device, it encrypts data to be sent to the device with the current timestamp in the system. It then again encrypts data with a timestamp. Next, the server adds a timestamp to the response and encrypts it with a private key and sends the response to a mobile device. At the mobile side, the reverse process is done. Data is decrypted with a public key, timestamp is retrieved and decrypted again with a timestamp ensuring triple encryption.
      3. SSL key based encryption: In SSL key based encryption, all data sent to the server is encrypted with a public key and on the server side, that data is decrypted using the private key. Vice versa for receiving data from server.
    4. Location and Timestamp Based Security: Location based security is implemented in an application to enable/ disable features of the app depending on the current location of the mobile device. This type of security is useful in health care apps and enterprise apps in which device features such as the camera needs to enabled and disabled in company premises. Timestamp-based security can be applied by setting a time to perform certain actions on mobile, such as enabling a time for online exam from mobile devices. This type of security is implemented on devices by setting a time for a task on the server, sending this time to the mobile and on start of that task, verifying the current time with the timestamp sent by the server. Location-based security is implemented with GeoFencing techniques where we set the geolocation boundaries and perform the required enabling/disabling of features depending on current location of device.
    5. Biometric Authentication: Biometric authentication includes authentication using face recognition and voice reorganization to ensure that the same user is accessing the current application session. It can avoid vulnerable uses of application. This is implemented by storing the user’s biometric information on the device in local databases or local files and then verifying that the user entered biometric information when the application starts, such as voice enabled password, iris scan, etc.
    6. Role Based Access: Role based access means to allow user to get limited features of an application. For example, Admin can get the entire module access, but the end user can get specific feature access. Using this approach, we can restrict the user from higher-level features.
    7. Login Based Security: On login-based security, a different way could be implemented.
      1. Only one device-based session of login is allowed at a time. For example, the user cannot login on two devices at a time. User login is configured for specific type of devices (iPhone, Samsung).
      2. Passcode or Pattern-based authentication is enabled for single sign on option. For example, for the first time, the user can login using their credentials and after that, they should ask for a passcode or pattern authentication.
    8. Remote Actions on Data: Mobile devices are easily lost or stolen, and many users change their devices. In such situations in which users have  their private or enterprise data on mobile devices, there is a strong chance of data to go in the wrong hand. In such cases, we can take below actions on an app and its data remotely:
      1. Remote data backup: In this approach, we implement an application to send data to the user periodically, which makes the server to have a replica of data. This replication of data from device to server becomes useful when the user changes the device and installs the app on other device.
      2. Remote Data Wipe:Many times when user’s device is loststolen or for enterprises when user leaves the organization, it becomes necessary to retrieve the access from the user and remove all the data from user’s device. For this, we use remote data wiping. This approach is implemented by sending a silent notification on the device indicating the data wipe actions, which in turn makes the application  delete data on device.
    9. Code Security: Many times user’s devices are rooted or jail-break. These types of devices can easily leak IPA and APK files for apps. From these IPA and APK files, one can decompile the code and steal the code logic as well as get important data from the  application code. This can be harmful in the case of cross platform apps, where the application code is stored in local folders like assets or www. Once the APK or IPA code is cracked, the complete code of the cross platform application is available to the user which can be very easily replicated as another application. To avoid this, we should have below code security:
      1. Encrypting local files: In this approach, we encrypt local files with the secret key for apps. This includes encryption of files in assets/ www folder, which in turn secures cross platform code. This code is then decrypted when the app is installed on the device and then loaded as an app on the device.
      2. Code Encryption: In this approach, we secure application’s code by using tools such as ProGaurd and DexGaurd for android, which compresses code and applies encrypting algorithms to it. In case APK is leaked, the code won’t be understood by hacker.