Implementation Group Meeting 2010-07-06
Notes from the NHIN Direct Implementation Group
Date: July 6, 2010
Time: 3pm - 4:30pm
Attendees: Allscripts, Amedisys, Argonne National Laboratory, Atlas Development, Axolotl, CareSpark, Center for Democracy & Technology, Cerner, Clinical Groupware Collaborative, CO State HIE/CORIO, Emdeon, Epic, FEI, Gartner, GE, High Pine Associates, HLN Consulting, IBM, Inpriva, Kaiser, Kryptiq, Massachusetts eHealth Collaborative, MedAllies, Medicity, MedNet, MedPATH Networks, MedPlus/Quest Diagnostics, Microsoft, Misys Open Source Solutions (MOSS), NYC Dept. of Health and Mental Hygiene’s PCIP, ONC, Oregon HIE Planning Team, Redwood MedNet, RelayHealth, Rhode Island Quality Institute, Secure Exchange Solutions, Siemens, Sujansky Associates, SureScripts, Techsant Technologies, VA, Vangent, VisionShare
Actions for this week
||Review consensus proposal
||Send commitment to participate in one or more of workgroups, and specify whether you will serve as a HISP or not and in which geography
||If participating in a geography, fill out project brief template found on Implementation Geographies wiki page
||Compile list of organizations who commit to be a HISP or not and in which geography and post to wiki
Actions from last week
||Review consensus proposal and cast vote on wiki
||Put together statement of intent for new workgroups
||Put together documentation/marketing materials on NHIN Direct
- As you can see by the timeline, we’ve moved the next face to face and deliverable deadline to August 17th.
- Advantages are that we can have significant participation
- Just to review these deliverables:
- Reference Implementations: Provide a high quality open source reference implementation of the recommended specification
- Reference Implementation Guides: Provide reference implementation guides for edge systems and routing systems (including sample code, testing and conformance documentation, legal and policy documentation, etc...)
- Conformance Testing Scripts and Services: Provide conformance UATs and an automated conformance service for each concrete implementation
- Key Implementation Geographies: The Implementation Geographies WG will finalize a set of key geographies for early real-world implementation
- Interaction Model/Service Orchestration Model: The Abstract Model WG and the Concrete Implementation WG will provide an Interaction Model and Service Orchestration Model
- We’re at a stage that it’s worth re-stating what it means to be an implementation group member. Historically that’s been to bring up testing and implementation in 2010.
- Would like to be more flexible in terms of how organizations can participate.
- Implementation Group members must:
- Regularly attend Implementation Group weekly meetings AND
- Meaningfully participate in one of the following:
- Contribute source code or documentation to the reference implementation(s), specifications, implementation guides, etc.
- Support real-world early implementations with one of:
- Groups of providers or patients participating
- EHRs, EHR modules, PHRs, etc. implementing the specification
- HISPs or HIE technology implementing the spec
- Training, certification, or support services to providers
- We ask each IG member to announce which implementation category(ies) are planned for support
- So we’ve made participation available in two ways – if you can’t contribute providers or support reference implementation, we’re open to having you support providers who would like to participate.
- If you can’t contribute in any of those ways, you can be an observing member. That will have some implications in call for consensus process. We’re also asking each of the implementation groups to announce which geography they’d like to participate in.
- We have a wiki page or discussion where we’ve asked organizations to commit. Primarily, we’d like for you to send us an email and let us know which group you’re planning on supporting.
- We now have consensus which is great. COPY From Slide for Consensus proposal.
- The deadline was June 30th, there were a couple of organizations who asked for extension until Friday. As of Friday, we have all Yes endorsements.
- Generally two themes to the comments:
- Request for Security & Trust specification be tighter and clearer.
- And set of issues related to XDR.
- We will provide more material around security and trust – security of payloads, encryption, etc.
- Those will all be better detailed as we update the consensus proposal.
- There were a whole set of comments related to XDR – mostly around end to end SMTP and NHIN Exchange.
- I believe the consensus proposal adequately addresses the concerns in the comments. I would be happy to clarify this and would be happy to state this in the preamble.
- If you feel language as read is not appropriate, please let Arien know.
- There has been a number of comments about how NHIN Direct will work with HITPC and HITSC.
- We plan to have continued collaboration with HIT Policy Committee and HIT Standards Committee
- Vetting of the consensus specifications against policy guidelines
- Continued development of privacy and security policy framework
- Communication and collaboration about project work on:
- Documentation and Testing
- Security and Risk Analysis
- Open Source Reference Implementation
- Early Implementation Geographies
- Work with IHE to modify XDR specification to better meet policy guidelines and usage needs
- We will make sure that end specifications and early real world implementation we do will be aligned with their expectations.
- We’re working with Tiger Team and we’ll be working with standards committee review team to review specification against the policy framework.
- Dixie requested that we make sure we’re in sync with Tiger Team work until the Standards Committee review team does a second pass.
- We fully expect additional opportunities to review these proposals against legislative mandates.
- We have a number of touch points with policy committee and standards committee.
- We’re in close collaboration with Tiger Team and individual members of both committees.
- I know a number of people have raised comments, and I want to reassure folks that I think we’re in close collaboration.
- Security and Trust WG will be focused on Threat Assessment model for SMTP backbone.
- Implementation Geographies:
- We discussed a plan of action for participating in a pilot, and there was a recommendation to create a wiki template for a pilot project brief which allows anyone who wants to advertise a pilot to do so in a structured way.
- Gary put something together which can be found on the Implementation Geographies WG.
- He also put together an example which you should look at for the Rhode Island Quality Institute.
- I saw a good first example, and hopefully we’ll get more.
- How does filling out template relate to reference implementation group?
- Please include your organization in one of the implementation geographies.
- Please send an email to Uvinie and fill out the project brief template on the wiki.
- Reference Implementation:
- Wanted to be inclusive as possible by developing parallel platform.
- We made a decision to continue licensing around BSD License. Brian will create first draft.
- We’ll also look at reference implementation work and create a list of software components.
- As with any open source work, if organizations have their own interests, please work on them even if out of order.
- We do see that we need to have close collaboration between this workgroup and reference implementation group. We want to make sure that the EHR vendors serving real world providers know what’s going on when creating the HISP requirements.
- If there is existing open source code that could serve these purposes but not licensed the same way, are we going to replicate something that is BSD licensed?
- Generally, if you have two components that connect via well defined interfaces, you don’t need to co-mingle licenses. For example, GPL license Postfix implementation and communicates with SMTP, you can treat different components under different licenses as separate software components, and not worry about dual licensing issues.
- If you have one piece of code that has parts of it licensed differently, that becomes more complex.
- What we’ll try to do is to avoid those situations by making sure it’s two components that are communicating through well defined but separate components.
- Question around open source license for GPL vs. BSD. I’m assuming BSD license is not a viral license?
- No, it is commercial, all rights, no rights reserved licensed.
- Can we have someplace on NHIN Direct website all organizations that are considering to be HISPs and if they consider national or regional geographies.
- Please let Uvinie know as part of declaration of commitment. Please specify whether you will serve as a HISP or not and in which geography or nationwide. Uvinie will create a list of organizations that are serving as HISPs and in which geography and post to wiki.
- Documentation and Testing: Purpose is to create effective documentation and testing guidance for implementers including:
- Specification documentation
- Implementation guides
- Conformance testing guides
- In addition, the Documentation and Testing Workgroup will create overviews for general consumption and work with the Reference Implementation Workgroup to create a testing service corresponding to the conformance testing guides.
- Need close collaboration with Reference Implementation group
- Will create materials. We have yet to have first workgroup meeting, so stay tuned.
- We continue to have additional organizations asking to participate. We have 60 organizations and over 200 participants. We expect based on upcoming work and based on additional requests, that this list will change a little bit.
- Thank you everyone for your participation.