Template:FHIR Resource Proposal

To use this Template:

1. Search (or Go to) for a page with name like xxxxx_FHIR_Resource_Proposal
2. Click on the RED link to the (previously) undefined page in order to edit it.
3. Type {{subst::Template:FHIR Resource Proposal}} as the only content for the new page.
4. Preview (if desired) to verify the reference was typed correctly
5. "Save" the page.

   At this point, the contents of this template (with the following exceptions) will replace the substitution link. The exceptions are:

   • These instructions will not appear.
   • The small blue-font annotations about each entry will be replaced with an <!-- XML Comment --> saying the same thing. These comments are visible while editing, but they do not appear when the Wiki page is previewed or saved.

6. Re-edit the page to include the appropriate content in each of the sections
7. Save again
   

The displayed contents below this line is the outline for a resource proposal

---

---

For additional guidance on considerations for resource creation, refer to FHIR Resource Considerations

PutProposedResourceNameHere

Resource names should meet the following characteristics:

• Upper 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 work group name

The name of the work group that is proposed to have responsibility for developing and maintaining the resources.
YourWorkGroupName

Committee Approval Date:

Please enter the date that the committee approved this Resource proposal

Contributing or Reviewing Work Groups

Additional work groups that may have an interest in contributing to, or reviewing the content of the resource (optional)

• Work Group Name
• or link
• or "None"

FHIR Resource Development Project Insight ID

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 [[1]]

Scope of coverage

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

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

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
• 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

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

List all of the specifications (beyond those in the standard 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

What are the resources 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)

Resource Boundaries

What are the boundaries between this resource and other resources where implementers might have questions about which should be used when?

Are we confident existing implementations will be able to make the distinction?

Timelines

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.)

When Resource Proposal Is Complete

When you have completed your proposal, please send an email to FMGcontact@HL7.org