esMD+Transaction+Requirements

include component="page" wikiName="siframework" page="esMD Header"

The esMD transaction requirements are largely met by the following Nationwide Health Information Network web service specifications and related standards:
 * __Related Standards__**


 * [|Nationwide Health Information Network Document Submission] - Nationwide Health Information Network web service that provides the ability to “push” data for a given patient from one entity to another via configuration on the submission side. This specification recognizes and utilizes the Health Information Technology Standards Panel (HITSP) Document Reliable Interchange Transaction or HITSP/T31, Version 1.3, specification to enable Document Submission transactions over the Nationwide Health Information Network.
 * __Transaction Requirements__**

This initial analysis was based on v2.0 of the Nationwide Health Information Network Authorization Framework Specification
 * Authorization Framework**

a. In Section 2.1.2 Identify of the Record Target… i. The specification states "..the record target is the unambiguous person identity in the responding NHIO…". In the case of Document Submission, this should be the "…in the receiving NHIO…". A change to the specification is probably not required to address this. Many areas of this document identify a "receiving" or "responding" NHIO, which does not necessarily apply to the Document Submission service, but the intentions are probably still clear. ii. CMS does not have a concept of a person identity. Is this an issue that needs to be specifically addressed? b. Section 3.2 Specific Nationwide Health Information Network Assertions lists the required and optional elements in the authorization statement. i. Subject ID Attribute - In the case of release of information contractors (ROIs), is this the ROI or the provider or individual on whose behalf the disclosure is being made? Is it necessary to clarify this in the Profile? ii. Role Attribute - In the case for ROIs, is there a need for an additional User Role in HITSP C80? Or should this be specified as the role of the provider or other individual on whose behalf the disclosure is being made? iii. Purpose for Use Attribute - Should the Profile define the appropriate Purpose for Use? Are "Payment", "Fraud detection", or "Disclosure for insurance or disability coverage determination" appropriate? Should the Profile specify the correct purpose-for-use? iv. Patient Identifier Attribute - This attribute is optional. Should (or may) the claim ID or other identifier specific to esMD be specified as required within this field? Should the appropriate identifier be included in some other (metadata) field instead of the Authorization Framework? v. NPI - An NPI is required by esMD for logging purposes. Should Profile specify that this field in the assertion is required? Or should the NPI be included in some other (metadata) field?

This initial analysis is based on v1.1.0 of the Document Submission Emergence Pilot Web Service Interface Specification and on Revision 6.0 of the IHE IT Infrastructure Technical Framework Volume 3
 * Document Submission**

a. In Section 1.6 Relationship to other Nationwide Health Information Network Cooperative Specifications… i. This section states that "…when individually identifiable information is exchanged, then each NHIE must have a common understanding of the patient's identity…". ii. This project will include individually identifiable information, but the “common understanding” for CMS does not include unique patient IDs. Both organizations are aware of RAC IDs and claim numbers which can perhaps be used for this purpose. I do not believe there is any required action. Agreed? b. In Subject 2.2 Assumptions… i. This section likewise indicates that "…the patient to whom the document belongs… has had his/her identity from the receiving Nationwide Health Information Network determined…". ii. The only exchange prior to Document Submission will be the paper request for documentation, which will have identifiers for the request and claim, but not the patient. I do not believe there is any required action. Agreed? c. In Section 2.6 Technical Pre-conditions… i. This section likewise indicates that "…the identity of the patient at the receiving NHIE has been determined by [the] initiating Nationwide Health Information Network through some verifiable means…". ii. The means will be the paper request for documentation, which will not include an identifier for the patient. I believe this should meet this requirement. Agreed? d. In Section 3.4 Synchronous / Asynchronous Behavior… i. This section states that "…receiving NHIEs… may restrict submissions to use… asynchronous mode based on agreements with its trading partners…". ii. This will be the case for this project. Should the Profile state that requirement? iii. There is a need to finalize the specifics of how asynchronous exchange is supported by Document Submission to support this project in time for CONNECT to implement that behavior in line with the specification. My understanding is that a separate working group is addressing asynchronous exchange for Patient Discovery and Document Submission. Is there anything that can be done to accelerate that process? e. In Section 3.5.3 XDSDocumentEntry.patientId and Section 3.5.6 XDSSubmissionSet.patientId… i. This required element "…represents the… patient… from the Receiving NHIE's… domain…". ii. CMS does not have a unique patient ID for each patient. iii. Alternatives that might be used include claim numbers or RAC request IDs. 1) These numbers will be unique to esMD, but not necessarily unique to CMS. 2) A single patient may, and probably will, have several identifiers. 3) A claim number or RAC ID is unique to a single patient. Should one of these identifiers be used instead of the patient ID? Should a new field be added rather than “reusing” (i.e., “mis-using”) this field? f. In Section 4 Error Handling… i. Additional errors are likely necessary to specify: 1) Failure to pass document validation. Within the CARE Profile, this error is specified as CAREDocumentNotWellFormed. 2) Failure to include a recognized claim or other identifier. If the claim number or RAC ID is used as a surrogate patient ID, should this error be XDSUnknownPatientId or XDSPatientIdDoesNotMatch, or should a new error be added anyway? 3) Are there others we should be thinking about? g. There is no obvious place to include NPI as part of the message metadata, should it not be included in the Authorization Framework as a required assertion element. i. Should the Profile specify that it is a required assertion in the Authorization Framework? ii. Should a field be added to the metadata to specify the NPI instead? h. In Section 4.1.8 Submission Set Metadata of the IHE ITI-TF volume 3… i. There exists an optional metadata element intendedRecipient that “Represents the organization(s) or person(s) for whom the Submission set is intended.” ii. While CMS intends to implement a separate gateway for each current project, and there are pending updates to the Service Registry specification that would include a mechanism to identify the appropriate web service endpoint by Profile, should the Profile specify this as a required field to enable future routing capabilities?

include component="page" wikiName="siframework" page="esMD Header"