[go: up one dir, main page]
FHIR Release 3 (STU)

This page is part of the FHIR Specification (v3.0.2: STU 3). 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.19 Outstanding Issues

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
  • 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 Known Problems" be represented?
  • DataElement: Should DataElement, 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?
  • RESTful API: Should servers maintain ids when processing transactions?
  • RESTful API: What are the documentation requirements around transaction integrity?
  • Managing Resource Identity: Mandating Identification practices for cross-system interoperability?
  • Observation: Request for feedback on using the lastn operation and whether it should be applied to other resources
  • Operations: Do we need a way to execute operations asynchronously?
  • 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
  • Workflow: several implementation questions