FHIR Release 3 (STU) 4

This page is part of the FHIR Specification (v3.0.2: (v4.0.1: R4 - Mixed Normative and STU 3). ) in it's permanent home (it will always be available at this URL). 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 R4 R3 R2

2.19 2.22 Outstanding Issues

FHIR Infrastructure Work Group Maturity Level : N/A Standards Status : Informative

This specification is currently in its third round of trial use. 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:

  • AllergyIntolerance : new codes needed for certainty?
  • AllergyIntolerance : How should "No "No Known Allergies" Allergies" be represented?
  • Appointment : Values for Appointment.priority: how interoperable are they
  • BodySite : Should it be an independent resource or a datatype? 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 "No Known Problems" Problems" be represented?
  • DataElement DeviceRequest : Should DataElement, this be rolled into StructureDefinition as a Logical Model? Markdown : Probable that will recommend/require CommonMark in release 4 - implementation consequences? Extensibility : Do we need to support modifier extensions on extensions? RESTful API : Consequence of side effects in batches and transactions? combined with SupplyRequest?
  • RESTful API Exchange : Should servers maintain ids when processing transactions? RESTful API : What are the documentation requirements around transaction integrity? Managing Resource Identity : Mandating Identification practices support for cross-system interoperability? ProtocolBuffers be added to the specification?
  • Observation : Request for feedback on using What is the lastn operation and whether it should be applied to other resources Operations : Do we need a best way to execute operations asynchronously? group Observations?
  • Patient : Should linking/merging affect the RESTful API?
  • Profiling Resources : Need feedback on using system profiles
  • JSON-LD format : Need feedback on the JSON-LD format and it's usefulness References between Resources : Do we need to allow contained resources that reference the container?
  • Safety : Request for comments about further development
  • Search : does text search need to be standardized? Search : Problems with which elements are marked as 'included in summary' Security : Feedback about signatures on RESTful interfaces sought
  • Subscription : messaging details still to be resolved
  • SupplyRequest : Should this be combined with DeviceRequest?
  • Persistent Store/Database : Is a standard extension required for resolved links?
  • Task : Question about pre-requisites
  • Workflow : several implementation questions