Empowering Mobile Healthcare Providers via a Patient Benefits Authorization Service

1. 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

2. 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.

3. 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

4. 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.

5. Introduction Motivation Major hindrances to this process are • Limitedface-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.

6. 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.

7. 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”.

8. 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.

9. 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.

10. 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:

11. Outline • Previous Work • Foundation for mobile solution • Mobile Solution • Architecture • Implementation • Summary

12. 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

13. Previous Work • 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) Features

14. 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.

15. 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.

16. Operating System Previous Work Storage and retrieval of Transaction Context Web Server Workflow Engine Mail Server Database Architecture Agency Server Internet and the WWW 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 Agency Personnel Client Encrypted Communication using SSL 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 System Web Browser Email Client ActiveX Components Smart Card reader Physician Client .

17. Previous Work 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 ofinformation had to be entered Disadvantages with respect to Mobile users

18. 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

19. Mobile Solution Key Features • Use of common data exchange format to enable heterogeneous systems to interoperate. • Process efficiency improved through local workflow in theHealthcare Provider system.

20. Mobile Solution Architecture , Usage Scenario 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. Healthcare Provider # 3 Healthcare Provider #2 Healthcare Provider #1 Desktop Client Server Mobile Client XML DTD Local Repository Wireless Network 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. Internet Health Insurance Agency # n Health Insurance Agency # 2 Health Insurance Agency # 1 Server Local System 7. Agency system processes request & performs local workflow. 9. Send response (results sentsyn/asynchronously to care provider system which transmits to mobile client) XML DTD Local Repository

21. Mobile Solution Implementation 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. Healthcare Provider # 3 Healthcare Provider #2 Healthcare Provider #1 Desktop Client Server Mobile Client XML DTD Local Repository Wireless Network (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. Internet Health Insurance Agency # n Health Insurance Agency # 2 Health Insurance Agency # 1 Server Local System J2EE technology similar to the healthcare provider site for various tiers. (Java Servlets, EJB,JAXP) XML DTD Local Repository

22. Implementation • Candidate Enabling Technologies • J2EE • J2ME • HTTPS • Servlets/JSP with EJB • Wf-XML

23. Implementation Mobile User Application J2ME based application on the wireless device

24. Implementation Mobile User Application

25. Implementation Mobile User Application

26. Implementation Mobile User Application

27. Implementation Mobile User Application

28. 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

29. 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>

30. 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>

31. 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>

32. 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.

33. 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.

34. 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.

35. Thank You. Vijayanand Bharadwaj, Ravi Raman, Ramana Reddy,Sumitra Reddy {vbharadw, rraman, yreddy, sreddy}@wvu.edu