Implementation Group Meeting 2010-04-20
Notes from Implementation Group
Status of Notes: DRAFTDate: April 20, 2010
Time: 3pm-4pm
Attendees: NIH NCI, Allscripts, Axoltotl, California Health and Human Service Agency,. CareGroup/BIDMC, CareSpark, Cerner, CGI Federal, Clinical Groupware Collaborative, CSC, eClinicalWorks, Epic, GE, Google, HealthBridge, Healthcare Information Xchange of NY, HLN Consulting, Kaiser, Kryptiq, Massachusetts eHealth Collaborative, MedAllies, Medicity, MedPlus, Inc./Quest Diagnostics, Microsoft, Mirth Corporation, Mobile MD, NextGen, NIST, ONC, Oracle Health Sciences Global Strategies, Oregon's Strategic Workgroup for the HIT Oversight Council, RelayHealth, Rhode Island Quality Institute, Social Security Administration , SureScripts, VA, VisionShare, CA HIE, HIT PC and NHIN WG, IBM, ICA, Redwood MedNet, Secure Exchange Solutions & VLER
Actions for this Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 15 |
4/20/10 |
Review addressing specification from and endorse yes/no. If you do not vote we will assume consent = endorsement: [1] |
Open |
All |
4/27/10 |
| 16 |
4/20/10 |
What do we mean by “trust assertion” |
Open |
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
Review of Last Meeting
· User Story WG: Clarified Must/Should stores, elevated individual involvement stories to a must, said they were close to finalized must list.
· Content Packaging WG Agreed on overall set of goals for content packaging (support for simple metadata with ability to scale up to use of XDS metadata).
· Security and Trust WG Agreed on overall approach to express policy and trust agreements via the use of certificate-based signatures. Agreed that there should be at least one polling based option for Source/Destination (but that should not limit other concrete implementations.
· Robust HIE WG Clarified requirements of Abstract Model relevant to status and polling (reflected in updated Abstract Model) and reviewed early proposal to use XDS Metadata as the common link (reflected in early draft Content Container Specification).
· Individual Involvement WG Recommended individual involvement stories tied to meaningful use be Must. Clarified implications of individual involvement needs for content packaging and clarified asymmetric trust issue for individuals (easier to assess)
· Addressing WG Updated addressing specification to clarify intent of specification vs. non-normative formatting of an addressing, removed primacy of URN specification.
· Abstract Model Review WG introduced Abstract Model and gave a call for consensus.
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
User Story Review WG
· This week, the WG set the following action items:
o Update Immunization User Story updated and do full call for consensus by next meeting
o Place MU Matrix on the Wiki
o Remove the Provider sends and receives data with minimal HIT technology Story
o Ensure that language used in the rest of the stories referring to EHR is consistent
o Terminology section will define EHR in a way that reflects the ISO, ARRA and IFR definitions
o Change design principal #9 will be modified to be consistent with those definitions
· More background in last week’s meeting notes
o http://nhindirect.org/User+Story+Review+2010-04-10
Content Packaging WG
· Last meeting the group set action items to:
o Provide posts on the wiki further thoughts on an alternative, simple content packaging formula that meets use case of presupposition
o Provide post on applicability of ZIP on Wiki
o Provide Post about MIME on Wiki
o Further discuss message signature heading
· Discussions
o How XDS would work within MIME – robust discussion from GoogleGroup and now Wiki – interoperability vs. simplicity
o Consensus is that we don’t need to preclude either approach
o Robust HIE WG should pay attention
o Rough consensus working towards two notions –
o Notion #1 – simple subset of SDS metadata
o Notion #2 – more “plug and play” documentation for a user to pick up and run with the level of SDS metadata
o Make it possible to just start with very basic levels of metadata, but scale up to more complicated
· Draft proposal created
o http://nhindirect.org/Content+Container+Specification
· Rousing conversation regarding Specifications and Service Descriptions
o [2]
· NHIN Direct Abstract Model version 2.0
o [3]
· More background in last week’s meeting notes
o http://nhindirect.org/Content+Packaging+Meeting+2010-04-14
Security & Trust WG
· Last meeting, the group set action items to:
o Investigate our use of government ASTM Use Cases
o Provide information about the Kantara initiative on the Wiki W
o Write this idea of “chain of trust” on the Wiki. They will explore re-cert an existing address and frame up as key issue to discuss for next time
o What makes healthcare different, and how is it different from financial data?
o Need to finalize some of the discussions so that we can bring them up at the May 6th meeting
o Note: Robust HIE WG noted the trust model as one of the clear areas for continuity for how the trust models fit together
§ Robust HIE will be asking S&T WG to work on this
o Sean wrote something on asymmetrical trust issues
· Discussions:
o Discussion: We think "CA" so that users can think "trust“
§ [4]
o Discussion: HealthQuilt Trust Model
§ [5]
§ Allows HISP to have multiple certificates at the same time
§ Certificates should be held at HISP, routing, organization and and at the provider/individual level
o Discussion: Message vs. Transport... and the answer is 'yes'
§ [6]
o Discussion: Kantara initiative
§ [7]
· Risk Assessment Mitigation page
o http://nhindirect.org/Risk+Assessment+and+Mitigation
· More background in last week’s meeting notes
o http://nhindirect.org/Security+%26+Trust+Meeting+2010-04-15
Comment from David McCallie
· Is there a place we here we are specificying what is being trusted?
· Assigning S&T WG to define: what do we mean by “trust assertion”
Comment from Brian Behlendorf
· I wonder if you will coordinate this discussion with the NHIN Workgroup of the HITPC which is presenting on HIE Trust Framework Recommendations at tomorrow’s meeting?
· Arien has weekly policy & steering committee meetings
Robust HIE
· The last meeting, the group set action items to:
o Explore the assumption that NHIN Direct uses current NHIN specifications, using the current IHE Implementation proposal as a starting point (http://nhindirect.org/IHE+Implementation)
o Explore the assumption that NHIN Direct uses either the REST or SMTP implementation proposals. How would that fit with or conflict with the current NHIN?
o Mapping NHIN Direct Principals with NHIN Principals
o Dependencies on S&T WG
· More background in last week’s meeting notes
o http://nhindirect.org/Robust+HIE+Meeting+2010-04-13
Addressing WG
· The last meeting, the group set action items to:
o Amend Health Domain Name sentence
o Ensure REST/IHE and SMTP concrete implementation Straw Cases to use health information exchange mapping
o Ensure that the Health Endpoint Name is responsible for routing the end the transaction is received to the endpoint
o Called for a vote for consensus
o Addressing Specification Workgroup Endorsements
§ http://nhindirect.org/Addressing+Specification+Workgroup+Endorsements
o By the end of this week, all IG members should review addressing specification from and endorse yes/no. If you do not vote we will assume consent = endorsement: http://nhindirect.org/Addressing+Specification+Implementation+Group+Endorsements
o Addressing Specification Other Endorsements
§ http://nhindirect.org/Addressing+Specification+Other+Endorsements
Individual Involvement
- The last meeting, the group set action items to:
- Summarize for consensus to be able to pass on for the packaging group
- Write up a description of the asymmetric trust problem to pass onto the Security & Trust to figure out an elegant solution
- Agree on this story and then ask the S&T group to work on this on our behalf: http://nhindirect.org/A+patient+sends+a+message+to+the+provider
- The last meeting, the group decided that:
- Discharge summary User Story should be a Must
- The must-have individual involvement stories (2011 MU criteria)
o That patient -> provider user story is a Should not a Must
· HIT Patient Engagement Hearing
o Two way communication is important to patients/providers
Abstract Model
- Concluded the Implementation Group Call for Consensus on Abstract Model version 1.1
- Last week’s meeting: Discussed and enacted Abstract Model changes from Abstract Model workgroup members
- Changed HSP (Health Service Provider) to HISP (Health Information Service Provider)
- Removed examples from Abstract Model. Created a linked Examples page still under construction.
- Replaced “user/process” language with language from the Addressing spec (“endpoint”).
- This week’s meeting:
- Discuss changes suggested by Implementation Group members
Concrete Implementation
· Co-leads from Microsoft and Apache models the working together behavior that we are looking for
· Level setting about the goals and framing issues
o Goals: Recommend a high level concrete implementation or set of concrete implementations mapping to the abstract model and meeting all Must User Stories
o Level Setting
§ Follow the recommendations (or request changes) of the Abstract Model, Addressing and Content Packaging WGs
§ Meet the Must recommendations of the User Story WG
§ Follow the input of the Robust HIE WG how concrete implementations should work with robust HIE services
§ Balance the feedback and needs of:
§ Simplicity (argues for only one concrete implementation)
§ Supporting existing IHE specs and preserving at least one polling-based Source/Destination implementation
§ Consider as input existing REST, SMTP and IHE straw cases
§ Transport independent
§ Recommend V1 implementation model, rather than many to reduce the amount of policy recommendations
§ Edges, more variability – accepted, proceeded
§ Use Code
Future Workgroups
· Implementation Geographies
· Where and how we are bringing these to light
· Goals: trying to define a number of good implementation geographies that we can agree on
o Sub working groups
o If anyone wants to join email [[8]]
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
· Addressing WG: Wednesdays 3:30pm-4:30pm EST
· Abstract Model Review WG: Wednesdays 11am-12pm EST
· Concrete Implementation WG: Tuesdays 12pm-1pm EST