Addressing Meeting 2010-05-19
Jump to navigation
Jump to search
Notes from Addressing & Directories Workgroup
Status of Notes: DRAFT
Date: May 19, 2010
Time: 3:30pm-4:30pm
Attendees:
Actions from This Meeting
n/a
Decisions from this Meeting
Notes
Agenda
· Review action items
· Discuss the work group’s scope
· Next steps
Discussion
· Review of action items
o Action #1 - NHIN workgroup will consider the role of addressing/directories, but there are higher priority items for the work group to tackle
§ Gives us the opportunity to think through key issues and provide framing ideas to the policy folks
o Action #2 - Arien has turned over responsibility for writing the charter to David Kibbe,
§ Instead of writing a charter, David posed some questions on the discussion tab to get opinions on what’s in scope vs out of scope for the group
§ We should have a charter in the next couple weeks
· Potential policy consideration: Should we recommend a technology or particular class of directory technology?
Comment from 'Thomas Davidson
· What is meant by technology?
Comment from 'David Kibbe
· Real issue is LDAP, beyond that we’re staying fairly vague
· Begs the question of what data is needed and what avenues are needed to expose this data
Comment from 'Vassil Peytchev
· We need to describe what we want the services to do before we specify the technology
· Also need to look at how the requirements for this technology will work with security and privacy
· Should look beginning from the perspective of the source to see what conditions need to exist
Comment from Karen Witting
· Clarify two places where directories might be useful:
o Source HISP/destination HISP
§ Source HISP needs to find correct destination HISP end point
§ Destination HISP needs to take the given health internet address and look up more complicated endpoint of where to route information to next
§ Both of these seem just like a look-up function, not really a directory function
o Source
§ Source needs to figure out what the health internet address is
§ May need a complex directory here
Comment from Arien Malec
· The use case for addressing/directories is where:
o An individual provider has a need to refer to another provider
o Provider knows of the existence of this other provider, but does not know their health internet address
Comment from 'Thomas Davidson
· Fine with either approach of a data model or technology
· Need to break out what information needs to be looked up
· Assumes a use case that is similar to that described by Arien’s
Comment from 'Chris Lomonico
· Need to nail down a proprietary technology and a data model
Comment from 'Brett Peterson
· Feels like it’s too early to hash out these issues
· However, once we do hash out these issues, we should take Vassil’s approach
· Not wise to mandate that a HISP should provide directory services
Comment from 'Joel Ryba
· Need both directory structures
o HISP requires a DNS directory that is separate from source being able to find another provider
· Definite security implications that should be looked into
Comment from 'Mark Stine
· We need to focus on what needs to get done before getting too bogged down on technology
o Shouldn’t dictate a technology as long as directory provider can support the minimum data
Comment from Arien Malec
· Directory decisions should be grounded in the user stories
Comment from 'David Kibbe
· For the use cases we are considering, the actors are providers or provider organizations that have a NHIN address and are seeking info about another NHIN addressee
o What info should be minimally made available?
o How should info be made available?
· Would each HISP have its own directory structure in order to serve small medical practices or providers that use the HISP?
o Info that HISP might have or need could be very minimal
Comment from Arien Malec
· We should start looking at the use case in terms of business language/clinical language before looking at data content
Comment from 'David Kibbe
· Should we take on all the NHIN Direct user stories or just limit ourselves to those which involve actors that are providers (and take on one-two of these)?
Comment from Arien Malec
· Agree that we should limit ourselves to one-two user stories
Comment from 'Thomas Davidson
· Are we constraining ourselves to lookup only by an individual or will we also look at HISP-based look-up?
Comment from 'David Kibbe
· Call for comments based on the following assumptions:
o Actor is an individual provider
o Provider has a NHIN address
o Provider needs another provider’s NHIN address for the purpose of care
o Provider knows that the other provider has a NHIN address, but doesn’t know the address
· Where is this information stored?
· How does the provider know where to access this info?
Comment from 'Vassil Peytchev
· From user’s perspective it’s the system’s responsibility to provide the appropriate directory information based on their role
· An organization may maintain both a directory service a credentialing service or there by an environment where these are separate
Comment from 'Joel Ryba
· Looking at how email is used today, there are different ways to find someone’s email address
· Purpose of a directory is to provide either a demographic search or certificate info
· Finding someone’s address can be done out of band
Comment from Karen Witting
· Address can be supplied in several ways
Comment from 'Mark Stine
· Directory services can be provider by a HISP or a service provider specializing in directories
· Should there be limitations to what you can query (especially if you have a nationwide directory service)?
· What about population and maintenance of the directory?
· What type of data do we want to store in the directories?
Comment from 'Thomas Davidson
· Directory is the most prevalent way to do look-up in the constrained scenario that was presented earlier
· In this case, we end up at a technology right away, LDAP
Comment from 'Chris Lomonico
· Need a way to verify accuracy of data
Comment from 'Brett Peterson
· For stage 1 MU, you will know who you’re sending data to, therefore look-up will be done through out of band mechanics and no automated mechanism is needed
Comment from Arien Malec
· There are a number of organizations that are interested in providing directory services (state HIEs, national organizations)
· We should focus on the key user stories for directories that already drive NHIN Direct activities
· This work group could provide useful guidance to potential directory providers based on these user stories
· We can also comment on the IHE specification
· Don’t think we should create/recommend a standard for the technology
· Don’t think we should address how the directories are maintained (this is a policy question)
Comment from 'David Kibbe
· Not within our scope to think through what a directory service should be, who should do it, or how to do it
· As per Brett’s point, NHIN addresses will be exchanged between people who know and communicate with each other right now
· We can make recommendations about what directory information to include or not include
· Open questions:
o HISP-HISP lookup or HISP-edge technology
o Relationship to security
§ Will be contingent upon the chosen backbone and edge protocols
§ How HISPs interact with CA
Comment from Arien Malec
· This is an issue for other workgroups, ie: security and trust as well as the concrete implementations
· Should Addressing work group make recommendations about what directory information to include or not include?
Comment from 'Vassil Peytchev
· Agrees with this scope
Comment from Karen Witting
· Doesn’t see any value in making these recommendations
· Doesn’t think any directory work at this time is necessary and that we should put this group on hiatus
Comment from 'Mark Stine
· Agrees that group should start with directory information but that this is not a high priority at the moment
Comment from 'Thomas Davidson
· We should comment on the IHE spec
Comment from 'Chris Lomonico
· We should recommend a technology
Comment from 'Brett Peterson
· Directory info is a good place to start, but we should wait to tackle this until mid June
Comment from 'David Kibbe
· Decision to put group on hiatus until after the June 11th meeting
Status of Notes: DRAFT
Date: May 19, 2010
Time: 3:30pm-4:30pm
Attendees:
Actions from This Meeting
n/a
Decisions from this Meeting
| # |
Date |
Action |
| 1 |
5/19/10 |
Suspend Addressing and Directories WG until after June 11th meeting |
Notes
Agenda
· Review action items
· Discuss the work group’s scope
· Next steps
Discussion
· Review of action items
o Action #1 - NHIN workgroup will consider the role of addressing/directories, but there are higher priority items for the work group to tackle
§ Gives us the opportunity to think through key issues and provide framing ideas to the policy folks
o Action #2 - Arien has turned over responsibility for writing the charter to David Kibbe,
§ Instead of writing a charter, David posed some questions on the discussion tab to get opinions on what’s in scope vs out of scope for the group
§ We should have a charter in the next couple weeks
· Potential policy consideration: Should we recommend a technology or particular class of directory technology?
Comment from 'Thomas Davidson
· What is meant by technology?
Comment from 'David Kibbe
· Real issue is LDAP, beyond that we’re staying fairly vague
· Begs the question of what data is needed and what avenues are needed to expose this data
Comment from 'Vassil Peytchev
· We need to describe what we want the services to do before we specify the technology
· Also need to look at how the requirements for this technology will work with security and privacy
· Should look beginning from the perspective of the source to see what conditions need to exist
Comment from Karen Witting
· Clarify two places where directories might be useful:
o Source HISP/destination HISP
§ Source HISP needs to find correct destination HISP end point
§ Destination HISP needs to take the given health internet address and look up more complicated endpoint of where to route information to next
§ Both of these seem just like a look-up function, not really a directory function
o Source
§ Source needs to figure out what the health internet address is
§ May need a complex directory here
Comment from Arien Malec
· The use case for addressing/directories is where:
o An individual provider has a need to refer to another provider
o Provider knows of the existence of this other provider, but does not know their health internet address
Comment from 'Thomas Davidson
· Fine with either approach of a data model or technology
· Need to break out what information needs to be looked up
· Assumes a use case that is similar to that described by Arien’s
Comment from 'Chris Lomonico
· Need to nail down a proprietary technology and a data model
Comment from 'Brett Peterson
· Feels like it’s too early to hash out these issues
· However, once we do hash out these issues, we should take Vassil’s approach
· Not wise to mandate that a HISP should provide directory services
Comment from 'Joel Ryba
· Need both directory structures
o HISP requires a DNS directory that is separate from source being able to find another provider
· Definite security implications that should be looked into
Comment from 'Mark Stine
· We need to focus on what needs to get done before getting too bogged down on technology
o Shouldn’t dictate a technology as long as directory provider can support the minimum data
Comment from Arien Malec
· Directory decisions should be grounded in the user stories
Comment from 'David Kibbe
· For the use cases we are considering, the actors are providers or provider organizations that have a NHIN address and are seeking info about another NHIN addressee
o What info should be minimally made available?
o How should info be made available?
· Would each HISP have its own directory structure in order to serve small medical practices or providers that use the HISP?
o Info that HISP might have or need could be very minimal
Comment from Arien Malec
· We should start looking at the use case in terms of business language/clinical language before looking at data content
Comment from 'David Kibbe
· Should we take on all the NHIN Direct user stories or just limit ourselves to those which involve actors that are providers (and take on one-two of these)?
Comment from Arien Malec
· Agree that we should limit ourselves to one-two user stories
Comment from 'Thomas Davidson
· Are we constraining ourselves to lookup only by an individual or will we also look at HISP-based look-up?
Comment from 'David Kibbe
· Call for comments based on the following assumptions:
o Actor is an individual provider
o Provider has a NHIN address
o Provider needs another provider’s NHIN address for the purpose of care
o Provider knows that the other provider has a NHIN address, but doesn’t know the address
· Where is this information stored?
· How does the provider know where to access this info?
Comment from 'Vassil Peytchev
· From user’s perspective it’s the system’s responsibility to provide the appropriate directory information based on their role
· An organization may maintain both a directory service a credentialing service or there by an environment where these are separate
Comment from 'Joel Ryba
· Looking at how email is used today, there are different ways to find someone’s email address
· Purpose of a directory is to provide either a demographic search or certificate info
· Finding someone’s address can be done out of band
Comment from Karen Witting
· Address can be supplied in several ways
Comment from 'Mark Stine
· Directory services can be provider by a HISP or a service provider specializing in directories
· Should there be limitations to what you can query (especially if you have a nationwide directory service)?
· What about population and maintenance of the directory?
· What type of data do we want to store in the directories?
Comment from 'Thomas Davidson
· Directory is the most prevalent way to do look-up in the constrained scenario that was presented earlier
· In this case, we end up at a technology right away, LDAP
Comment from 'Chris Lomonico
· Need a way to verify accuracy of data
Comment from 'Brett Peterson
· For stage 1 MU, you will know who you’re sending data to, therefore look-up will be done through out of band mechanics and no automated mechanism is needed
Comment from Arien Malec
· There are a number of organizations that are interested in providing directory services (state HIEs, national organizations)
· We should focus on the key user stories for directories that already drive NHIN Direct activities
· This work group could provide useful guidance to potential directory providers based on these user stories
· We can also comment on the IHE specification
· Don’t think we should create/recommend a standard for the technology
· Don’t think we should address how the directories are maintained (this is a policy question)
Comment from 'David Kibbe
· Not within our scope to think through what a directory service should be, who should do it, or how to do it
· As per Brett’s point, NHIN addresses will be exchanged between people who know and communicate with each other right now
· We can make recommendations about what directory information to include or not include
· Open questions:
o HISP-HISP lookup or HISP-edge technology
o Relationship to security
§ Will be contingent upon the chosen backbone and edge protocols
§ How HISPs interact with CA
Comment from Arien Malec
· This is an issue for other workgroups, ie: security and trust as well as the concrete implementations
· Should Addressing work group make recommendations about what directory information to include or not include?
Comment from 'Vassil Peytchev
· Agrees with this scope
Comment from Karen Witting
· Doesn’t see any value in making these recommendations
· Doesn’t think any directory work at this time is necessary and that we should put this group on hiatus
Comment from 'Mark Stine
· Agrees that group should start with directory information but that this is not a high priority at the moment
Comment from 'Thomas Davidson
· We should comment on the IHE spec
Comment from 'Chris Lomonico
· We should recommend a technology
Comment from 'Brett Peterson
· Directory info is a good place to start, but we should wait to tackle this until mid June
Comment from 'David Kibbe
· Decision to put group on hiatus until after the June 11th meeting