esMD+Open+Issues


 * Please Note:** There was a script error during a save and all the notes were deleted. They have been restored from a cached version on Google, but notes between 5/24 and 6/16 have been lost.

** Current Open Issues from Dan Kalwa (CMS) for the 6/16/2010 esMD meeting: **

The meeting on the implementation of 275 in esMD specifically and X12 transactions in general has yet to occur. The current version of the file contains only 275 information, per our conversations last week. Christine Stahlecker's comments have been incorperated into the current esMD 275 profile.

** Current Open Issues from Dan Kalwa (CMS) for the 5/17/2010 esMD meeting: **

CMS believes that all of the technical issues raised on the calls have been addressed. If there are no further comments on this draft we will move it to final.


 * Current Open Issues from Dan Kalwa (CMS) for the 5/12/2010 esMD meeting:**

We have reformatted the profile document to conform with previously published documents.

Keith Boone suggested that we remove our proposed extra metadata element "Contractor ID" and instead use existing "intededRecipient" metadata filed. The question to the group is: Can we require that participants fill that field with CMS specified data? The field was inteded for use as a routing element so that we can send the files to the correct CMS contractor.


 * Current Open Issues from Dan Kalwa (CMS) for the 5/5/2010 esMD meeting:**"

The updated version of the esMD profile now contains error messages for this profile.

CMS is exploring extending the XDS submission set metadata to allow for our CASE ID and CLAIM NUMBER field requirements rather than attempting to utilize an existing metadata field.

**Open Issues provided by Dan Kawla (CMS) for the 4/27/2010 esMD meeting:**

1. Whether there are additions to the enumerations for role and/or purpose for use in the Authorization Framework. a. Discussed the possible need for a role to address submissions of ROIs, or whether such submissions would better be described by the role of the provider, etc, on whose behalf the submission was being made. b. Unclear from the discussion whether a submission performed by the administrative staff for a provider should be identified as a role of Administrative Staff or Medical Doctor. c. Impression of workgroup: It is unlikely that any new roles are required. The profile should probably identify those roles that CMS would accept. d. Action: CMS team is to review the roles in the current HITSP C80 specification and determine which roles are most appropriate for this profile. e. Discussed the most appropriate purpose-for-use, and whether "Payment" was likely to be acceptable. f. Impression of the workgroup: Payment should be appropriate. Fraud Detection is not appropriate. g. Action: No action at this time.  2. How best to ensure that the provider NPI is included in the Document Submission exchange and available to CMS. a. Impression of the workgroup: The NPI in the SAML assertion should remain optional, as its purpose is helping implement policy for exchange of information, not identification of the source of documentation. It should instead be included in the document payload, which would in turn ensure that it appears in the metadata associated with Document Submission. b. Action: Research the Author and Legal Entity fields in the CDA and determine if one or both are appropriate for the NPI.
 * h. CMS believes that any of the roles may be necessary since it expects to communicate with most (if not every) different types of providers in the course of various audits and investigation. **
 * c. Based on research CMS believes that either field would be acceptable.**

3. How to address requirements to include the recipient organization’s patient ID in the message when CMS has no patient ID.
 * a.** **CMS would like to use the CLAIM ID provided by our contractors to fill the PATIENT ID.**

4. How to include the case ID in the message to identify the request for documentation correlated to the submission. a. Impression of the workgroup: The case ID should be used as the patient ID to fill the requirements to include a patient ID. Additional patient demographics should also be included in the CDA document to help RACs and MACs ensure an appropriate match. b. Action: Research with the RACs and MACs to determine what demographic information, perhaps in addition to a claim number, should be included in the C62 document.
 * c. Based on the research: CMS suggest using the CLAIM ID in the Patient ID field and CASE ID could go in another field. Perhaps DESCRIPTION.**

5. What errors need to be added to Document Submission to address esMD requirements.

**The following analysis was provided by Rim Cotheren for the 4/21/2010 esMD meeting:**

Five main issues to be addressed:

1. Whether there are additions to the enumerations for role and/or purpose for use in the Authorization Framework. 2. How best to ensure that the provider NPI is included in the Document Submission exchange and available to CMS. 3. How to address requirements to include the recipient organization’s patient ID in the message when CMS has no patient ID. 4. How to include the RAC ID and/or claim number in the message to identify the request for documentation correlated to the submission.

5. What errors need to be added to Document Submission to address esMD requirements.

I am hopeful that resolution of these issues will create few changes or no changes to the current specifications, and at most that any required changes would be minor in scope. Portions not contributed by visitors are Copyright 2010 Tangient LLC.**
 * Contributions to http://standards-and-interoperabilty-specifications.wikispaces.com are licensed under a** [|**Creative Commons Attribution Share-Alike 3.0 License**]**.