1 / 3

David’s Proposal (360X Initial Phase)

David’s Proposal (360X Initial Phase).

micah
Download Presentation

David’s Proposal (360X Initial Phase)

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. David’s Proposal (360X Initial Phase) Mandatory Payload = MU2 Consolidated CDA. Qualifier: "leniency" (allowance for null or alternative codes) should be allowed in the following areas of structured data: coded procedures, coded immunizations, and coded results. All these were not in MU1, and are also not part of the "clinical information reconciliation" objective of MU2, whereas medications (RxNorm), med allergies (RxNorm), and problems (SNOMED CT) are required to be reconciled. All those are also new requirements to MU2. Optional Payload = additional structured or unstructured content (basic+, supplemental, administrative, etc.) including threaded "conversations/chatter" to assist clinician adoption. I actually believe that most EHRs can produce and send unstructured data (CDA, PDF, plain text, etc.). It's just that there aren't any standard for the specific formats or content types of unstructured data, and I don't think we should be making those requirements here Recommended (but not mandatory) Packaging Payload = XDM packaging and minimal metadata (per XDR and XDM for Direct Messaging specification) to assist EHRs in classifying/matching documents for incorporation. We have not discussed this on the past few calls, but it was mentioned a few calls back, and is already part of the ONC Final Rule as an optional standard, and is also recommend by the Direct Project Timeframe: HIMSS 2013 is February 2013. For solutions to be deployed and working in physician practices by that time, let's assume they were "working" for at least one full month, i.e., January 2013. Working backwards, that means they had to be installed, configured, and tested. Suppose that takes one month (and we all realize that because of holidays December is not really a full month for most people). That means that the EHR systems must be ready (development done) by the end of November. That is just barely two months from now. Every day that scope is not settled, the time frame shortens. Of course, if the timeframe is changed, then different considerations come into play.

  2. Yvan’s (Related) Follow-Up • I was on the Transport workgroup trying to address the packaging of the payload and the Transport workgroup voted that this aspect was the responsibility of the Payload workgroup. • I tend to agree that this group should address it. • This should include: • XDM wrapper as mentioned below • Referral ID: do we need this to identify the instance of the referral? • Multiple documents: how do we send them? • a. One at a time: how does the recipient know they have all the information? Does it matter to the referral consumer? • b. In a single transaction • i. One email with all attachments • ii. One submission set with all documents • c. Using a container of reference: same here, how does the recipient know they have all the information • i. XDS folders • ii. The email thread • I feel like the most realistic approach would be option b). • Does the group think that this is in scope?

  3. Mallika’s Proposed Phasing Phase 1 - Just connect (heterogeneous) - Clinician focused - Save LivesA. Simple exchange of existing clinical payload (consolidated CDA) from sender to receiver using Directed exchange.B. Return of consultation summary (consolidated CDA?) from receiver to sender using Directed exchange.C. In this phase referral information is limited to freetext entry of what is required to make the referral request.Phase 2 - Add useful workflow - Clinician and backoffice focused - Increase Adoption A. Simple exchange of existing clinical payload (consolidated CDA) from sender to receiver using Directed exchange.B. Return of consultation summary (consolidated CDA?) from receiver to sender using Directed exchange.C. Workflow (NEW for phase 2, this is how we raise the bar from a basic Phase 1)We propose that the 360X group work on defining elements of the payload for the referral workflow itself. This includes data elements for initial request, patient header, status, referral id, priority, referral reason, referral type, provisional diagnosis, insurance, chatter between participants and if/how these overlap with the CDA.Phase 3 - Add social elements - Clinician and patient focused - Game changerTo be defined, but perhaps this is where we start expanding CDA to include Steven Beller's Supplemental/Social Data

More Related