This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Registry Use Cases"

From HL7Wiki
Jump to navigation Jump to search
 
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:Interdependent Registries]]
+
[[:Category:Interdependent_Registries]]
[[:Category:Patient Administration Work Group]]
+
[[:Category:Patient_Administration_Work_Group]]

Latest revision as of 18:04, 28 December 2010

Back to Project Page

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

Basic Scenario

  1. 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

  1. Search organization that match services offered, location, name, etc.
  2. Identify matching organization(s)
  3. 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
  4. 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

  1. The name, contact information, and up-to-date certifications/service information is made available to the requesting provider.

Actors

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

Basic Scenario

  1. 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

  1. Search organization that match services offered, location, name, etc.
  2. Identify matching organization(s)
  3. 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
  4. 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

  1. The name, contact information, and up-to-date certifications/service information is made available to the requesting provider.

Actors

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

  1. Provider Registry automatically triggers a license verification to relevant certification board/directories.
  2. Provider Registrynotifies the provider if the renewal is not available.

Post-conditions

Actors

Manage Registry Content

This use case is based on the Registry State Machine:

  1. Add object (error if the object exists)
  2. 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