R4 Ballot #2 (Mixed Normative/Trial use)

This page is part of the FHIR Specification (v3.5.0: R4 Ballot #2). 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.22 Outstanding Issues

FHIR Infrastructure Work GroupMaturity Level: N/ABallot 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: What are 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
  • 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?
  • Workflow: several implementation questions
    • -->