This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). 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.12 Outstanding Issues

This specification is currently approaching its third round of trial use. While some parts of the specification are mature and stable, much work remains to be done. The following general areas of functionality have been deferred to a future version:

• Adverse Event Reporting
• An alarm resource to represent current issues with the patient (e.g. device created)
• Concern Tracking
• Clinical Studies and Protocols
• Aggregated Data Reporting including Public Health Reporting
• Payment related resources, and specifically, an Account resource for payment tracking
• 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:

• AllergyIntolerance : new codes needed for certainty?
• AllergyIntolerance : How should "No Known Allergies" be represented?
• Appointment : Values for Appointment.priority: how interoperable are they
• BodySite : Should it be an independent resource or a datatype?
• CarePlan : Combination concepts of "Care Plan" and "Care Team", and patient being optional
• ClinicalImpression : General Questions about use
• Composition : Is title different to type? and open questions about document signatures
• Condition : Questions about Condition.category
• Condition : How should "No Known Problems" be represented?
• DataElement : Should constraints be common across Questionnaire, DataElement, and StructureDefinition?
• DiagnosticReport : Relationship between DiagnosticReport and Composition?
• Extensibility : Do we need to support modifier extensions on extensions?
• Managing Resource Identity : Mandating Identification practices for cross-system interoperability?
• Markdown : Should we support CommonMark>
• Messaging : What additional events should be defined?
• Operations : Do we need a way to execute operations asynchronously?
• Patient : Should linking/merging affect the RESTful API?
• Patient : Comment sought on MPI matching
• PractitionerRole : Practitioner.role to be removed?
• Profiling Resources : Need feedback on using system profiles
• References between Resources : Do we need to allow contained resources that reference the container?
• RESTful API : Do we need to support PATCH?
• RESTful API : Consquence of side effects in batches and transactions?
• RESTful API : Should servers maintain ids when processing transactions?
• RESTful API : What are the documentation requirements around transaction integrity?
• RiskAssessment : several open issues
• Search : Feedback required on _has parameter
• Search : does text search need to be standardized?
• Search : Do we need additional rules about _include?
• Security : Feedback about signatures on RESTful interfaces sought
• Subscription : messaging details still to be resolved
• Workflow : several implementation questions