IHE Retrieve Form for Data Capture (RFD) Profile IHE Retrieve Form for Data Capture (RFD) Profile...
-
Upload
kamryn-wattles -
Category
Documents
-
view
244 -
download
3
Transcript of IHE Retrieve Form for Data Capture (RFD) Profile IHE Retrieve Form for Data Capture (RFD) Profile...
Profile: RFD
2
Integrating the Healthcare Enterprise™
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
> 370 members: 55 healthcare professional organizations15 government agencies15 SDOs and trade associations40 provider, research and education organizations250 health IT and consulting companies
Implementation guides for use of HL7, DICOM, and other standards to meet specific workflow challenges
Profile: RFD
3
Retrieve Form for Data Capture (RFD)a standard for research data collection from EMRs
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
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)
Profile: RFD
4
Form Filler
EMR System
1. In patent record display, user selects form to be filled 2. EMR sends request for form with
attached patient record extract (CCD)
Form ManagerForm Receiver
EDC System
3. EDC prepopulates form with data from extract
4. EDC sends prepopulated form
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)
8. At end of reporting period, EDC creates consolidated submission, QA manager releases to agency
QRDA
Profile: RFD
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
Profile: RFD
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
Profile: RFD
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)
Profile: RFD
8
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]
Retrieve Form
Form Manager
B
Form Filler
A
Prepopulation Data (CDA)
Form
Profile: RFD
9
Participating Actors• Form Filler submits form data to
Form Receiver
Parameters• instanceData – data to be
submitted to the form receiver [Required]
Submit Form
Form Receiver
C
Form Filler
A
Profile: RFD
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)
Profile: RFD
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
Profile: RFD
13
CCD Header - recordTarget
Data Element Optionality XML structure location
Date of Birth R patientRole/patient/birthTime
Gender R patientRole/patient/administrativeGenderCode
Ethnicity O patientRole/patient/ethnicGroupCode
Race R2 patientRole/patient/raceCode
NOTE: Optionality = R for Required, R2 for Required if known, O for Optional
Slide courtesy of
Profile: RFD
15
CCD Sections Overview
Section Name Optionality Template ID
Active Problems R 1.3.6.1.4.1.19376.1.5.3.1.3.6
Past Medical History R2 1.3.6.1.4.1.19376.1.5.3.1.3.8
Procedures and Interventions R2 1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11
Social History R2 1.3.6.1.4.1.19376.1.5.3.1.3.16
Current Medications R 1.3.6.1.4.1.19376.1.5.3.1.3.19
Vital Signs R2 1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2
Slide courtesy of
Profile: RFD
16
Data Element Optionality Template ID
Physical Exam R2 1.3.6.1.4.1.19376.1.5.3.1.1.9.15
Allergies and Other Adverse Reactions
R 1.3.6.1.4.1.19376.1.5.3.1.3.13
Coded Results R2 1.3.6.1.4.1.19376.1.5.3.1.3.28
CCD Sections Overview (ctd.)
Slide courtesy of
Profile: RFD
17
CCD Medications Section
LOINC code identifies this section as Medication historyNarrative Text
Structured Data
Slide courtesy of
Profile: RFD
18
CCD Medications Section - text
ID may be referenced in structured data
Slide courtesy of
Profile: RFD
19
CCD Medications Section – coded entry
Med start and end time Route
Dose Medication Detail
Slide courtesy of
Profile: RFD
20
CCD Section - manufacturedMaterial
Medication code
Decoded name
Reference to original verbatim text
Slide courtesy of
Profile: RFD
21
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
Transformations
Slide courtesy of
Profile: RFD
22
Simple variable name mapping:
birthTime BRTHDTC
Transformations – Map Variables
<ItemData ItemOID='BRTHDTC'> <xsl:attribute name="value"
select="ClinicalDocument/recordTarget/patientRole/patient/birthTime/@value"/>
</ItemData>
Slide courtesy of
Profile: RFD
23
Simple code mapping (M 1, F 2):
administrativeGenderCode GENDER
Transformations – Simple Codes
<ItemData ItemOID='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
Profile: RFD
24
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
Transformations – Drug Codes
Slide courtesy of
Profile: RFD
25
Mapping between NCDR Cath-PCI and CDA
NCDR CDA NotesField ID Field Name Field Description Field Value
SetHierarchical message component
HL7 Value Set
210 Patient First Name
Patient First Name ClinicalDocument > recordTarget > patientRole > patient > name = name
Name data type has HL7 defined markup for components (given and family names) patient demographics are arbitrarily associated with the unique ID record target participation
220 Patient M.I. Patient Middle Initial 230 Patient Last
NamePatient Last Name
240 Patient SSN Indicate the nine-digit Patient’s Social Security Number (SSN). Although this is the Social Security Number in the USA, other countries may have different National Identification Numbers. For example, in Canada, this would be the Social Insurance Number.
ClinicalDocument > recordTarget > patientRole > id = ssnproviderOrganization >name = “US Social Security Administration”
Alternatively , name of provider organization may be for another country
242 Unique Patient ID
This is an arbitrary number (not a recognizable ID like SSN or Medical Record Number) that uniquely and permanently identifies each patient. Once assigned to a patient, this can never be changed or reassigned to a different patient. If a patient returns to the hospital, they MUST receive this same unique patient identifier.
ClinicalDocument > recordTarget > patientRole > id = unique idproviderOrganization >name = hospital name
SSN and unique ID are conveyed in separate record target participations; patient demographics (name, DOB, sex, race) are arbitrarily associated under this unique ID record target participation
Mapping by E. Honeycut (DCRI) and H. Solomon (GE) for HL7 Cardiology SIG
Profile: RFD
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