Difference between revisions of "Retrieve Form for Data Capture"
| Line 1: | Line 1: | ||
| − | |||
| − | |||
__TOC__ | __TOC__ | ||
| Line 7: | Line 5: | ||
Retrieve Form for Data Capture provides a method for gathering data within a user’s current application to meet the requirements of an external system. RFD supports the retrieval of forms from a form source, display and completion of a form, and return of instance data from the display application to the source application. | Retrieve Form for Data Capture provides a method for gathering data within a user’s current application to meet the requirements of an external system. RFD supports the retrieval of forms from a form source, display and completion of a form, and return of instance data from the display application to the source application. | ||
| − | |||
| − | |||
| − | |||
=Benefits= | =Benefits= | ||
| + | * ability to fill in form data within a user's current application | ||
| + | * standardized interaction for filling form data | ||
=Details= | =Details= | ||
| − | + | The Retrieve Form for Data Capture Profile (RFD) provides a method for gathering data within a user’s current application to meet the requirements of an external system. RFD supports the retrieval of a form from a form source, the display and completion of the form, and the return of instance data from the display application to a receiving application. In addition, RFD provides a mechanism to amend data that was previously captured. | |
| − | + | Consider the case where a healthcare provider site uses an Electronic Health Record (EHR) to document patient care. In this case, the EHR acts as the local home application for the provider’s personnel. Suppose an external agency, through some contractual arrangement, requires data from the provider, some of which reside in the EHR’s database, the rest requiring data entry by the EHR’s users. RFD enables the EHR user to retrieve a data capture form from the external agency, to fill out the form, and to return the data to the external agency without leaving the provider’s local home application, the EHR. The profile also permits the external agency to indicate that there is a need to clarify points about the data so captured and provides the mechanisms to allow the data to be modified. | |
| − | + | Many potential uses of RFD want the form to dynamically pre-populate forms from the host application’s database, that is have the form delivered with host application database values filled in to appropriate fields of a form. RFD permits automatic form population and provides a generic mechanism by which this can be accomplished. However, the profile does not speak to the issue of content, remaining silent on normative vocabularies and other enablers of semantic interoperability. Specific domain groups – clinical trials, drug safety, bio-surveillance – will build on RFD by contributing content specifications or by evaluating and recommending existing content standards that will operate within RFD. When RFD, as an infrastructure profile, integrates with domain-specific content standards, a much greater level of interoperability will result. | |
| − | + | The RFD profile provides a generic polling mechanism to allow an external agency to indicate issues with data that have been captured and enable the healthcare provider to correct the data. The profile does not dictate the mechanism employed or content required to achieve such corrections. | |
| − | + | In this profile, the external agency provides data capture forms in a schema appropriate to its domain. The profile intends to minimize the work that the displaying application should do, and to bring over fully functional forms that carry with them the instruction necessary to complete the form. The RFD Profile uses XForms technology to support negotiation between the form display and form provider systems, so that iterative exchanges can deal with issues like form selection, completion of a series of forms, partial completion of forms, returning to forms partially filled out in earlier sessions. RFD also supports archiving a copy of the completed form. | |
| − | |||
| − | |||
| − | + | RFD offers the capability to leverage industry standards that address both the structure and content of forms used for data capture. HL7’s Individual Case Safety Record (ICSR) and CDISC’s Operational Data Model (ODM) provide examples. | |
| − | + | The infrastructure provided by the RFD profile can be utilized by many domain groups and the following domain-specific use cases illustrate the wide variety of uses to which RFD can be made. | |
| − | == | + | =Systems Affected= |
| + | HIS | ||
| − | + | '''Actors & Transactions:''' | |
| − | [ | + | [[Image:RFD-Actor-Transaction.jpg]] |
| − | + | ==Specification== | |
| − | |||
| − | === | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | '''Profile Status:''' [[Comments| Trial Implementation]] | |
| − | [ | ||
| − | [http://www. | + | '''Documents:''' |
| + | * [http://www.ihe.net/Technical_Framework/index.cfm#IT Request Form for Data Capture (RFD)] Trial Implementation Supplement | ||
| + | :* Vol. 1 - Section 17 | ||
| + | :* Vol. 2b - Sections 3.34, 3.35, 3.36 & 3.37 | ||
| − | [http://www. | + | * [http://www.ihe.net/Technical_Framework/index.cfm#IT IHE IT Infrastructure Technical Framework Version 5 or later] |
| + | :* Vol. 2x - Appendix V, W | ||
| − | |||
| − | + | '''Underlying Standards:''' | |
| + | :* ETF RFC1738, Uniform Resource Locators (URL), December 1994, http://www.faqs.org/rfcs/rfc1738.html | ||
| + | :* IETF RFC2616 HyperText Transfer Protocol HTTP/1.1 | ||
| + | :* Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October 2000. http://www.w3.org/TR/REC-xml. | ||
| + | :* ITI TF-2x: Appendix V Web Services for IHE Transactions | ||
| + | :* XForms 1.1, W3C Working Draft. http://www.w3.org/TR/2004/WD-xforms11-20041115/ | ||
| + | :* XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition).A Reformulation of HTML 4 in XML 1.0. W3C Recommendation 26 January 2000, revised 1 August 2002. http://www.w3.org/TR/xhtml1. | ||
| + | :* XHTML™ Basic. W3C Recommendation 19 December 2000. http://www.w3.org/TR/xhtm-basic. | ||
| + | :* http://www.w3.org/TR/xhtml-basic | ||
| − | |||
| − | |||
=See Also= | =See Also= | ||
Revision as of 15:19, 22 March 2011
Summary
Retrieve Form for Data Capture provides a method for gathering data within a user’s current application to meet the requirements of an external system. RFD supports the retrieval of forms from a form source, display and completion of a form, and return of instance data from the display application to the source application.
Benefits
- ability to fill in form data within a user's current application
- standardized interaction for filling form data
Details
The Retrieve Form for Data Capture Profile (RFD) provides a method for gathering data within a user’s current application to meet the requirements of an external system. RFD supports the retrieval of a form from a form source, the display and completion of the form, and the return of instance data from the display application to a receiving application. In addition, RFD provides a mechanism to amend data that was previously captured.
Consider the case where a healthcare provider site uses an Electronic Health Record (EHR) to document patient care. In this case, the EHR acts as the local home application for the provider’s personnel. Suppose an external agency, through some contractual arrangement, requires data from the provider, some of which reside in the EHR’s database, the rest requiring data entry by the EHR’s users. RFD enables the EHR user to retrieve a data capture form from the external agency, to fill out the form, and to return the data to the external agency without leaving the provider’s local home application, the EHR. The profile also permits the external agency to indicate that there is a need to clarify points about the data so captured and provides the mechanisms to allow the data to be modified.
Many potential uses of RFD want the form to dynamically pre-populate forms from the host application’s database, that is have the form delivered with host application database values filled in to appropriate fields of a form. RFD permits automatic form population and provides a generic mechanism by which this can be accomplished. However, the profile does not speak to the issue of content, remaining silent on normative vocabularies and other enablers of semantic interoperability. Specific domain groups – clinical trials, drug safety, bio-surveillance – will build on RFD by contributing content specifications or by evaluating and recommending existing content standards that will operate within RFD. When RFD, as an infrastructure profile, integrates with domain-specific content standards, a much greater level of interoperability will result.
The RFD profile provides a generic polling mechanism to allow an external agency to indicate issues with data that have been captured and enable the healthcare provider to correct the data. The profile does not dictate the mechanism employed or content required to achieve such corrections.
In this profile, the external agency provides data capture forms in a schema appropriate to its domain. The profile intends to minimize the work that the displaying application should do, and to bring over fully functional forms that carry with them the instruction necessary to complete the form. The RFD Profile uses XForms technology to support negotiation between the form display and form provider systems, so that iterative exchanges can deal with issues like form selection, completion of a series of forms, partial completion of forms, returning to forms partially filled out in earlier sessions. RFD also supports archiving a copy of the completed form.
RFD offers the capability to leverage industry standards that address both the structure and content of forms used for data capture. HL7’s Individual Case Safety Record (ICSR) and CDISC’s Operational Data Model (ODM) provide examples.
The infrastructure provided by the RFD profile can be utilized by many domain groups and the following domain-specific use cases illustrate the wide variety of uses to which RFD can be made.
Systems Affected
HIS
Actors & Transactions:
Specification
Profile Status: Trial Implementation
Documents:
- Request Form for Data Capture (RFD) Trial Implementation Supplement
- Vol. 1 - Section 17
- Vol. 2b - Sections 3.34, 3.35, 3.36 & 3.37
- Vol. 2x - Appendix V, W
Underlying Standards:
- ETF RFC1738, Uniform Resource Locators (URL), December 1994, http://www.faqs.org/rfcs/rfc1738.html
- IETF RFC2616 HyperText Transfer Protocol HTTP/1.1
- Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October 2000. http://www.w3.org/TR/REC-xml.
- ITI TF-2x: Appendix V Web Services for IHE Transactions
- XForms 1.1, W3C Working Draft. http://www.w3.org/TR/2004/WD-xforms11-20041115/
- XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition).A Reformulation of HTML 4 in XML 1.0. W3C Recommendation 26 January 2000, revised 1 August 2002. http://www.w3.org/TR/xhtml1.
- XHTML™ Basic. W3C Recommendation 19 December 2000. http://www.w3.org/TR/xhtm-basic.
- http://www.w3.org/TR/xhtml-basic
See Also
Profile Status: Trial Implementation
The IT Infrastructure Technical Framework is the official master document for this Profile.
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.>
<Replace the Template links below with links to the actual pages for the Profile>
The Profile FAQ Template answers typical questions about what the Profile does.
The Profile Purchasing Template describes considerations when purchasing equipment to deploy this Profile.
The Profile Implementation Template provides additional information about implementing this Profile in software.
This page is based on the Profile Template