DSTU2 QA Preview

This page is part of the FHIR Specification (v1.0.0: DSTU 2 Ballot 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

1.6 Outstanding Issues

This specification is currently in it's second round of trial use. Much work remains to be done.

Specifically, there are still many outstanding questions about the Request/Fulfillment cycle (Order/ OrderResponse and how various statuses and workflows associated with requests, as well as how proposals cascade to plans to orders to downstream/encoded orders, etc. This is a matter of ongoing investigation.

In addition, 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
  • Use of RDF
  • A full server side query framework

For some of these, some draft content is included in the specification as draft for implementer consideration.

In addition, there is a number of specific notes through the specification requesting feedback from implementers:

  • AllergyIntolerance: how to report 'no known allergies' of various flavors
  • Appointment: suitability of Appointment.priority values
  • BodySite: suitability of this as a resource?
  • CarePlan: 2 questions about usage
  • ClinicalImpression: general usage questions
  • Composition: question about title being mandatory, and about signatures
  • Invariants: is there a replaceement for XPath?
  • DataElement: question about relationship between DataElement and other resources
  • Markdown: which markdown flavor can we settle on, if any?
  • DiagnosticReport: relationship with Observation
  • RESTful API: question about using the PATCH operation
  • RESTful API: what should we do about side-effects and transactions?
  • RESTful API: Transaction integrity and introspection
  • Resource Identification: identifier policy rules?
  • Messaging: what additional events should be defined?
  • Operations: should it be possible to execute operations asynchronously?
  • Patient: what effect linking/merging/unlinking should have on other functionality such as the GET operation?
  • Patient: Comment on MPI search query sought
  • Profiling: Note about need for feedback about use of profiles
  • References: Should inside out containment be allowed?
  • RiskAssessment: General usage questions
  • Search: how much should text search be standardised?
  • Search: Should additional rules about how _include works be made?
  • Security: Using signatures with RESTful interfaces is a poorly understood area
  • Subscription: Use with messaging is still to be clarified