FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

FHIR Infrastructure icon Work GroupMaturity Level: N/AStandards Status: Informative

This specification is currently still under development. 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, or alerting implementers to open issues:

  • Appointment: Values for Appointment.priority: how interoperable are they?
  • Appointment: Question about recurring appointment functionality
  • Basic: How explicit should the specification be about using Basic for inter-version hacking?
  • Bundle: Question around summary and nested resources
  • CapabilityStatement: Question about support for reverse chaining
  • CapabilityStatement: General note about support
  • ClinicalAssessment: 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?
  • DeviceRequest: Should this be combined with SupplyRequest?
  • GenomicStudy: Encouraging feedback
  • Must-support: Implementer attention is drawn to a proposal to rework must-support
  • Observation: What is the best way to group Observations?
  • Patient: Should linking/merging affect the RESTful API?
  • Permission: This is a draft resource
  • Person: Note about use
  • Person: Note about linking patients
  • Person: Note about system support
  • Product: This is a draft resource
  • 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
  • Security: Feedback about signatures on RESTful interfaces sought
  • Subscription: Websockets needs further development
  • Subscription: Messaging needs further development
  • Subscription: Channels needs further development
  • SubscriptionTopic: This is a draft resource
  • SubstancePolymer: This is a draft resource
  • SubstanceReferenceInformation: This is a draft resource
  • Persistent Store/Database: Is a standard extension required for resolved links?
  • Task: Question about pre-requisites
  • TestScript: Note about use for non-FHIR implementations
  • Workflow: several implementation questions