Healthcare Provider Directory USA National Extension

IHE USA HPD USA National Extension Implementation Task Force Collaboration Page

New 2016 Work

This page is for the use of the IHE USA Implementation Task Force that is working on the USA National Extension to HPD. All work will be posted here, or linked to from here, to allow for transparency, vendor and technology neutrality, and openness.

This Task Force is open to all.

Authority

• On Nov 13th, IHE International ITI Technical Committee and Planning Committee agreed that this work item would be an appropriate USA National Extension.
• Dec 3rd, Eric Heflin proposed this to the IHE USA Board of Directors, whom approved it as work under the IHE USA Implementation Task Force as their first work item.

HPD USA National Extension Wiki Specification

To facilitate quick turn around, efficient, and group collaboration, this Task Force has elected to create the first version of the HPD USA National Extension on this Wiki with the intent to create a standard Word format artifact after HIMSS16.

Follow the below link for the Wiki Specification for the HPD USA National Extension.

HPD USA National Extension Wiki Specification

Call for Participation

This Call for Participation was sent by IHE USA Tue, Dec 29, 2015 at 9:13 AM to the IHE USA mail list.

Join IHE USA’s New Implementation Task Force to Shape the Future of Healthcare

The call for participation is open until January 4

IHE USA will create their first US National Extension to IHE’s Healthcare Provider Directory (HPD) Profile. The HPD National Extension is critical to advance interoperability in the US. Therefore, IHE USA plans to fast track the development, testing, and implementation. Learn how you can get involved – Listen to recent presentation on HPD.

Link to recorded webinar: https://himss.webex.com/himss/lsr.php?RCID=fcbd34a689f14de1a21beee8cb73a3b4

Link to presentation PDF: http://wiki.ihe.net/images/7/7a/2015_to_2016_IHE_USA_HPD_National_Extension_Call_for_Participation_v004.pdf

This short-term taskforce will meet during the month of January 2016 to develop the

National Extension and plans to conduct the following activities: • January 2016 – IHE USA Implementation Task Force will meet to develop the specification and conduct virtual testing on the HPD US National Extension • January 28, 2016 – Test the HPD US National Extension at the IHE NA Connectathon 2016 o New and existing vendors are eligible to participate • March 1 – 3, 2016 – Demonstrate at the HIMSS16 Interoperability Showcase™ in Las Vegas, NV

Join us as we share the future of healthcare! The Task Force will begin work the week of

January 4, 2016. To participate, complete our brief survey.

Survey link: https://docs.google.com/forms/d/1ou8GAIpvfow6nmYP8bmnmPMgO_xnk8k_RD18rDtxcNA/viewform

Use Cases

This project is intended to satisfy needs of well defined business and clinical use cases. The use cases will be used to define requirements, and used to judge the sufficiency of the resulting national extension. Below is an initial list of use case titles which will be defined in more detail. Please review this list and provide comments.

Base Healthcare Provider Directory Query Use cases (International):

• Identify human or organizational providers based on attributes
  • Referrals target identification - hospital
  • Referrals target identification - specialist
  • Emergency responders
  • Identify provider based zip code, specialty, gender, and language spoken
  • Many other similar degenerate use cases
• Identify provider(s) based on their relationships to an organization
• Identify organization(s) based on relationship to an organization
• Keeping provider lists current
  • Feed of information from one provider directory to another (as an Option)
  • Run-time federation from one provider directory to another (as an Option)
  • Based on a client query or subscription from one provider directory to another (as an Option)
• Encapsulated or linked object retrieval
  • X.509 secure email certificate retrieval
• Generic electronic services discovery
• Target of an automated patient consent expression

Base Healthcare Provider Directory Feed Use cases (International):

• Add provider
• Update provider
• Delete

Base Healthcare Provider Directory Federated Query Use cases (International):

• Region to region dynamic federation
• National federated provider directory
• Federation to authoritative sources, such a hospital staff directory, regional medical licensing body, etc.

Proposed USA National Extension Use Cases:

• Same as Base Healthcare Provider Directory/Federated plus...
• Specific electronic services discovery (FHIR, secure email, IHE / SOAP, etc.)
• Consumer/patient directory (from a proposed FHIR use case)
• Precisely specified storage location and structure for USA-specific identifiers (DEA, NPI, state drivers license, board license id, etc.)
• Identification of a test patient

Change Proposals:

• Use of first class address object, instead of embedded name value pairs, for all addresses
• Include a Geographic Information System (GIS) location indicator (lat/long)

Proposed USA National Extension Other Possible Functions:

• Support for required query types (six)
• Support for use cases using query Boolean logic (AND/OR) support

Work Plan

The work plan will be determined by the work group. But an initial work plan is:

Meeting once (or more) per week until the IHE NA Connectathon in Jan, 2016.

Host a Virtual Connectathon during the month of Jan.

Quickly create a document with the core constraints identified by initial implementors of HPD for the USA region.

Testing at the IHE North American Connectathon 2016

Registration has closed but… Organizations already registered for IHE NA Connectathon testing can add the USA National Extension option still (contact Eric Heflin). HPD USA National Extension will be tested on Thursday, January 28 using Gazelle plus manual review

HIMSS16 Interoperability Showcase. Several Showcase options under consideration. Your feedback is requested. Please let us know ASAP if you have an interest in participating in the HIMSS16 Interoperability Showcase!

Goals

The goals will be self-determined by this workgroup. The expectation is to constrain the IHE International HPD profile to make it more implementable in the USA. Expected areas of focus include:

Value set determination for various attributes of people and organizations Required queries Implementation details for IHE SOAP web services end points Implementation details for secure email (Direct Project) addresses Changing certain attributes to be required, or required if known Others determined by the group

Scope

The proposed scope, subject to modification by the Task Force is:

• New suggestions from workgroup (paraphrased):
  • Since this is a US extension, perhaps we could call out the National Provider Id (NPI) and associated taxonomy support and validation (https://npiregistry.cms.hhs.gov/). It's true that not all US providers have an NPI but if they do then National Plan and Provider Enumeration System (NPPES) the can be useful means to validate any instance of US- based HPD.
  • Another taxonomy issue is specializations. Several solutions were considered. Including an authoritative decision in the extension would clear things up.
  • Need to specify how to present NPIs and what to do with entities lacking them.
  • The name standards in HPD is for Western names. While this is a US national extension, there are a lot of cases in the US where the Western name standard may work poorly. We may want to consider how to address that such as making displayName “strongly recommended” or required where the Western standard does not apply. We may want to consider something more structured.
  • On “Define the “Electronic Service” attribute as needed by defined use cases”, broaden the list here to include other service types profiles outside of the IHE and eHealth Exchange. At a minimum, we may want to add an item for HPD, so you can explicitly retrieve the endpoint for a federated node to query it directly. This would enable a new use case of allowing the use of HPD to discover other HPD directories. Add to the scope a method of uniquely identifying the end point type, such as Direct email vs. IHE XCPD vs IHE HPD vs FHIR base URL, etc. Need to identify (or define if we must) a value set and coding scheme to represent this additional information.

Must implement the following query (searchRequest) operations:

• Individual Provider by a defined list of attributes
  • Base object is HCProfessional
  • List attributes (optional, required, required if known, conditional)
• Organizational Provider by a defined list of attributes
  • Base object is HCRegulatedOrganization
  • List attributes (optional, required, required if known, conditional)
• Relationships by a defined list of attributes
  • Base object is groupOfNames
  • List attributes (optional, required, required if known, conditional)
• AND/OR Boolean logic support
• Wild card support
  • Define what types are required
  • Define what types are optional
  • Determine if provider directories are required to support fullsubTree searches under a base DN, or must every query be fully scoped to a leaf-node?
• Other?

Define the “Electronic Service” attribute as needed by defined use cases:

• For eHealth Exchange
• For Direct Project/Secure email
• For FHIR base URLs

Require that HPD servers support at certain quantities of responses per query:

• At least 100
• At most 1000

eHealth Exchange Attribute attribute definitions:

• End point version numbers
• End point URLs
• Type of service being provided at that end point
• Architecture
  • Value set TBD, but perhaps (federated, cdr, hybrid, other)
• Use cases supported by that group of end points
  • Determine value set
    • Treatment
    • Claims
    • PHR
    • Others?
• Human readable organization name
• Relationship
  • Humans admin contacts
  • Other organizations (parent, child, sibling)
• Status
  • Active/inactive/etc.
• HomeCommunityID (HCID) OID value
• Human contacts
  • Name
  • Title/role
  • Address
  • Telephone
  • email
• Company information
  • Name
  • Address of service location(s)
  • Telephone
  • email
  • IP address(es) for sending to that organization
  • IP address(es) for receiving from that organization
  • Content types for sending to that organization
  • Content types for receiving from that organization
  • purposeofuse value set sent from that organization
  • purposeofuse value set accepted by that organization
  • role value set sent from that organization
  • role value set accepted by that organization
• Other?

Direct Project/Secure e-mail attribute definitions:

• Certificate or location for certificate acquisition
• email address
• email address type
• Other attributes similar to the eHealth Exchange such as use cases supported, versions, admin contacts, etc.
• Other?

FHIR attributes:

• Base URI
• Security requirements
  • Open, OAuth2, 2-way-TLS, other
• Other attributes similar to the eHealth Exchange such as use cases supported, versions, admin contacts, etc.
• Other

Base64 encoded control message syntax:

• Is not tested by Gazelle validators
• Constrain the structure to a single structure (with clarity on the namespace prefix)
• Create validation rules for this data field and that represented inside it. (At least three different representations of the control segment message structure were identified at the CAT15 testing.)

General attribute clarifications/USA constraints

• Make Organization Provider attributes required:
  • (See table Table 3.58.4.1.2.2.3-1:Organizational Provider Mapping for views on national extensions)
    • Type with a USA defined value set
    • Electronic Service URI? WSDL?
    • Medical Records Delivery Email Address?
    • Specialty and a USA defined vocab?
    • Identifiers and types for USA
    • Certificates including definition of types

• Individual Provider attributes (Table 3.58.4.1.2.2.1-1 HPDProvider Optional Attributes)
  • (See Table 3.58.4.1.2.2.2-1:Individual Provider Mapping for ideas related to national-extensions)
    • Type with USA defined value set
    • Identifier USA defined type and value set

Electronic ServiceURI URI for WSDL, needs clarification. HPD assumed it could point to another directory or to an end point with a WSDL. But no directory exists and WSDL is not universally supported.

Make three address required (mailing, billing, physical) Make detailed address values required $addr (required now) plus ($city, $zip, $state, $addr1, $addr2, etc.)

Define vocab for credential, specialty

• Certificate details
• Make provider medical records deliver email address required if known (R2)

Clarify: Question about federating directory aggregating multiple responses into single searchResponse's vs 1 searchResponse with everything vs 1 searchResponse for each searchResultEntry. No conclusion about correct behavior.

How should the base DN be determined or constrained? Should we have the same base DN for all HPD USA implementers?

The list of “Type” values that go in the HCIdentifier will be constrained to a specific value set.

Others items as determined by the group

Open Discussion

From Rim 2016-01-22 <edited>:

HPDProvider

• hpdProviderLanguageSupported - was O
  • We discussed this at length as a very useful value, but potentially difficult for directory operators to collect and maintain accurately, and inaccuracy was potentially worse that an absence of information. We decided to recommend that it be filled in, but not make it required. I know that “recommended” is not an appropriate word for a specification and is not testable.
• hpdProviderBillingAddress - was O
  • We discussed this too, and determined that for most of the use cases we envisioned, it held little value and left it as optional.
• hpdProviderMailingAddress - was O
  • Ditto.
• hpdProviderLegalAddress - was O
  • Ditto.
• hpdProviderPracticeAddress - was O
  • We need to continue the discussion regarding making service location a first class object. I think I understand, but have some angst if the only reason is based on LDAP indexing. That said, we decided in California to make this optional for individuals, but required for organizations and require that every individual have an organization identified. So the practice address would always be associated with an organizational relationship. This makes the data more complicated to retrieve for individuals, but the required queries are consistent for all. Also, practice address may often have a related organizational relationship (an individual may have more than one practice location) and that context and relationship is important and can’t be represented for individual providers within the HPDProvider object.
• hpdMedicalRecordsDeliveryEmailAddress - was O
  • 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.
• memberOf - was O
  • I agree with your proposed “special rule if a solo provider…”. In California, we require an organization for all, including solo providers that is the practice for the solo provider as an organization.
• hpdCredential - was O
  • I’m undecided…

• Other things we discussed, but I didn’t see here:
  • The various phone and fax numbers – all R2
  • We actually relaxed this requirement, making them O. Then we provided implementation guidance, first following the same rules as for address (there must be phone numbers with an organization affiliated with each individual), and required this field for individuals only if the phone number an individual wished to publish was different from the organizational phone number.

• • One of the things we discussed at length is that we can’t make address information for individual providers required if providers don’t want that information published. Your average HIE will know the address and phone numbers, and R2 means (or at least implies) they then must publish them.

• • I don’t think I have any comments on your proposal for credential. It was not considered a high-priority object in our discussions, and the entire object remains O.

• HPDProviderMembership
  • telephoneNumber - was O
  • In California, we made this required, given the requirements I listed above. That means that every provider must have a phone number associated with their organization, but may have a separate number for themselves in the HPDProvider object.
• facsimileTelephoneNumber - was O
  • I’d leave this O.
• mobile - was O
  • I’d leave this O.
• mail - was O
  • I’d leave this O.

• The above really reflects my thoughts that we should encourage participate without making the data requirements onerous. I won’t fight R2 too hard though.

• HPDElectronicService
  • As you say, we need to talk about this more.
• hpdServiceAddress - was R
  • Agreed that this needs to be further constrained and likely need to extend the object model.
• hpdIntegrationProfile - was O
  • Agreed that this needs to be required, and we need to develop an enumerated terminology for this.
• hpdContentProfile - was O
  • I would only make this required if the enumerated terminology includes “Unspecified”. For example, many allow Direct messages with any payload, and that should be encouraged. I likewise would not want to limit in some way the documents that an organization might choose to expose through Query for Documents.
• hpdCertificate - was O
  • I think this may need to be a more complicated rule. For Direct, there are other discovery mechanisms that are part of the standard and adding it here has no value. For some services, however, requiring it here might be appropriate as THE place to search.

• HCProfessional
  • Individual Providers MUST not be used to store Organizational Providers.

Agreed.

• Provider “Identifiers”/HCProfessional/hcIdentifier - was R
  • In California, this is where we put the NPI and made it required for individuals (and required if known for organizations). Ayami can discuss the thoughts on how to represent NPI.
• Provider Type/HCProfessional/HCProfessional - was R
• Provider Type description/inetOrgPerson/description - was R
  • We didn’t discuss either of these, but I agree that we need a terminology.
• Provider Title/inetOrgPerson/title - was O
  • I’m not sure that I see sufficient value to make this required or even required if known.
• Provider First name/inetOrgPerson/givenName - was R2
  • Agreed
• Provider Middle Name/inetOrgPerson/initials - was O
  • Agreed
  • It has this name because it is part of the inetOrgPerson object, which has a bad name. Guidance still appears that it can be used for a middle name or middle initial(s).
• Provider Last Name/inetOrgPerson/sn - was R
  • Agreed.
• Provider Known names/inetOrgPerson/cn -was R
  • Agreed.
• Provider Language Supported/HPDProvider/hpdProviderLanguageSupported - was O
  • See note above.
• Provider Gender/Natural Person/gender - was O

We put this in the same bucket as language, recommended. I know that “recommended” is not a real term in standards and not testable, but perhaps R2 should be considered.

• Provider medical records deliver email address/HPDProvider/hpdMedicalRecordsDeliveryEmailAddress - was O
  • See note above.

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.

• I might not do this for “mail”, as I’d put that in the same class as a phone number. But the others, and hpdMedicalRecordsDeliveryEmailAddress, I strongly agree.

• Provider Facility Name/inetOrgPerson/physicalDeliveryOfficeName - was R2
  • Agreed.
• Provider Mailing Address - was R2
• Provider Billing Address - was O
• Provider Practice Address - was R2
  • See discussion above. For individuals, I believe they should all be O and instead be represented through an organization.

• Provider Practice Organization - was O
  • There is an operational reason to perhaps make this required, but it is not fundamental.

Here is the thinking…

• If I don’t use this attribute, and I want to find the direct address for Dr. Smith at Community Hospital, I need to search for Dr. Smith, then get the memberOf objects, find Community Hospital, get the right service object, and I have a Direct address. That will always work. And it works and is the only way it works if Dr. Smith has more than one affiliation at this DN.

• However, many of the federated directories will have Dr. Smith with a single affiliation – the one associated with the organization hosting the directory. In this case, I search for Dr. Smith, look at the organizational affiliation returned and if it is the right one and the only one, get the service object, and I have a Direct address. It is fewer trips to the Directory. It only works if there is a single organization listed at the DN, but that is likely the most common case.

• Provider Business Phone - was R2
• Provider Mobile Phone - was R2
• Provider Pager - was R2
• Provider Fax - was R2
  • See discussion above.

• Provider “Credential” - was O
  • I’d leave this optional.
• Provider Specialty - was O
  • Agreed, and that is what we have done in California. We specified the Taxonomy data set rather than what is listed in HPD.
• Provider Relationship - was O
  • We made this required in all cases, with the special rule for solo practices to represent the practice as an organization.
• Legal Address - was O
  • I’d leave optional.
• Electronic Service - was O
  • I’d make this required if known. The directory should be useful for providers that don’t have an electronic means of communication. If our use cases don’t including “finding a cardiologist within a zip code” without returning a Direct address for all cardiologists, then it should.

From Rim <edited>:

The S&I Framework identified 7 primary use cases (see https://docs.google.com/spreadsheets/d/1B7G-p53o7rtJXp349XwTcb4fsBJkPQVgtO1vTWb4Zg/edit#gid=0):

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.

I don’t know that everyone would still consider all of these use cases high priority, but this relates to the list I was drawing from memory in my comments of late.

I believe that 1, 2, 3, and 4 are fundamental. I think 5 probably is useful, but might be considered a degenerate case of 2. As I said before, I’m not so sure about 6 by itself. I think 7 is a valuable use case, but may not be independent of the others already on the list and might be achieve through 6 (perhaps the reason for 6) followed by 2.

---

From Marty: How do we ensure the quality of the data? Eric H suggested that we have an additional entry in the directory indicating the curator of a given sub-tree.

---

From Rim:

>> Rim/all, unless there are objections, I’ll make the below changes. (eric)

1. Yellow pages lookup – I think this makes sense as stated in the HPD profile.

2. Query providers and their associations – I think this likewise makes sense as a use case, although I found the title confusing. The description is for finding the service endpoint for each of a list of providers (not specific as to whether individual or organization), and assumes that the service endpoint is through an individual’s association with an organization (I think). I think a cleaner use case might be explicit about finding electronic service information for one or more individual providers.

3. Emergency responders identification – While the user story is different, I’m not sure that the capability here is any different than the yellow pages lookup above. 4. Referrals target identification – hospital – Ditto. 5. Referrals target identification – specialist – Ditto.

6. Keeping provider lists current – It was not clear to me in reading this use case whether this was effectively the same as (2) above (but with different information), or a need to push updates to an organization instead. Or perhaps this is designed to make update dates queriable. I’m unaware of any push update, so I suspect it is the latter. I’m good with that. >> This was for organizations, like the SSA, that have an extensive internal provider dir. So the SSA would query the HPD sources periodically for new info, or use the provider information feed optional capability I presume (my impression, I don’t want to try to represent the SSA).

7. Certificate retrieval – This looks like a special case of (2) for individuals. 8. Language retrieval – This looks like a special case of (1) for organizations.

9. Add provider 10. Update provider

I don’t use or think about the update use cases, so I don’t have any comments on these two.

11. Federated query inside a state 12. Federated query to other state 13. National federated provider directory 14. Federated data contribution 15. eHealth Exchange services discovery

I think these are fine. They probably say more about architectures supported by the federation option than the API, but I believe them to be necessary and complete.

16. Same as Base HPD/Federated plus... 17. Direct Project/Secure email address acquisition 18. Direct Project/Secure email x.509 certificate retrieval 19. IHE/SOAP end-point acquisition 20. Consumer/patient directory (from a proposed FHIR use case) – I’m not sure what this is. 21. FHIR end point identification 22. Identification of a test patient – I’m not sure what this is.

To me, these look less like use cases and more like user stories that are examples of use cases. I think there are probably at least four use cases above:

1. Find information on an individual provider. The information found will be based on the HPD data model and required attributes in it. Based on the above, that needs to (at least potentially) include contact information, address, Direct address, SOAP service endpoint, FHIR resource, language, specialty, and x.509 certificate. 2. Find information on an organizational provider. The information may largely be the same as an individual. 3. 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. 4. Find a list of organizational providers that match a demographic. Information may be largely the same as an individual.

I don’t see anything specific to NPI in the above, so we either need a user story for NPI or need to add that to information in the use cases.

What I see somewhat missing is:

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 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?”.

I am confident that if we determine how a Direct address will be represented in HPD, how a SOAP or eHealth Exchange service endpoint is represented, how a FHIR resource is represented, and how an NPI is represented, we can accomplish all of these use cases given what HPD does today.

Question: How much to we want to give implementation guidance? For example, use case 6 in my list can require many queries to achieve in the most general case, but specific cases can take fewer if certain optional attributes are populated.

---

From Ron: If I’m reading the specification correctly, specifically defining HPDProviderMailingAddress, HPDProviderBillingAddress, HPDProviderPracticeAddress as only using the PostAddress address attribute format may not meet the community needs.

Page 64 shows the following Example of content to be stored in the PostalAddress attribute of the hpdProvider...Address object:

status=primary $ addr = 1221 Circle Lane Nowheresville CA 98765 US $ streetNumber=1221 $ streetName=Circle Lane $ city=Nowheresville $ state=CA $ postalCode=98765-4321 $ country=US

Both the LDAP V3 RFC: http://www.ietf.org/rfc/rfc2252.txt?number=2252

And RFC 4517, Section 3.3.28 states:

“Many servers limit the postal address to no more than six lines of no more than thirty characters each.

     Example:
        1234 Main St.$Anytown, CA 12345$USA
        \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA”

Assuming the hcProvider…Address objects are using the PostalAddress object, then each line may be limited by the key namespace of the “key=value” so now the content is limited to less than 30 characters.

I don’t know if the Examples used in the Attached (source: http://wiki.siframework.org/IHE+HPD+Standard+Analysis ) sufficiently tests the format with long Address names or USPS Standardized Address compliance.

Also attached are the USPS Publication for printed address which states: “The Postal Service and commercial MLOCR equipment can read a maximum of 40 characters per line within a maximum of 8 separate words per line”

There is an Update to the ISO 29091 (29019-2013) Specification but I don’t know if defines the ObjectClasses as only supporting the PostalAddress Attribute or simply defines it as a $ delimited key=value based object.

I’m curious what experience related to integration with multiple LDAP V3/DSML V2.0 compliant directories (see list here: https://www.ldap.com/choosing-an-ldap-server ) would reveal.

Do we need to TEST and then address the limitation noted by RFC 4517, Section 3.3.28 or stated that the implementers’ must ensure their LDAP Schema doesn’t limit the Postal Address to 6 lines? Assuming the limitations do exist, do we need to inform the readers that “Attribute values may be truncated to 30 characters when used in the postal address”?

There are other LDAP V3 defined attributes that support the following related to location and addresses: 5.7. c

  This attribute contains a two-letter ISO 3166 country code
  (countryName).

   ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )

5.8. l

  This attribute contains the name of a locality, such as a city,
  county or other geographic region (localityName).

   ( 2.5.4.7 NAME 'l' SUP name )

5.9. st

  This attribute contains the full name of a state or province
  (stateOrProvinceName).

   ( 2.5.4.8 NAME 'st' SUP name )

5.10. street

  This attribute contains the physical address of the object to which
  the entry corresponds, such as an address for package delivery
  (streetAddress).

   ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

5.17. postalAddress

  ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch
    SUBSTR caseIgnoreListSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

5.18. postalCode

  ( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )

5.19. postOfficeBox

  ( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )

5.20. physicalDeliveryOfficeName

  ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

If the ISO 29091-2013 is not tightly tied to the postalAddress object or now incorporates these additional attributes into the hpd…Address schema then all may be well.

If not, what do we to be prepared to address to ensure interoperability?

---

From Greg:

- “AND/OR Boolean logic support” Need to be thinking about these in terms of limiting of ldap/dsml functionality. Instead of affirming "needs to support and/or logic" (which of course you should, ldap/dsml does thus the hpd spec demands it!), it helps to see what you're excluding. For example, the implication is "may not support 'not', 'equalityMatch', 'substrings', 'greaterOrEqual', 'lessOfEqual', 'present', 'approxMatch', or 'extensibleMatch'" (these are FilterGroup operations in the dsml). It then becomes clear we also need 'equalityMatch', 'substrings'. Should we support 'Not'? What about 'present'? I suspect we could do without approxMatch, >=, <=, and definitely 'extensibleMatch'. This discussion is hidden by the way this scope item is phrased.

Keep in mind any restrictions on query syntax limits clients. Server authors will prefer to make their job easy by limiting their implementations. But doing so also strongly limits hpd client options. It's easy to hide behind identified usecases to make these determinations, but I think the bar needs to be much higher with a rationale for each specific exclusion.

For example, objectClass may be one of the harder attributes for non-ldap based servers to handle. An argument could be made for not requiring any FilterGroup operations against it. Meanwhile wildcard searches (FilterGroup substrings operation) are one of the more productive ways to find anything in a directory. A rationale must be given for any fields exempted.

- Require that HPD servers support at certain quantities of responses per query: I like the idea of a minimum... a server that caps it's results to 10 is being intentionally obstructionist.

- Endpoint discovery I continue to puzzle over this discoverable-endpoints idea. There's no way anyone is going to put a url and a private certificate into the directory (pix, xds, xca). When push comes to shove someone has to pick up the phone and call the place, get legal to draft contracts, and IT guys to sort out certificates, software configuration, and possibly dole out user accounts. This is for exactly the same reason that having a Direct implementation won't automatically get you into a national trust bundle. I won't object to specifying them, because I like to be pleasantly suprised :-)

Time Line

Date	Activity/Event
Published Oct 13, 2014	Publication as IHE HPD Trial Implementation Supplement
In progress now	Vendor Product Development
In progress now	Registration for NA Connectathon 2016 USA National Extension Testing
In process now (deadline extended!)	Register for HIMSS 16 Interop Showcase
Call for participation	Now through Jan 4, 2016
Virtual Connectathon	Now through end of Jan 26th, 2016 (meeting schedule 1-3 times a week depending on participant interest)
Jan 28th (one day)	IHE NA Connectathon 2016
End of Jan 2016 through HIMSS16	HIMSS16 Interoperability Showcase™ Setup / Prep
Feb 30th through Mar 4th, 2016	HIMSS16 Interoperability Showcase
Post HIMSS16, targeting April 2016	IHE USA National supplement publication process
Targeting May 2016	Available for Deployment to Customers

FAQ

Frequently asked questions

• Q01: I see that the 2015 version of the IHE HPD Intnl Profile was updated. What changed between it and the 2014 version?
  • A: Only the file name changed. Click this link to see the result of a comparison of the two pdf files. http://wiki.ihe.net/index.php?title=File:Comparison_of_2014_to_2015_profiles.pdf

• Q02: What is the purpose of this project?
  • A: To create a version of the IHE HPD profile that is implementable in the USA.

• Q03: What will be tested at the IHE 2016 NA Connectathon?
  • A: We will test that which is defined in the USA National Extension profile. At this point, Eric H expects that will entail the use of the basic Gazelle test tool to test the base IHE HPD profile, but that additional manual tests will be conducted by one or more Connectathon Monitors and via peer-to-peer testing. These manual tests will confirm interoperability for those additional constraints defined in the USA National Extension, such as demonstrating support for each requirement attribute, query type, control message syntax, etc.

• Q04: Are we starting from scratch?
  • A: No. We have three key sources to draw upon. 1) The original ONC ModSpec work included many of the USA-specific concepts in scope. They were defined and published under that venue and then removed so that the HPD profile would work in multiple countries. 2) The initial group of implementers have provided feedback regarding the USA needed capabilities. 3) Those seeking to deploy a new provider directory, such as the FHIR Argonaut group, and the Sequoia Project (eHealth Exchange and Carequality) have captured additional requirements.

References

ONC Provider Directory Round Table (Policy and Technology) http://wiki.ihe.net/images/e/e4/2014-04-17-HIECommunityRoundtable_ONCProviderDirectoriesUpdate.pdf Presentation

Gazelle Test Tool: http://ihe.wustl.edu/gazelle-na/

ONC Test tool: http://sitenv.org/provider-directory-test-tool

Source and instructions for building the PDTI test tooling: https://github.com/siteadmin/pdti

Outside the show floor Gazelle http://ihe.wustl.edu/gazelle-na/home.seam

Test Data: http://sitenv.org/provider-directory-test-tool

ONC Documentation: http://modularspecs.siframework.org/Provider+Directories+Artifacts Test Tools/Data/Schemas/etc.:

Initial project: http://modularspecs.siframework.org/Provider+Directories+Artifacts

Google Groups HPD: https://groups.google.com/d/msg/ihe-hpd-implementors/

To Participate

For any questions, concerns, or to participate, please contact either Sarah Willis or Eric Heflin at the following:

Eric Heflin (eric.heflin <at> thsa.org) Sarah Willis (swillis <at> himss.org)

Meeting Minutes

2016-01-06

Agenda:

• Introductions
• Mission / Mandate (largely self-determined!)
• NA Connectathon/HIMSS16/IHE USA spec process
• Governance / Leadership
  • IHE USA Implementation Taskforce/IHE International/ISO governance
  • Call for co-leaders
  • Open to all, vendor and technology neutral, transparent process
• Workplan
  • Effort
  • Schedule
  • Communications
• Q&A
• Other topics?
• First working session (we begin work today!)
• Next meeting
  • Scheduled for next Wed Jan 13th
  • Can also meet on Mon Jan 11th if there is interest/justification
• Closing

Minutes: The meeting was called to order at 2:03pm Central Time.

Roll:

• Amaymi Tyndall - RAIN (present)
• Dan Chaput - ONC (present)
• Timothy Tyndall - RAIN/Live Oak (present)
• Gonzalo Hernando - Sequoia (present)
• Chuck Swegle - GE Healthcare (present)
• Marty Prahl - SSA Contractor (present)
• Matt Rahn - ONC (present)
• Messah Combey-Adamah - (present)
• Rim Chothren - CAHIE (present)
• Ron Bowron - Argo Data Source (present)
• Sarah Willis-Garcia - HIMSS/IHE USA (present)
• Siva Kandaswamy - WebRecycles, connectathon (present)
• Eric Heflin - THSA/Sequoia Project/IHE (present)

The agenda published on the IHE wiki was accepted and used to guide our discussion.

Members didn't object to roll being taken, thus will be recorded for each meeting.

Eric H. The background, context, and scope were discussed. Co-leaders, participants, and observers are all welcome. Work will be done under ISO governance rules (transparent, open, inclusive, public, vendor neutral, etc.). Negative information learned about others cannot be shared, but successes can be shared (as per IHE NA Connectathon rules).

Eric H. Discussed the reason for the creation of this Task Force. The goal is to address gaps identified via broad industry listening sessions for the country's national provider directory strategy. According to research and discussions, HPD is not viable yet, for all, due to lack of USA-specificity. A broad market survey was conducted and no other solutions were found to exist at this time that met all of the requirements of the identified provider directory use cases, for the USA market. The IHE International Information Technology Infrastructure Workgroup Planning Committee and Technical Committees agreed that this was an appropriate USA National Extension work item. Thus Eric H. proposed this work to the IHE USA Board of Directors, which approved it in December, 2015. Resulting in the formation of this Implementation Task Force.

Eric H. Discussed that the definition of success for the project, could perhaps, be an implementable specification that becomes an IHE USA National extension and is published early in 2016 to the IHE ITI Technical Framework as a Volume 4 supplement. Additional success goals could be that the specification is proven out during testing via a virtual connectathon, and at the IHE NA Connectathon, plus demonstrable at the HIMSS16 Interop Showcase for those interested in such. Ultimate goal is to get products on the market, and customer solutions deployed ASAP, targeting Q2 2016. No objections were heard, but support is still being determined for the venues.

Sarah W. covered connectathon access, email connectathon@ihe.net for interest, Jan 14th deadline for registering to test the HPD USA National extension. On-site registration is possible after Jan 14th. Sarah W. provided several links: http://www.iheusa.org/connectathon.aspx and http://www.iheusa.org/connectathon-participantresources.aspx with more info about the IHE NA Connectathon.

A question was raised about the relationship of this work to FHIR Provider Directory work. Eric H. indicated the Argonaut project was being engaged with, with the intent to bridge HPD work and FHIR work, under that venue. Once completed, the expectation is that the output of a FHIR dir spec would be shared publicly, with HL7 and with IHE, and that the same use case applied to a FHIR provider dir as a SOAP provider dir. Eric H also indicated that he was seeking to ensure maximum compatibility and interoperability between the FHIR work and the HPD work. There was strong support for this approach. Eric H agreed to continue to engage with the Argonaut Project leadership to collaborate, try to transparently share the FHIR work with the HPD USA National Extension Task Force both ways, including with any available written artifacts.

Each member of the group provided a brief introduction.

Use cases were briefly discussed (in passing, not in detail) and were generally agreed to. (Note that the Task Force probably needs to review in detail to ensure we have the same goals.)

Eric H. offered to host a "virtual connectathon" as soon as Task Force members were ready, if they saw value in that. He also offered to host additional meetings as often as the Task Force felt would be productive, including twice a week, to daily. It's up to the Task Force to decide on their meeting schedule. HIMSS, IHE USA and Eric are supportive of whatever meeting frequency seems to be productive to all.

Dan C. mentioned that the ONC is working on holding a Provider Directory summit in early April, 2016.

Several specific objectives were noted: Minimal data set, targeted queries, ESI, direct addresses, metadata being managed esp. Attributes should be constrained. Queries should be constrained such as to correlated with the minimal required attributes.

Rim is able to participate, Siva hopes to implement, Timothy is available to help in any way, Marty participant, Ron participant. Others are also invited to express a level of engagement, just to help with planning. (Not a formal commitment.)

Next steps: Each Task Force member is to respond with their specific objectives, status, if they plan to participate as an observer, if they plan to go to the NA Connectathon, and if they want to demonstrate the USA National Extension at the HIMSS16 Interop Showcase. Also, each Task Force member is to review the Scope document (that Eric H. will circulate after the call) to provided feedback (what's missing from the scope, what should be removed, changes, etc.). The hope is to make progress between now and the next meeting.

The next meeting will be next Wed, at the same time.

The call was opened up to comments for anyone, and no additional comments were received other than affirmation by several that we seem to be headed in the right direction.

The meeting was adjourned at 3:00pm Central time.

Corrections to the above notes are welcome!

2016-01-13

Roll:

• Amaymi Tyndall - RAIN (present)
• Dan Chaput - ONC (present)
• Timothy Tyndall - RAIN/Live Oak (present)
• Gonzalo Hernando - Sequoia
• Chuck Swegle - GE Healthcare
• Marty Prahl - SSA Contractor (present)
• Matt Rahn - ONC
• Messah Combey-Adamah -
• Rim Chothren - CAHIE (present)
• Ron Bowron - Argo Data Source (present)
• Sarah Willis-Garcia - HIMSS/IHE USA
• Siva Kandaswamy - WebRecycles, connectathon (present)
• Eric Heflin - THSA/Sequoia Project/IHE (present)
• Greg Carver - CareEvolution (present)
• Jim Derrickson - InterSystems (present)
• Jim Mulligan - FHA (present)
• Sukanya - GE (present)

Agenda:

• Introductions to/from any new Task Force members
• Approve minutes from last meeting
• Announcements
• Discuss voting process for the Task Force
• Discuss work done between this call and the last call
  • Review FAQ, new Scope items, new Discussion items
• Determine interest in NA Connectathon/HIMSS16 Interop Showcase
• Very brief timeline review
• Other topics?
• Spec creation working session
  • Begin work on spec
  • Define artifact (wiki, word, comments to PDF, Google doc, other)
• Start testing (virtual connectathon)
  • Establish end points, whom is ready to test basic connectivity
  • Define how to share information about end points, base DN, contacts
• Next meeting
  • Scheduled for next Wed Jan 20th
  • Can also meet earlier if there is interest/justification
• Closing

Minutes:

• Meeting called to order at 3:03pm Central Time
• New members introduced themselves.
• Minutes from prior meeting as posted on this wiki were approved.
• Announcements
  • Eric H announced that FHIR work on dirs have now started, and that he intends to submit our revised HPD use cases to the FHIR Argonaut project. No objections were heard. Intent is to keep FHIRdir and HPD USA national extension as compatible as possible. Also discussed MiHIN's specification (FHIRdir based on HPD), and the interest by others in HPD work.
• Discuss voting process for the Task Force
  • A simple majority voice vote of those on the call will be used.
• Discuss work done between this call and the last call
  • Review FAQ, new Scope items, new Discussion items
• Determine interest in NA Connectathon/HIMSS16 Interop Showcase
  • Not discussed due to time constraints
• Very brief timeline review
  • Not discussed due to time constraints
• Spec creation working session
  • DECISION: work will be done directly on this wiki, on a new sub page
  • Rim: Most use cases fall into two categories, information about a person, or an org.
  • Ron: Dirs can be flat or hierarchical
  • Rim: A question for the group to decide is how much implementation guidance should we provide, such as related to LDAP tree walk best practices?
  • Ron: Who can add, update, read, etc.. most identity provider ACLs are flat.
  • Eric: Add/update are out of scope, as is access control, for now, if the group agreed? No objection were heard.
  • Marty: Relationship searches are part of a key use case for the SSA.
  • Eric: What, if any, constraints do we need to impose on DSML? Do we want to list required DSML features, or list those that are optional?
  • Greg: Need to address those not supporting substring matching, as it seemed to be a big point of contention last time.
  • Rim: It is not feasible to write different clients for each directory to accommodate directory server differences, esp. where there could be federation, thus we need to keep the existing HPD requirement to support DSML v2, otherwise client implementations are not feasible.
  • DECISION: we reinterate that DSML v2 support, full syntax, is required of HPD servers (provider information source actors).
    • At this time, we will not change DSML optionality or LDAP optionality (we may revisit this in the future)
  • Group discussion about the USA National Extension limited to only constraining, not relaxing, the base IHE HPD profile. Group agreed that was the desired approach.
  • Eric post-call thought: We can submit a change proposal to IHE if the task force feels the base IHE HPD spec needs to relax a constraint since base HPD is still in Trial Implementation status
  • Ron: We need to specify what HPD attributes would be required.
  • Eric: We need to look at the base HPD schema and see if substring searching is allowed on all strings
  • Greg: Base HDP schema definition already indicates which attributes are searchable, and how (case insensitive).
  • DECISION: Implementors will support substring searching on all DSML string values as per the existing HPD schema.
  • Action item: Eric is to email and post the HPD schema file for the task force
  • Ron: We might want to adopt ISO postal object model, including a change proposal to IHE.
  • Eric: CPs are in scope I feel. No objections were heard to Ron's proposal.
• Start testing (virtual connectathon)
  • Establish end points, whom is ready to test basic connectivity
  • Define how to share information about end points, base DN, contacts
  • Not discussed due to time constraints
• Next meeting
  • Will meet next Mon, Jan 17th, at 11am Central time
• Meeting adjourned at 4:02pm Central

2016-01-18

Roll:

• Amaymi Tyndall - RAIN (present)
• Dan Chaput - ONC
• Timothy Tyndall - RAIN/Live Oak (present)
• Gonzalo Hernando - Sequoia
• Chuck Swegle - GE Healthcare
• Marty Prahl - SSA Contractor
• Matt Rahn - ONC
• Messah Combey-Adamah - (present)
• Rim Chothren - CAHIE (present)
• Ron Bowron - Argo Data Source
• Sarah Willis-Garcia - HIMSS/IHE USA
• Siva Kandaswamy - WebRecycles, connectathon
• Eric Heflin - THSA/Sequoia Project/IHE (present)
• Greg Carver - CareEvolution
• Jim Derrickson - InterSystems
• Jim Mulligan - FHA
• Sukanya - GE
• Did Davis - Sequoia (present)

Agenda:

• Introductions to/from any new Task Force members
• Approve minutes from last meeting
• Announcements
• Discuss work done between this call and the last call
  • Review LDIF file
  • Initial specification for HPD USA National Extension
  • Prioritize use cases
  • New Open Discussion items
• Determine interest in NA Connectathon/HIMSS16 Interop Showcase
  • Who will be at the Connectathon next week?
    • None on the call today
  • What should be the work plan for this week?
• Very brief timeline review
• Other topics?
• Spec creation working session
  • Continue work on spec (wiki)
• Start testing (virtual connectathon)
  • Establish end points, whom is ready to test basic connectivity
  • Define how to share information about end points, base DN, contacts
  • RAIN/Live Oak is ready
• Next meeting
  • Scheduled for next Wed Jan 20th
  • Can also meet earlier if there is interest/justification
• Closing

2016-01-20

Roll:

• Amaymi Tyndall - RAIN (present)
• Chuck Swegle - GE Healthcare
• Dan Chaput - ONC
• Didi Davis - Sequoia (present)
• Eric Heflin - THSA/Sequoia Project/IHE (present)
• Greg Carver - CareEvolution (present)
• Gonzalo Hernando - Sequoia (present)
• Jim Derrickson - InterSystems
• Jim Mulligan - FHA
• John Donnelly - IntePro (present)
• Messah Combey-Adamah - (present)
• Marty Prahl - SSA Contractor (present)
• Matt Rahn - ONC
• Rim Chothren - CAHIE (present)
• Ron Bowron - Argo Data Source (present)
• Sarah Willis-Garcia - HIMSS/IHE USA
• Siva Kandaswamy - WebRecycles (present)
• Timothy Tyndall - RAIN/Live Oak (present)
• Sukanya - GE

Agenda:

• Virtual connectathon
  • If you are ready to test, send end points via email to the task force
  • Messah would be acting as a consumer
  • RAIN can do both consumer and directory actors
• New additional working meeting set for Friday 2016-01-22, at 3pm Central (4pm Eastern, 1pm Pacific)

Working session on specification

2016-01-22

Roll:

• Amaymi Tyndall - RAIN (present)
• Chuck Swegle - GE Healthcare
• Dan Chaput - ONC
• Didi Davis - Sequoia
• Eric Heflin - THSA/Sequoia Project/IHE (present)
• Greg Carver - CareEvolution
• Gonzalo Hernando - Sequoia
• Jim Derrickson - InterSystems
• Daryl Flaming - InterSystems (present)
• Jim Mulligan - FHA
• John Donnelly - IntePro
• Messah Combey-Adamah - (present)
• Marty Prahl - SSA Contractor
• Matt Rahn - ONC
• Rim Chothren - CAHIE
• Ron Bowron - Argo Data Source
• Sarah Willis-Garcia - HIMSS/IHE USA
• Siva Kandaswamy - WebRecycles
• Timothy Tyndall - RAIN/Live Oak (present)
• Sukanya - GE

Agenda:

• Approve minutes
• Virtual connectathon
  • If you are ready to test, send end points via email to the task force
  • Messah would be acting as a consumer
  • RAIN can do both consumer and directory actors
    • End points:
      • Address: http://directory.direct.liveoaktech.net/sandbox/dsml/search.php
      • WSDL: http://directory.direct.liveoaktech.net/sandbox/LiveOakDirect.wsdl
      • Base DN: o=rainLiveOakTest,dc=hpd
• Final count of NA Connectathon Participants
• Work on specifications
• Testing at the Connectathon and/or virtual testing