This wiki has undergone a migration to Confluence found Here
Difference between revisions of "201901 vhdir"
Jump to navigation
Jump to search
(Created page with "{{subst::Template for FHIR Connectathon Track Proposals}}") |
|||
| (8 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
__NOTOC__ | __NOTOC__ | ||
=Track Name= | =Track Name= | ||
| + | VhDir | ||
==Submitting WG/Project/Implementer Group== | ==Submitting WG/Project/Implementer Group== | ||
| − | + | FHIR-I / Federal Health Architecture / Office of the National Coordinator | |
==Justification== | ==Justification== | ||
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. --> | <!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. --> | ||
| + | VhDir IG describes the architectural considerations for attesting to, validating, and exchanging data from a central source of validated provider data (i.e. a Validated Healthcare Directory or VHDir), as well as a RESTful FHIR API for accessing data from a VHDir. | ||
| + | Many of the clinical workflows require the provider data such as their location details, their electronic address to send information, their specialty, their insurance preferences etc. All of this data gets curated in a healthcare directory which is then accessed in clinical workflows to perform the necessary actions. | ||
| + | |||
| + | Technical Considerations: The Connectathon should identify the technical APIs that are most meaningful, the specific search parameters that are most meaningful. | ||
| + | |||
| + | Policy Considerations: The Connectathon should identify what kind of validations should be performed on the data before consuming the data. | ||
==Clinical input requested== | ==Clinical input requested== | ||
<!--Please indicate here if you would like input from the the Clinical community please indicate so here. The connectathon organizers will contact you to follow up. --> | <!--Please indicate here if you would like input from the the Clinical community please indicate so here. The connectathon organizers will contact you to follow up. --> | ||
| + | Yes, need to determine the commonly used search parameters in workflows for making the directory information useful. | ||
==Related tracks== | ==Related tracks== | ||
<!--Other tracks in this event that share similar goals and could either be combined, or an attendee could reasonable do both --> | <!--Other tracks in this event that share similar goals and could either be combined, or an attendee could reasonable do both --> | ||
| + | Transitions of Care. | ||
==Proposed Track Lead== | ==Proposed Track Lead== | ||
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon --> | <!-- Name, email and Skype id of individual who will coordinate the track at the connectathon --> | ||
See [[Connectathon_Track_Lead_Responsibilities]] | See [[Connectathon_Track_Lead_Responsibilities]] | ||
| + | |||
| + | Daniel Chaput, Alex Kontur. | ||
==Expected participants== | ==Expected participants== | ||
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track --> | <!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track --> | ||
| + | |||
| + | FHA | ||
| + | ONC | ||
| + | |||
==Roles== | ==Roles== | ||
Please include information here regarding how much advance preparation will be required if creating a client and/or server. | Please include information here regarding how much advance preparation will be required if creating a client and/or server. | ||
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | <!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | ||
| − | === | + | |
| − | + | ===VhDir Server=== | |
| + | The VhDir Server provides the validated health care directory content to all the local environments via VhDir Clients. | ||
| + | The VhDir has to preload a set of validated healthcare directory information. | ||
| + | |||
| + | ===VhDir Client=== | ||
| + | The VhDir Client queries and downloads validated healthcare directory content from VhDir Server. | ||
| + | The VhDir client has to support the various search APIs for workflows to retrieve the directory content. | ||
==Scenarios== | ==Scenarios== | ||
<!-- What will be the actions performed by participants? --> | <!-- What will be the actions performed by participants? --> | ||
| + | 1. VhDir Client queries VhDir Server for Practitioner information | ||
| + | |||
| + | 2. VhDir Client exposes the VhDir Server information using the VhDir Search APIs. | ||
| + | |||
| + | |||
| + | ===Scenario 1 : VhDir Client queries the VhDir Server=== | ||
| + | :Action: VhDir Client queries the VhDir Server | ||
| + | :Precondition: VhDir Server is pre-loaded with validated healthcare directory information. | ||
| + | :Success Criteria: Clients should be able to successfully download the provider information. | ||
| + | :Bonus point: Query Practitioner Information and use include parameters to retrieve additional information such as Organization, practitionerRole, OrganizationAffiliation. | ||
| + | |||
| − | ===Scenario | + | ===Scenario 2 : VhDir Client exposes the VhDir Server information using the VhDir Search APIs.=== |
| − | :Action: | + | :Action: VhDir Client exposes the downloaded healthcare directory information to the workflow using FHIR APIs, in this case the Client is exposing as a FHIR Server. |
| − | :Precondition: | + | :Precondition: VhDir Client has downloaded the healthcare directory information from VhDir Server. |
| − | :Success Criteria: | + | :Success Criteria: clients in workflow should be able to query healthcare directory for specialty, location, address etc. |
| − | :Bonus point: | + | :Bonus point: Use the VhDir Extensions and VhDir specific search parameters to query the information. |
| − | |||
==TestScript(s)== | ==TestScript(s)== | ||
Latest revision as of 13:02, 26 September 2018
Track Name
VhDir
Submitting WG/Project/Implementer Group
FHIR-I / Federal Health Architecture / Office of the National Coordinator
Justification
VhDir IG describes the architectural considerations for attesting to, validating, and exchanging data from a central source of validated provider data (i.e. a Validated Healthcare Directory or VHDir), as well as a RESTful FHIR API for accessing data from a VHDir.
Many of the clinical workflows require the provider data such as their location details, their electronic address to send information, their specialty, their insurance preferences etc. All of this data gets curated in a healthcare directory which is then accessed in clinical workflows to perform the necessary actions.
Technical Considerations: The Connectathon should identify the technical APIs that are most meaningful, the specific search parameters that are most meaningful.
Policy Considerations: The Connectathon should identify what kind of validations should be performed on the data before consuming the data.
Clinical input requested
Yes, need to determine the commonly used search parameters in workflows for making the directory information useful.
Related tracks
Transitions of Care.
Proposed Track Lead
See Connectathon_Track_Lead_Responsibilities
Daniel Chaput, Alex Kontur.
Expected participants
FHA ONC
Roles
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
VhDir Server
The VhDir Server provides the validated health care directory content to all the local environments via VhDir Clients. The VhDir has to preload a set of validated healthcare directory information.
VhDir Client
The VhDir Client queries and downloads validated healthcare directory content from VhDir Server. The VhDir client has to support the various search APIs for workflows to retrieve the directory content.
Scenarios
1. VhDir Client queries VhDir Server for Practitioner information
2. VhDir Client exposes the VhDir Server information using the VhDir Search APIs.
Scenario 1 : VhDir Client queries the VhDir Server
- Action: VhDir Client queries the VhDir Server
- Precondition: VhDir Server is pre-loaded with validated healthcare directory information.
- Success Criteria: Clients should be able to successfully download the provider information.
- Bonus point: Query Practitioner Information and use include parameters to retrieve additional information such as Organization, practitionerRole, OrganizationAffiliation.
Scenario 2 : VhDir Client exposes the VhDir Server information using the VhDir Search APIs.
- Action: VhDir Client exposes the downloaded healthcare directory information to the workflow using FHIR APIs, in this case the Client is exposing as a FHIR Server.
- Precondition: VhDir Client has downloaded the healthcare directory information from VhDir Server.
- Success Criteria: clients in workflow should be able to query healthcare directory for specialty, location, address etc.
- Bonus point: Use the VhDir Extensions and VhDir specific search parameters to query the information.
