Difference between revisions of "Transitions of care (MU3)"

From OpenEMR Project Wiki
 
Line 35: Line 35:


Note for a valid CCDA document (in the United States) the patient encounter type MUST be an option that uses CPT4 codes.  Only encounter types from the following list are considered valid for the encounter type (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.3.88.12.80.32/expansion/Latest -- requires UMLS account).
Note for a valid CCDA document (in the United States) the patient encounter type MUST be an option that uses CPT4 codes.  Only encounter types from the following list are considered valid for the encounter type (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.3.88.12.80.32/expansion/Latest -- requires UMLS account).
For the Jeremy Bates scenario the healthy / wellness checkup for the encounter diagnosis must be entered in with two issues.  One is the healthy wellness checkup code and the other one is a SNOMED-CT code for "Problem".


===CCD-A Sections===
===CCD-A Sections===

Latest revision as of 21:01, 18 May 2022

This document is part of our OpenEMR Certification Stage III Meaningful Use Documentation

Status

  • Ready for testing

Notes

  • For testing Looks like we do have to use two different usernames for testing.
  • b(1) testing uses openemr-edge2015@directtest.interopengine.com the where h(1) requires us to use openemr@test.directproject.net sandbox username.

Testing companion guide stated the following: - The scope of this criterion is limited to the Consolidated CDA (C-CDA) Continuity of Care Document (CCD), Referral Note, and (inpatient setting only) Discharge Summary document templates. [see also 80 FR 62633]

So for ambulatory care we have

- Other sections can be found here: http://www.hl7.org/ccdasearch/

Data Entry

For the CCD-A to generate properly you must configure the Carecoordination settings to specify the author, legal authenticator, custodian, etc. These users MUST have their address information set up in the Address Book.

The facility must have the address information setup in the Facilities edit screen.

Facility and users must have populated the phone number and npi information as well.

Measurements for (b)(1) testing must be set to report as Metric (kg,Celsius, etc) for vital reporting.

To pass ONC testing, Phone numbers must be entered with a region specifier such as for US numbers: +<region>(XXX)-XXX-XXXX. For example a US number would be +1(555)-723-1544.

In order for Procedures to be stored in the CCD-A they must be entered in via the Fee Sheet (accessible by selecting the encounter and then accessing the Fees -> Fee Sheet screen).

Whereas labs are added using a Procedure Order in OpenEMR (NOT the fee sheet).

Clinical notes regarding procedures, labs are entered in using the Clinical Notes Form.

Note for a valid CCDA document (in the United States) the patient encounter type MUST be an option that uses CPT4 codes. Only encounter types from the following list are considered valid for the encounter type (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.3.88.12.80.32/expansion/Latest -- requires UMLS account).

For the Jeremy Bates scenario the healthy / wellness checkup for the encounter diagnosis must be entered in with two issues. One is the healthy wellness checkup code and the other one is a SNOMED-CT code for "Problem".

CCD-A Sections

The supported sections for Clinical Care Document (CCD) are as follows:

  • Medications Section (entries required) (V2) (required) (oid:2.16.840.1.113883.10.20.22.2.1.1)
  • Plan of Treatment Section (V2) (optional) (oid:2.16.840.1.113883.10.20.22.2.10)
  • Medical Equipment Section (V2) (optional) (oid:2.16.840.1.113883.10.20.22.2.23)
  • Nutrition Section (optional) (oid:2.16.840.1.113883.10.20.22.2.57)
  • Procedures Section (entries required) (V2) (optional) (oid:2.16.840.1.113883.10.20.22.2.7.1)
  • Functional Status Section (V2) (optional) (oid:2.16.840.1.113883.10.20.22.2.2.1)
  • Mental Status Section (V2) (optional) (oid:2.16.840.1.113883.10.20.22.2.3.1)
  • Immunizations Section (entries required) (V3) (optional) (oid:2.16.840.1.113883.10.20.22.2.4.1)
  • Results Section (entries required) (V3) (required) (oid:2.16.840.1.113883.10.20.22.2.5.1)
  • Vital Signs Section (entries required) (V3) (required) (oid:2.16.840.1.113883.10.20.22.2.18)
  • Problem Section (entries required) (V3) (required) (oid:2.16.840.1.113883.10.20.22.2.17)
  • Payers Section (V3) (optional) (oid:2.16.840.1.113883.10.20.22.2.21)
  • Social History Section (V3) (required) (oid:2.16.840.1.113883.10.20.22.2.17)
  • Advance Directives Section (entries optional) (V3) (optional) (oid:2.16.840.1.113883.10.20.22.2.21)
  • Family History Section (V3) (optional) (oid:2.16.840.1.113883.10.20.22.2.15)
  • Allergies and Intolerances Section (entries required) (V3) (required) (oid:2.16.840.1.113883.10.20.22.2.6.1)
  • Encounters Section (entries optional) (V3) (optional) (oid:2.16.840.1.113883.10.20.22.2.22)

Note we do not support importing or exporting the Payer nor the Nutrition template in OpenEMR

Procedure Activity Procedure Section is contained within the Procedures Section which we support

The supported sections for Referral Document types are as follows

  • US Realm Patient Name (PTN.US.FIELDED) (optional)
  • Assessment Section (optional)
  • Review of Systems Section (optional)
  • History of Present Illness Section (optional)
  • General Status Section (optional)
  • US Realm Person Name (PN.US.FIELDED) (required)
  • Medications Section (entries required) (V2) (required)
  • Plan of Treatment Section (V2) (optional)
  • Medical Equipment Section (V2) (optional)
  • Nutrition Section (optional)
  • Procedures Section (entries optional) (V2) (optional)
  • Functional Status Section (V2) (optional)
  • Reason for Referral Section (V2) (required)
  • Assessment and Plan Section (V2) (optional)
  • Mental Status Section (V2) (optional)
  • Immunizations Section (entries required) (V3) (optional)
  • Results Section (entries required) (V3) (optional)
  • Past Medical History (V3) (optional)
  • Vital Signs Section (entries required) (V3) (optional)
  • Problem Section (entries required) (V3) (required)
  • Physical Exam Section (V3) (optional)
  • Social History Section (V3) (optional)
  • Advance Directives Section (entries optional) (V3) (optional)
  • Family History Section (V3) (optional)
  • Allergies and Intolerances Section (entries required) (V3) (required)

- In order to satisfy the requirement of detecting valid / invalid CCDA 1.1 & 2.1 documents we have to use Schematron to validate all of this stuff. -- Technical outcome – The health IT can detect valid and invalid ToC/referral summaries upon receipt of C-CDA documents formatted to C-CDA Release 1.1 and 2.1.

Regulation Text

§ 170.315 (b)(1) Transition of care

  1. Send and receive via edge protocol—
    1. Send transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) and that leads to such summaries being processed by a service that has implemented the standard specified in § 170.202(a); and
    2. Receive transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) from a service that has implemented the standard specified in § 170.202(a)(2).
    3. XDM processing. Receive and make available the contents of a XDM package formatted in accordance with the standard adopted in § 170.205(p)(1) when the technology is also being certified using an SMTP-based edge protocol.
  2. Validate and display —
    1. Validate C-CDA conformance – system performance. Demonstrate the ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with the standards specified in § 170.205(a)(3), (4), and (5) for the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates. This includes the ability to:
      1. Parse each of the document types.
      2. Detect errors in corresponding “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in § 170.205(a)(3), (4), and (5).
      3. Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from the standards adopted in § 170.205(a)(3), (4), and (5).
      4. Correctly interpret empty sections and null combinations.
      5. Record errors encountered and allow a user through at least one of the following ways to:
        1. Be notified of the errors produced.
        2. Review the errors produced.
    2. Display. Display in human readable format the data included in transition of care/referral summaries received and formatted according to the standards specified in § 170.205(a)(3), (4), and (5).
    3. Display section views. Allow for the individual display of each section (and the accompanying document header information) that is included in a transition of care/referral summary received and formatted in accordance with the standards adopted in § 170.205(a)(3), (4), and (5) in a manner that enables the user to:
      1. Directly display only the data within a particular section;
      2. Set a preference for the display order of specific sections; and
      3. Set the initial quantity of sections to be displayed.
  3. Create. Enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in § 170.205(a)(3), (4), and (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:
      1. The data classes expressed in the standard in § 170.213 and in accordance with § 170.205(a)(4), (a)(5), and paragraphs (b)(1)(iii)(A)(3)(i) through (iii) of this section, or
      2. The Common Clinical Data Set in accordance with §170.205(a)(4) and paragraph (b)(1)(iii)(A)(3)(i) through (iv) of this section for the period until December 31, 2022, and
      3. The following data classes:
        1. Assessment and plan of treatment. In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).
        2. Goals. In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).
        3. Health concerns. In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).
        4. Unique device identifier(s) for a patient's implantable device(s). In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standard specified in § 170.205(a)(4).
    1. Encounter diagnoses. Formatted according to at least one of the following standards:
      1. The standard specified in § 170.207(i).
      2. At a minimum, the version of the standard specified in § 170.207(a)(4).
    2. Cognitive status.
    3. Functional status.
    4. Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information.
    5. Inpatient setting only. Discharge instructions.
    6. Patient matching data. First name, last name, previous name, middle name (including middle initial), suffix, date of birth, address, phone number, and sex. The following constraints apply:
      1. Date of birth constraint.
        1. The year, month and day of birth must be present for a date of birth. The technology must include a null value when the date of birth is unknown.
        2. Optional. When the hour, minute, and second are associated with a date of birth the technology must demonstrate that the correct time zone offset is included.
      2. Phone number constraint. Represent phone number (home, business, cell) in accordance with the standards adopted in § 170.207(q)(1). All phone numbers must be included when multiple phone numbers are present.
      3. Sex constraint. Represent sex in accordance with the standard adopted in § 170.207(n)(1).