HPD USA National Extension Wiki Specification

From IHE Wiki
Jump to navigation Jump to search

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

    • 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

Attribute Constraints

HPDProvider

Table 3.58.4.1.2.2.1-1: HPDProvider Optional Attributes is hereby constrained as follows:

hpdProviderStatus - was O
TBD: Constrain value set 3.58.4.1.2.3-1?
R
FHIR mapping: Not mapped to FHIR
hpdProviderLanguageSupported - was O
TBD Constrain value set more than RFC 5646 + ISO 639 for interoperability in USA
No change (leave optional since we rather have higher quality and perhaps missing data than low quality present data)
Decision: We'll work on value sets in a second pass or via a sub work group
FHIR mapping: Practitioner.communication https://www.hl7.org/fhir/practitioner-definitions.html#Practitioner.communication
hpdProviderBillingAddress - was O
TBD about using a postal address first class object
No change
Discussed and determined that for most of the use cases we envisioned, it held little value and left it as optional.
FHIR mapping: Practitioner.practitionerRole.address https://www.hl7.org/fhir/practitioner-definitions.html#Practitioner.address, but note that HPD will likely be making a breaking change to change the address format
Eric to determine where hpdProviderLegalAddress is mising from these notes
FHIR mapping: TBD
hpdProviderMailingAddress - was O
TBD about using a postal address first class object
No change
Discussed and determined that for most of the use cases we envisioned, it held little value and left it as optional.
FHIR mapping: Practitioner.practitionerRole.address https://www.hl7.org/fhir/practitioner-definitions.html#Practitioner.address, but note that HPD will likely be making a breaking change to change the address format
hpdProviderPracticeAddress - was O
TBD about using a postal address first class object
R2 (note this implies we will not accept an address in to the directory without a practice address. Are we in agreement that the practice address is so important, that we accept this exclusionary criteria?
Discussed requiring all Individual Providers to have a required link to an Org Provider. And the org provider would then have additional attributes such as service location, and billing addresses. Feedback requested!
R2 under the reasoning that several use cases require the ability to search for a provider by their locality.
FHIR mapping: Practitioner.practitionerRole.address https://www.hl7.org/fhir/practitioner-definitions.html#Practitioner.address, but note that HPD will likely be making a breaking change to change the address format
hpdMedicalRecordsDeliveryEmailAddress - was O
F (forbidden)
We went the opposite way, and said that this field should NEVER be used for Direct. Direct addresses should be listed as part of service objects, and entering them here would confuse Direct with other secure email mechanisms. This field therefore remained optional and reserved only for non-Direct secure email addresses. Implementation guidance is to not use it at all to avoid confusion. I’d like to see it deprecated in favor of always using the service object to remove ambiguity, or making some guidance clearer.
FHIR mapping: Practitioner.practitionerRole.telecom.us-core-direct
memberOf - was O
R
Rule is that all Individual Providers must be a member of an organization, such as their business practice. This business practice will have additional attributes for more robust searching that could have been accomplished via IP class searching.
FHIR mapping: Practitioner.practitionerRole.organization
hpdCredential - was O
R2 for Individual Providers, O for Org Providers
Useful for consumer use, and perhaps others. Such as to determine if the provider is an MD, vs. a RN. Or an O.D. vs. a D.O.
FHIR mapping: Practitioner.practitionerRole.specialty
hpdProviderLegalAddress - was O
TBD about using a postal address first class object
No change
Discussed and determined that for most of the use cases we envisioned, it held little value and left it as optional.
FHIR mapping: Practitioner.practitionerRole.address https://www.hl7.org/fhir/practitioner-definitions.html#Practitioner.address, but note that HPD will likely be making a breaking change to change the address format
hpdHasAService - was O
R if the target of the HPD implementation is for electronic services discovery.
O if the target does not include electronic services discovery
Useful for both IP and OPs. Thus it belongs in this base class.

HPDProviderCredential

Table 3.58.4.1.2.2.1-2: HPDProviderCredential Mandatory Attributes is hereby constrained as follows:

credentialType - was R
No change
TBD Need to determine the value set. Base spec mentions <degree, certificate, credential>. Degree is not allowed for Org Providers.
FHIR mapping: Practitioner.?
credentialName - was R
Follows the ISO21091 naming format as that of the HCStandardRole.
TBD Need to determine value set.
FHIR mapping: Practitioner.?
credentialNumber - was R
TBD, determine if we need to point implementers to a list or directory of OIDs for this value?
FHIR mapping: Practitioner.?

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)
TBD, do we need to establish a value set?
FHIR mapping: Practitioner.
credentialIssueDate - was O
R (Required if this object exists)
FHIR mapping: Practitioner.
credentialRenewalDate - was O
R (Required if this object exists)
FHIR mapping: Practitioner.
credentialStatus - was O
R (Required if this object exists)
TBD if we need to constrain value set in table 3.58.4.1.2.3-1.
Required due to the use case of a person searching for a provider needs to know if the credential is valid, revoked, etc.
FHIR mapping: Practitioner.

HPDProviderMembership

Table 3.58.4.1.2.2.1-4: HPDProviderMembership Mandatory Attributes

hpdMemberId
No change
hpdHasAProvider
No change
hpdHasAnOrg
No change


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

hpdHasAService - was O
R2 (Required if known) if the directory is targeting electronic services discovery otherwise it is O
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:

hpdServiceId - was R
No change
hpdServiceAddress - was R
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

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

hpdIntegrationProfile - was O
R (Required)
otherwise this is not interoperable
TBD Need to define the value set
hpdContentProfile - was O
R (Required if known)
TBD Need to define the value set
hpdCertificate - was O
R2 (Required if known)
TBD Need to define the encoding and cert format, such as base64 encoded DER
Since this multivalued, need to determine a mechanism, such as an extension, to specify which certificate has what purpose
Also, since this is not the only place were certificates can be stored, we need to define the rules about when this field is used vs the other location

Individual Provider/HCProfessional

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

Individual Providers MUST not be used to store Organizational Providers.

Unique Entry Identifier/inetOrgPerson/uid - was R
No change
Provider “Identifiers”/HCProfessional/hcIdentifier - was R
TBD Need to define type value set
Provider Type/HCProfessional/HCProfessional - was R
TBD Need to constrain value sets. An example Individuals or Groups Values from the Healthcare Provider Taxonomy Published by the American Medical Association at http://www.adldata.com/Downloads/Glossaries/taxonomy_80.pdf.
Provider Type description/inetOrgPerson/description - was R
TBD Need to define value set, perhaps use display name from AMA.
Provider Status/HPDProvider/hpdProviderStatus - was O
R
TBD Need to identify the value set constraints on table 3.58.4.1.2.3-1
Provider Primary Name/inetOrgPerson/displayName - was R
No change
Provider Title/inetOrgPerson/title - was O
R2
Provider First name/inetOrgPerson/givenName - was R2
No change
Provider Middle Name/inetOrgPerson/initials - was O
No change
TBD, this may be an error in the base spec. Should we really use a field called "initials" for a middle name?
Provider Last Name/inetOrgPerson/sn - was R
No change
Provider Known names/inetOrgPerson/cn -was R
No change
Provider Language Supported/HPDProvider/hpdProviderLanguageSupported - was O
R2 (To support an identified use case)
Provider Gender/Natural Person/gender - was O
R2
Required by one use case, which is to identify a provider by gender due to patient preferences
May have an error, since "Natural Person" is not a properly formed LDAP class type
Provider medical records deliver email address/HPDProvider/hpdMedicalRecordsDeliveryEmailAddress - 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/inetOrgPerson/mail - was O
S-MIME Certificate/inetOrgPerson/userSMIMECertificate - was O
R2
Signing Certificate/HCProfessional/hcSigningCertificate - was O
R2
User Certificate/inetOrgPerson/userCertificate - was O
No change
Electronic Service URI/groupofURLs/labeledURI - was O
TBD determine a way to specific more advanced attributes such as version of service, type of service, content formats, etc.
Creation Date//createTimestamp - was R
No change
Last Update Date//modifyTimestamp - was R
No change
Provider Facility Name/inetOrgPerson/physicalDeliveryOfficeName - was R2
C - Required if the provider is associated with an org, or perhaps make mandatory with a special case if solo
Provider Mailing Address - was R2
TBD Need to determine if this should be a pointer to a first class address object
Provider Billing Address - was O
TBD Need to determine if this should be a pointer to a first class address object
Provider Practice Address - was R2
R
TBD Need to determine if this should be a pointer to a first class address object
Provider Practice Organization - was O
C - Required if the provider is associated with an org, or perhaps make mandatory with a special case if solo
Provider Business Phone - was R2
No change
Provider Mobile Phone - was R2
No change
Provider Pager - was R2
No change
Provider Fax - was R2
No change
Provider “Credential” - was O
R2
Provider Specialty - was O
R2
TBD Need to determine value set
Provider Relationship - was O
C - Required if the provider is associated with an org, or perhaps make mandatory with a special case if solo
Legal Address - was O
R
Electronic Service - was O
R
Required by all of our use cases

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.

DSML Control Segment

Organizational Provider Attribute Constraints

Individual Provider Attribute Constraints

Organizational Provider Extensions

Individual Provider Extensions

Non-Normative Sample LDIF Schema File

Base IHE HPD International Change Proposals

Use Postal address object.

Retrieved from "http://wiki.ihe.net/index.php?title=HPD_USA_National_Extension_Wiki_Specification&oldid=94129"