EZ-Suite Interfacing Applications. Jeremy Powell (Chief Growth Officer, Citra Health Solutions) Rini Jose (Product Manager, Citra Health Solutions)

Transcription

1 EZ-Suite Interfacing Applications Jeremy Powell (Chief Growth Officer, Citra Health Solutions) Rini Jose (Product Manager, Citra Health Solutions)

2 Agenda Items CITRA suite Current External Integrations EZ-PARTNER & EZ-CAP API Different Transaction Sets / APIs API Components Authorization Software Development Kit (SDK) Case Study CAQH CORE Connectivity Requirements Eligibility Request Response (270/271) Claims Status Request Response (276/277) Web services Connectivity Technical Requirements CORE Compliant Envelope Specifications CORE Compliant Envelop Message Automated file transfer with SFTP / FTPS Files upload / download via EZ-NET Web portal Claim Shop Q&A 2

3 3 Current External Integration

4 Citra suite provides breadth of capabilities Advisory Services Risk & Profile Management Care Setting Resolution Quality Enhancement Revenue Management CONTRACTING REPORTS & ANALYTICS REFERRAL MANAGEMENT CREDENTIALING ASSESSMENT NETWORK MANAGEMENT PATIENT OUTREACH AND EDUCATION CLINICAL CASE MANAGEMENT CLAIMS ADJUDICATION ENROLLMENT BILLING

5 Current integration capabilities present challenges Version EZCap EZCap EZCap ezcap ezcare eznet ezpartner SERVICES ezanalytics Custom Reports OHS CHS HEDIS ezinsight OHS-DW CHS-DW ACG ClaimShop Custom Scripts

6 ez cap ez insights ez care presentation business logic data

7 Next generation normalizes source data with Citra service through a gateway and service bus, allowing for faster time to market for new value based services Pharmacy Claims Encounter Claims Hospital ADT PCP/Special ists Patient-self reported Electronic Health Records Lab Results Demographics Allscripts Gateway Utility Services Health Information Exchange Gateway Value creation services Applications as a Services Decision Support Master Patient Index Population Health Re-admissions Chronic Care Management Analytics and Reporting Claims Security Outcome Measures Spine Care Payment Care Management Patient-centric warehouse 7

8

9 # NQF Measure Name Clinical Claims Diabetes: Hemoglobin A1c Poor Control (>9.0%) Diabetes - High Blood Pressure Control (< 140/90) Diabetes - Low Density Lipoprotein Control (<100) CAD - Angiotensin-Converting Enzyme (ACE) Inhibitor or Angiotensin Receptor Blocker (ARB) Therapy - Diabetes or Left Ventricular Systolic Dysfunction (LVEF < 40%) CAD - Low Density Lipoprotein Control (<100) IVD - Complete Lipid Profile and LDL Control (< 100) Diabetes - Hemoglobin A1c Control (< 8 percent) 1 0 9

10 10

11 11

12 12 EZ-PARTNER & EZ-CAP API

13 EZ-PARTNER Provides a mechanism to integrate external software applications with the EZ-CAP platform. Operates as a Transaction Orchestration server which processes specific transactions in a real-time environment. Interacts with external applications by means of a request file (.IN file extension), which contains the information to either query from or submit to EZ-CAP. Processes the request by polling a designated directory where the request file is placed, communicating the request to the EZ-CAP platform, and returning a response file (.OUT) in a designated directory, containing the result of the submission. 13

14 EZ-CAP API (Application Programming Interface) EZ-CAP API Software development kit allows external applications to interact with EZ-Suite to request or modify information stored in the EZ-CAP database. EZ-CAP API receives the Request input as a Stream Reader or API object, (Stream Reader with predefined tab separated data format) and returns a formatted Response (with tab separated data in a predefined format as a data stream) in the API object of the request transaction. The external software processes this response within its application domain. 14

15 EZ-PARTNER Transactions Sets / APIs Eligibility Inquiry (001) Authorization Inquiry (002) Authorization Request (003) Authorization Update (012) Provider Inquiry (004) Modifier Code Inquiry (005) Diagnosis Code Inquiry (006) Service Code Inquiry (007) Place of Service Inquiry (008) Claim Request (009) Customer Service Inquiry (010) Claim Inquiry (011) 15

16 API Request flow 16

17 17 EZ-PARTNER Dashboard

18 EZ-CAP Authorization API EZ-CAP Authorization API allows user to interact with EZ-Suite and access EZ-CAP data related to Authorization. Hardware and Software Requirements Auth. API is a.net application that runs on a PC-based local area network. EZ-CAP users need the following to install the API A computer to run the EZ-CAP API with dual network connection: Access to the disk drive where the external application resides. (For example, if the PMS application is a Unix application, then the machine running EZ-CAP API must be able to access the Unix disk.) To access the disk drive where the EZ-CAP database resides. Both the API server & the external application needs access rights to create, read, write, delete, and rename files on the disk drive where the external application resides. 18

19 Authorization Transactions Authorization Request (003) Used to submit authorizations (referrals) directly to EZ-CAP. The information returned in the response object contains details of the success or failure of the Authorization request. If the request was successful, the response object will return the EZ-CAP authorization number and status code. Authorization Update (012) Used to Update Authorization data in EZ-CAP. The information returned in the Response object contains details of the success or failure of the Modification requested. If the update was successful, the Response object returns the EZ-CAP authorization number and status code. 19

20 API Licensing Options - Light, medium and high Type1 (Light): API will process only Mandatory (required) fields. Light SDK will process the fields with Required column as yes as mentioned in API Specification format in Request Header table Type2 (Medium): API will Process Mandatory fields mentioned in API Format Specification document with some optional fields. Type3 (High): API will process ALL the fields mentioned in API Format Specification document. 20

21 Process Log Table The Log table can be used to view the processing details of (error/warning/pend messages) Authorizations entered into EZ- CAP via the EZ-CAP API API updates the log for every authorization entered by the API (Minimum one row per Request added to the log table.) If an Authorization Request contains no error/warning/pend messages, then single row will be added to the log table. If an Authorization request contains error/warning/pending messages, one row per error/warning/pending message will be added to the log. Users can create reports using this table to view the contents 21

22 22 CAQH CORE Operating Rules Phase 1 & Phase II Connectivity Rules Web services Implementation

23 Operating rules are crucial in a technology-driven world Organizations have a critical need to electronically share large quantities of data quickly and accurately. Many industries, such as banking and telecommunications, embrace technical standards and common business practices to simplify sharing data among many parties. Operating rules support standards, and then specify the business actions each party must adhere to in order to ensure a high volume of reliable transactions can occur smoothly in a given industry. 23

24 CAQH CORE Connectivity Rules The Committee on Operating Rules for Information Exchange (CORE ) Connectivity & Security Subgroup adopted existing open standards in formulating Connectivity Rules that provide industry specific (for healthcare administrative electronic transactions) guidance on using these open standards. The CORE Connectivity Rule was developed using a consensus-based approach among industry stakeholders, and is designed to facilitate interoperability, improve utilization of administrative transactions, enhance efficiency and lower the cost of information exchange in healthcare. 24

25 CORE Phase I Connectivity Rule The CORE Phase I Connectivity required the use of HTTP/S over the public Internet. Allowed: HTTP POST methods using name/value pairs, HTTP MIME Multipart, W3C XML Schema, and SOAP+WSDL (among others). Further, within each of these method implementations, significant variations exist in field names and locations of Phase I Connectivity metadata, including the message envelope structure, authentication methods, routing approaches and security-related information. These variations among enveloping methods and metadata pose a major challenge for interoperability. 25

26 CORE Phase II Connectivity Message Envelope Standards The CORE Phase II Connectivity created a definitive Rule that would further facilitate interoperability. The result is improved efficiencies and utilization of electronic transactions while lowering the administrative costs for healthcare providers and payers. CORE shortlisted two envelope standards that met the overwhelming majority of criteria HTTP MIME Multipart SOAP + WSDL SOAP+WSDL supports interface definition using an XSD schema/wsdl, automated development/validation, and is well-aligned with standards adoption within healthcare industry bodies. Citra adopted the SOAP + WSDL standard 26

27 CORE Phase II Connectivity XML Schema Specification The CORE Phase II compliant XML Schema Specification file name is called CORERule2.2.0.xsd, and is available at This schema has ten elements, each representing a type of Request or Response message envelope: Real time Request Schema (Element name is COREEnvelopeRealTimeRequest) Real time Response (Element name is COREEnvelopeRealTimeResponse) 27

28 The Real time Request Message Structure SOAP version 1.2 must be implemented by all Servers. The HTTP Headers are shown colored in blue. The WS-Security Username and Password token (shown in pink) is added to the SOAP Header by the platform from which the SOAP request originates. The portion of the SOAP envelope colored in green has the remaining metadata that is defined as part of the CORE Phase II Connectivity Rule (show in green). 28

29 Real Time Requests Real time requests must include a single inquiry or submission e.g., one eligibility inquiry to one information source for one patient. In this model the response from the message Receiver is either an error response or the corresponding ASC X12 message response (e.g., a TA1, 997 v or v if the request was a v ). Submitter Authentication and Authorization Handling The two methods for Submitter Authentication specified in this rule are: Username/Password using the CORE-compliant Envelope to send the UserName and Password, as specified in the CORE-compliant Envelope Metadata specifications. envelope. X.509 Certificate based authentication over SSL using the Secure Sockets Layer (SSLv3.0) open standard for client certificate based authentication. 29

30 30 HTTP File Transfer (EZ-NET Web portal)

31 EZ-EDI File transfer using EZ-NET Web portal (HTTP) Trading Partner Transfer mode configured as HTTP Submitter Services module HTTP path is configured on the Service Controller 31

32 32 FTP File Transfer

33 Automated EDI with FTP File pickup - Inbound EPF and X formats File drop - Outbound X Formats & Acknowledgements Trading Partner Transfer mode configured as FTP FTP Folder Structure FTP path is configured on the Service Controller 33

34 34 Claim Shop Interface

35 EZ-CAP Claim Shop Interface Seamless integration with EZ-CAP Interface added in EZ-CAP v6.5.1 Activation is required No server installation and updates Web service is hosted by MedAssets MedAssets installs updates Server is up and available 99.9% of the time

36 Pricing Hospital and Professional Claims using MedAssets managed care insurance pricing Get Contract and Copay values for the successfully priced claims Show Diagnosis Related Group (DRG) grouper details for Hospital Inpatient Claims Show Ambulatory Payment Classification (APC) details for each detail line for Hospital Outpatient Claims MedAssets CCI Edits Diagnosis-code validation, National Coverage Determinations (NCD), Local Coverage Determinations (LCD), Policy, Age, Gender, Medically-Unlikely (MUE), Modifier, and Advanced Beneficiary Notice of Noncoverage (ABN) Show Trigger Code, Excluded Code and Description for each detail line for Hospital Outpatient and Professional Claims DRG Claims (Hospital Inpatient Claims) not applicable for CCI Edits as they are included as part of pricing 36

37

38