This wiki has undergone a migration to Confluence found Here
Difference between revisions of "VerificationResult FHIR Resource Proposal"
Jump to navigation
Jump to search
(Created page with "{{subst::Template:FHIR Resource Proposal}}") |
|||
| Line 9: | Line 9: | ||
[[Category:Pending FHIR Resource Proposal]] | [[Category:Pending FHIR Resource Proposal]] | ||
| − | + | =VerificationResult= | |
| − | |||
| − | |||
| − | |||
| − | = | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Owning work group name== | ==Owning work group name== | ||
| − | + | [[Patient Administration]] | |
| − | |||
| − | [[ | ||
==Committee Approval Date:== | ==Committee Approval Date:== | ||
| Line 43: | Line 25: | ||
==FHIR Resource Development Project Insight ID== | ==FHIR Resource Development Project Insight ID== | ||
| + | 1345 | ||
| + | |||
| + | ==Scope of coverage== | ||
| + | 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. | |
<!-- Define the full scope of coverage for the resource. The scope must be clearly delineated such that it does not overlap with any other existing or expected resource. The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%" | <!-- Define the full scope of coverage for the resource. The scope must be clearly delineated such that it does not overlap with any other existing or expected resource. The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%" | ||
| Line 60: | Line 47: | ||
==RIM scope== | ==RIM scope== | ||
| + | unknown | ||
| − | + | ==Resource appropriateness== | |
| + | 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. | |
<!-- Does the resource meet the following characteristics? | <!-- Does the resource meet the following characteristics? | ||
| Line 79: | Line 68: | ||
==Expected implementations== | ==Expected implementations== | ||
| + | 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) | ||
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. --> | <!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. --> | ||
| Line 89: | Line 79: | ||
==Example Scenarios== | ==Example Scenarios== | ||
| − | + | * Centralized Healthcare Directory service | |
| − | + | * Distributed/Federated Provider Directory service | |
| + | * Aggregated Directory Service | ||
==Resource Relationships== | ==Resource Relationships== | ||
| + | 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== | ==Timelines== | ||
| − | + | May Ballot 2018 - draft is in the build that went to the Jan 2018 Comment ballot | |
| − | |||
==gForge Users== | ==gForge Users== | ||
| − | + | brian_pos | |
| − | + | Cooper Thompson | |
| + | Andrew Torres | ||
==When Resource Proposal Is Complete== | ==When Resource Proposal Is Complete== | ||
Revision as of 00:54, 2 February 2018
This page documents a Pending FHIR Resource Proposal
Contents
- 1 VerificationResult
- 1.1 Owning work group name
- 1.2 Committee Approval Date:
- 1.3 Contributing or Reviewing Work Groups
- 1.4 FHIR Resource Development Project Insight ID
- 1.5 Scope of coverage
- 1.6 RIM scope
- 1.7 Resource appropriateness
- 1.8 Expected implementations
- 1.9 Content sources
- 1.10 Example Scenarios
- 1.11 Resource Relationships
- 1.12 Timelines
- 1.13 gForge Users
- 1.14 When Resource Proposal Is Complete
- 1.15 FMG Notes
VerificationResult
Owning work group name
Committee Approval Date:
Please enter the date that the committee approved this Resource proposal
Contributing or Reviewing Work Groups
- Work Group Name
- or link
- or "None"
FHIR Resource Development Project Insight ID
1345
Scope of coverage
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.
RIM scope
unknown
Resource appropriateness
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
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
Example Scenarios
- Centralized Healthcare Directory service
- Distributed/Federated Provider Directory service
- Aggregated Directory Service
Resource Relationships
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
May Ballot 2018 - draft is in the build that went to the Jan 2018 Comment ballot
gForge Users
brian_pos Cooper Thompson Andrew Torres
When Resource Proposal Is Complete
When you have completed your proposal, please send an email to FMGcontact@HL7.org
