Abstract Model WG Meeting Notes 040710

Notes from 'Abstract Model' Workgroup
Status of Notes: DRAFT
Date: April 7, 2010
Time: 11am-12pm
Attendees: Honora Burnett, Arien Malec, Brett Peterson, David McCallie, Vassil Peytchev, Galen Mulrooney, John Moehrke, Mark Gingrich and Steven Waldren
Actions

#	Date	Action	Status	Owner	Due Date
16	4/7/10	· Make Edits: Extract pulling requirement from HSP to polling destination leg	Complete	Brett	4/9/10
17	4/7/10	· 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	Complete	Brett	4/9/10
18	4/7/10	· Make a PDF copy of Abstract Model and send to WG	Complete (used wiki and discussion group instead)	Brett	4/9/10
19	4/7/10	· Review Abstract Model and offer objections or consent	Complete	All	4/12/10
20	4/7/10	· Brett will make edits from WG members, include contextual statement and send to Honora on Monday morning	Complete (Brett posted to wiki and discussion board instead)	Brett	4/12/10
21	4/7/10	· Honora will send out to group on Monday no later than 3pm EST	Assume no longer needed - using wiki and discussion group instead	Honora	4/12/10

Notes
Agenda and Framing

• Review of last week’s action items
• Discussion
• Next Steps

Actions Items From Last Week:

• Arien is going to do quick turn on the changes:

· Alter transaction 2.1 to remove incorrect language: say “assertion of mutual trust”
· Alter transaction 2.2 to insert “securely sends” instead of “sends”
· Remove the “destination may transform” bullet
· Add to transaction 2.3 and 1.3 that reflect the status back in a way that is query-able by the source

• Members of the group do a review and then vote via yeah or nay a move to consensus
• Brett will represent this group during next week’s implementation group call

Discussion
Arien performing ”glue” function and providing updates from other WGs:

• Robust HIE WG notes that the Abstract Model WG limits them in two ways:

1. Requirement of Message Status back from the destination

· Making the User Story WG prioritize the story that justifies message status
· This work is going on to decide whether message status should be “must have” or “should have”
· Arien thinks this will probably end up being “must have”

1. Insistence of requiring destination to HSP to be able to configured as a pulled transaction instead of having an open port sitting at the physician office

· Arien will raise this topic to the Security and Trust WG to get ruling about the feasibility of a single doc practice with a single port and confirm whether his fears are founded or unfounded

Given these two assumptions, we think the Abstract Model is final or near final

Brett Peterson:

• In response to two: – supported in both ways about the sophistication/scope and focus … should be a polling requirement, we could have language to support this

Comment from Vassil Peytchev:

• Do we have to define the status for pulling
• Logging information can be used as information about the status
• Any of the actors can review the logs and determine the status
• How far in the abstract model are we getting?
• Comment from Arien on this topic:

· SOAP based transition leg would meet the terms of the abstract model
· HSP Destination and supported a transaction directly into it combining the role of HSP and destination and the SOAP transaction has ACK/NACK
· We should put in language that it should literally be a separate transaction
· ATNA wasn't confined to an affinity domain
· Logging domain isn’t limited to infinity domain
· Asking HSP to providing logging functionality is not far fetched
· Can we solve this at the functioning level
· We should clarify that the presence of separate transactions doesn’t/shouldn’t apply that they can’t be combined as long as we meet the functional requirements

Comment from John Moehrke

• Don’t get down into the transactional requirements
• What is being discussed is not just an acknowledgement of a transaction, success or failure but that there is a workflow
• Reassessing and being clear about what the requirement is here
• In User Story WG we are splitting message receipt acknowledgment, from workflow accepted status
• Receiving side pulls for data and spins up service is a security and complexity concern but might be getting too far into the weeds
• ATNA wasn't confined to an affinity domain
• Status receipt as transactional requirement will end up being an important user story, but the abstract model should be abstract
• Extract pulling requirement from HSP to polling destination leg (Brett will do this)
• Edits to Abstract Model

· NHIN Direct Provider Address to NHIN Direct Address
· Changed “Provider” to “User”
· Removed old terms like DPS

“Error handling mechanism has not been explored”

Comment from David McCallie

• Are there retry intervals, application layer duty to do the retry – explicitly

Comment from Arien

• Mechanics of error transaction are implicitly implementation based
• Does specifying it or not reduce the interoperability of concrete implementations?

• Remove error handling message line or make a statement that it doesn’t fit the Abstract Model’s mission
• This would be addressed within the concrete implementation – the Abstract Model is a higher level
• Addition of ACK/NACK takes care of the problem at a high level, prescriptive measures beyond this have too much guidance
• Or, should there be a statement abstractly that the delivery level expectations need to be as opposed to defining transactional requirements
• Hinder/Neutral to interoperability, Abstract Model needs to give a mechanism for the source to receive or query the resulting status so any concrete implementation can mix and match with others

· Expectation: the sender should know whether the sender has received the information

Comment from Vassil Peytchev

• Functional requirements as opposed to messaging/transactional requirements

· Start providing functional requirements for interaction
· Leave the transaction but be clear that the how is implementation dependent, be clear that this is abstract

Comment from David McCallie

• Real abstract model is what the users expectations are (functional requirements, or elaborate user story)
• If it is robust enough to enable interoperability it needs to be fleshed out
• If it needs to be abstract enough to enable us to think about these items

• Brett Peterson: Can’t think of a way to go with that – let the comments rest for the time being

Comment on the Wiki Page on discussion area that indicated Term HSP is being used to map to both organizational duties and system behaviors, and depending on audience that would confuse folks.
Are there concerns about this? Do we need to separate or should we leave as is?

Comment from David McCallie

• Noted that this isn’t for onboarding

Comment from Vassil Peytchev

• Separating government polices from technical is a good idea

Comment from John Moehrke

• No real good solution
• We might be too far into the weeds here
• Is there a solution with no external bodies?
• Sender and a receiver

Comment from Steven Waldren

• Make sure it is abstract if it is there

Comment from Arien Malec
· Statement in abstract model 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
· NHIN WG “trust enabeling organization”
· Might need a term in the middle?
· 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 (Brett will do this)

Comment from David McCallie

• Contrast to what DEA has proposed around ePerspricbing – onerous technical requriments around the transfer of trust
• Good we not getting into that territory

Comment from Vassil Peytchev

• Functional requirement language to be added to Abstract Model (Vassil)

Set a goal of calling for consensus within the implementation group

• Remove pulling (Brett)
• Insert language about proxy’s roles, technology orchestration (Brett)

Where do we go from here?

• Intent of abstract model is to provide common terminology to guide Implementation – we’re done
• Insuring interoperability of concrete implementation – we’re not done
• Consensus in this group that we’re ready for this, then we need to couch this call for consensus with a clear description of what they are saying yes on and the context
• IG needs to be clear about what they are saying yes on and the context
• Brett will do edits to satisfaction
• Make a PDF copy
• Send it around to the members of this WG to get objections or consent
• We should get this out with a statement about what we are getting consensus on no later on 3pm EST on Monday

• Notice for proposed final consensus (will be final after User Group weighs in)
• Keep next week’s call is still on