Addressing WG Notes 04072010
Jump to navigation
Jump to search
Notes from 'Addressing 'Workgroup
Status of Notes: DRAFT
Date: April 7, 2010
Time: 3:30pm-4:30pm
Attendees: Honora Burnett, Arien Malec,Brett Peterson, David Kibbe, Jeff Fisher, John Moehrke, Laurance Stuntz, Lin Wan, Martin Prahl, Tim Denis, Vinod Muralidhar, Wes Rishel and Steve Adams
Actions
Notes '
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Actions Items f'rom Last Week:
· Arien will formalize proposal on table in draft spec
· Group will review with goal of calling for consensus next meeting
· Wes is WG Leader
· We want to use only the most commonly used and well supported features of any standard
· The addressing spec needs three components:
o End point receiver (ex: wesj)
o Domain name -- business organization (ex: Rishel.com) associated with the end point
o Mapped through an external routing organization or technology organization (ex: Google or Gmail)
· Treat patient address in the same way (has the same three parts) as above
Discussion
Updates from Arien
· Listed on addressing specification page
· Work that Arien did is expressed in the Synopsis page
· Health Internet Addresses consist of a Health Domain Name portion, formatted according to the requirements of RFC 1034, and a Health Endpoint Name, formatted according to the local-part requirements of RFC 5322.
· Health Domain Name identifies the organizations that assigns the Health Endpoint Names and assures that they correspond to the real-world person, organization, machine or other endpoint that they purport to be.
· Health Endpoint Names express real-world origination points and endpoints of health information exchange, as vouched for by the organization managing the Health Domain Name.
· URN form: "urn:nhin:" + Health Domain Name + ":" + Health Endpoint Name
o If this is the right path, we should go through a certain process
· Email Address: Health Endpoint Name + "@" + Health Domain Name
o Express this as the intended recipient
· REST URI points to REST Implementation
· WSDL Reference points to the IHE Implementation
· Organizations that manage Health Domain Names MUST maintain DNS entries for the Health Domain Name.
· Abstract model calls it an HSP (health service provider) or HISP (Health Information Service Provider)
Comment from John Moehrke
· Are we selecting a smaller sub-set or will we have a translation between all of these
· URN is recommended form
· Seems to be saying the same thing to express it one way or to express it the other
· The only reason Arien/Brett threw out URN mapping because it doesn’t bias us
· Within XCN you can insert the identifier in many ways – a way of carrying a lot of potential fields in a well defined format and then we can profile it
Comment from Laurance
· Gets to concerns around how do we get directories
· Fine with this spec as written
Comment from Lin Wan
· Struggling to grasp how this is going to be used
· Is this intended to be part of meta data or how does this connect to the actual addressing
o How would software take an address and use it
o Take an address and use it to map to a REST based transaction
o Specified out in REST implementation
o IHE – UDDI lookup, or conventions for RESTFUL discovery and specification for how to include specification
o Discover given an address see who handles routing
o Where to put the address in the transaction so receiving ISP can see what inbox this goes into
· How would one discover the recipient’s address? Address discovery.
o Interim answer is that just like we can email each other without a directory
o Assume that at a minimum we can solve this through out of band discovery
o Form an address directory workgroup
Comment from Vinod Muralidhar
· Will banding hold against large networks
· Already does
· Inside organizations host directories
· Concept is good
Comment from Tom Davidson
· What is the difference between REST URL & SOAP URL
· REST Implementation proposal describes all of this
· Proposal we didn’t take up
· This might want to be taken up by the concrete implementation groups
· IHE or Robust HIE working group should give us direction in terms of expectations
· Parsing out URI that we get back to determine what to do with it
Comment from Brett Peterson
· We are making an assumption that there will be more than one
Comment from Wes Rishel
· Some concerns about the HL7, XCN and XON representations
· We have an approach that is easily mixable with the protocols mixed with NHIN Connect implementations
· We need to have a mapping to these data types, if we don’t then we just need to note this and move on
o 1) XCN and XON are data types not data fields
o 2) Semantically, these are not well mapped to what these data types represent in HL7 (XCN represents a person) and the end point of this may or may not be a person
§ Places in HL7 fields where data is repeated
§ Data type that supports phone number and email address, semantically mapping in HL7 we should go to those data types where HL7 already assumes there might be multiples
§ Can we use XCN when we’re refereeing to provider, and XON when we’re referring to organization
§ In XDS metadata there is an intended recipient and is defined as being a composite field that includes both (optional field)
§ Standard that works the best is the one that gives everyone the most opportunity to disagree on how to use it
§ XXCN to identify an person
§ XXON to identify an organization
§ Document that we document semantic roughness around what we are talking about
· Structure of the specification
o John’s issue about a URN as pure, but an email address format is more comfortable
o Propose moving these example sections off to the example section of the specification and just having one normative section describing what a health internet address looks like
· Thread of whether it is appropriate to even have NHIN Direct out in the word
o Is there a place for this minimum without loading it with the complexity
John’s issue about a URN as pure, but an email address format is more comfortable:
Question for the group: we leave the actual specification to say that health internet address contains a health domain name and a health end name and not a preferred format into the spec itself and move examples to an example section:
· What does preferred mean in terms of defining a format
· Brett Peterson – only reason historically why the URN was added was to get around objectives of using a specific emails addresses. Would rather use an email address. Because the goal is to be able to have providers/patients give someone else my health address in a way that makes sense.
· David Kibbe – Make sure physicians that have some technology, but not a complete EHR requires both an URN and an email.
· Jeff Fisher- Agree with what has been said, share lack
· Tom Davidson – What does technology need in order to process what is being given? Keeping needs of computer processing mechanism for purpose of dissemination
· New concept: public string that represents an individual’s health internet address
· Requirement to determine this address is valid, and that isn’t an implicit requirement
· Arien will go with above proposal and send revised document out to the members of this group to get yas or nays to see if we can move this to the implementation group
Status of Notes: DRAFT
Date: April 7, 2010
Time: 3:30pm-4:30pm
Attendees: Honora Burnett, Arien Malec,Brett Peterson, David Kibbe, Jeff Fisher, John Moehrke, Laurance Stuntz, Lin Wan, Martin Prahl, Tim Denis, Vinod Muralidhar, Wes Rishel and Steve Adams
Actions
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 4 |
4/7/10 |
Move example sections off to a separate example section of and just having one normative section describing what a health internet address looks like |
Completed |
Arien |
4/14/10 |
| 5 |
4/7/10 |
Review revised document and vote on whether this can be moved to the larger implementation group |
Open |
All |
4/14/10 |
Notes '
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Actions Items f'rom Last Week:
· Arien will formalize proposal on table in draft spec
· Group will review with goal of calling for consensus next meeting
· Wes is WG Leader
· We want to use only the most commonly used and well supported features of any standard
· The addressing spec needs three components:
o End point receiver (ex: wesj)
o Domain name -- business organization (ex: Rishel.com) associated with the end point
o Mapped through an external routing organization or technology organization (ex: Google or Gmail)
· Treat patient address in the same way (has the same three parts) as above
Discussion
Updates from Arien
· Listed on addressing specification page
· Work that Arien did is expressed in the Synopsis page
· Health Internet Addresses consist of a Health Domain Name portion, formatted according to the requirements of RFC 1034, and a Health Endpoint Name, formatted according to the local-part requirements of RFC 5322.
· Health Domain Name identifies the organizations that assigns the Health Endpoint Names and assures that they correspond to the real-world person, organization, machine or other endpoint that they purport to be.
· Health Endpoint Names express real-world origination points and endpoints of health information exchange, as vouched for by the organization managing the Health Domain Name.
· URN form: "urn:nhin:" + Health Domain Name + ":" + Health Endpoint Name
o If this is the right path, we should go through a certain process
· Email Address: Health Endpoint Name + "@" + Health Domain Name
o Express this as the intended recipient
· REST URI points to REST Implementation
· WSDL Reference points to the IHE Implementation
· Organizations that manage Health Domain Names MUST maintain DNS entries for the Health Domain Name.
· Abstract model calls it an HSP (health service provider) or HISP (Health Information Service Provider)
Comment from John Moehrke
· Are we selecting a smaller sub-set or will we have a translation between all of these
· URN is recommended form
· Seems to be saying the same thing to express it one way or to express it the other
· The only reason Arien/Brett threw out URN mapping because it doesn’t bias us
· Within XCN you can insert the identifier in many ways – a way of carrying a lot of potential fields in a well defined format and then we can profile it
Comment from Laurance
· Gets to concerns around how do we get directories
· Fine with this spec as written
Comment from Lin Wan
· Struggling to grasp how this is going to be used
· Is this intended to be part of meta data or how does this connect to the actual addressing
o How would software take an address and use it
o Take an address and use it to map to a REST based transaction
o Specified out in REST implementation
o IHE – UDDI lookup, or conventions for RESTFUL discovery and specification for how to include specification
o Discover given an address see who handles routing
o Where to put the address in the transaction so receiving ISP can see what inbox this goes into
· How would one discover the recipient’s address? Address discovery.
o Interim answer is that just like we can email each other without a directory
o Assume that at a minimum we can solve this through out of band discovery
o Form an address directory workgroup
Comment from Vinod Muralidhar
· Will banding hold against large networks
· Already does
· Inside organizations host directories
· Concept is good
Comment from Tom Davidson
· What is the difference between REST URL & SOAP URL
· REST Implementation proposal describes all of this
· Proposal we didn’t take up
· This might want to be taken up by the concrete implementation groups
· IHE or Robust HIE working group should give us direction in terms of expectations
· Parsing out URI that we get back to determine what to do with it
Comment from Brett Peterson
· We are making an assumption that there will be more than one
Comment from Wes Rishel
· Some concerns about the HL7, XCN and XON representations
· We have an approach that is easily mixable with the protocols mixed with NHIN Connect implementations
· We need to have a mapping to these data types, if we don’t then we just need to note this and move on
o 1) XCN and XON are data types not data fields
o 2) Semantically, these are not well mapped to what these data types represent in HL7 (XCN represents a person) and the end point of this may or may not be a person
§ Places in HL7 fields where data is repeated
§ Data type that supports phone number and email address, semantically mapping in HL7 we should go to those data types where HL7 already assumes there might be multiples
§ Can we use XCN when we’re refereeing to provider, and XON when we’re referring to organization
§ In XDS metadata there is an intended recipient and is defined as being a composite field that includes both (optional field)
§ Standard that works the best is the one that gives everyone the most opportunity to disagree on how to use it
§ XXCN to identify an person
§ XXON to identify an organization
§ Document that we document semantic roughness around what we are talking about
· Structure of the specification
o John’s issue about a URN as pure, but an email address format is more comfortable
o Propose moving these example sections off to the example section of the specification and just having one normative section describing what a health internet address looks like
· Thread of whether it is appropriate to even have NHIN Direct out in the word
o Is there a place for this minimum without loading it with the complexity
John’s issue about a URN as pure, but an email address format is more comfortable:
Question for the group: we leave the actual specification to say that health internet address contains a health domain name and a health end name and not a preferred format into the spec itself and move examples to an example section:
· What does preferred mean in terms of defining a format
· Brett Peterson – only reason historically why the URN was added was to get around objectives of using a specific emails addresses. Would rather use an email address. Because the goal is to be able to have providers/patients give someone else my health address in a way that makes sense.
· David Kibbe – Make sure physicians that have some technology, but not a complete EHR requires both an URN and an email.
· Jeff Fisher- Agree with what has been said, share lack
· Tom Davidson – What does technology need in order to process what is being given? Keeping needs of computer processing mechanism for purpose of dissemination
· New concept: public string that represents an individual’s health internet address
· Requirement to determine this address is valid, and that isn’t an implicit requirement
· Arien will go with above proposal and send revised document out to the members of this group to get yas or nays to see if we can move this to the implementation group