Vijayanand Bharadwaj, Ravi Raman, Ramana Reddy and Sumitra Reddy Concurrent Engineering Research Center Lane Department of Computer Science and Electrical.

Vijayanand Bharadwaj, Ravi Raman, Ramana Reddy and Sumitra Reddy

Concurrent Engineering Research CenterLane Department of Computer Science and Electrical Engineering

West Virginia University

June 21, 2001

Empowering Mobile Healthcare Providers via a

Patient Benefits Authorization Service

Introduction

Having examined the patients benefits authorization process in the healthcare arena, we seek to utilize existing technologies and provide an infrastructure to enable mobile physicians to conduct the process smoothly with increased efficiency.

Our solution addresses issues like limited physician-patient encounter time ,disparate requirements amongst multiple insurance agencies as well as limited input-output capability of wireless devices, information security, and lack of uniform data exchange format among others.

Introduction

• Healthcare providers (physicians) are highly mobile and examine patients while moving between various facilities.

• Decisions about patient care often requires information from variety of sources both internal and external to the organization.

Motivation

IntroductionCurrent System

• Typically in the United States patients are under managed healthcare plans from healthcare insurance organizations.

• As part of their cost curtailment procedures, these insurance agencies require healthcare providers to obtain prior authorization before prescribing a course of treatment, including – referrals to specialists,

– admission to hospitals,

– diagnostic procedures,

– surgeries

– for some medications.

Motivation

IntroductionMajor hindrances to this process are

• Limited face-to-face encounter time (<5-10 minutes ) in which to decide best course of treatment

• Widely varying health benefits and pre-certification regulations among insurance agencies.

Motivation

Introduction

• Thus often physicians are ill-equipped to provide a course of treatment which addresses the patient's needs and is compliant with the agency’s procedures.

• Consequently they may feel as seen not to be in control of the care giving procedure and experience a loss of credibility.

Motivation

Current Practices :-

• Submit justifications for recommended treatments and await approval. If disallowed then form alternative care plans.

• Regulations for each patient’s

insurance agency is

ascertained manually

through use of “cheat-sheets”.

Introduction Motivation

• Requests are made on paper-based forms which are then faxed across to the agency. These have to be examined by administrators and replies have to be faxed which can take up to 48 hours or more.

• Communication is primarily using fax and/or telephone.

Introduction Motivation

Drawbacks of Current Practices:-

• Incomplete , invalid information due to human errors result in additional delays as they have to be rectified after being detected.

• Confidential patient medical records are faxed openly which may result in compromising their security due to loss or theft.

Introduction Motivation

The physicians inability to provide a timely course oftreatment due to the above factors results in a deterioration in the overall quality of care provided.

Our Solution

• Use of available technologies to address the needs of mobile healthcare providers involved in such transactions.

• This solution may be considered as a framework for systems with similar needs in other domains too.

The rest of this presentation is as follows:

Introduction Motivation

Outline

• Previous Work– Foundation for mobile solution

• Mobile Solution – Architecture

– Implementation

• Summary

Previous Work

• To tackle the issue of enabling such transactions, we created a Web-Based Implementation as part of the Secure Collaborative Telemedicine Project at CERC, WVU (May 2000)

• Handled key issues in such systems, namely:– Workflow

– Interoperability

– Communication

– Security

– Process Efficiency

• Use of ubiquitous Internet and WWW (HTTPS protocol) enabling organizations to communicate, thereby easing development and deployment. ( Used Microsoft IIS 4.0)

• Client application being a browser , greatly simplified installation and use.

• Workflow involved in each organization could be handled through server-side scripting . (Active Server Pages)

• Requests made using forms. (HTML, DHTMLand scripting)

Previous Work

Features

• Communication between organizations enabled both,– Synchronously : through HTTPS

– Asynchronously : through email notification ,

thus minimizing delays.

• Security enforced using HTTPS and SSL (for encryption). Authentication of clients and servers, possible through X509 digital certificates.

• Process Efficiency improved by– Minimizing errors by use of Smartcards and automatic form filling

using Active Components

– Client side validation using JavaScript.

Previous Work Features

• User “mobility” supported as user is not tied to any one domain (Windows NT 4.0) by use of Smartcards. – Cards carrying physician information could be used at any

workstation with card reader.

– Browser extracts certificate from card and uses it in the authentication process. Thus user does not have to depend on certificates being present on the machine.

Previous Work Features

Operating System

Previous Work

Architecture

Workflow Engine

MailServer

Web Server

Database

Internetand the WWW

Encrypted Communication using SSL

Storage and retrieval of Transaction

Context

Agency Server

Agency Personnel Client

Physician Client .

1. Sends Initial HTTPS request and Certificate

2. Receives Tasks List

3. Receives Request Information

4. Sends Processed Request which causes auto E-Mail notification

Operating SystemWeb Browser Email ClientActiveX Components Smart Card reader

1. Sends Initial HTTPS request & Certificate

2. Receives ActiveX Components

3. Sends Filled Request Form

4. Receives Confirmation of Actions

5. Receives (later on) E-Mail Notification

6. Logs on as before and checks results

Previous implementation proves insufficient because

• Users needed a desktop/laptop (wired terminal) to use the system. Centralized setting in many clinics.

• Each organization had a separate form with its own format which had to be filled (automatically).

• In spite of smartcard automation significant amount of information had to be entered

Previous Work

Disadvantages with respect to Mobile users

Mobile Solution

* Use of a wireless device to conduct such a process over a wireless network.

* Due to input-output constraints of wireless devices minimal or “just-enough” input of information.

* Use of secure protocols to ensure patient information security over both wireless and wired networks.

Key Features

Mobile Solution

* Use of common data exchange format to enable heterogeneous systems to interoperate.

* Process efficiency improved through local workflow in the Healthcare Provider system.

Key Features

Mobile Solution Architecture , Usage Scenario Healthcare Provider # 3

Healthcare Provider #2

Healthcare Provider #1 Desktop Client

Server

XML DTD

LocalRepository

Mobile Client

Wireless Network

Health Insurance Agency # n

Health Insurance Agency # 2

Health Insurance Agency # 1

Server

Local System

LocalRepository

XML DTD

Internet

1. Mobile user logs on to system using a client application running on the wireless device

2. Upon authentication, selects certain task to be performed

3. Inputs required information (PID, name) and makes request.

4. Backend service processes user’s request and performs any local workflow.

5.Packages Wf-XML request message.

6.Contacts external system and after getting authenticated sends request.

7. Agency system processes request & performs local workflow.

9. Send response (results sent syn/asynchronously to care provider system which transmits to mobile client)

Mobile Solution ImplementationHealthcare Provider # 3

Healthcare Provider #2

Healthcare Provider #1 Desktop Client

Server

XML DTD

LocalRepository

Mobile Client

Wireless Network

Health Insurance Agency # n

Health Insurance Agency # 2

Health Insurance Agency # 1

Server

Local System

LocalRepository

XML DTD

Internet

1. Java MIDlets run on J2ME compliant mobile clients .

2. MIDlets send requests to servers over wireless n/w, Java servlets are invoked for tasks.

3. Corresponding responses are displayed.

(J2EE Platform)

1. Java Servlets used for various tasks, client authentication, request processing, invoking backend processes, connecting to external agencies, transmitting results back to mobile user

2 .Servlets and or EJB for Wf-XML processing (JAXP parsers),database access, workflow logic.

J2EE technology similar to the healthcare provider site for various tiers.(Java Servlets, EJB,JAXP)

Implementation • Candidate Enabling Technologies

– J2EE

– J2ME

– HTTPS

– Servlets/JSP with EJB

– Wf-XML

Implementation Mobile User Application

J2ME based application on the wireless device

Implementation Mobile User Application

Implementation Mobile User Application

Implementation Mobile User Application

Implementation Mobile User Application

Implementation Mobile User Application Features of J2ME

•Transport protocol neutral

• Support for HTTPS

• Rich customizable GUI

• As opposed to a WAP like model, eliminates the extra node.

• Can make use of device dependent features if any. Build powerful applications depending on the device (parse XML on the device )

•Can support an application suite

<?xml version=“1.0”?>

<WfMessage Version=“1.0”>

<WfTransport/>

<WfMessageHeader>

<Request ResponseRequired=“Yes”></Request>

<Key>R_D_T.org/Wfengine?id=167352</Key>

</WfMessageHeader>

<WfMessageBody>

<CreateProcessInstance.Request

StartImmediately=“true”>

<ObserverKey> MHS.com/wfx578</ObserverKey>

<ContextData> <HealthBenefitsAuthorizationMessage> <MessageType>Request</MessageType> <HealthBenefitsCategory> Medication Approval </HealthBenefitsCategory> <CaseNumber New=“yes”></CaseNumber> <PatientInformation> <Demographics> <Name>William Smith</Name> <Gender>Male</Gender> <DOB>….</DOB> <ContactInformation>…….. </ContactInformation> </Demographics>

Implementation Wf-XML Request Message

<Justification> <Diagnosis> <ICD-9-CM>…</ICD-9-CM> <CPT-4>…</CPT-4> <Explanation>…</Explanation></Diagnosis> </Justification> </MedicationDetails> </Clinical> <HealthCareProvider> My Health Systems </HealthcareProvider> <Physician> <Name>John Doe</Name> <Provider_ID>HSW5683</ Provider_ID > </Physician> </HealthBenefitsAuthorizationMessage> </ContextData> </CreateProcessInstance.Request> </WfMessageBody></WfMessage>

<InsurerDetails> <InsurerName>Blue Cross Blue Shield </InsurerName> <Plan> F8752-23</Plan> <Group> AG4576298</Group> <MemberID >26549</MemberID> </InsurerDetails> </PatientInformation> <Clinical> <MedicationDetails> <MedicationName> </MedicationName> <Class>……</Class> <Dosage>….</Dosage> <Duration> <From>…</From> <To>…</To> </Duration>

Implementation Wf-XML Request Message

Implementation<?xml version=“1.0”?>

<WfMessage Version=“1.0”>

<WfTransport/>

<WfMessageHeader>

<Response/>

<Key>R_D_T.org/Wfengine?id=167352</Key>

</WfMessageHeader>

<WfMessageBody>

<CreateProcessInstance.Response>

<ProcessInstanceKey>

R_D_T.org/WfcXML1673

</ProcessInstanceKey>

<ResultData>

<HealthBenefitsAuthorizationMessage>

<MessageType>Response</MessageType>

<HealthBenefitsCategory> Medication Approval </HealthBenefitsCategory> <CaseNumber>MA12345</CaseNumber> <RequestOutcome> <Status> Denied</Status> <DenialCode>D987</DenialCode> <Rationale>....…</Rationale> </RequestOutcome> <AuthorizationID>RDT2456 </AuthorizationID> <Date>…..</Date> </HealthBenefitsAuthorizationMessage> </ResultData> </CreateProcessInstance.Response> </WfMessageBody>

</WfMessage>

Wf-XML Response Message

Implementation Wf-XML FeaturesFeatures of Common data exchange format like Wf-XML

•Advantages of an XML based exchange format

•Can support any sort of domain specific XML within it (Contextdata and Resultdata tags)

•Not bound to any specific transport mechanism

•Can be packaged /parsed easily using JAXP or customized tools.

•For this application one common DTD encompassing all elements can be created. Specific elements can be used by interested parties. Wf-XML need not be extended.

Summary• Reference Implementation provided for applications

involving the following:– Information access and decision support for mobile users using

wireless devices.

– Remote activation of workflow and obtaining results in spite of wireless device constraints.

– Interoperability through the common data exchange mechanism

– Information confidentiality maintained

– Demonstrates an improvement in overall process efficiency by various mechanisms such as client side validation, local system workflow.

• This could be extended to other domains with similar needs.

Summary• What is needed is a consensus among various participating

organizations over the actual context data for a domain such as healthcare and creation of appropriate DTD(s). These will dictate the requirements of the parsers and validation components needed to complete such applications.

Thank You.

Vijayanand Bharadwaj, Ravi Raman, Ramana Reddy,Sumitra Reddy

{vbharadw, rraman, yreddy, sreddy}@wvu.edu