DSTU2

This page is part of the FHIR Specification (v0.0.82: (v1.0.2: DSTU 1). 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

1.6 Open Outstanding Issues

There are a number of issues in which input based on implementation experience This specification is specifically sought during the currently in its second round of trial use phase: use. Much work remains to be done.

Conformance : How system profiles

Specifically, there are used still many outstanding questions about the Request/Fulfillment cycle ( Order : The need for additional kinds of order to be defined Resource Identification : Managing resource identification in distributed systems Query / Search : How should text search be standardized? Query / Search : How much should _include be standardized? Security Labels : How much policy can be standardized, OrderResponse and how does this impact on this specification? Security : What use cases are there for digital signatures? Messaging : Messaging has not yet been well-exercised at connectathon, so feedback based on implementation various statuses and workflows associated with requests, as well as how proposals cascade to plans to orders to downstream/encoded orders, etc. This is welcome a matter of ongoing investigation.

In addition, there are the following general areas of functionality have been deferred to a future proposed resources: version:

  • A notification resource for creating and recording notifications between parties Adverse Event Reporting
  • An alarm resource to represent current issues with the patient (e.g. device created)
  • A person resource to support person registries Concern Tracking
  • An appointment resource for making Clinical Studies and tracking arrangements around the future of care Protocols
  • Aggregated Data Reporting including Public Health Reporting
  • Payment related resources, and specifically, an Account resource for payment tracking
  • Possibly a way to define particular queries (finer detail than Profile provides) One or more resources for Advance Care Directive / Power of Attorney
  • Use of RDF
  • A full server side query framework

Note that other resources beyond these may be anticipated. For some of these, some draft content is included in the specification for implementer consideration.

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

  • AllergyIntolerance : how to these, further work 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 planned around tracking there a replaceement for XPath?
  • DataElement : question about relationship between DataElement and reporting clinical observations / vital signs, 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 supporting remote consultations / telehealth. 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
var disqus_shortname = 'fhirdstu';(function() {var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); })(); Please enable JavaScript to view the comments powered by Disqus. comments powered by Disqus