Abstract Model WG Meeting Notes 042110

From Direct Project
Jump to navigation Jump to search
Notes from 'Abstract Model' Workgroup
Status of Notes: DRAFT
Date: April 21, 2010
Time: 11am-12pm
Attendees: Honora Burnett, Arien MalecEve Hoar, Vassil Peytchev, John Moehrke, Karen Witting, Eric Heflin, Dan Russler, Galen Mulrooney, Mike Lincoln, Mark Gingrich, Brett Peterson & Rich Kernan

Actions for this Week
#
 Date
 Action
 Status
 Owner
 Due Date
29
4/21/10
Post example 1 diagram source file
 Complete
 Rich
4/28/10
30
4/21/10
Delete the term “onboarding”
Complete
 Brett
4/28/10
31
4/21/10
Make a note on the diagram and also in the documentation to indicate the presence of a combined HISP/Destination
Open
Vassil & Dan
4/28/10
32
4/21/10
Make a note that it is an earlier version and WG should select the tools that they want to use, and then Dan will export into that
Open
Dan & All
4/28/10
33
4/21/10
Simplify 3.x HISP-Destination Language in transaction not to imply polling based model but to still express the intent of the model
Complete
 Brett
4/28/10
34
4/21/10
Change 2.1 language and M-architecture diagram to express “mutually authenticated”
Complete
 Rich
4/28/10
35
4/21/10
Put the architectural guidance one pager on the Wiki and we will discuss next week
Open
Arien
4/28/10


Actions from Last Week

#
 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 and Framing
· Review of last week’s action items
· Discussion
· Next Steps

Discussion
· Arien providing glue function
· Rich is going to provide architectural guidance document and boil it down to a one pager with the central key points
· Arien will put this one pager on the Wiki and we will discuss next week
· Good mapping
Issue Framing

  1. Discuss comments from the Implementation Group call for Consensus on Abstract Model version 1.1:
    • Healthcare Information Xchange of NY: Comment that transaction 1.3 ACKs should really be part of transaction 3.2 and 3.3 messages. A wiki post was made asking for further clarification.
    • Joel will talk to this next week
    • Joel’s point – inn transaction 3.2 it was intent that the destination could query by ACK/NACK
    • Application architecture – concern here
    • Should the blue and the red should be allowed to go away because they are application architectures
      • Normative speck should only be the black
      • Or not? HISP-HISP that is true, but how do we support small businesses? Members of the community in healthcare without datacenter?
      • Keep in mind, we are an implementation group
      • Start with an abstract model, but we can’t make it so abstract that it removes us from our mission
    • We agree on the business outcomes/intent of:
      • That we should be supporting small organizations that should be able to connect via only polling
      • Something like the model that Vassil proposed (use XDR almost all the way) should be within the bounds
    • IBM: "Add to description of Destination that it is a system which cannot easily accept incoming messages. This could be stated in this way: An actor to which messages are delivered through a polling mechanism." Broader issue: The HISP to Destination transactions clearly communicates a polling model. Does the Abstract Model need to also explicitly represent a model where the Destination maintains an open port and is pushed incoming messages by its HISP?
    • Design principals state that we will have at least one connectivity model, and it is expressed elsewhere
    • Should we generalize the abstract model to remove any representation of polling?
    • Comment from Vassil:
      • First Diagram from the notes, one of the arrows has a two way area, supporting that in a graphical representation can help support this
      • Two way communication
      • How do we distinctly express this?
    • Comment from John Moehrke
      • Only want to talk about directionality of the information, not of the concrete transaction
      • Principal: we want to limit security exposure of any of these end points (already expressed in design principals)
      • Say abstractly “this is being pushed”
    • Comment from Dan Russler
      • Part of the issue – what are we assuming is the technology situation of source/destination
        • Is it always on, or is it only on 8 hours a day
        • Talk about asynchronous vs. synchronous (anything that is one can be asserted as the other with the right technology)
        • Need to assume there is a person at the endpoint -- what is in-between can be implementation specific
        • Once session is set up, we can start doing pushes, but we can’t automatically assume that we can do pushes
        • May need to either say:
          1. User Event
          2. Polling Event
          3. Or assumption of 24X7 system
    • Comment from Rich Kernan
      • Don’t make this so abstract that the information is difficult to convey


2. Discuss modifications made to Rich Kernan's "intro" diagram found hereand linked off of the Abstract Model Examplespage
· Brett will simplify 3.x HISP-Destination Language in transaction not to imply polling based model but to still express the intent of the model
· 1.1 and 3.1 imply that we are authenticating the end point human, but suspect those should be bi-directional
· “M-architecture” diagram
· Rich will change 2.1 language and M-architecture diagram to express “mutually authenticated”
· M-architecture is for marketing/educational diagram … change the name to “Educational Diagram”

    • Epic: "We suggest that future iterations of the abstract model include functional requirements for the actors."
      • Overlap with “human user”
      • Covered if we agree on diagrams and use that as a tool
      • Think of functional requirements as an alternative to what Dan Russler has started working on
      • As we start doing Implementation having requirements will help us evaluate
  1. Discuss Dan Russler's BPMN document expressing the Abstract Model found here.

· This may not be correct, but Dan tried to be as true as possible to the text descriptions with the abstract models
o Go back and forth with text and pictures to make sure everything is aligned
· Request that the source files were shared, and so it is done with XMI files posted on the Wiki
· Advances of Business Process Model Notation (BPMN)
· Idea of multiple pulls that represent different organizations
· How organizations implement their business processes – fit anything technology related into that business model
· The two things that confuse people
o Difference between sequence flow and messages
o Only internet communications expressed here
· Tried to standardize
o Sequence of events should be exactly the same
· Comment from Vassil:
o User authenticates the source
· Authentification doesn’t link appropriately
o First diagram, HSP/destination is combined
o The way this is represented suggests that the destination HSP
o Allow combination of Source/HISP and Destination/HISP
o Solid arrows only represent sequence flow
o Vassil will help Dan Russler make a note on the diagram and also in the documentation to indicate the presence of a combined HISP/Destination
o Dan will make a note that it is an earlier version and WG should select the tools that they want to use, and then Dan will export into that
o Will revisit this next time, Vassil will prepare more concrete examples of what we could include in Abstract Model
o Going to accommodate some of the functional requirements – source/HISP/destination could be combined entities
· Comment from Rich Kernan
o Likes this, but the diagram of source/destination of source/destination concerns
· Next week we will do another round to explore this again

  1. Is the Abstract Model Examples page the right place for the Visio and BPMN expressions of the Abstract Model? Do we post the source Visio and BPMN diagrams as well?

· Rich will post the diagram in PDF and Visio

  1. Define or eliminate the term "onboarding" as mentioned in this thread
    • Brett will delete the term “onboarding”
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Abstract_Model_WG_Meeting_Notes_042110&oldid=14"