1 / 43

Records Management and Evidentiary Support (RM-ES) Update

Records Management and Evidentiary Support (RM-ES) Update. Foundational considerations for esMD’s Author of Record Workgroup and assuring infrastructure trust . Agenda Outline. About the HL7 EHR RM-ES Workgroup. What is RM-ES? Records Management and Evidentiary Support

didier
Télécharger la présentation

Records Management and Evidentiary Support (RM-ES) Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Records Management and Evidentiary Support (RM-ES) Update Foundational considerations for esMD’s Author of Record Workgroup and assuring infrastructure trust

  2. Agenda Outline

  3. About the HL7 EHR RM-ES Workgroup • What is RM-ES? • Records Management and Evidentiary Support • Sub Workgroup of the HL7 EHR Workgroup • Developing EHR-S Functional Model Standards • EHR-S FM Release 1; EHR-S FM Release 1.1 (ISO); • Under Development – EHS-S FM Release 2 (Ballot planned December 2011 – April 2012) • RM-ES Standard • Functional Profile derived from the HL7 EHR-System Functional Model release 1 • RM-ES Projects: • Advance RM-ES Functions in the HL7 EHR-S FM Release 2 • Record Infrastructure • Metadata Framework • Begin development of RM-ES Functional Profile Release 2 (after EHR standard complete) • Metadata for HIE Functional Profile • Evidentiary Medical Record Ballot – environmental scan of other HL7 standards • Interoperability/Lifecycle Model - CDA – RM-ES Crosswalk • Support esMD Project – requirement development

  4. About the HL7 EHR RM-ES Workgroup • Workgroup Leads: • Michelle Dougherty, MA, RHIA, CHP, AHIMA • Reed Gelzer, MD, MPH, HIT Policy and EHR Specialist, Provider Resources, Inc. • Meetings: • Open Meetings Every Monday Conference Calls at 12 Noon EST • Wiki (Under Development and Being Updated) • http://wiki.hl7.org/index.php?title=EHR_RM-ES • Member Expertise • HIM, HIT, Compliance (regulatory and billing), Medical Record Auditors, Legal, Clinical, Case Management, Record Management, Interoperability

  5. Record Management & Evidentiary Support • Primary Drivers: Quality of the record of care -- especially accuracy, integrity, and timeliness • Objective: Maximizing the utility of patient data for the purposes of supporting clinical patient care and organization operations for clinical patient care • Scope: The health care enterprise assigns primary responsibility for patient care to the organizations and individuals providing that care. Therefore the affirmative duty of each specific organization and provider is to assure accuracy, integrity, reliability of the record of care • Exchange of patient data is a secondary function whose value is dependant on the quality of the source record • Aggregate patient data for other than patient care support is a secondary function whose value is dependent on the quality of the source record • Result: Increasing interconnectivity with other domains • Privacy/Security • Attachments • CDA and Structured Documents

  6. Records Management in the US:Layered Requirements • Records Management Foundations • Business Records rules • Jurisdictional requirements • Compliance requirements • Legal system rules • Payer rules • Facilities Requirements • Statutory • Operations • Process-specific requirements: Program Integrity • Claims Review Contractors • Recovery Audit Contractors, others

  7. RM-ES Functional Standards HL7 EHR System Functional Model RM-ES Functional Profile Standards (R1) (Focused On: User Authentication, Access Controls, Information Attestation, Record Support Development of EHR-S FM Release 2: New Record Lifecycle Management Improve Comprehensiveness of Audit & Metadata Functions Metadata for HIE Functional Profile Developed a draft for comment ballot based on EHR-S FM R2 Structure (we expect significant modifications)

  8. Agenda Outline

  9. RM-ES esMD Project Scope(HL7 Chartered Fall 2011) This project will: Evaluate the business requirements of ESMD for the possible utilities or necessities of RMES conformance (including use cases expressing patient, work, and information flows) and, where utilities or necessities are identified Map to current appropriate technical standards requirements, and If gaps or inconsistencies are identified, describe them in sufficient detail to support follow-on projects to develop the necessary technical standards requirements to eliminate them, in conjunction with other standards already embedded in ESMD.The project will initially focus on business requirements for well circumscribed, limited, and practical Use Cases (Ex: Progress Notes with digital signature(s)) and then potentially expand to other documentation types.

  10. Landmines for the esMD Project (from an RM-ES perspective) Purpose • Establishing, preserving and transporting document-level proof of authorship • Accurately capturing, preserving and transporting the ability for a Claims Review Contractor to identify who provided what services or goods as documented within the medical record • Continuous chain of trustworthiness of electronic claims attachments from data source creation Scope • Authorizing the validity of document content, regardless of the format of the structured content of the record. • All content of a patients chart in scope: The signature solution with any relevant document/content • Signature pertains to document entry made at time of service

  11. esMDand Navigating Landmines(from an RM-ES perspective) Important Qualifier • Scope will be revisited/re-evaluated by the workgroup if necessary following completion of environmental scan • Pending standard definitions or Certification requirements for the content of medical record system outputs for health information exchange , the Claims Review Contractor will have to blindly accept the provider organization’s definition of their “official” medical record output(s) • Stipulations of minimum content, pertinent to authoring, rigorously consistent with existing CMS Policy, appears within esMDAoR Scope

  12. The esMD RMES Team Records Management and Evidentiary Support (RMES) Sub-Workgroup Supporters of the Special esMD Project Beth Acker Veterans Administration Kim Baldwin-Stried Lake County Physicians’ Association Bobbi Bonnet Kaiser Permanente Chad Brouillard Foster and Eldridge, LLP Gary Dickinson CentriHealth Michelle Dougherty*AHIMA Barbara Drury Pricare, Inc. Reed Gelzer* Provider Resources, Inc. Susan Niederkorn American Osteopathic Association Patricia Powles Veterans Administration Robert Tennant MGMA Serafina Versaggi Eversolve, LLC Lydia Washington AHIMA *co-Chairs

  13. Agenda Outline

  14. Author of Record Purpose and Scope Author of Record Workgroup Purpose Statement The purpose of this workgroup is to investigate and recommend options to replace provider wet signatures on paper clinical documents with an electronic solution that provides document level proof of authorship. This solution must be identified in order for CMS to accurately authenticate who documented within the medical record, and trust the validity of the electronic claims attachments received.

  15. Author of Record Purpose and Scope In Scope: • Solutions that can replace wet signatures to authorize the validity of document content on a patient’s medical record, and can work regardless of the format of the structured content of the record. • All content of a patients chart is considered in scope: The signature solution should work with any relevant document • This workgroup may provide suggestions to CMS regarding policies needed to support the recommended solution • Signature pertains to document entry made at time of service • Scope will be revisited/re-evaluated by the workgroup if necessary following completion of environmental scan Out of Scope: • Revisions or additions made after the date of service for the claim

  16. Claims Attachments’ Constituencies Concerns Communicated To HHS Excerpted from page 3 of the NCVHS Chair letter to Secretary Sebelius

  17. What gaps are we trying to address? • Solutions that can replace wet signatures to authorize the validity of document content on a patient’s medical record, and can work regardless of the format of the structured content of the record. • Today’s Problems: • EHRs have not addressed signature and document validity (HIM/Record Management principles) • Signatures are no guarantee of identity • Not clear what the signatures means • It is not possible for a claims processor to assume that what is represented as a progress note was created in compliance with CMS guidelines for documentation of services • Important points to discuss: • What is it that you sign? • What does my signature mean? • Is the signature bound to content? • What technical standard supports the signature? • What is an export from the EHR? • Does the object for export need to be signed and who is it signed by?

  18. Agenda Outline

  19. Authorship & Role (Content Creation) • Gap: • What is signed? • What does the signature mean? • Is the signature bound to content? • RM-ES Principle: • All authors and contributors to a record entry/document should be identified and retained • Optimally, their role should be specified • Authorship relates to signature and what it means • Problem: • EHR systems today may over write the author and retain only one not reflecting who did what • An author/contributor’s role that the signer has is not clear • Why it matters to esMD Author of Record: • Payers (like CMS) specify services that must be performed by specific qualified professionals or mechanism to reimburse for split services • https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/downloads//eval_mgmt_serv_guide-ICN006764.pdf • Today’s EHR systems wouldn’t provide assurances based on documentation of who documented what to be a valid business record for payment purposes • Discussion: • Is authorship assurance important to esMD?

  20. Signatures (Attestation of Content) • Gap: • What is signed? • What does the signature mean? • Is the signature bound to content? • What technical standard supports the signature? • RM-ES Principle: • The “signature” finalizes a record entry by the author/contributor • Locks the entry so that further alternation is completed through proper amendment/correction procedures) • Systems must be able to handle more than one signature for a record entry/document and tie the content to the author and related signature • There should be a signature “ceremony (process) that reflects an intent to sign and acceptance terms • The technical process to support the signature should be strong enough to guarantee identity • The signature should be bound to the content through it’s lifecycle and with exchange • Problem: • Need to define what the signatures means in an EHR • The intent of the signature is dependent on the role • Lack of standards for the application of an e-signature (including what to call it) • Various requirements for e-signatures that haven’t been harmonized • The concept of binding signature to content isn’t well understood with data reuse and HIE

  21. Signatures (Attestation of Content) • Gap: • What is signed? • What does the signature mean? • Is the signature bound to content? • What technical standard supports the signature? • Why it matters to esMD Author of Record: • Payers (like CMS) require signatures for specific types of providers to pay a claim* • Today’sEHR systems do not utilize signature technology that verifies identity and binds to content. * https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/downloads//eval_mgmt_serv_guide-ICN006764.pdf • Discussion: • What does an author sign? • What does the author’s signature do? • Should the signature remain bound to the content? What if it is a component of the content used out of context • What standards/technical approach should be used?

  22. Exporting Content from the EHR to Payers • Gap: • Minimal definition of the content of the medical record created and maintained in the EHR • RM-ES Principle: • Content is bound to the author/signer • Signature stays with content through lifecycle and exchange • Provider organizations must define their official representation (output) of the medical record for disclosure purposes • Problem: • EHR content is highly variable with minimal standards on content and data elements. • Will the payer accept what the provider defines as the record? • Will the payer accept records created where the system generates content based on business rules? • Should there be standards for the content of the record content? • How does data pulled from various sources and placed in a CDA impact the authenticity of the record bound by the signature? • Why it matters to esMD Author of Record: • Frustration expressed with variability and quantity of medical record content. • Content is critical for making payment determinations (particularly medical necessity) • Discussion: • What is an export from the EHR? • Does the object for export need to be signed and who is it signed by?

  23. Agenda Outline

  24. esMD RM-ES Narrative • Origination: Predated S&I Initiative • Work began Summer 2011 • Purpose and Scope (previously stated) • Evaluate the business requirements of ESMD for the possible utilities or necessities of RMES conformance (including use cases expressing patient, work, and information flows) and, where utilities or necessities are identified • Initial focus: 1) Progress Note supporting tasks of Claims Review Contractors 2) Clinical Orders • Map to current appropriate technical standards requirements, and • If gaps or inconsistencies are identified, describe them in sufficient detail to support follow-on projects to develop the necessary technical standards requirements to eliminate them, in conjunction with other standards already embedded in ESMD. • Alignment with S&I • Supports preliminary work for Author of Record WG

  25. esMD RMES Narrative Progress Note Task: Supporting the needs of an organization receiving a request for a rendering/view of services provided in an episode of care use by a Claims Review Contractor (CRC) Attentive to Author of Record: Primary focus on authorship considerations • Creating a basic, simplistic episode of care narrative • Detailed assertions • Detailed constraints • Identifying limitations • Identifying the appropriate pertinent terminology • Identifying the appropriate range of discretion for designing a Progress Note output • Identifying the appropriate range of discretion in determining the minimum necessary information for a CRC

  26. esMD RMES Preliminary Findings Key findings regarding Author of Record considerations Terminology harmonization across EHR-S/RMES, Security, Claims Attachments, and Structured Documents will be vital and extraordinarily valuable Articulating and defining “Author” variants and types is necessary Includes clear and concise real world illustrations of functional and operational support requirements CDA definitions facilitate illumination of capabilities and limitations “Author” and “User” functions inextricably linked, with Privacy and Security requirements facilitating reduction of range, variability in challenges to RMES principles Current state of Standards and varies from important environmental factors Rules and regulations Case law Substantial impact anticipated: esMD uptake will greatly benefit the US marketplace, speeding reductions in variations in EHR System design and use, improving system data quality and information integrity

  27. Preliminary Recommendations for AoR • Use case simplicity • Consistent reminders of the unique conditions of organizations’ interactions with Claims Review Contractors and Program Integrity support • Include mapping to at least four types of EHR information recorders in the HL7 CDA R2 normative specifications • Data enterer • Author • Authenticator • Legal Authenticator • Reference other pertinent Standards • Be prepared to break new ground, carefully

  28. esMD/RMES NarrativeWork in Progress For Future Use Case Provide illustrations of how the narrative illuminated key questions and informs recommendations Ex: “Authoring” detail required to support provider’s interests and claims review contractors interests in assuring proper scope of care boundaries and episode complexity represented Ex: Claims Review Contractor requirements and Evidentiary supports, where are boundaries for “data” and “metadata” specific to Author of Record considerations

  29. Agenda Outline

  30. Electronic Signature Requirements and Guidelines Inventory • Compiling a Resource on -- • Existing rules, regulations, and guidance on electronic signature requirements in US domains • Thank you Serafina Versaggi for creating the inventory • Maintained on HL7 G Forge • What is Emerging: • Required characteristics for signatures (including electronic/digital signatures) • How it could be used for AoR: • Provides a launching point for the WG to understand what are the current requirements across various stakeholders for medical record signatures (wet, electronic, digital)

  31. Agenda Outline

  32. esMD RMES Key QuestionsOverview Progress Note Task: Supporting the needs of an organization receiving a request for a rendering/view of services provided in an episode of care use by a Claims Review Contractor (CRC) Attentive to Author of Record: Primary focus on authorship considerations • Creating a basic, simplistic episode of care narrative • Detailed assertions • Detailed constraints • Identifying limitations • Identifying the appropriate pertinent and harmonized terminology • Identifying the appropriate range of discretion for designing a Progress Note output • Identifying the appropriate range of discretion in determining the minimum necessary information for a Claims Review Contractor

  33. Assess Utilities of CDA Authoring Types dataEnterer: Represents the participant who has transformed a dictated note into text. A person entering the data into the originating system. The data entry person is collected optionally for internal quality control purposes. This includes the transcriptionist for dictated text. Author: Represents the humans and/or machines that authored the document. A party that originates the Act and therefore has responsibility for the information given in the Act. Authenticator: Represents a participant who has attested to the accuracy of the document, but who does not have privileges to legally authenticate the document. An example would be a resident physician who sees a patient and dictates a note, then later signs it. (See also legalAuthenticator (§ 4.2.2.8 )) • A verifier who attests to the accuracy of an act, but who does not have privileges to legally authenticate the act. • A clinical document can have zero to many authenticators. While electronic signatures are not captured in a CDA document, both authentication and legal authentication require that a document has been signed manually or electronically by the responsible individual. An authenticator has a required authenticator.time indicating the time of authentication, and a required authenticator.signatureCode, indicating that a signature has been obtained and is on file.

  34. Authoring User Types legalAuthenticator: Represents a participant who has legally authenticated the document. The CDA is a standard that specifies the structure of exchanged clinical documents. In the case where a local document is transformed into a CDA document for exchange, authentication occurs on the local document, and that fact is reflected in the exchanged CDA document. A CDA document can reflect the unauthenticated, authenticated, or legally authenticated state. The unauthenticated state exists when no authentication information has been recorded (i.e., it is the absence of being either authenticated or legally authenticated). While electronic signatures are not captured in a CDA document, both authentication and legal authentication require that a document has been signed manually or electronically by the responsible individual. A legalAuthenticator has a required legalAuthenticator.time indicating the time of authentication, and a required legalAuthenticator.signatureCode, indicating that a signature has been obtained and is on file.

  35. Authoring User Types Participant: Used to represent other participants not explicitly mentioned by other classes, that were somehow involved in the documented acts. recordTarget: The recordTarget represents the medical record that this document belongs to. A clinical document typically has exactly one recordTarget participant. In the uncommon case where a clinical document (such as a group encounter note) is placed into more than one patient chart, more than one recordTarget participants can be stated.

  36. ConsiderWhat is being signed Produced = (aka Render or View) a construct from the EHR-System that represents that system’s output for a Progress Note For Claims Review (PN4CR). The RMES requirement is that that there be a clear records management and evidentiary path for all elements of the PN4CR, including the organization’s authoritative entity vouching for its soundness and compliance with PN4CR requirements. Two options hypothesized:

  37. What is being signed First Option: Conceptualize the EHR system’s production of an artifact meeting esMD requirements for a Progress Note for Clinical Review purposes (PN4CR). This would perhaps be one of multiple output options from the EHR-System. The output for PN4CR requires that a responsible entity affirm that the output meets the stipulated requirements for that PN4CR. This affirmation is separate and distinct from Record Entry authors. In effect, the production of an end user-specific document that is a compilation of data from the system purporting to meet the end-user’s specifications and business requirements. As a compilation, its creation is an action that requires a Record Entry validated in some manner by a responsible, authoritative entity. That responsible entity may be an individual as author or the entity may be a business rule set with an authoring entity (or individual). This would mean that the output is itself the result of a given individual’s act, requiring an authenticated (“signed”) action record, with necessary attributes (ex: date, time). May apply to larger institutions

  38. What is being signed Second Option: The Act of authentication, attestation, and assertion of completeness and accuracy of the output content bound by authors’ signatures could include, by policy, assertion that the output mode itself complies with PN4CR specifications. This would convey that the authors are also taking responsibility for fitness of the system and its configuration for the purposes of producing the PN4CR. This may apply to a smaller enterprise.

  39. Who and How Many Authors (and of what?) Questions: Should record multiple authors into an esMD export object or artifact? If so, what level of detail? • Most Basic: Is it pertinent to a CRC to know that more than one individual acted in a care-delivery role and recorded their actions and observations into the EHR?  Yes or No • Less Basic: Is it pertinent to a CRC to know the identities and roles of each individual that acted in a care delivery role and recorded their actions and observations into the EHR? • More Detailed: Is it pertinent to a CRC to know the identities and roles of each individual, and to associate that individual with those services they provided and the services they in turn recorded in the record?

  40. Who and How Many Authors (and of what?) Questions: Should record multiple authors into an esMD export object or artifact? If so, what level of detail? Taking into account the collated answers to the questions in items 1-3, again, constrain the question only to our Use Case narrative, deliberately limited to two authors each providing different services and recording those services as separate authoring events in the EHR system.  Thus instructed, to what extent, if any, does the construct that is conveyed to the CRC have to include a view or rendering of all the Progress Note data in a manner that includes (or excludes):  • The presence of information input from more than one authoring individuals, not necessarily both individually identified (presumably all agree that at least the final author in this Use Case must be individually identified in the rendering sent to the CRC via esMD.) • The presence of information input from each of two identified authoring individuals or • The assignment of the services provided by each of the two identified individuals, each individual’s contribution to the services readily identified (as in a paper record). Alternatively, we can pass this question to one or more Claims Review Contractors for further input or consideration by CMS for policy alignments

  41. Agenda Outline

  42. Additional Questions and Discussion

  43. The esMD RMES Team Beth Acker Veterans Administration Kim Baldwin-Stried Lake County Physicians’ Association Bobbi Bonnet Kaiser Permanente Chad Brouillard Foster and Eldridge, LLP Gary Dickinson CentriHealth Michelle Dougherty* AHIMA Barbara Drury Pricare, Inc. Reed Gelzer* Provider Resources, Inc. Susan Niederkorn American Osteopathic Association Patricia Powles Veterans Administration Robert Tennant MGMA Serafina Versaggi Eversolve, LLC Lydia Washington AHIMA *co-Chairs

More Related