Difference between revisions of "Registry Use Cases"
Line 1: | Line 1: | ||
− | [[PA Interdependent Registries|Back to Project Page] | + | [[PA Interdependent Registries|Back to Project Page]] |
=May 2011 Use Cases= | =May 2011 Use Cases= | ||
The following use cases will be addressed by the May 2010 Interdependent Registry Domain Analysis Model (DAM) ballot: | The following use cases will be addressed by the May 2010 Interdependent Registry Domain Analysis Model (DAM) ballot: | ||
Line 52: | Line 52: | ||
This use case relies on correct associations between organizations and provider and requires up-to-date credentials to be stored in the [[Registry_Actors#Provider_Registry| Provider Registry]] | This use case relies on correct associations between organizations and provider and requires up-to-date credentials to be stored in the [[Registry_Actors#Provider_Registry| Provider Registry]] | ||
+ | ==Update Provider Licence Information== | ||
+ | ===Pre-conditions=== | ||
+ | The license/certification of a provider has expired. | ||
+ | ===Basic Scenario=== | ||
+ | #[[Registry_Actors#Provider_Registry| Provider Registry]] automatically triggers a license verification to relevant certification board/directories. | ||
+ | #[[Registry_Actors#Provider_Registry| Provider Registry]]notifies the provider if the renewal is not available. | ||
+ | |||
+ | ===Post-conditions=== | ||
+ | ===Actors=== | ||
+ | *[[Registry_Actors#Provider_Registry| Provider Registry]] | ||
+ | * Certification Directories? | ||
+ | |||
+ | ==Manage Registry Content== | ||
+ | This use case is based on the [[PA_Registry_State_Model|Registry State Machine]]: | ||
+ | # Add object (error if the object exists) | ||
+ | # Update object (eror if the object does not exist) | ||
+ | #* Includes provider certfication, services available, locations per organization, etc. | ||
---- | ---- | ||
− | [[:Category: | + | [[:Category:Interdependent_Registries]] |
− | [[:Category: | + | [[:Category:Patient_Administration_Work_Group]] |
Latest revision as of 18:04, 28 December 2010
Contents
May 2011 Use Cases
The following use cases will be addressed by the May 2010 Interdependent Registry Domain Analysis Model (DAM) ballot:
Look up Provider By Organization or Location
This use case is based on NHIN Direct User Stories.
Pre-conditions
- NHIN Direct care provider refers patient to hospital including summary care record
- The provider describes the order, including the hospital facility she is ordering service[...].
Basic Scenario
- Based on the requesting provider's request, the EHR System or Portal/HIE/ISP
connects to the local Organization Registry and looks up the organization intended as the destination for the referral
- Search organization that match services offered, location, name, etc.
- Identify matching organization(s)
- If the identity of a specific provider is known, then the EHR Systemwill look up the provider by name, specialty, etc. in the Provider Registry
- If the provider's identity is not known then a generic request for provider will be issued to the destination EHR System or Portal/HIE/ISP using the specialty or the services required for the referral.
Post-conditions
- The name, contact information, and up-to-date certifications/service information is made available to the requesting provider.
Actors
- EHR System
- Provider Registry
- Organization Registry
- Portal/HIE/ISP
- Requesting Provider who initiates the look up
Dependencies
This use case relies on correct associations between organizations, locations, and provider and requires up-to-date provider records that use digital certificates stored in the Provider Registry.
Look up Provider by Specialty
This use case is based on NHIN Direct User Stories.
Pre-conditions
- NHIN Direct care provider refers patient to specialist including summary care record
- In some cases the referral is directed to a specific specialist, and in other cases to a specialist practice.
Basic Scenario
- Based on the requesting provider's request, the EHR System or Portal/HIE/ISP
connects to the local Organization Registry and looks up the organization intended as the destination for the referral
- Search organization that match services offered, location, name, etc.
- Identify matching organization(s)
- If the identity of a specific provider is known, then the EHR Systemwill look up the provider by name, specialty, etc. in the Provider Registry
- If the provider's identity is not known then a generic request for provider will be issued to the destination EHR System or Portal/HIE/ISP using the specialty or the services required for the referral.
Post-conditions
- The name, contact information, and up-to-date certifications/service information is made available to the requesting provider.
Actors
- EHR System
- Provider Registry
- Organization Registry
- Portal/HIE/ISP
- Requesting Provider who initiates the look up
Dependencies
This use case relies on correct associations between organizations and provider and requires up-to-date credentials to be stored in the Provider Registry
Update Provider Licence Information
Pre-conditions
The license/certification of a provider has expired.
Basic Scenario
- Provider Registry automatically triggers a license verification to relevant certification board/directories.
- Provider Registrynotifies the provider if the renewal is not available.
Post-conditions
Actors
- Provider Registry
- Certification Directories?
Manage Registry Content
This use case is based on the Registry State Machine:
- Add object (error if the object exists)
- Update object (eror if the object does not exist)
- Includes provider certfication, services available, locations per organization, etc.
Category:Interdependent_Registries Category:Patient_Administration_Work_Group