HPD USA National Extension Wiki Specification

HPD USA National Extension Wiki Specification

This page is what will soon become the USA National Extension specification proper. The broader context for this effort can be found in the wiki page Healthcare Provider Directory USA National Extension.

Required Queries

Implementers declaring conformance to the HPD USA National Extension MUST support the following queries.

1. Query individual provider based on potentially ambiguous search criteria
   • MUST
2. Retrieve individual provider based on unique search criteria
   • MUST
3. Query organizational provider based on potentially ambiguous search criteria
   • MUST
4. Retrieve organizational provider based on unique search criteria
   • MUST
5. Retrieve the list of organizations for a specific individual provider by querying based on hcPracticeLocation field
   • Require the hcPracticeLocation (DN's of organizations the individual provider is associated with) member information field to be populated. (It is optional in the base IHE HPD specification.)
   • MUST support
6. Require memberOf fields to be populated. For individual providers with no
   • MUST support
7. Retrieve the list of individual providers for a given organizational provider
   • MUST support

Other Rules

1. • Provider Directories MUST NOT store Individual Providers in an Organizational Provider object.
   • Provider Directories MUST NOT store Organizational Providers in a Individual Provider object.

1. To do: Eric or other task force members to determine what the Canadian InfoWay HPD-like directory lesson's learned

Required Attributes

HPDProviderCredential

Table 3.58.4.1.2.2.1-3: HPDProviderCredential Optional Attributes is hereby constrained as follows:

Condition

If the Individual Provider or Organizational Provider has a non-empty Credential attribute, then the following attributes within the HPDProviderCredential object must be populated as specified below:

credentialDescription - was O

R (Required if this object exists)

credentialIssueDate - was O

R (Required if this object exists)

credentialRenewalDate - was O

R (Required if this object exists)

credentialStatus - was O

R (Required if this object exists)

HPDProviderMembership

Table 3.58.4.1.2.2.1-5: HPDProviderMembership Optional Attributes is hereby constrained as follows:

hpdHasAService - was O

R2 (Required if known)

telephoneNumber - was O

R2 (Required if known)

facsimileTelephoneNumber - was O

R2 (Required if known)

mobile - was O

R2 (Required if known)

pager - was O

No change, this remains O

mail - was O

R2 (Required if known)

HPDElectronicService

Table 3.58.4.1.2.2.1-6: HPDElectronicService Mandatory Attributes is hereby constrained as follows:

hpdServiceAddress

Need to further constrain this attribute to identify the type of service, and potentially other attributes such as the version of service, use cases, etc. for email, FHIR, SOAP web services end point, etc.

Need to constrain the "type" of service value set

We may need to extend this object model

See https://tools.ietf.org/html/rfc4403 for a potential mapping from UDDI to LDAP

HPDElectronicService

Table 3.58.4.1.2.2.1-7: HPDElectronicService Optional Attributes is hereby constrained as follows:

hpdIntegrationProfile

R2 (Required if known)

hpdContentProfile

R2 (Required if known)

hpdCertificate

R2 (Required if known)

Individual Provider Mapping

Table 3.58.4.1.2.2.2-1: Individual Provider Mapping is hereby constrained as follows:

Provider Status - was O

R but need to identify the value set

Provider Title - was O

No change, for human consumption only, thus there will be no value set defined

Provider First name - was R2

No change

Provider Middle Name - was O

No change

Provider Language Supported - was O

No change

Provider Gender - was O

R2

Required by one use case, which is to identify a provider by gender due to patient preferences

Provider medical records deliver email address - was O

R2

Needed by Direct, but, need to constrain if the Direct email address goes here, vs. the HPDElectronicService object?

Eric H feels we should remove all below attributes for this object, and promote them to the HPDElectronicService object as new extensions to that object class. What do others think? This would be an IHE HPD CP.

Provider email address - was O

S-MIME Certificate - was O

Signing Certificate - was O

User Certificate - was O

Electronic Service URI - was O

Provider Facility Name - was R2

Provider Mailing Address - was R2

Provider Billing Address - was O

Provider Practice Address - was R2

Provider Practice Organization - was O

Provider Business Phone - was R2

Provider Mobile Phone - was R2

Provider Pager - was R2

Provider Fax - was R2

Provider “Credential” - was O

Provider Specialty - was O

Provider Relationship - was O

Legal Address - was O

Electronic Service - was O

Value Set Constraints

Provider Credential Provider Specialty

Queries Defined in the S&I Framework

1. Retrieve a list of individual providers with specific individual attribute(s)
   • This use case might be used to retrieve a list of Spanish-speaking cardiologists within a specific ZIP code.
2. Retrieve information on a specific individual provider
   • This use case might be used to retrieve the phone number, address, or Direct address for a specific provider by name or other unique attribute.
3. Retrieve a list of individual providers with specific individual attribute(s)
   • This use case might be used to retrieve a list of dermatology clinics within a specific ZIP code.
4. Retrieve information on a specific organization
   • This use case might be used to retrieve the phone number, address, or organizational relationships for an organization by legal name or other unique attribute
5. Retrieve the list of organizations for a specific individual provider
   • This use case might be used to retrieve the hospitals with which a specific provider has a relationship, such as admitting rights.
6. Retrieve the list of individuals for a specific organization
   • This use case might be used to retrieve the orthopedic surgeons associated with a specific hospital.
7. Retrieve a list of individuals and organizations with specific attributes
   • This use case might be used to retrieve all of the Spanish-speaking cardiologists with admitting rights to a hospital within a certain ZIP code.

Based on our discussions to date:

1. Find information on an individual provider.
   • The information found will be based on the HPD data model and required attributes in it. The query MUST support for querying of all required attributes as per this national extension. The query MUST allow for, and gracefully handle, queries for all optional attributes defined in this national extension, or base IHE HPD.
   • Attributes of particular focus include: contact information, address, Direct Project / secure email address, SOAP service endpoints, FHIR resources, language, specialty, and x.509 certificate.
   • Eric note: How is this different, if at all, from the next query?
2. Find a list of individual providers that match a demographic.
   • The demographic will be based on the HPD data model and required attributes. Based on the above, that needs to be (at least) address, specialty, and language.
3. Find information on an organizational provider.
   • The information may largely be the same as an individual.
4. Find a list of organizational providers that match a demographic.
   • Information may be largely the same as an individual.
   • Eric note: How is this different than finding an organizational provider?
5. Find all individual providers affiliated with an organization.
   • I’ve heard people voice a need for this query, but I’m not sure I know the user story that goes with it. Is there one?
6. Find electronic service information for an individual associated with an organization.
   • This is supported, but it is not clear to me that it is outlined in the use cases above. We may want to be explicit about this use case: “Dr. Smith’s Direct address at Community Hospital rather than Dr. Smith’s Direct address at Smith Private Practice”.
7. Find the organization, or organizations, associated with an individual or organization.
   • Depending upon how we enable organizational service endpoints, it may be necessary to walk the hierarchy. For example, if I want the XCA query endpoint for Dr. Smith, I may need to look up the XCA query endpoint for the hospital Dr. Smith is affiliated with. If I want to look up the XCA query endpoint for an ED, I may need to look up the XCA endpoint at hospital housing the ED. Think of it as “given an individual, what is the parent organization?” and “given an organization, what is the parent organization?”.

Required LDAP/DSML Support

As per the base IHE HPD specification, implementers are required to support the full DSML v2 syntax.

For the USA National Extension, Provider Information Directory actor implementers MUST either support the federation option, or, they MUST harmlessly ignore the federation option. It is not conformant for a Provider Information Directory actor to return an error if a valid federation option is contained in a request.

Base IHE HPD International Change Proposals

Use Postal address object.