Quality Outcome Reporting for EMS: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
Jstamm (talk | contribs)
Afourquet (talk | contribs)
No edit summary
Line 4: Line 4:


==Summary==
==Summary==
''<Describe the profile in about a paragraph using user-oriented languageFocus on what it accomplishes for a user (i.e. the Use Cases). Don't get into how it works, leave that to the Details section.>''
New approaches to improvement to Emergency Medical Services (EMS) include leveraging clinical and process quality measures, including patient outcomesEMS is unique to medicine as it is impossible to separate administration/operations from clinical care. EMS is the only component of the healthcare system that brings the care to the patient. All other components require the patient to come to the care provider. These efforts are often manual and entail manual data collection, rather than utilizing electronic information that is already collected in EMS electronic Patient Care Record (ePCR) systems and provider electric health records systems. This profile will facilitate electronic data capture of quality measure data to enable automated data capture and streamline quality measure analysis.


''<Insert a simple graphic that, at a glance, visually summarizes what the profile is about.  Do not use an actor/transaction diagram here.  Show your graphic to someone for 5 seconds (literally) and ask them what it's about.  If what they say hits the main points in your summary paragraph, you have succeeded.  E.g. a graphic of a hospital, a clinic, and a lab with patient records moving between them.  .>''


''<See [[Help:Contents#Tips_.26_Tricks| Help - Tips and Tricks]] for details on inserting an image/graphic.>''
==Benefits==
This profile will improve the timeliness and accuracy of the information used to compute EMS quality measures.  


==Benefits==
''<If the profile can improve Cost, Safety, Quality or Efficiency then list the specific examples of that benefit (e.g. error reduction, increased throughput) and how they come about (e.g. SWF reduces patient errors due to mistyped demographics at the modality by transfering demographics electronically from the Order Filler).  Consider using a bullet list for readability.  Such benefits help users and vendors make the business case for the profile.  If the profile does not improve any aspect of Cost, Safety, Quality or Efficiency feel free to talk about something else here.>''


==Details==
==Details==


''<A few paragraphs, if appropriate, providing more details (mostly in user-speak, not tech-speak) on what the profile does and how it works.>''
This profile uses a query and a SEND transaction to move quality measurement data across several EMR entities that will allow for this data to be used for quality and registry measurement for Hospitals and EMS companies. These transactions utilize FHIR and the transactions are specified with the profile.  
 
 
''<If the user might be familiar with the mechanisms used by the profile, you can mention them here. E.g. Evidence Documents is based on DICOM Structured Report (SR) Templates.>''
 
''<If the user might have an appreciation for the problems addressed in the profile, you can mention them here, but keep it short.  E.g. Mapping HL7 Order fields to DICOM Modality Worklist attributes can be inconsistent in the marketplace, so Scheduled Workflow provides vendors with more detailed instructions.>''
==Systems Affected==
==Systems Affected==
''<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>''
''<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>''
Line 31: Line 25:


''<Insert an actor-transaction diagram, and or list of Content Definitions>''
''<Insert an actor-transaction diagram, and or list of Content Definitions>''
We expect that this profile will affect:
Hospitals may use it to send data to registries (e.g. STEMI or Stroke) or use it to respond to a query for information from an ambulance organization.
Ambulance organizations may use it to query the hospital for quality data measurement data or to send their measurement data to the registries that apply to their industry.
Registries may use it to query query the measurement data from either hospitals or ambulance organization.
Actors:
Data Responder - The Data Responder shall be responsible for the creation of content and the transmission of a QORE document to an Data Consumer.
Data Consumer - The Data Consumer is responsible for initiating a query to the Data Responder system for documents meeting certain criteria and can retrieve selected documents supplied by the Data Responder. Data Consumer is also responsible for receiving EMS quality data needed to compute EMS measures from the Data Sender. 
Data Sender - The Data Sender is responsible for sending EMS quality data needed to compute EMS measures to the Data Receiver.
Transactions:
Query for EMS Quality Data [QRPH-55] - The Data Consumer sends a query for an EMS Quality Data to the Data Responder. 
Send EMS Measure Report Data [QRPH-56] - The Data Sender sends quality measure report data to the Data Consumer. 


==Specification==
==Specification==

Revision as of 12:14, 10 May 2018

The QORE (Quality Outcome Reporting for EMS) profile profile will facilitate electronic data capture of quality measure data to enable automated data capture and streamline quality measure analysis. This will improve the timeliness and accuracy of the information used to compute EMS quality measures.

Summary

New approaches to improvement to Emergency Medical Services (EMS) include leveraging clinical and process quality measures, including patient outcomes. EMS is unique to medicine as it is impossible to separate administration/operations from clinical care. EMS is the only component of the healthcare system that brings the care to the patient. All other components require the patient to come to the care provider. These efforts are often manual and entail manual data collection, rather than utilizing electronic information that is already collected in EMS electronic Patient Care Record (ePCR) systems and provider electric health records systems. This profile will facilitate electronic data capture of quality measure data to enable automated data capture and streamline quality measure analysis.


Benefits

This profile will improve the timeliness and accuracy of the information used to compute EMS quality measures.


Details

This profile uses a query and a SEND transaction to move quality measurement data across several EMR entities that will allow for this data to be used for quality and registry measurement for Hospitals and EMS companies. These transactions utilize FHIR and the transactions are specified with the profile.

Systems Affected

<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>

  • PACS systems may store, manage, and/or display Evidence Documents.
  • Display systems may query, retrieve and display Evidence Documents.
  • Reporting workstations may retrieve, process and include details from Evidence Documents in reports

Actors & Transactions:

<Insert an actor-transaction diagram, and or list of Content Definitions> We expect that this profile will affect: Hospitals may use it to send data to registries (e.g. STEMI or Stroke) or use it to respond to a query for information from an ambulance organization. Ambulance organizations may use it to query the hospital for quality data measurement data or to send their measurement data to the registries that apply to their industry. Registries may use it to query query the measurement data from either hospitals or ambulance organization.

Actors: Data Responder - The Data Responder shall be responsible for the creation of content and the transmission of a QORE document to an Data Consumer. Data Consumer - The Data Consumer is responsible for initiating a query to the Data Responder system for documents meeting certain criteria and can retrieve selected documents supplied by the Data Responder. Data Consumer is also responsible for receiving EMS quality data needed to compute EMS measures from the Data Sender. Data Sender - The Data Sender is responsible for sending EMS quality data needed to compute EMS measures to the Data Receiver.

Transactions: Query for EMS Quality Data [QRPH-55] - The Data Consumer sends a query for an EMS Quality Data to the Data Responder. Send EMS Measure Report Data [QRPH-56] - The Data Sender sends quality measure report data to the Data Consumer.


Specification

Profile Status: Final Text <Replace "Final Text" with "Trial Implementation" or "Public Comment" as appropriate.>

Documents:

<Provide direct links to the specific volumes or supplements, and list the volume sections relevant to this profile. This is a simple inventory of official normative and informative text. If you would like to provide a reading guide or walkthrough of what is in each of the different sections for implementers or users, do that in the Profile FAQ or the Profile Implementation Page linked below. If the profile uses transactions from multiple Tech. Frameworks, repeat the structure below.>

IHE Radiology Technical Framework:

  • Vol. 1 - Section 5 (SWF Profile)
  • Vol. 2 - Sections 4.8 to 4.10, 4.14 to 4.19, and 4.23
  • Vol. 3 - Appendix E

Underlying Standards:

<list all the standards on which the profile is based; if possible with links to sources>

FHIR Implementation Guide

See Also

<The following sections can be left out if there is nothing to point to. This is just to show where such information can go.>


Related Profiles

<List profiles this one depends on, profiles that depend on this one, profiles that are synergistic with this one. Start with the name of the other profile as a link and then explain the relationship.>


Consumer Information

The Profile FAQ Template answers typical questions about what the Profile does. <Replace the link with a link to the actual FAQ page for the Profile>

The Profile Purchasing Template describes considerations when purchasing equipment to deploy this Profile. <Replace the link with a link to the actual Purchasing page for the Profile>

Implementer Information

The Profile Implementation Template provides additional information about implementing this Profile in software. <Replace the link with a link to the actual Implementation page for the Profile>

Reference Articles

<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis). Go ahead, Google: IHE <Profile Name> abstract or Google: IHE <Profile Name> and under the "more" select "Scholar". You might be surprised. >

This page is based on the Profile Overview Template