R4 Ballot #1 (Mixed Normative/Trial use) Release 4
This page is part of the FHIR Specification (v3.3.0: R4 Ballot 2). The current version which supercedes this version is 4.0.1 . For a full list of available versions, see the Directory of published versions
FHIR Infrastructure Work Group Maturity Level : N/A Ballot 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 Known Allergies" be represented?
  • Appointment : Values for Appointment.priority: how interoperable are they
  • 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?
  • Device : Questions about instance vs kind, and multiple UDIs DeviceRequest : Should this be combined with SupplyRequest?
  • DiagnosticReport : Request for comments on Clinical Genomics approach Exchange : Should support for ProtocolBuffers be added to the specification?
  • RESTful API : Consequence of side effects in batches and transactions? RESTful API Observation : What are is the documentation requirements around transaction integrity? Immunization : Question about doseSequence and several new elements ImmunizationEvaluation : Question about general recommendation design ImmunizationRecommendation : Question about recommendation cardinality and general recommendation design Media : Request for comments on changes, and relationship with Observation Narrative : Should narrative support multiple languages more directly? Patient : Request for comments on several changes Patient : Request for comments on Clinical Genomics approach best way to group Observations?
  • Patient : Should linking/merging affect the RESTful API?
  • 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
  • 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
  • ServiceRequest : Various Implementation/Design questions 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
  • -->