Transcript wetice2001_bharadwaj - Lane Department of Computer Science

Empowering Mobile Healthcare Providers via a
Patient Benefits Authorization Service
Vijayanand Bharadwaj, Ravi Raman, Ramana Reddy and Sumitra Reddy
Concurrent Engineering Research Center
Lane Department of Computer Science and Electrical Engineering
West Virginia University
June 21, 2001
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
Motivation
• 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.
Introduction
Motivation
Current 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.
Introduction
Motivation
Major 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.
Introduction
Motivation
• 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.
Introduction
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.
The physicians inability to provide a timely course of
treatment due to the above factors results in a
deterioration in the overall quality of care provided.
Introduction
Motivation
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:
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
Previous Work
Features
• 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.
Operating System
Previous Work
Workflow
Engine
Web Server
Mail
Server
Storage and retrieval
of Transaction
Context
Database
Architecture
Agency Server
Internet
and the WWW
1. Sends Initial HTTPS request &
Certificate
2. Receives ActiveX Components
Encrypted Communication using SSL
Agency Personnel
Client
3. Sends Filled Request Form
4. Receives Confirmation of Actions
5. Receives (later on) E-Mail
Notification
6. Logs on as before and checks
1. Sends Initial HTTPS
results
request and Certificate
2. Receives Tasks List
Operating System
Web Browser
Email Client
ActiveX Components
Physician Client .
3. Receives Request
Information
Smart Card reader
4. Sends Processed
Request which causes
auto E-Mail notification
Previous Work
Disadvantages with respect to Mobile users
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
Mobile Solution
Key Features
* 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.
Mobile Solution
Key Features
* Use of common data exchange format to enable
heterogeneous systems to interoperate.
* Process efficiency improved through local workflow in the
Healthcare Provider system.
Mobile Solution Architecture , Usage Scenario
1. Mobile user logs on
to system using a client
application running on
the wireless device
Healthcare Provider # 3
Healthcare Provider #2
Healthcare Provider #1 Desktop Client
Mobile Client
2. Upon authentication,
selects certain task to
be performed
XML
DTD
Local
Repository
Server
4. Backend service
processes user’s
request and performs
any local workflow.
3. Inputs required
information (PID, name)
and makes request.
Wireless
Network
Health Insurance Agency # n
Internet
Health Insurance Agency # 2
Health Insurance Agency # 1
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)
Server
Local System
XML
DTD
Local
Repository
Mobile Solution
Implementation
1. Java MIDlets run
on J2ME compliant
mobile clients .
Healthcare Provider # 3
Healthcare Provider #2
Healthcare Provider #1 Desktop Client
Mobile Client
XML
DTD
Local
Repository
Server
(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.
Wireless
Network
2. MIDlets send
requests to servers
over wireless n/w,
Java servlets are
invoked for tasks.
3. Corresponding
responses are
displayed.
Health Insurance Agency # n
Internet
Health Insurance Agency # 2
Health Insurance Agency # 1
J2EE technology
similar to the
healthcare provider
site for various tiers.
(Java Servlets,
EJB,JAXP)
Server
Local System
XML
DTD
Local
Repository
Implementation
• Candidate Enabling Technologies
– J2EE
– J2ME
– HTTPS
– Servlets/JSP with EJB
– Wf-XML
Implementation
J2ME based
application on the
wireless device
Mobile User Application
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
Implementation
Wf-XML Request Message
<?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
<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>
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>
Implementation
Wf-XML Response Message
<?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>
Implementation
Wf-XML Features
Features 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