View source for VisionClaim FHIR Resource Proposal

=VisionClaim=

<!-- Resource names should meet the following characteristics:
* Lower camel case
* U.S. English
* Domain-friendly
* Short
* Clear
* Unique
* Avoid non-universal abbreviations (e.g. URL would be ok)
* Be expressed as a noun
* Be consistent with other similar resources
 -->

==Owning committee name==

<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. -->
[[Financial Management]]

==Contributing or Reviewing Work Groups==

<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the resource (optional) -->
* Claims with Attachments
* Patient Administration
==FHIR Resource Development Project Insight ID==
994
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->

==Scope of coverage==
The VisionClaim is one of a suite of similar resources (OralClaim, VisionClaim, PharmacyClaim, ProfessionalClaim, InstitutionalClaim) which are used by providers to 
exchange the financial information, and supporting clinical information, regarding the provision of healthcare goods and services. The primary uses of this resource is to support eClaims, 
the exchange of proposed or supplied products and services to benefit payors, insurers and national health programs, for treatment payment planning and reimbursement.

The Claim is intended to support:
<li>Claims - where the provision of goods and services is <b>complete</b> and reimbursement is sought.</li>
<li>Pre-Authorization - where the provision of goods and services is <b>proposed</b> and either authorization and/or the reservation of funds is desired.</li>
<li>Pre-Determination - where the provision of goods and services is <b>explored</b> to determine what services may be covered and to what amount. Essentially a 'what if' claim.</li>

<!-- Define the full scope of coverage for the resource.  The scope must be clearly delineated such that it does not overlap with any other existing or expected resource.  The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%"

Scope should consider numerous aspects of breadth of scope, including:
* Subject: Human vs. non-human vs. non-patient (e.g. lab bench medicine)
* Disciplines: Environmental Health, Palliative, Respiratory, Psychology, Maternity, Clinical Research
* Delivery environment (Community, Geriatric, Home care, Emergency, Inpatient, Intensive, Neonatal, Pediatric, Primary)
* Locale: Country, region

As a rule, resources should encompass all of these aspects.
 -->

==RIM scope==
PaymentRequest (classCode=XACT,moodCode=PRP,RQO)
<!-- Identify the formal RIM mapping for the root concept of the resource.  The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. -->

==Resource appropriateness==
Claims, and the variants of Pre-Determinations and Pre-Authorizations, are the means through which Providers submit patient rendered services to the Patient's insurers for reimbursement. The reimbursement may or may not be assigned to the Provider.
There are generally agreed types of claims based on the class of health discipline and adjudication engines are often segmented along these same lines of: OralHealth, Vision, Pharmacy, Professional (Medical and Chiro,Physio, Rehab - typically outpatient care) and Institutional (Hospital, clinic, etc).
<!-- Does the resource meet the following characteristics?

Must
* Represents a well understood, "important" concept in the business of healthcare
* Represents a concept expected to be tracked with distinct, reliable, unique ids
* Reasonable for the resource to be independently created, queried and maintained

Should
* Declared interest in need for standardization of data exchange</span>
* Resource is expected to contain an appropriate number of "core" (non-extension) data elements (in most cases, somewhere in the range of 20-50)
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document 
 -->

==Expected implementations==
This is a key resource expected by most Healthcare billing implementations where Vision Health care is provided.
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->

==Content sources==
Existing normative V3 and V2 specifications, 
Canadian Specifications, 
X12
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult

Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->

==Example Scenarios==

<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource.  They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->

==Resource Relationships==
Refers to VisionPrescription, Patient, Practitioner, Organization, Coverage, Referral, ClaimResponse.
Is referred to by ClaimResponse, ReconciliationResponse, Reversal, Readjudication, PaymentNotice, StatusRequest, FinancialAttachment, InformationCheck, ExplanationOfBenefit and occasionally by a Claim resource.
<!-- What are the resources do you expect will reference this resource and in what context?

What resources do you expect this resource reference and in what context?

Note: These may be existing resources or "expected" resource

Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
 -->

==Timelines==
Ready for DSTU 2
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->

==gForge Users==

<!-- Identify the userids who will require commit access to gForge to maintain the resource.  (Ensure all users have registered for gForge.) -->
paulknapp