> For the complete documentation index, see [llms.txt](https://docs.snomed.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snomed.org/implementation-guides/cancer-synoptic-reporting-implementation-guide/5-technical-application/5.2-standardized-model-representation-using-fhir/5.2.1-fhir-resources.md).

# FHIR Resources

There is no specific FHIR Resource applicable for Synoptic Cancer Reporting, and the diversity of information required in different types of cancer makes it very difficult to use a single FHIR resource; this leads to the need for a specific FHIR resource for every kind of cancer.

Creating a new FHIR resource is a collaborative and iterative process. It requires significant engagement with the healthcare community to ensure that the resource is both technically sound and clinically relevant. The ultimate aim is to facilitate interoperability and improve patient care by representing health data in a standardized and meaningful way.

These are the typical steps involved in the creation of a new FHIR Resource:

1. **Identification of Need** :
   1. Consult with oncologists, pathologists, and IT professionals. Review current FHIR resources to ensure there's no overlap with existing structures concerning synoptic cancer reporting.
2. **Initial Research** :
   1. Gather templates and standards currently used in synoptic reporting. Identify unique data elements necessary for the report.
3. **Drafting the Proposal** :
   1. Define the data elements, structure, and relationships of the new resource. Document the purpose and use cases of the proposed resource.
4. **Community Engagement** :
   1. Share the draft proposal with relevant FHIR workgroups to gather feedback. Refine the proposal based on the insights and suggestions from the community.
5. **Development & Prototyping**:
   1. Utilize FHIR development tools to model and prototype the new resource. Ensure that it aligns with existing FHIR guidelines and conventions.
6. **Documentation** :
   1. Provide detailed information about the resource, including its purpose, structure, and examples, to assist future implementers.
7. **Formal Review** :
   1. Submit the resource for review by official FHIR governance bodies. Address any suggestions or concerns raised by HL7 committees.
8. **Trial & Feedback**:
   1. Implement the new resource in real-world healthcare settings. Gather feedback from these implementations and refine the resource accordingly.
9. **Standardization Process** :
   1. Push for the inclusion of the resource in future FHIR standards. Engage with the FHIR community and stakeholders to promote its adoption.
10. **Maintenance** :\
    1\. Regularly review and update the resource, considering new clinical insights or technological advancements.
11. **Promotion & Training**:\
    1\. Develop training materials or sessions for the new resource. Engage with health IT and clinical communities to increase awareness and understanding.

The decision to use FHIR resources for this Use Case will provide great specificity and level of detail in the captured data and great uniformity between implementations. However, the process of creating resource specifications from scratch is slow, taking many months to develop each resource. The stability of the resources, only updating in new FHIR versions and not independently, also complicates the need for continuous improvement or adaptations to new requirements.

<a href="https://docs.google.com/forms/d/e/1FAIpQLScTmbZIf0UEQwYDkY27EEWBkaiYkHSbR0_9DmFrMLXoQLyL7Q/viewform?usp=pp_url&#x26;entry.1767247133=Cancer+Synoptic+IG&#x26;entry.670899847=FHIR%20Resources" class="button primary">Provide Feedback</a>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.snomed.org/implementation-guides/cancer-synoptic-reporting-implementation-guide/5-technical-application/5.2-standardized-model-representation-using-fhir/5.2.1-fhir-resources.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.