Workflow and Challenges

Transcription

1 Interactive Discussion Between Providers and Payers on Proposed Changes to Attachments Workflow and Challenges Erik Pupo, Deloitte

2 Objectives of this session What are some common implementation challenges with CDA? Structured data versus unstructured data what is realistic for day 1 for both provider & payer? Interactive discussion on potential impacts of Complete Documentation Templates (CDT) to attachments for providers and payers What are some of the potential workflow changes? How can those challenges be resolved? What does attesting to an attachment mean? What do these proposed changes mean for providers and payers?

3 CDA Challenges Quality of implementation Using C32 as an example CCD/C32 has cascading references, excessive implementation options, and ambiguities which lead to variability in implementation C32 has very few absolute requirements adding the burden to the implementer On average only 30% of the C32 health summary is populated by the Department of Veteran Affairs (VA) On average only 15% of the C32 vocabulary guidelines are followed by the VA CDT has much more absolute requirements which has its own set of strengths and weaknesses

4 CDA Attachment Challenges The Big Issues Payers who want no controls on what can be asked for Understanding what CMS wants controls to be Providers who want no requirement for attachments Understanding the law says there must be a rule The Manageable Issues Predictable content from the provider to the payer Avoiding the provider sending the entire chart vs. prolonging adjudication Structured vs. unstructured vs. document image Coding versus text

5 What are common CDA implementation issues?

6 Smart CCDA Collaborative Findings One key takeaway from this research is that live exchange of C-CDA documents is likely to omit relevant clinical information and increase the burden of manual review for provider organizations receiving the C-CDA documents. Common challenges included omission or misuse of allergic reactions, omission of dose frequency, and omission of results in interpretation

7 Common CDA Issues with Data Elements Excess Precision in effectivetime Exclusive use of a physical quantity Unstructured Reaction for Allergies Great divergence in how vendors approached the documentation of allergic reactions. Difficulties in medication interval timing To communicate a medication prescription, one needs to know the drug, the dose timing and the amount to be administered at each dose. Most vendors expressed the drug in RxNorm with ease, but expressing the dose (as dosequantity) and the timing (as effectivetime xsi:type= PIVL_TS ) was more difficult. Use of deprecated LOINC codes Use of RxNORM codes at the incorrect level of precision Use of incorrect SNOMED-CT codes Lack of UCUM utilization

8 Major CDA Readability Issues The document contains entries without any textual representation. Some documents consist solely of entries. The standard states that all attested information must be present in human readable form. The stylesheet as used in the project adds information not present in document (e.g. the contact details of the author). This information could have been sent as part of CDA. If a different stylesheet is used, this information would be lost. The standard specifies that the attested contents of the CDA document have to be faithfully rendered without adding anything which may lead the human reader to misinterpret its contents. The stylesheet is not based on the text as present in the CDA document, but on its entries. Entries may not contain the exact same information as is present in the text - using the entries as a source for the stylesheet may lead to misinterpretation of the document contents. The entries are not an integral part of the attested content of the document. A stylesheet may only use the content of CDA document entries when the entries have a DRIV relationship with the text, i.e. if the sectiontext was fully derived from the entries.

9 Major CDA Entry Template Issues Broken links: unresolved references between entries and the textual content can cause validation problems Entries used as textual element an observation is effectively used as a textual section with an associated date. Technically this is a valid entry, in the spirit of CDA it is however questionable.

10 Major CDA Datatype Issues Identifiers: improperly formed IIs (e.g. root and extension swapped in one example; extension without root) Codes: Improperly formed CDs (code without codesystem), CD/CE with codesystem and codesystemname swapped, and entire CDA documents without a single codesystem attribute anywhere. Illegal URLs: "tel: 123.." - a space after the colon - this is not a valid URL. "tel:(555).." - the braces are not a valid URL. Or even not using a URL at all: value="somebody@somewhere.org". Timestamp (TS): Incomplete use of time zone (should be: -0800) Day and month cannot be 0 Invalid data type substitution (see fragment D3). The data type substitution rules are poorly understood.

11 Major CDA Coding Issues SNOMED qualifiers (CD data type) The qualifiers have to be taken from SNOMED if the main concept code is from SNOMED. The use of a different code system for a qualifier isn't allowed. Invalid UCUM units e.g. "picog", "md/dl". Must use allowed code sets. Attributes with CS data types, and attributes that have a CNE binding to a concept domain will use codes outside the defined value set Qualifier (CD data type) A code is required for a qualifier.

12 Common CDA Data Omissions Medication Timing Interval Majority of vendors are omitting medication timing information, even when known based on medication sig information. This is permitted in the CCDA IG since it is only a SHOULD conformance requirement, but it omits a key part of of prescription information dosequantity Some vendors did not include dosequantity on any medication or included the XML element but never populated with actual values. dosequantity is only a SHOULD conformance requirement since ratequantity would be used when no discrete dose is administered (e.g. for continuous IV infusion), but this omits a key part of of prescription information. interpretationcode Many vendors included this on every lab result and some included on vital signs as well. A few vendors omitted interpertationcode on any result observation or only included it on a minority of cases (i.e. when not normal). Some vendors also used this element in different ways (i.e. one used A for any abnormal results, where most used L for low and H for high when physical quantities were represented). methodcode or targetsitecode This data was generally omitted in CCDAs by most vendors. referencerange In a few cases, reference ranges were omitted from common lab results where they would be expected to be available

13 Issues with Not Entering Data Correctly act/statuscode. Vendors difficulty in managing the act/statuscode for active problems and/or allergies. act/effectivetime. Nearly all vendors showed confusion in how to populate the act/effectivetime information within allergy and problem sections of the CCDA. Most were simply replicating the biological onset and resolution dates as recorded in the observation element. dosequantity. Multiple vendors were not correctly using units within dosequantity as it relates to the level of medication specified by the RxNorm code. Once explained, most vendors understood the relationship and the necessity of coordinating units in a UCUM conformant manner. administrationunitcode. One vendor used administrationunitcode in a understandable, albeit technically incorrect way to specify additional drug form information. This element is only needed in the rare instances where a medication is described as an entire package (e.g. bottle of eye drops) but the unit of administered is smaller (e.g. an individual eye drop). Result observation/value. There were multiple questions from vendors on how to appropriately use UCUM for units and also in how to represent results which did not come as a specific value (e.g. less than 0.01). Allergy Code for Drug Allergy. At least one vendor shared a sample when the allergy was presented at the level of a pill (e.g. loratadine 10mg oral tablet) rather than the logical ingredient level (e.g. loratadine). While not controlled via conformance criteria, ingredient level information for allergies would likely make decision support and drug check easier to implement.

14 In summary. CDA is NOT THAT EASY TO DO Its created a whole industry around implementation, validation, testing, workflow optimization, business process engineering, system optimization, analytics

15 What are some of the challenges that CDT can bring and how can providers and payers adjust to them?

16 Where does the CDA fall into a payer workflow?

17 How does CDA XML map to the payer workflow?

18 Potential Workflow Advantages from CDT Predictable content You know what data is coming from provider to payer Payers can slowly learn what to look for Possible auto-adjudication benefits You have everything you would possibly need for adjudication

19 Potential Workflow Disadvantages from CDT You have to provide everything or say why you cannot Implications of using nullflavor CDA may not be the optimal choice to providing all this data CDA can have problems conveying workflowrelated information as well as information related to patient-location tracking in hospitals.

20 Most Common CDA Workflow Issues Coordinating Problem Status and Timing Information Coordinating Medical Interval, Dose and Code (PreCoordinated) Creating Drug & Class Allergies with Coded Reactions Creating a Highly Structured Lab Result Complete Vital Sign Set with BMI Coordinating Current Smoking & Tobacco Use

21 Simple CDA Workflow Example United Healthcare Technically the workflow is the same regardless of CDA document type Where the challenges for workflow lie is in 3 areas: 1. Transforming data into a format it can be sent into/received/analyzed 2. Populating data into the CDA 3. Using nullflavors as the mechanism to answer a question

22 Transforming Data into a CDA Converting data Is the data coming from multiple systems? Do I need to fill out missing identifiers and details? Can I convert local data types to HL7 data types? Data Quality consumer data Constructing Narrative (and format conversions) Determining the need for structure and non-structure Coding of structured data Facing the facts Attachments images and digital signatures

23 Populating a CDA Systems have been customized by organizations for internal use - however, it is clear that many systems were never designed to work together or to exchange data. Applications not targeted by Meaningful Use rules (such as pharmacy, lab, radiology, etc. applications) may not be capable of generating CDA documents on their own. Data input varies as well Different users enter data using different rules, and in some cases, they have interpreted and applied rules differently, even when the rules were supposedly uniform.

24 Use of nullflavor Smart CCDA found several issues with the use of nullflavors: In some instances, a nullflavor should have been specified when a code value was unknown. Instead, vendors utilized an invalid code or in one instance SNOMED code , which means Unknown. Commonly, the wrong nullflavor was used, with many vendors overutilizing nullflavor = UNK. This nullflavor is defined to be used when a proper value is applicable, but is not known in the CCDA IG. Its use in sample documents revealed two mistakes. First, UNK was used when a translation or noncoded value was readily available. In these circumstances, a more appropriate nullflavor would be OTH. Second, UNK was used when not applicable, such as effectivetime/high for an active problem. A more appropriate nullflavor may be NI or NA, although another common conventions omit such XML elements altogether. Empty XML tags (e.g. <title/>) are not legal Either a value, an explicit nullflavor, or an xsi:null should be used. Codeinstead of nullflavor attribute For example: code="unk"> instead of nullflavor="unk". originaltext The use of originaltext is only allowed if the nullflavor= "OTH".

25 Summing it up. These challenges are no different for any other type of healthcare interoperability scenario but they will require: Learning and adapting by providers and payers Providing detailed guidance and samples Vendor collaboration Will this be possible?

26 How might Attestation potentially work?

27 Attestation Progression - Planned

28 Expected Provider/Payer Environment for Attestation Digital signature on bundle of documents Standards to be used PKI: X.509v3 Signing Certificates (FBCA Medium) IHE DSG (XAdES) SAML Assertion for delegation of rights Environment Created as part of sending documents from provider to payer Validated upon receipt One signer (submitter) only for the full bundle of documents Delegation of rights as required to support authorization chain

29 Current Technical Possibilities XML-Digital Signature value inserted into the structure of the CDA document as an extension XML-Digital Signature in Encapsulating mode (Where the outer XML is XML-Digital Signature, and where the contained CDA is untouched) XML-Digital Signature in Detached mode (Where the XML- Digital Signature is itself a document that signs the CDA document by reference) S/MIME Digital Signature on the CDA Document and any images that go with it

30 Using Digital Signature in the CDA

31 Placing the Signature in the CDA Document

32 Obtaining a Digital Certificate

33 Act of Attestation

34 Digital Signature Usage Attesting a document as true copy - to verify that the document being used is the same as the original document and has not been modified by error or intent. Also important to establish the signer and the reason for signature Attesting clinical information content - a physician may choose to review a document and apply a signature to attest the report is complete and correct. Attesting to a diagnostic report - a doctor may verify a diagnostic report and apply a signature across both the source data and the diagnostic report. This provides a proof that the original data has also not changed since the diagnosis was made. Co-Signatures and Counter-Signatures. This functionality allows for complex workflows that might need to have signatures in a specific order. Signing multiple documents. This functionality produces one signature that signs multiple documents.

35 Potential Attestation Issues Document authors should make sure the attestable content of the document is present in the form of human readable text (for review) It is not yet clear what technological approach would work best It is envisioned that different attestation scenarios could exist Change in mindset Desire of providers to review Conducting reviews What does the user interface for review look like?

36 Conclusion How can we make this work? Structured data vs. unstructured data Capturing data in a structured manner can be challenging, so allowing for some conditionality here is needed Ensuring that CDA is generated each time and not used as the database by EHR vendors Each payer may have specific data requirements Payers should create a companion guide with specific business rules and guidance on how to populate Payers would have flexibility to make some information conditional based on need Reconciling perceived contrasting approaches Send me every data element by populating every template Send me situational data (only the templates I need) Commenting and engaging Remove emotion and embrace middle ground

37 Attachments Laurie Darst, Mayo Clinic

38 Current Claim Attachment Challenges Requests for additional information may be misrouted at hospitals and large medical facilities Payers may lose attachments or are unable to reassociate the paper attachment with the claim The need for additional information (attachments) is a major source of pended and/or denied claims One estimate indicates there are 700 million attachment requests annually

39 Recognized Industry Benefits Providers Reduced payment delays due to requests ROI available by saving people, paper and postage Reduced denials and rework for failure to provider additional documentation Health Plans ROI available by saving people, paper and postage Reduced rework Fewer pended claims for documentation requests

40 Collaboration: WPS and Mayo Clinic Early 2005 preliminary discussions on the concept of an electronic claim attachment project Determined unsolicited attachment type would be the ideal Collaborated on unsolicited attachment opportunities Agreed to implement operative report attachments in situations where there was a 22 or 62 modifier present Structured text (versus scanned image) would be sent The operative would be electronically stapled to the 837 claim using the 275 transaction Factor in the HIPAA minimum necessary requirements Our mutual goal was to implement this into our production processes this was not just a proof of concept pilot

41 Mayo Project Process & Challenges Created an edit in our claims scrubber software to flag for an operative report in those situations when there was a 22/62 modifier present on a surgical procedure code Wanted to automate the request for operative reports (no human intervention) Needed to work with mapping software vendor to do enhancements to their mapping tool to allow us to populate the BIN segment with the data from our surgical reporting system Determined how to merge data from two systems (Surgical Reporting System and Claim Scrubber Software) into one document EDI staff from Mayo and WPS needed expertise for programming the CDA R2 document structure reached out to HL7 CDA R2 expert

42 Project Results: Success!! Moved electronic operative report claim attachments into production on May 15, 2006 Operative reports are sent the same day as the claim The claim attachment control number linked the claim and the attachment so programming done at WPS allowed the nurse reviewers to easily review the operative reports at the same time the claims is received WPS staff reported the claim was adjudicated within 1-2 days after the claim was sent Mayo received payment for these services days sooner than the cumbersome development letter process Change in Medicare Carrier in 2013 project was replicated to do unsolicited operative reports - claim attachments with NGS

43 Attachments Mary Lynn Bushman, NGS

44 Attachments Current Attachment Success Accept the X with embedded HL7 Perform standard level edits on the 275 Map the 275 and HL7 data to an XML file Pulled into our imaging system Clinical staff is able to review the data and make payment determination on the claim Mayo is being paid quicker than waiting for us to request the data

45 Attachments Current Model in Production X Version 6020 HL7 CDA R2 Unsolicited model only Sending attachment information for surgical procedures billed with 22 or 62 modifiers Phase 2 in analysis

46 Attachments Current Example CURRENT STATE using CDA R2: <?xml version="1.0"?> <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:mif="urn:hl7-org:v3/mif" xmlns:xsi=" xsi:schemalocation="urn:hl7-org:v3 CDA.xsd"> <typeid root=" " extension="pocd_hd000040"></typeid> <id root=" " extension="47"></id> <code code=" " codesystem=" " codesystemname="loinc" displayname="op REPORT"></code> <effectivetime value=" "></effectivetime> <confidentialitycode code="n" codesystem=" "></confidentialitycode> <recordtarget> <patientrole> <id root=" " extension=" a" assigningauthorityname="medicare"></id> <patient> <name> <family>lastnm1</family> <given>first</given> </name> <administrativegendercode code="m"></administrativegendercode> <birthtime value=" "></birthtime> </patient> <providerorganization> <id root=" "></id> <name> <suffix>mayo CLINIC</suffix> </name> </providerorganization> </patientrole> </recordtarget> <author> <time value=" "></time> <assignedauthor> <id root=" " extension=" "></id> <assignedperson> <name> <family>last</family> <given>first</given> </name> </assignedperson> <representedorganization> <id root=" "></id> <name> <suffix>mayo CLINIC</suffix> </name> </representedorganization> </assignedauthor> </author> <custodian> <assignedcustodian> <representedcustodianorganization>

47 Attachments Future Content With the proposed approach for Attachments, the CDA will need to include the current state as well as the following sections. Each section also includes entry level data. There may be several entry level data elements is a section. As a note, if this information is not captured or determined by the physician to not meet the minimum necessary requirements, the physician will have the option to state that the data is not available or not applicable. However, each section must either contain the appropriate data (section and entry level data) or the null value indicated not available or not applicable.

48 Attachments Future Content Additional Documentation Section (CDT) Anesthesia Section (V2) Complications (V2) Externally Defined CDE Section (CDT) Implants Section (NEW) Medical Equipment Section (V2) Operative Note Fluid Section Operative Note Surgical Procedure Section Orders Placed Section (CDT) Payers Section (V2) Physical Findings of Skin Section (New) Plan of Treatment Section (V2-CDT) Planned Procedure Section (V2) Postoperative Diagnosis Section Preoperative Diagnosis Section (V2)

49 Attachments Future Content Procedure Description Section Procedure Disposition Section Procedure Estimated Blood Loss Section Procedure Findings Section (V2) Procedure Implants Section Procedure Indications Section (V2) Procedure Specimens Taken Section Surgery Description Section (New) Surgical Drains Section

50 Attachments Payer Business Impacts to consider with Future State Additional data will not always be necessary with all scenarios Additional data increases the size of the file Provider will choose to either default to the null flavors or just go ahead and send the entire record as this is easier to do. Therefore plans must consider this in their implementation. Large files will add costs for storage May increase the processing time since clinical staff will need to weed through the additional data May be out of compliance with Minimum Necessary requirements

51 Attachments Payer Business Impacts to consider with Future State May increase the processing time since clinical staff will need to weed through the additional data If Plan is able to take in codified data and process, this would not occur. Unfortunately it appears that many systems cannot take in codified data and therefore will relay on their clinical staff to perform additional work. May be out of compliance with Minimum Necessary requirements

52 Mind the Gap Level Setting: Types of attachments and amount Formats currently in use Methods of communications Goal for attachments: Payer -Use of attachments by Payer Provider - Use of attachments by provider Challenges and Solutions Low Tech to High Tech

53 Level Setting Types of Attachments and Frequency Invoices, Itemized Bills, Clinical Documentation Explanation of Benefits Prior Authorization

54 Level Setting Payer Query: Number of attachments received: 18%+ Explanation of Benefits* Medical Records Itemized Billed, letters, other *More payers are able to use the primary payment data sent in the claim

55 Level Setting Provider Response: Number of Attachments Sent: 15%+ Explanation of Benefits Medical Records Other *Certain payers such as Workers Compensation are most always paper with attachments

56 Level Setting Formats currently in use Paper or other hard copy media Digitized paper (PDF) Formatted data directly from a system: X-Rays Formatted information HL7 X12 Transactions (837 COB)

57 Level Setting Methods of communications Hand delivery Snail Mail Clearinghouse Secure File Transfer Protocol Web Services HTTPS Health Information Exchanges Secure including the Direct Protocol

58 Goals Payer Patient Safety - Efficacy - Cost Minimum Necessary Provider Treatment Payment for a service - delivered Approval for a service - yet to be delivered Appeals

59 Challenges Payer Getting the right information Solicited vs. Unsolicited Paper Standard Electronic Formats Provider Sending information Timely Sending enough information to satisfy a payer request securely Finding applications that interface with one another without a lot of manual intervention

60 Step Solutions Allow Access to the pertinent Information Move to standard format Remove Manual Intervention Digitize Paper Create Workflow

61 Step Solutions Paper - Now Send and Receive secondary claims electronically Digitize paper Accept electronic claims with PWK and send an attachment in an electronic method Utilize the methods available for transport of attachments Clearinghouse HUBs Health Information Exchange Standard Formats months Use the current X12 transactions Prior Authorization Referral Learn to re-purpose the HL7 transactions including C-CDA for administrative purposes Learn to use new standard formats e-pa Access - Future When/ Where Available Allow access to medical records Integrate PHR data with Provider Data Connect PHRs EHRs HIEs

62 Time for Questions