Overview

This is he first official connectathon for the Validated Healthcare Directory Implementation Guide and is targeted to ensure that the guide is implementable, and that some common scenarios are checked.

This diagram describes the concepts behind the validated health care directory.


PractitionerRole describes the relationship between a practitioner and an organization. A practitioner provides services to the organization at a location. Practitioners also participate in healthcare provider insurance Networks through their role at an Organization.

Figure 1: PractitionerRole

Similar to PractitionerRole, OrganizationAffiliation describes relationships between organizations. For example: 1) the relationship between an organization and an association it is a member of (e.g. hospitals in a hospital association), 2) an organization that provides services to another organization, such as an organization contracted to provide mental health care for another organization as part of a healthcare provider insurance network, and 3) distinct organizations forming a partnership to provide services (e.g. a cancer center).


Figure 2: OrganizationAffiliation










Network is a group of practitioners and organizations that provide healthcare services for individuals enrolled in a health insurance product/plan (typically on behalf of a payer). InsurancePlan describes a health insurance offering comprised of a list of covered benefits (i.e. the product), costs associated with those benefits (i.e. the plan), and additional information about the offering, such as who it is owned and administered by, a coverage area, contact information, etc.

Figure 3: Network / InsurancePlan

Roles

Local Requester (Client)

An application that can search for information necessary to support scenarios which support obtaining provider data.

Available Clients

Validated Healthcare Directory (Server)

A server that makes Validated Healthcare Directory available to local implementations of directories.

Available Servers

Scenarios

Note: Scenarios 1-6 are repeated from the Virtual Connectathon held December 11th, 2018. If you participated in that Connectathon you may consider starting with Scenario 7. 

Find details on an individual practitioner

These actions allow the Local Requester to find current, detailed information on a practitioner from a Validated Healthcare Directory to support local workflow. Expected uses include verifying the local data is current e.g. address, license status, accepting new patients, etc.


Scenario 1: Local Data Validation - A Local Workflow Environment needs to verify details on a prior known individual as part of a local use case.

This scenario tests the ability to send a fully qualified query to the Healthcare Directory to receive data that describes an individual provider. Local Requester will use predetermined NPI numbers to get the practitioner, the practitioners qualifications and any Validation profiles.  

  1. Using a Practitioner’s NPI number 9998367938 get the practitioner’s qualifications.

  2. Verify the Practitioner has a current, validated license in the state of CT (Connecticut). Note this can be done via a rev-include (or first getting the practitioner, then finding the verification result).

  3. Stretch goal - programmatically determine the status of the qualification

  4. Stretch goal - persist the data in the local system

Profiles Utilized: Practitioner, PractitionerRole, Validation

Precondition: Server is available, local system can access server

Success Criteria: Visual inspection of data received.


Scenario 2: Request data on a set of practitioners  - A Local Workflow Environment needs the data on a set of practitioners as defined by jurisdictional boundaries, in this case a state.  This might be an initial fetching of information, a bulk update/verification or similar local use case where obtaining information on a state is required.

This scenario tests the ability to send a qualified query to the Validated Healthcare Directory and receive data on a set of providers. (This example will be obtaining data with addresses in a particular state jurisdiction.)

  1. Request all practitioners with any practitioner.address that is in the state of CT (Connecticut).

  2. Or any practitioners who have a qualification (e.g. license) where the qualification is valid is in the state of CT (Connecticut).

  3. Stretch goal - persist the data received in the local system.

  4. Feel free to repeat for Massachusetts (MA) and Rhode Island (RI).

  5. Stretch goal II - programmatically identify any providers who are license outside of the state where they live.

Profiles Utilized: Practitioner, PractitionerRole, Location

Precondition: Server is available, local system can access server

Success Criteria: Visual inspection of data.


Find details on an individual organization

Scenario 3: Request data on an individual  organization - A Local Workflow Environment needs current data on an individual organization including all locations, and services.

This scenario tests the ability of a Local Requester to query the Healthcare Directory and receive organizational information including locations and services provided by the organization.  Local Requester will use a specific organization to receive the locations of the organization and specialty areas by location.

  1. Using the organization GREATER LAWRENCE FAMILY HEALTH CENTER, INC., query the locations and services for that organization.

  2. The requester will be querying on a specific organization to determine details which identify location and services of that organization.

Profiles Utilized: Organization, HealthcareService, Location

Precondition: Server is available, local system can access server

Success Criteria: Visual inspection of data.


Scenario 4: Request Data on Organizations - A Local Workflow Environment needs current data on an individual organization’s affiliations; including all locations and the services delivered at those locations.

This scenario tests the ability of a Local Requester to query the Healthcare Directory and receive organizational information including affiliations with other organizations.   Local Requester will use a specific organization to receive the locations of the organization and specialty areas by location.

  1. Using the organization BAY STATE COMMUNITY SERVICES, INC. query the Healthcare Directory to receive related organizations and HealthcareServices provided for each organization.

  2. This scenario will get the Direct email addresses of any entity returned.

Profiles Utilized: Organization, OrganizationAffiliation, HealthcareService

Precondition: Server is available, local system can access server

Success Criteria: Visual inspection of data.


Find details on a provider and their organizational relationships

Scenario 5: Request Organization data for a specific Provider - A Local Workflow environment needs updated information for a specific provider and all organizations the provider is affiliated with.

This scenario tests the ability for a Local Requester to query by a given provider to find all associated organizations, locations, networks and practice specialty, including a Direct address if available.

  1. Given the NPI 9994024518, query for the associated provider, the organizations he/she is affiliated with, all locations and services and the networks he subscribes to.

  2. Determine the existence of a Direct address


Profiles Utilized: PractitionerRole Organization, OrganizationAffiliation, Network, Location, HealthcareService

Precondition: Server is available, local system can access server

Success Criteria: Visual inspection of data.


Scenario 6: Identify data associated with a Network - A Local Workflow needs available data from a Healthcare Directory concerning a Network, including all services, locations, practitioners, and organizations.

  1. Using the Network MA Bronze Plan PPO, locate all services, locations, providers and organizations who belong to the network.

  2. Stretch goals: the following networks are on the server:

Feel free to build a simple network Directories based on the data on the server

Profiles Utilized: Network, OrganizationAffiliation, Practitioner, Location, HealthcareServices, Organization, PractitionerRole

Precondition: Server is available, local system can access server

Success Criteria: Visual inspection of data


Scenarios 7-n are under development. 

Scenario 7: Geo Coded Query I - A local workflow needs VhDir information for a given state.

split this into to separate searches:

use the address-state search parameter to fetch all the practitioners with home address locations in MA

use the qualification-wherevalid-code search parameter to fetch all practitioners with qualifications in MA

[base]/Practitioner?address-state=MA

[base]/Practitioner?qualification-wherevalid-code=MA

Deduplicate this list and use i for the following steps.

Note address-state parameter in FHIR but not VHDIR IG


Scenario 8: Services - local workflow needs information either limited by or including services  

using the chained search...

`[base]/HealthcareService?type=respiratory-therapy%Location.address-state=RI`

*Note address-state parameter in FHIR but not VHDIR IG*


        1. KENT COUNTY MEMORIAL HOSPITAL
        2. COMPREHENSIVE COMMUNITY ACTION, INC.
        3. SOUNDVIEW ORTHOPAEDIC ASSOC. LLP
        4. RHODE ISLAND SUBSTANCE ABUSE TREATMENT INC
        5. CODAC INC
        6. RHODE ISLAND SUBSTANCE ABUSE TREATMENT, INC.
        7. BAYSIDE ENDOSCOPY, LLC
        8. DISCOVERY HOUSE UTAH
        9. ROGER WILLIAMS MEDICAL CENTER
        10. TOLLGATE SLEEP DISORDERS CENTER, INC.


using the chained search...

`[base]/HealthcareService?Location.address-state=MA`

*Note address-state parameter in FHIR but not VHDIR IG*

1187 services provided by Organizations in MA*** 

using the chained search...

`[base]/HealthcareService?Location.address-state=MA&Location.address=Barnstable`

*Note


step 1 get provider practice location (lat = 41.764349, lon = -72.726388)

step2 using that location chained search...

[base]/HealthcareService?Location.near=lat|lon|100|[mi_us]

Note

step 1 get provider practice location (lat = 41.764349, lon = -72.726388)

step2 using that location chained search

[base]/InsurancePlan?coverageArea.near=lat|lon|100|[mi_us]

Note

 Scenario 9 - Find credentials and other items that are expiring


Find all licenses that are expired or will expire in the next 90 days. (period on active qualification on practitioner, note:  period and status may be out of sync).

{{url}}/Practitioner?qualification-period=eb2019-03-09

! no search parameter defined for Qualification period in VHDIR*

! period and status are two different axis. inactive and active are not the same as expired.

Scenario 10 - Certificates  and Validation that are expiring


`GET [base]/VerificationResult?status-date=sa[today-60days]&validation-status=validated`

*NOTE*: Searches parameters appear not supported in the VHDIR Demo Server


GET [base]/VerificationResult?status-date=lt[today-30days]&validation-status=val-fail,reval-fail

NOTE: Searches parameters appear not supported in the VHDIR Demo Server

GET [base]/Practitioner?certificate-date=gt[today+60days]

NOTE: No search parameter for certificate date

Scenario 11 - Membership

Organizations

step1 get the id of the network = "vhdir-network-HPID110000"

step2 search for OrganizationAffiliation and include Organizations

{{url}}/OrganizationAffiliation?primary-organization=[id]&_include=OrganizationAffiliation:participating-organization

Providers

-step1 get the id of the network = "vhdir-network-HPID110000"
-step2 search for PractitionerRole and include Practitioners

`{{url}}/OrganizationAffiliation?primary-organization=[id]&_include=OrganizationAffiliation:participating-organization`

709**Practitioners**


Scenario 12 - Subscription (push) data to multiple local directory

For this use case the Subscription.criteria would be based on a region such as Greater Boston Area either using a geolocation data or zip lists

e.g.

Practitioner?addess-postalcode:contains=[zip list]  (using :contains suffix since the zips in the server are Zip+4 and using 5 digit zips in search)

Any newly created or updated resources that meet this criteria in the resource cause the Server to notify the subscriber and "forward" ( e.g., POST)  the result of the search criteria - the updated Practitioner, PractitionerRole and Endpoint - to the specified endpoint.  Note that an alternate flow is that the Server would notify the subscriber of an update without a payload and then the subscriber would fetch the data through the REST API to a predetermined endpoint ("middleman" server).

here is an example Subscription to push all updated Practitioners, PractiionerRoles, and  Endpoints from the vhdir-demo server to the "local-dir"

{
   "resourceType":"Bundle",
   "id":"VhDir-subscription-bundle",
   "meta":{
      "lastUpdated":"2017-01-24T01:43:30Z"
   },
   "type":"transaction",
   "entry":[
      {
         "fullUrl":"urn:uuid:61ebe359-bfdc-4613-8bf2-c5e300945f0a",
         "resource":{
            "resourceType":"Subscription",
            "id":"vhdir-connectathon-scenario-12p",
            "status":"requested",
            "contact":[
               {
                  "system":"phone",
                  "value":"ext 4123"
               }
            ],
            "end":"2020-01-01T00:00:00Z",
            "reason":"(push) healthcare directory data to multiple local directories",
            "criteria":"Practitioner?address-postalcode:contains=02108, 02109, 02110, 02111, 02113, 02114, 02115, 02116, 02118, 02119, 02120, 02121, 02122, 02124, 02125, 02126, 02127, 02128, 02129, 02130, 02131, 02132, 02134, 02135, 02136, 02151, 02152, 02163, 02199, 02203, 02210, 02215, 02467",
            "channel":{
               "type":"rest-hook",
               "endpoint":"https://local-dir/fhir",
               "payload":"application/fhir+json",
               "header":[
                  "Authorization: Bearer secret-token-abc-123"
               ]
            }
         },
         "request":{
            "method":"POST",
            "url":"Subscription"
         }
      },
      {
         "fullUrl":"urn:uuid:61ebe359-bfdc-4613-8bf2-c5e300945f0a",
         "resource":{
            "resourceType":"Subscription",
            "id":"vhdir-connectathon-scenario-12pr",
            "status":"requested",
            "contact":[
               {
                  "system":"phone",
                  "value":"ext 4123"
               }
            ],
            "end":"2020-01-01T00:00:00Z",
            "reason":"(push) healthcare directory data to multiple local directories",
            "criteria":"PractitionerRole?practitioner.address-postalcode:contains=02108, 02109, 02110, 02111, 02113, 02114, 02115, 02116, 02118, 02119, 02120, 02121, 02122, 02124, 02125, 02126, 02127, 02128, 02129, 02130, 02131, 02132, 02134, 02135, 02136, 02151, 02152, 02163, 02199, 02203, 02210, 02215, 02467",
            "channel":{
               "type":"rest-hook",
               "endpoint":"https://local-dir/fhir",
               "payload":"application/fhir+json",
               "header":[
                  "Authorization: Bearer secret-token-abc-123"
               ]
            }
         },
         "request":{
            "method":"POST",
            "url":"Subscription"
         }
      },
      {
         "fullUrl":"urn:uuid:61ebe359-bfdc-4613-8bf2-c5e300945f0a",
         "resource":{
            "resourceType":"Subscription",
            "id":"vhdir-connectathon-scenario-12pe",
            "status":"requested",
            "contact":[
               {
                  "system":"phone",
                  "value":"ext 4123"
               }
            ],
            "end":"2020-01-01T00:00:00Z",
            "reason":"(push) healthcare directory data to multiple local directories",
            "criteria":"Endpoint?_has:PractitionerRole:endpoint:practitioner.address-postalcode:contains=02108, 02109, 02110, 02111, 02113, 02114, 02115, 02116, 02118, 02119, 02120, 02121, 02122, 02124, 02125, 02126, 02127, 02128, 02129, 02130, 02131, 02132, 02134, 02135, 02136, 02151, 02152, 02163, 02199, 02203, 02210, 02215, 02467",
            "channel":{
               "type":"rest-hook",
               "endpoint":"https://local-dir/fhir",
               "payload":"application/fhir+json",
               "header":[
                  "Authorization: Bearer secret-token-abc-123"
               ]
            }
         },
         "request":{
            "method":"POST",
            "url":"Subscription"
         }
      }
   ]
}

(Can Consider alternative approaches such as W3C Pub/Sub  approach )


Scenario 13 - Daily refresh data (pull) based on a "last update query".

This can be accomplished using a single batch transaction or multiple GETs of the form:

GET [base]/[Type]?_lastUpdated=gt[Yesterday]

Batch:

<?xml version="1.0" encoding="UTF-8"?>
<Bundle xmlns="http://hl7.org/fhir">
  <id value="vhdir-last_lastupdated_bundle-request"/>
  <!--   This bundle is a batch of requests to the FHIR RESTful API   -->
  <type value="batch"/>
  <!--   Each entry is used to represent a RESTful API request -->
  <entry>
    <request>
      <method value="GET"/>
      <url value="/Practitioner?_lastUpdated=gt20190114"/>
    </request>
  </entry>
  <entry>
    <request>
      <method value="GET"/>
      <url value="/PractitionerRole?_lastUpdated=gt20190114"/>
    </request>
  </entry>
  <entry>
    <request>
      <method value="GET"/>
      <url value="/Organization?_lastUpdated=gt20190114"/>
    </request>
  </entry>
  <entry>
    <request>
      <method value="GET"/>
      <url value="/OrganizationAffiliation?_lastUpdated=gt20190114"/>
    </request>
  </entry>
  <entry>
    <request>
      <method value="GET"/>
      <url value="/Location?_lastUpdated=gt20190114"/>
    </request>
  </entry>
  <entry>
    <request>
      <method value="GET"/>
      <url value="/InsurancePlan?_lastUpdated=gt20190114"/>
    </request>
  </entry>
  <entry>
    <request>
      <method value="GET"/>
      <url value="/Endpoint?_lastUpdated=gt20190114"/>
    </request>
  </entry>
  <entry>
    <request>
      <method value="GET"/>
      <url value="/VerificationResult?_lastUpdated=gt20190114"/>
    </request>
  </entry>
  <entry>
    <request>
      <method value="GET"/>
      <url value="/CareTeam?_lastUpdated=gt20190114"/>
    </request>
  </entry>
  <entry>
    <request>
      <method value="GET"/>
      <url value="/HealthcareService?_lastUpdated=gt20190114"/>
    </request>
  </entry>
</Bundle>


Scenario 14: Bulk data (TBD if build data is available on test servers)

Scenario 15: Care Teams - (TBD)

Other thoughts that were discussed - TBD if to include

 Attendees

Brian Postlethwaite (Telstra Health)

Dan Chaput (ONC)

Eric Haas (health edata)

Lindsey Hoggle (IRIS Health Solutions)

Ron Shapiro (Qvera)

Jay Wall (immutaMED)

Joel Francis (Canada Health Infoway)

Notable achievements

Discovered issues/questions:

In addition to those noted above, we were asked to provide additional clarification to the verification-result resource in relation to the provenance resource and the use cases and workflows that populate those resources.

Outcomes/Next Steps