Page tree
Skip to end of metadata
Go to start of metadata

VerificationResult[edit | edit source]

Owning work group name[edit | edit source]

Patient Administration

Committee Approval Date:[edit | edit source]

7 Feb 2018 (Brian Postlethwaite, Louis Bedor 3-0-0)

Contributing or Reviewing Work Groups[edit | edit source]

  • Seeking interested workgroups

FHIR Resource Development Project Insight ID[edit | edit source]


Scope of coverage[edit | edit source]

The VerificationResult resource records the details and results of a resource that needs to be, or has been verified by multiple parties. It does not represent the workflows or tasks related, but does cover the who did what when, why, and when it needs to be done again.

This is in contrast to the AuditEvent which could record that a resource was received from someone, and the Provenance that records who it came from.

It was considered to be implemented as a profile on Provenance, however this seems to be different in scope in that its includes details of the verification.

(A similar concept exists outside of healthcare in Art/Musical Equipment in Appraisals vs Provenance, the provenance of the piece covers its chain of ownership, where an appraisal covers how it was check for its authenticity)

RIM scope[edit | edit source]


Resource appropriateness[edit | edit source]

When receiving content from a 3rd party system (such as a directory) it is important to be able to determine the quality of that data. This resource provides a receiver of the content the knowledge of where the data came from (especially where content was aggregated from multiple sources)

This is to be stored external to the resource, instead of within it, so that where not required, the additional content of the verification (which could be quite extensive) does not need to be loaded.

Expected implementations[edit | edit source]

The ONC has indicated that they desire to create a service that uses this capability where they will be distributing aggregated healthcare directory data from a central service to Organizations for local usage (based on a specific data usage agreement)

Content sources[edit | edit source]

Example Scenarios[edit | edit source]

  • Centralized Healthcare Directory service
  • Distributed/Federated Provider Directory service
  • Aggregated Directory Service

Resource Relationships[edit | edit source]

Reference(any) - Our initial requirements are needed against:

  • Organization
  • OrganizationRole (OrganizationAffiliation)
  • Location
  • Practitioner
  • PractitionerRole
  • HealthcareService

We do not currently expect other resources to specifically reference VerificationResult

Timelines[edit | edit source]

May Ballot 2018 - draft is in the build that went to the Jan 2018 Comment ballot

gForge Users[edit | edit source]

  • brian_pos
  • Cooper Thompson
  • Andrew Torres

When Resource Proposal Is Complete[edit | edit source]

When you have completed your proposal, please send an email to

FMG Notes