This page is part of the FHIR Specification (v5.0.0-ballot: FHIR R5 Ballot Preview). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

2.1.24 Outstanding Issues

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards Status: Informative

This specification is currently normative. While some parts of the specification are mature and stable, and HL7 is focusing on moving these to a formal standard, much work remains to be done in other areas. The following general areas of functionality have been deferred to a future version, or are incompletely covered in this version:

• An alarm resource to represent current issues with the patient (e.g. device created)
• Concern Tracking
• Aggregated Data Reporting including Public Health Reporting
• One or more resources for Advance Care Directive / Power of Attorney
• A full server side query framework

For some of these, some draft content is included in the specification for implementer consideration.

In addition, there are a number of specific notes in the specification requesting feedback from implementers, or alerting implementers to open issues:

• Appointment: Values for Appointment.priority: how interoperable are they?
• Appointment: Question about recurring appointment functionality
• Basic: How explicit should the specification be about using Basic for inter-version hacking?
• Bundle: Question around summary and nested resources
• CapabilityStatement: Question about support for reverse chaining
• CapabilityStatement: General note about support
• ClinicalImpression: General Questions about use
• Clinical Reasoning: Multiple questions about implementation and usage
• Composition: Is title different to type? and open questions about document signatures
• Condition: How should "No Known Problems" be represented?
• DeviceRequest: Should this be combined with SupplyRequest?
• GenomicStudy: Encouraging feedback
• Must-support: Implementer attention is drawn to a proposal to rework must-support
• Observation: What is the best way to group Observations?
• Patient: Should linking/merging affect the RESTful API?
• Permission: This is a draft resource
• Person: Note about use
• Person: Note about linking patients
• Person: Note about system support
• Population: This is a draft resource
• Product: This is a draft resource
• Profiling Resources: Need feedback on using system profiles
• References between Resources: Do we need to allow contained resources that reference the container?
• Safety: Request for comments about further development
• Security: Feedback about signatures on RESTful interfaces sought
• Subscription: Websockets needs further development
• Subscription: Messaging needs further development
• Subscription: Channels needs further development
• SubscriptionTopic: This is a draft resource
• SubstancePolymer: This is a draft resource
• SubstanceReferenceInformation: This is a draft resource
• Persistent Store/Database: Is a standard extension required for resolved links?
• Task: Question about pre-requisites
• TestScript: Note about use for non-FHIR implementations
• Workflow: several implementation questions