Abstract Model WG Meeting Notes 041410

From Direct Project
Jump to navigation Jump to search
Notes from Abstract Model Workgroup
Status of Notes: DRAFT
Date: April 14, 2010
Time: 11am-12pm
Attendees: Honora Burnett, Arien Malec, Brett Peterson, Dan Russler, Vassil Peytchev, Mark Gingrich and Steven Waldren Karen Witting, Mike Lincoln & Keith Boon
Actions
#
 Date
 Action
 Status
 Owner
 Due Date
22
4/14/10
Next time, discuss HISP-S to make the same distinction that EHR-S provides
Open
Brett
4/21/10
23
4/14/10
Use term HISP instead of HSP
Complete
 All
4/21/10
24
4/14/10
Propose a more advanced diagram to match Abstract Model
Complete
 Dan
4/21/10
25
4/14/10
Update diagram to match abstract model language
· The numbers 1,2,3 should go in an different order – follow transaction numbers in the abstract model
· Acronym HSP to HISP
· Take ? off addressing
Complete
 Brett/Rich
4/21/10
26
4/14/10
Remove the typical examples line from the source, destination and HSP
Complete
 Brett
4/21/10
27
4/14/10
Remove the word optional and say explicitly – HSP MAY be combined with HSP and source and HSP MAY be combined
Complete
 Brett
4/21/10
28
4/14/10
Changing User/Process to the term “endpoint” as defined by the Addressing specification
Complete
 Brett
4/21/10

Notes


Agenda

  1. Review of actions from previous meeting
  2. Discussion based on Issue Framing
  3. Review of actions and decisions


Issue Framing:

  1. On its 4/7/2010 call, the Addressing Workgroup (and other independent sources) suggest changing the term HSP (Health Service Provider) to one of those listed below. The thought was that HSP is confusing and over-reaching as the term Health Service Provider typically refers to a clinician (doc, therapist, etc...).
    • HISP (Health Internet Service Provider)
    • HISP (Health Information Service Provider)
    • Use one of the first two terms above but keep the acronym HSP (similar to CMS standing for the Centers for Medicare and Medicaid Services)
    • ESP (Exchange Service Provider)
    • HESP (Health Exchange Service Provider)
  2. Rich Kernan: Suggestion to include a graphical representation of the Abstract Model on the Abstract Model wiki page. Comments on initial draft from Rich: NHINDirect-AbstractModel-0.2.pdf
  3. Dan Russler suggestions:
    • Under "Source" change from "...Typical examples of a Source are a provider EHR..." to "...Source may be as simple as a web browser to as complex as a provider EHR...". Same with Destination. Comes from this thread.
    • Under Transactions: "Note that some of these steps are optional" needs to read "Note that some of these steps are optional or may be re-ordered."
  4. David McCallie's suggestion: Consider adding caveat about need for policy-specified audit and logging of all transactions.
  5. Vassil Peytchev comment: Clarification that the address is not necessarily a person (user). Response (Brett): Is this clear enough from the current definition of "NHIN Direct Address" in the Abstract Model?

Actions Items from Last Week:
· Make Edits: Extract pulling requirement from HSP to polling destination leg
· Make Edits: Add language to abstract model to describe this: that says we are only using the term HSP to refer to technology orchestration, but while policy is important we aren’t getting into policy when using this term
· Make a PDF copy of Abstract Model and send to WG
· Review Abstract Model and offer objections or consent
· Brett will make edits from WG members, include contextual statement and send out

Discussion
· Issue Framing
· Some of the issues from the WG call for consensus
· IG calls for consensus will go through today
· First issue: Universally the term HSP is confusing
o People think this is a doctor
o Change this term, options:
§ HISP Health Internet Service Provider
§ HSP Health Information Service Provider
§ ESP Exchange Service Provider
§ HEST Health Exchange Service Provider
· Brett: HISP – Health Internet Service Provider
Comment from Dan Russler
· HSP is from the DURSA and so we should change it
Comment from Karen Whiting
· Likes Health Information Service Provider
· Understand relationship between this and the gateway
Comment from Mike Lincoln
· Likes Health Information Service Provider
Comment from Vassil Peytchev
· Likes Health Information Service Provider
Comment from Keith Boon
· Likes Health Information Service Provider
· Health Internet Service Provider sounds sexy from a marketing perspective
Comment from Arien Malec
· Likes Health Information Service Provider
· Company or other organization that supports and provides technical exchange services

· The group likes Health Information Service Provider
· Does the HSP language match the DURSA language?
· Also matches what we say in the Abstract Model
· Emphasize that we are talking about a system
· Next time, discuss HISP-S to make the same distinction that EHR-S provides
· Don’t link to the DURSA
· MAKE CHANGE: Change the term to HISP

Framing Issue #2
· Suggestion to include graphical representation of the actors, include as an imbedded image
· Would this be helpful, and comments on PDF
Comment from Karen Witting
· Parenthesis from HSP – use HISP
Comment from Vassil Peytchev
· Get source for this so other people can use it for Concrete Implementation Group
Comment from Keith Boon
· Likes the diagram on the website now, helps people who aren’t familiar
· Not an either/or/and
Comment from Vassil Peytchev
· Get source for this so
Comment from Brett Peterson
· Intro diagram and advanced diagram
· Dan will propose a more advanced diagram and put on the Wiki and in the meeting notes for the next meeting
· Brett Peterson/Rich Kernan will update the diagram to match the Abstract Model
o the numbers 1,2,3 should go in an different order – follow transaction numbers in the abstract model
o Acronym HSP to HISP
o Take ? off addressing
Framing Issue #3

  • Dan Russler suggestions: Under "Source" change from "...Typical examples of a Source are a provider EHR..." to "...Source may be as simple as a web browser to as complex as a provider EHR...". Same with Destination.

Comment from Karen Witting
· Changes are good
· Go a bit farther – assumption that the destination is not able to open a port and receive a push
Comment from Vassil Peytchev
· Disagree
· Combined case, user is using a web browser to use a web browser
· If we put language there, then there is confusion that the web browser has to communicate with the HISP in a way that NHIN dictates
· Definition of the source is a system
· Source is not a web browser
Comment from Keith Boon
· Useful to give examples, but we need to note that these are examples not requirements
· Or just take out examples from the Abstract Model

Comment from Arien Malec
· Removed pulling because wanted to remove assumption that one must pull
· Requirement is well covered in the User Story

· Brett Peterson will remove the typical examples line from the source, destination and HSP

Comment from Vassil
· Adding a line that says: “not having an example is on purpose”
· Each one of these can have different capabilities

Comment from Vassil
· Make abstract model pure
· Create a non normative examples section that describes potential implementations in a way that helps clarify that there are different actors that can help fulfill the source/destination roles
· Brett Peterson: Remove the examples three lines
· Brett Peterson: Create verbiage that points to separate page
· Brett Peterson: Create a non normative examples section that describes potential implementations in a way that helps clarify that there are different actors that can help fufil the source/destination roles
o WG members will fill in the non-normative section

  • Dan Russler’s Suggestion: Under Transactions: "Note that some of these steps are optional" needs to read "Note that some of these steps are optional or may be re-ordered."
    • Which steps are necessary vs. optional
    • Clarification from Vassil that all the steps are optional
    • Take out “optional language” from Abstract Model and push it off to the new non-normative example section
    • Language can be expanded upon in example section
    • Wording around “Optional” is confusing
    • But removing it will require to have a source having a separate HSP and can’t combine source/HSP
    • ?? Remove the word optional and say explicitly – HSP MAY be combined with HSP and source and HSP MAY be combined

Comment from Arien Malec

  • Preserve level of “plugablity”
  • In those kind of modalities
  • The Source/HSP will be the same thing and that is a really valid use of this
  • Value to having a separable Source and HSP
Framing Issue #4
David McCallie's suggestion: Consider adding caveat about need for policy-specified audit and logging of all transactions.
· Mike Lincoln: Came up before and we removed it?
· Keith Boon: Abstract Model needs a way to express where auditing activities could occur
Comment from Arien Malec
· Pulled out for a good reason
· Because if we included it in one place we’d have to include it in all the places and audit would occur
· Need guidance as a good actor here
· Note: NHIN Workgroup is meeting today and discussing a whole similar set of topics about how an HSP can be a good actor

· Take no action, reserve the right down the road to revisit
Framing Issue #5
Vassil Peytchev comment: Clarification that the address is not necessarily a person (user). Response (Brett): Is this clear enough from the current definition of "NHIN Direct Address" in the Abstract Model?
Comment from Vassil
· Software Process/Organizational Process
· Queue, endpoints generically
· Brett Peterson: Changing User/Process to the term “endpoint” as defined by the Addressing specification
· Addressing Spec contains description around what an endpoint is: person
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Abstract_Model_WG_Meeting_Notes_041410&oldid=13"