Implementation Group Meeting 2010-04-27
Notes from Implementation Group
Date: April 27, 2010
Time: 3pm-4pm
Attendees: Allscripts, Axoltotl, California Health and Human Service Agency, CareSpark, Cerner, Cautois Patient, Clinical Groupware Collaborative, Community Choice PHCO, eClinicalWorks, Epic, HealthBridge, Healthcare Information Xchange of NY, IBM, ICA, Kaiser, HLN Consulting, MedAllies, Medicity, MedPlus, Inc./Quest Diagnostics, Microsoft, Mirth Corporation, Mobile MD, NextGen, NIST, ONC, Rhode Island Quality Institute, Secure Exchange Solutions SureScripts, VA & VisionShare
Actions for this week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 17 |
4/20/10 |
Sign up to at least one development team: [1] |
Open |
All |
5/4/10 |
| 18 |
4/20/10 |
Vote on consensus for User Stories: [2] |
Open |
All |
5/4/10 |
Actions from last Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 15 |
4/20/10 |
Review addressing specification from and endorse yes/no. |
Closed |
All |
4/27/10 |
| 16 |
4/20/10 |
What do we mean by “trust assertion” |
Closed |
Security & Trust WG |
4/27/10 |
Review of Workgroups
· User Story Review WG: Provide consistent, vetted set of user stories available on the Wiki
· Concrete Implementation WG: Recommend a high level concrete implementation or set of concrete implementations mapping to the abstract model and meeting all Must User Stories
· Content Packaging WG: Define a few workable alternatives, with pros/cons, for content packaging
· Security & Trust WG: Provide alternatives and highlight issues relating to security and trust enablement via technology (e.g., certificates and signatures)
· Robust HIE Interoperability WG: Define how to mix and match direct transactions and robust HIE/NHIN specifications and services (patient discovery and information access) capabilities at scale
· Individual Involvement WG: Clarify technology issues and policy implications for individual involvement in direct transport
· Addressing WG: Define an implementation neutral mechanism for addressing that enables provider/individual identification and enabling organization routing
· Abstract Model Review WG: Review and finalize a formal abstract model that all WGs can use to define common vocabulary
Deliverables
· Specification & Service Descriptions
· Process Recommendations
· Policy Recommendations
· Marketing/Awareness
Deliverables for May 6th Meeting
Deliverables in Progress:
· Key User Stories: The User Story WG will provide a consistent, vetted set of User Stories
· Content Container Specifications: The Content Packaging WG will define a few workable alternatives for content packaging so that patient data of mixed types can be packaged and sent
· Security & Trust Specifications: The Security & Trust WG will provide alternatives and issue relating to security and trust enablement via technology
· Robust HIE Service Description: The Robust HIE WG will provide a Service Description of how to mix and match direct transactions and robust HIE/NHIN specifications and services capabilities at scale
· Individual Involvement Service Description: The Individual Involvement WG will provide a Service Description of how individuals can participate in NHIN Direct Project Services
· Addressing Specification: The Addressing WG will provide a Specification on to effective addressing methods -- what is the health “email” address
· Abstract Model: The Abstract Model WG will provide a Diagram and Specification of an Abstract Model that all WGs can use to determine core architectural components, assumptions and terminology
Deliverables Not Yet Started:
· Edge Specification: The Concrete Implementation WG will provide a simple specification to allow EHR to send and receive content via enabling organization
· Routing Specification and Service Description: The Concrete Implementation WG will provide a specification and service description to cover routing between enabling organizations with the verification of signature based headers and explicit certified white lists
What is New about NHIN Direct?
· Bottom in black are the current NHIN Exchange specifications
· Top in green are the NHIN Direct project specifications that we are working on
· Important to note:
o NHIN Exchange are node to node, targeted messages
§ Rely on knowing what two nodes in the NHIN are exchanging data
o Edge interactions are left unspecified
§ About how nodes talk to each other
o Clinical data source/requestor that are different parties
§ Routing goes from source to destination and we’re routing transactions all the way through
§ Don’t know who the HISP at the other end are
· Useful in helping understand what is common and unique about NHIN Direct
Question from Jonah Frohlich
· Who is managing the directories?
· Directories are routing directories
· States will host provider directories
User Story Review WG
· Last week the WG:
· Updated Immunization User Story and do full call for consensus by next meeting
· Got MU Matrix into the Wiki
· Removed the Provider sends and receives data with minimal HIT technology Story
· Ensured hat language used in the rest of the stories referring to EHR is consistent and reflecting ISO, ARRA & IFR definitions
· Changed design principal #9 will be modified to be consistent with those definitions
· This week the WG will:
· Vote on consensus for User Stories: User Story Workgroup Endorsement
· Create a Long Term Care Story and a Quality Reporting Registry
· Update the stories that are links that are not complete & stories without links about Public Health and Quality Reporting
· Make clear when there are dual criteria for hospitals/providers that are reflected in the mapping and the story
Content Packaging WG
· Last week the WG:
· Provided post on the wiki further thoughts on an alternative, super simple content packaging formula that meets use case of presupposition
· Provided post on applicability of ZIP on Wiki
· Provided Post about MIME on Wiki
· This week the WG will:
· Write a Requirements Document for Content Packaging Specification
· Provide a “layering” discussion on the Wiki
Security & Trust WG
· Last week the WG:
· Investigated use of government ASTM Use Cases
· Provided information about the Kantara initiative on the Wiki
· Write this idea of “chain of trust” on the Wiki
· This week the WG will:
· Create a definitive statement on trust enablement for NHIN Direct for Workgroup consensus and Implementation Group consensus by the 5/6 meeting. Statement should cover the level of trust, the handling of different roles, etc…
Robust HIE
· Last Week the WG:
· Explored the assumption that NHIN Direct uses current NHIN specifications, using the current IHE Implementation proposal as a starting point
· Explored the assumption that NHIN Direct uses either the REST or SMTP implementation proposals. How would that fit with or conflict with the current NHIN?
· This week the WG will:
· Provide one page comparison guidance principles of NHIN with design principals of NHIN Direct
· Express dependency to S&T workgroup -- post to their page and make a comment and request that it becomes part of their discussion
Addressing WG
· Last week the WG:
· Amended Health Domain Name sentence.
· Ensured REST/IHE and SMTP concrete implementation Straw Cases to use health information exchange mapping
· Ensured that the Health Endpoint Name is responsible for routing the end the transaction is received to the endpoint
· Inserted Version Number
· Workgroup voted for consensus
· Next week the WG will:
· All WG Members will vote on “Implementation Group Endorsements”
· Arien/Karen will write in a revised wording for the text under Health Domain Name
Individual Involvement
· Had decisions – about:
o Individual involvement scope
§ 2011 Stage 1 MU - Must
· Provider sends a reminder, health information, clinical summary or discharge summary to an Individual
§ 2013 Stage 2 MU - Should
· Individual sends message to a provider
o Meeting individuals “where they are” – assumptions
- Each Individual may have multiple addresses (e.g., for multiple PHR’s, multiple e-mails). Each address has its own separate transmission.
- Outside of NHIN Direct:
- Provider verifies identity and consent before linking to an Individual’s address
- Provider makes the decision that it’s appropriate to provide information to this address
- Provider verifies that PHI is sent only to addresses with adequate authentication/security/logging
- These target addresses may optionally provide notification services to the Individual of the update via public email – “where they are”
o Proposed Guidance to Security & Trust workgroup:
o Asymmetric Trust
o Proposed Guidance to Packaging workgroup:
§ Descriptions of content (including multipart)
Abstract Model
· Last week the WG:
· Discussed comments from the Implementation Group Call for Consensus on Abstract Model version 1.1
· Changed HISP-to-Destination language to not imply polling as the only allowed model
· Removed the term “onboarding” from the HISP definition
· Discussed the two example diagrams found at http://nhindirect.org/Abstract+Model+Examples
· This week the WG will:
· Have another round of discussion of the two examples, especially the BPMN diagram.
· Ideally come to consensus that the current version of the Abstract Model
Concrete Implementation
· Last week the WG:
· Reached out to get a representative from ASP and SSA
· Got a statement from the Robust HIE WG
· Read the three concrete implementations
· Caught up on Addressing Specification, Content Packaging Specification & Abstract Model
· Had a conversation about rough consensus working code
· Now, the WG is currently organizing teams to push each proposal to the next stage:
· A software “map” describing the pieces required by each actor in the stories, and the existing software that can be used/built upon/modified.
· Description of the end-user UI for each actor, or running code that demonstrates this.
· A committed set of volunteers with the time and expertise to write the code and test tools usable for pilots, led by an identified organizer.
· This is where the “running code” part from the Design Principles comes into play – from here forward, discussions of “simplicity” or “that should work” and the like should get backed by code or pseudo-code that implements the position being taken.
· May 6th in-person meeting: a public review of the proposals on deck, and a last-call for further work. May 18: final recommendation.
· We'd like to see each Implementation Group participant sign up to at least one development team by the end of this week. – within today or tomorrow, information about how people join and then asking people to join
· [3]
Implementation Geographies WG
· Purpose is to provide a powerful demonstration of cross-state, cross organizational continuity of care
Future Workgroups
· Testing WG
· Documentation WG
· If anyone wants to join email [[4]]
Working Groups
· Content Packaging WG: Wednesdays 1pm-2pm EST
· Security & Trust WG: Thursdays 2pm-3pm EST
· Robust HIE Interoperability WG: Tuesdays 2pm-3pm EST
· Individual Involvement WG: Thursdays 1pm-2pm EST
· Implementation Geographies WG: Fridays 2pm-3pm EST
· Addressing WG: Wednesdays 3:30pm-4:30pm EST
· Abstract Model Review WG: Wednesdays 11am-12pm EST
· Concrete Implementation WG: Tuesdays 12pm-1pm EST
Discussion
Clarification request from Ashish Shah: Vision is for State's to assign/manage node addresses to providers listed in the provider directory for the community?
· Addresses for HISPS vs. addresses for providers
· Can and will provide for trust assertions
· States can be organizations that can vouch for the trust of HISP
· Trust relationship being asserted with the domain and not the assertion
· Working on this
· Topic for the May 6th meeting
Clarification from Susan Torzewski: Individual experience is meant to be non provider consumers?
· Markel foundation – individual rather than patient
Clarification from Mark Stine: Will the testing group address certification of NHIN Direct specifications or will this be addressed by external certifications bodies? E.g. the same ones that will perform EHR certification to meet meaningful use
· Set of conformance tests for someone operating in the HISP/Source/Destination role
· Tests for someone who is doing a concrete implementation
· How does this roll onto EHR? Can’t comment on …
· We can graduate recommended specifications – the criteria are still being worked out, but one of the key attributes would be a degree of real world implementation and public process
Question from Lee Jones: what will the IHE "concrete implementation" participants specifically be building? Is it an end-to-end transaction that fulfills the abstract model (i.e. the diagram you showed in today's presentation)?
· Intent is from source to destination