1 / 26

IHE Retrieve Form for Data Capture (RFD ) Profile Presented at NCDR.11

IHE Retrieve Form for Data Capture (RFD ) Profile Presented at NCDR.11. Integrating the Healthcare Enterprise™. > 370 members: 55 healthcare professional organizations 15 government agencies 15 SDOs and trade associations 40 provider, research and education organizations

gyula
Télécharger la présentation

IHE Retrieve Form for Data Capture (RFD ) Profile Presented at NCDR.11

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. IHE Retrieve Form for Data Capture (RFD) ProfilePresented at NCDR.11

  2. Integrating the Healthcare Enterprise™ > 370 members: 55 healthcare professional organizations 15 government agencies 15 SDOs and trade associations 40 provider, research and education organizations 250 health IT and consulting companies Implementation guides for use of HL7, DICOM, and other standards to meet specific workflow challenges • A public-private collaboration • Improve patient care and provider efficiency by harmonizing electronic health information exchange • Facilitating standards-based connectivity in all products • IHE Cardiology – sponsored by ACC, ASE, ASNC and HRS • www.IHE.net

  3. Retrieve Form for Data Capture (RFD)a standard for research data collection from EMRs RFD developed by IHE with - the clinical research standards organization EMRs have one interface supporting all research data entry EDCs have one interface supporting all EMRs Prepopulation based on patient document produced by EMR (e.g., Continuity of Care Document) • EMRs must support ever increasing research / quality data collection for diverse organizations • Researchers need a way to integrate with a broad variety of EMRs • Integration must facilitate prepopulation of data forms from EMR data

  4. EMR System EDC System Form Filler Form Manager Form Receiver 1. In patent record display, user selects form to be filled 2. EMR sends request for form with attached patient record extract (CCD) 4. EDC sends prepopulated form 3. EDC prepopulates form with data from extract 5. User manually completes form 6. EMR sends completed form, stored in EDC database 7. QA manager reviews data, adds subsequent info (e.g., discharge data) QRDA 8. At end of reporting period, EDC creates consolidated submission, QA manager releases to agency

  5. Other RFD Capabilities (Options) • Form Archiving – submitted form may be independently archived for audit purposes • Retrieve Clarification – Form Filler (EHR) can retrieve previously submitted forms that have been marked by Form Manager for rework/clarification

  6. Yes, It’s Real! • RFD demonstrated at IHE Connectathons by: • EMRs: Allscripts, Cerner, e-MDs, Epic, GE Centricity, Greenway • EDCs: Cerner, Fujitsu, IPL, IBM, Nextrials, OmniComm, Outcomes

  7. RFD for NCDR • Responsibility for data collection and quality remains with NCDR certified EDC systems • Simplified integration with EMRs • Prepopulation data in XML (HL7 CDA) • Minimally patient demographics, current medications, dates of procedures (Continuity of Care Document) • Additional prepopulation data from procedure-specific CDA reports (e.g., Cardiac Imaging Report)

  8. A Form Filler B Form Manager Retrieve Form • Participating Actors • Form Filler requests form from Form Manager • Parameters • formID – formID of the form being requested [Required] • archiveURL – URL of form archiver [Optional] • prepopData – data to be used to prepopulate the form [Optional] Prepopulation Data (CDA) Form

  9. A Form Filler C Form Receiver Submit Form • Participating Actors • Form Filler submits form data to Form Receiver • Parameters • instanceData – data to be submitted to the form receiver [Required]

  10. Prepopulation data - CDA • CDA is an XML structure that uses HL7 V3 Reference Information Model classes and data types • CDA itself is not a specific type of health document, but can be used to define many types of documents using constraints • A CDA document contains a standard header, and a document body • The document body contains sections, all of which contain narrative text, and some of which contain structured and coded data elements • There are many types of CDA documents, including: • Continuity of Care Document (CCD – required by US Meaningful Use regs) • XDS-MS Discharge Summary (HITSP C48) • History and Physical (HITSP C84) • Cardiac Imaging Report (in development by IHE Cardiology)

  11. Sample CDA

  12. Documents for NCDR prepopulation • All EMRs will be producing CCDs to comply with Meaningful Use regulations • More specific cardiology specific CDA document templates under development in IHE Cardiology • Initial Cardiac Imaging Report Content (CIRC) to be released 2Q2011 • Start with CCD, evolve to other document types

  13. CCD Header - recordTarget NOTE: Optionality = R for Required, R2 for Required if known, O for Optional Slide courtesy of

  14. CCD Header - recordTarget Name Gender Date of Birth Slide courtesy of

  15. CCD Sections Overview Slide courtesy of

  16. CCD Sections Overview (ctd.) Slide courtesy of

  17. LOINC code identifies this section as Medication history Narrative Text Structured Data CCD Medications Section Slide courtesy of

  18. CCD Medications Section - text ID may be referenced in structured data Slide courtesy of

  19. CCD Medications Section – coded entry Med start and end time Route Dose Medication Detail Slide courtesy of

  20. Medication code Decoded name Reference to original verbatim text CCD Section - manufacturedMaterial Slide courtesy of

  21. Transformations • Although EMRs agree to send CCD, a transformation is still necessary to bridge from CCD to the world of research – this is readily done using XSLT Slide courtesy of

  22. Transformations – Map Variables Simple variable name mapping: birthTime BRTHDTC <ItemDataItemOID='BRTHDTC'> <xsl:attribute name="value"select="ClinicalDocument/recordTarget/patientRole/patient/birthTime/@value"/> </ItemData> Slide courtesy of

  23. Transformations – Simple Codes Simple code mapping (M  1, F  2): administrativeGenderCodeGENDER <ItemDataItemOID='GENDER'> <xsl:attribute name="value"> <xsl:choose> <xsl:when test="…/administrativeGenderCode='M'"> 1 </xsl:when> <xsl:when test="…/administrativeGenderCode='F'"> 2 </xsl:when> </xsl:choose> </xsl:attribute> </ItemData> Slide courtesy of

  24. Transformations – Drug Codes • If CCD and target system use the same coding system, codes can be directly mapped • If using different coding systems, several possible techniques: • Pull verbatim text into the target system and re-code • Use a thesaurus and allow selection from a possible set of equivalent codes in the target coding system Slide courtesy of

  25. Mapping between NCDR Cath-PCI and CDA Mapping by E. Honeycut (DCRI) and H. Solomon (GE) for HL7 Cardiology SIG

  26. Profile: RFD Next steps • Read the RFD technical specification • http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_RFD_Rev2-1_TI_2010-08-10.pdf • Commit to implementation of RFD • Participate in the Connectathon in January 2012 • Join IHE International – it’s free! • Engage in the domain technical committees – Cardiology, IT Infrastructure, or Quality, Research & Public Health • Help create the CDA templates for Cath PCI Report and other NCDR-related encounters

More Related