Implementation Group Meeting 2010-05-06
Jump to navigation
Jump to search
NHIN Direct 05062010 F2F Meeting.pdf
Introduction by Farzad Mostashari
· Keep powder dry
· Be humble about the stuff government can do
· The world will change
· Don’t be arrogant about our ability to see the future
· Want people to have the information they need
· Can’t afford to have a single one size fits all approach to this
o NHIN Exchange
o Many organizations (small doctor’s offices will not participate across the country, gain advantages that the full implementation will require
o Would be irresponsible of us – not that HITECH has changed us, do something better than fax
o Challenge for us will be not going down dead ends
o Making sure that while
o Make it stupid simple, but not stupid
o Don’t exceed the policy bounds
o Most important thing is the trust that policy is not outstripping technology (or visa versa) in which the enabling organization doesn’t peak in the packaging
Introduction by Arien Malec
· Making life better for the country
· We need to keep firmly in mind the clinical/quality/access outcomes and be confident that this work is good for the country and for our children
· Round of Introduction s
· Timeline
· Documenting the story
Peter DeVault about User Story
· Call for consensus
o Rich Elmore
§ Ability for patient to send to provider – or have a story
o George Komatsoulis
§ Scope question
§ Do these user stories contain the content?
o Arien
§ Sending content to content packaging
o Farzad
§ Policy issues that haven’t been surfaced
§ MU state I
· Reached Consensus on User Stories, with the caveat that Individual involvement WG needs to continue work on the patient to provider story
Brett Peterson about Abstract Model
· Change Abstract Model based on other WG
· Edge-backbone-Destination
· Open debate about what these protocols are, how many there are
· Not a single, core directory/server – could be DNS
Karen Witting’s concerns
· Destination isn’t a pull
· Edge made more generic to allow for a push and a pull
· Diagram hasn’t changes, but the language “neutralizes it”
· Change Authenticate to a double area
· List/push should be combined into one transaction
· Conceptually as a WG we need to have a discussion about details
· Reached consensus with the caveat that Karen Witting’s question should be addressed (change authenticate to double arrow and list/push should be combined into one transaction)
Wes Rishel about Abstract Model
· Abstract notion of health internet address with health domain name and health endpoint address
· Health endpoint name varies
· Person can have multiple emails
Comment from John Moehrke & Karen Witting
· XCM isn’t a problem, it is an enabler
· Not email, health internet name and email
· Can we anchor it in the domain name system? (don’t want to say architecturally
· Is it a real problem to use the email encoding?
Comment from Dan Kazzaz
· URL
· Discovery of the URL is the complicated part (table this discussion for later)
· Reasonable to believe that mapping could exist between them
Comment from Farzad Mostashari
· SMTP, SOAP, REST, IHE – can they all communicate?
· Feasible
Comment from Tim Andrews
· Is there a requirement from DNS? How do domain names match up
Comment from Leroy Jones
· Carried out by concrete implementations
Call for consensus on http://nhindirect.org/Addressing+Specification
· Reached Consensus on the Abstract Model
David McCallie, Content Packing Workgroup
· Abstract level that needs coalescing as we go towards the concrete details
· However – big issues we need to identify
· Leverage as much of the internet as we ca
· Support simple email clients as edge applications
· Tension – some transport protocols
· Health content container shall be an instance of an Internet Message Format textual object
· Sender – multipart/mixed and optional of multipart/signed & multipart/encrypted
· Receiver
o Basic processing
o Email processing
o XDS Metadata processing
§ Wanted to indicate that a group of documents were all related on one patient, could do so with this
· Some open questions
o Certain transport protocols may operate better with “native” content specification, rather than RFC822
o Simple text formatting minimums?
o How will we implement /signed and /encrypted?
o XDS Metadata – what about “affinity domain” specific params?
o Multipart/related – disallowed?
o List of expected content (mime) types for healthcare
Question from John Moehrke
· With you on spirit
· Intricacies that could cause a problem
· Corse assumptions
o Reuse do Mime types
o Stay with text objects
o Details like the headers will depend on concrete implementations
o When it comes to simple text formatting, will all the concrete models identify the MIME type?
o Transport specification – we’ve transported it
Comment from Sean Nolan
· Sign/encrypt
· Specification says that basic processing must be able to handle signed/encrypted
· We can decide on a concrete implementation that everything must be encrypted or signed
· Don’t want to go back to the packaging thing and see that we haven’t seen this before
Comment from John Moehrke
· Say nothing about message signing/encrypting because that is part of security & trust WG
Comment from Farzad Mostashari
· No PHI in the header
· May be some organizations that may not wish to receive any message in which they are not confident that the content is compliant
· What harm is there to have a certificate or a signature that the content is what we are saying that it is …
Arien restating
· 1) I can reject it if it isn’t XDM wrapped
· 2) I may only want to trust certain people tabled for this afternoon’s conversation
· Not ready for consensus on the Content Packaging Spec, more discussion about:
o Security & trust issue – encryption and signatures
o “Karen’s Cross” how do you cross map between a minimal metadata model and sophisticated metadata model
Comprehensive HIE Interoperability WG with Vassil Peytchev
· Goals
o Define usage similarities and difference between direct and discovery/access capabilities
o Propose implementation specification of the abstract model using IHE/NHIN transactions – now falls under the IHE Concrete Implementation Subgroup
o Describe possible intersections between direct and discovery/access capabilities within an HIE and across HIEs
o Answer the question: What is the best way forward to ensure the collaborative co-existence of the NHIN Direct and NHIN Exchange capabilities?
· Discussions
o Where is the intersection between Comprehensive HIE capabilities and NHIN Direct
o Distinguishing features of the NHIN Exchange
o End points of NHIN Exchange and NHIN Direct transactions:
· Mapping of the Abstract Model to IHE/NHIN transactions
o Three variations
§ End-to-end push (using XDR)
§ Polling at the source/destination (using XDR/MPQ + extensions)
§ Polling at the source/destination (using XDR/XDM)
· Feedback to larger group
o Main goal – seamless use of both NHIN Direct and NHIN Exchange
o Trust model – need to bridge the gap between the simplified model for NHIN Direct and the capabilities of NHIN Exchange
o Concrete implementations and packaging – provide mapping to and from the metadata needed in NHIN Exchange
o Abstract Model – provide functional requirements for the actors (e.g. mobile sources/destinations, “always-on” HISPs)
Comment from Karen Witting
· How can we change the document so that Dr. B can email to Dr. A, source?
· How do we functionally bridge these two sections?
· What conversions need to happen
· Who does these conversions?
·
Comment from Noam Arzt
· There are HIE’s out there that aren’t NHIN Direct based
· HIE’s are confused – they want to know what this means for them in their world
· Make sure comprehensive HIE mandate includes state/regional HIOs where the HIO runs an equivalent set of services to NHIN
· Think beyond just NHIN exchange, and think through HIO glasses
Comment from Dan Russler
· Don’t use these abstract models – they are confusing
Comment from John Moehrke
· Third model for a regional HIO – but would that mean that there is extreme scope creep?
· Allow us to have some stupid simple transactions
· If you are an HIO participant and you do have a mechanism for managing consent/patient ID
· HIO nationwide or not to run a set of services, but exclude a set of amorphous technology
Comment from Lin Wan
· HIO/Regional RHIO’s are well positioned to be nodes/HISPS
· If I really care, can I bounce something?
· Not a transport layer decision – a content decision
Commend from David McCallie
· How do we create gateways?
Comment from Brett Peterson
· At the code-thon, there is an XMTP interest group at NHIN Workgroup
Comment from Farzad Mostashari
· What is the policy guidance around this – aka what does it mean for HIOs – sate/regional?
· NHIN Exchange participants – minimal impedances mismatch and shoe that that works
· Some utility to this
· Maybe there should be a push protocol – getting NHIN exchange participants getting the highest level of NHIN Direct Exchange specs to push a message
· Step up the impedance mismatch
· Getting to concrete implementation that uses the full capabilities on the SOAP side
Question from Dan Kazzaz
· Minimal Automation to more automation
· This is about standardizing a push
Comment from Steven Waldren
· How will clinicians get paid? What is the motivating piece of this?
· Issues of liability
· More conversation needed for the Comprehensive HIE including looking at a mapping between a minimal metadata model and sophisticated metadata model and also ensuring the mandate includes state/regional HIOs where the HIO runs an equivalent set of services to NHIN
Sean Nolan on Concrete implementation WG
· Overview of approach and timeline
· “Minimum Threshold” requirements for implementation groups
o Proposed Requirements
o Community of Supporters
o Software “Map”
o Description of end-user experience for all actors
o Community of Supporters
o Software Map
o End User Experience
· Early observations and learning
o Code is a great way to resolve ambiguity!
o Folks are moving forward with an assumption of MIME content
o We are quickly bumping up against S&T issues that need resolution
· Status updates from implementation groups
o REST
o http://nhindirect.org/REST+Implementation+Development+Team
§ Two projects:
· Java based project – 100% written
· Arien’s Ruby on Rails
· Very simple, but there is hard stuff we haven’t gotten to yet
o SMTP
o http://nhindirect.org/SMTP+Implementation+Development+Team
o IHE / SOAP
§ http://nhindirect.org/IHE+Implementation+Development+Team
§ Initial model based on XDR, XDS and XDM
§ A lot of work still needed
o XMPP
o http://nhindirect.org/XMPP+Implementation+Development+Team
§ Update on the Wiki
§ Instant messaging protocol
· Discussion
Comment from Karen Witting
· Concerned about calls for consensus
· Arien and Karen need to have a conversation about putting out open source
· Conversation about deliverables on the 18th
Comment from Wes Rishel
· Firmer at criteria for the cut
Comment from Vassil Peytchev
· One protocol vs. any protocol
· We made a distinction between backbone protocol and edge
· Variation on the edges for different reasons
· Simplicity sake --- wanted to say there is “one backbone”
Comment from Lin Wan
· Substantially different than other MIME?
· Content packaging workgroup has a specification that is XDM in an internet message format
· Allows to go simpler
Comment from Dan Kazzaz
· Open source
· Code contributed to the project is for everyone
· It would be ideal/desirable to say that the entire infrastructure can be run on open source
Comment from Rich Elmore
· Request – make visible, what is important to quality
o Unacceptable: minimal threshold doesn’t work
· How do we get to providers with a low level of adoption?
o Integrated HER on big side
o Email on small side
Comment from Will Ross
· Concerned about where we are taking this for the one implementation process
· Concerned because it seems like this is starting from scratch
o Where he sits, he isn’t finding it appropriate to hop to the next project
o How can we integrate what we’ve learned from connect?
Comment from Kris Oldberg
· How is the content married to the transport?
· Implementation WG meeting in October of last year – one provider testified that they had a patient moving to Arizona and recommended a provider who the same HER, but couldn’t get it to them
· Content is really important, but stupid simple transport is very important as well
Comment from Wes Rishel
· We’re not trying to decide which baby is ugly, but which one is going to grow up to be an ugly adult
· Hung up on a few issues:
o Cultural – better to wait? Once you get information flowing then you can demand the semantics
o 1) Chosen backbone protocol that is the one that IHE is using and supported by CONNECT
o 2) Different one is chosen and those responsible by CONNECT see a way to bridge through it
o 3) Picked one
Comment from Lin Wan
· Security thing – can make or break and without knowing
· Hasn’t been a “crisp” discussion
· Why can’t people just use email now (SMIME is hard to do for clients, and if we make it not hard then the whole thing will be easier).
· We know we have a time issue – one month more
· More discussion around the Concrete Implementation WG is needed, including:
o Give a month to complete
o One implementation may not be the right decision
o Tighten up the acceptance criteria
Security & Trust WG with Sean Nolan
· Can we apply the raw material where people can select things they want and as they grow more comfortable they can add additional items
· Nothing about the operation of NHIN should require a single authority
· Want to be able to separate technology from policy
· Everyone that is willing to send to an endpoint doesn’t want to receive from an endpoint
· Ability to implement policy is different than the ability to dictate
· Circle of trust
· Users don’t manage their own certificates
Comment from Devon McGraw
· Hard to divorce policy from technology
· Leaving the decision open changes things
· Don’t want people to be obstacles to exchange
Comment from Farzad Mostashari
· Stay within policy bounds of the HITSC
· Leaving optionally in leave the risks
· Incumbent on this group to be aware
· The HITSC Policy recommendations will be implementable
Questions from Sean Nolan
· Tension is that there is a set of NHIN policy that will be handed down over time
· How can I make myself belief that this technology will be implemented across the country – widely
· Consider later: do we want to say that we want technology that supports those and only those?
Question from Wes Rishel
· Problem of different people having different opinions of what a signature is
o Signing of work vs. authentication
· Signatures of a point of Origin?
· This more than others – language gets read by people who have not internalized difference
· Trust assertions
· Agreement: we are talking about “I am who I say I am”
Comment from Dan Russler
· “Keys for Consensus” should be “Policies for Consensus”
o We should make policy choices that are within policy bounds of the HITSC
o Farzad wishes that there was more acknowledgement of the HITSC policies and then a greater understanding of how we fit within it
· Table discussion: what are we extending on what has already been approved
Comment from Lin Wan
· Will it only be read from end user to end user?
· Intent is to say that only the endpoint who are expected to see the content of the message will see the content of the message
o Technology can’t make this decision true
· Policy guidance – intermediaries can’t break open the message
o What is meant by an intermediary
· To have sufficient trust, there will have to be a governmental role to do organizational vetting
· People have to be responsible at some point
· Tried to define a model that isn’t moving down individual certs
Comment from David McCallie
· Table this discussion until Farzad/Devon tell us about what we would have to meet
· Why do we not wait?
Comment from Farzad Mostashari
· There have already been policy bounds that have been put in place
· Trust us!
· Security and Trust WG needs more conversations, specifically around the following:
o Harmonization of HITPC recommendation language with Security and Trust WG outputs
o Exploring out the concrete proposals – i.e. how they would work in the real world and then present to the NHIN Workgroup and Privacy & Security Workgroup with technology/policy tradeoffs for each option
Richard Elmore for Individual Involvement
· More than just a patient
· Purpose is to clarify technology issues and policy implications for individual involvement in direct transport
· “Individual” = Non-provider participants in care
· 2011 Stage 1 MU
· Provider sends a reminder, health information, clinical summary or discharge summary to an Individual
· 2013 Stage 2 MU
· Individual sends message to a provider
· User Stories
o Five confirmed Individual Involvement User Stories (Must Haves)
o One User Story is being refined and prioritized
· The Role of the Patient / Individual
o An engaged patient is more likely to take steps to maintain and improve her health.
o Standardization of NHIN Direct transport protocols can apply to individuals in communication with their clinicians.
o Individuals who communicate with their clinicians asynchronously and electronically are potentially more engaged at potentially lower costs
· The Role of the Patient / Individual:
o 2011 Meaningful Use provides for an eligible professional to send a summary of the clinical information or reminder chart to an individual
o However, support for an individual to electronically message her clinician is not included until 2013.
· Considerations
o Unreliable Identities
o Indistinguishable Trust Levels
o Clinician Refusal
o Patient Expectations
o The Role of the Patient / Individual: Considerations
· Guidance to Content & Packaging
o Anticipate self-describing file types will evolve
o Individual “friendly” content descriptions
o For the bundle
o For individual attachments
· 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.
Arien Malec for Implementation Geographies
· Purpose is to plan for early implementations demonstrating real-world information exchange following existing care delivery patterns
· Leader: Paul Tuten
· Deliverables:
· Finalized set of key geographies for early real-world implementations
· Template operational plan identifying stakeholders, success criteria, and project considerations
· Updates
o DRAFT early list of potential geographies: http://nhindirect.org/Potential+Implementation+Geographies
o DRAFT early list of operational considerations
· http://nhindirect.org/Implementation+Operational+Plan
· Identify regions of the country
· Identify set of anchors that are referrals
· Engaging with key stakeholders
· Don’t use the word “pilot”
· Another meeting on the 11th – a two day meeting?
o Dan Kazzaz – Vegas/SSI
o Sean Nolan – Seattle
Structured Discussion
· Security & Trust
· Point of view: really important to tie individual signed assertions in the wrapper of the transaction itself to express security down to the organization level
o Done through WS security signatures
o Signed SAML assertion
o Mandates mutual TLS
§ Was the risk we tried to mitigate – but was it even a risk?
§ Tie to a specific address?
§ Counter assertion is TLS
· The system must enable trust assertions at either the organization or address/endpoint level. It is a matter of policy and preference whether organizations use a single certificate for all of their addresses, or assign individual certificates for each address.
· Pre-discussion – do we need to have PKI identity in our framework?
Comment from Lin Wan
· If we want to make sure it is a secure communication from the source to the HISP-Destination, or are we willing to accept that we have a trust fabric and it will security get to the destination without anyone having seen the data
Comment from Dan Kazzaz
· Providers/individuals need to think about our policy
· Sending PHI by email isn’t totally illegal
Comment from Farzad Mostashari
· Functions that need to be enabled that will need secure routing and identity assurance
· HSPS will need to be vetted
· Technical compliance
· Identity assurance
· Extension of chain of trust to the end
· How do you do identity assurance for a non-carbon based life form?
· 1) Policy onus on the HISP client routing
· 2) Highly leveraged port
o Economic decision on both sides: hard do adopt if we just start with HISP to HISP
o Use the word organization to organization?
Comment from Wes Rishel
· Are HISPS business organizations?
· HISP can represent more than one healthcare organization
· HISP responsible for secure routing, and we just set the requirements, but they do
· Policy decision – if the policy side says something than we might need to comply
· Those who are going to hook into it are those that have already done secure routing
o They have already built this stuff
o Concerned about if there is another system, we don’t want to ruin what they already have in place
Comment from Rich Elmore
· Decision to end up with an initial implementation of this
· Less concerned about what happens HISP-HISP
· Provide more flexibility on this – different capabilities
Wrap up from Arien
· End stage of this is to deliver higher quality, more efficient, more engaging health system
· Improving the healthcare delivery system
· Thank everyone for involvement and participation
· Theme:
o Technology/Policy conversations
o Need to make sure that decisions that have already been made at HITPC are fed back and we are using the appropriate terminology
Notes from NHIN Direct Face to Face Meeting
Status of Notes: DRAFT
Date: May 6, 2010
Time: 10am-5pm
Attendees: Zachary Gillen, Dan Russler, Martin Rice, Rodney Cain, Fred Trotter, Jonathan Gershater, John Blair, Karen Witting, Ashish Shah, Brett Peterson, Brian Ahier, Charles Curran, Chris Voigt, Dan Kazzaz, David McCallie, Doug Felton, Erik Horstkotte, Gary Christensen, George Komatsoulis, Greg Turner , Jeff Cunningham, Joel Ryba, John Moehrke, Ken Buetow, Kris Olberg, Lee Jones, Lin Wan, Lisa Carnahan, Mark Gingrich, Mark Hiner, Mark Stine, Martin Pellinat, Martin Prahl, Nageshwara Bashyam, Noam Arzt, Paul Saxman, Peter DeVault, Richard Elmore, Rob Wilmot, Robert Wah, Sean Nolan, Stephen Ondra, MD, Steven Waldren, Suhas Tripathi, Tim Andrews, Tim Crowmell, Tom Wagner, Vassil Peytchev , Wes Rishel, Will Ross, Arien Malec, Jackie Key, John Stinn, Rich Kernan, Kevin Puscas, Doug Fridsma, Farzad Mostashari
Decisions
| Date |
Decision |
| 5/6/10 |
More conversation needed for the Security and Trust WG, specifically around the following: 1) Harmonization of HITPC recommendation language with Security and Trust WG outputs 2) Exploring out the concrete proposals – i.e. how they would work in the real world? And then presenting to the NHIN Workgroup and Privacy & Security Workgroup with technology/policy tradeoffs for each option. |
| 5/6/10 |
More discussion around the Concrete Implementation WG is needed, including: the addition of a month for completion, not just having one implementation, and also tightening up acceptance criteria. |
| 5/6/10 |
More conversation needed for the Comprehensive HIE including looking at a mapping between a minimal metadata model and sophisticated metadata model and also ensuring the mandate includes state/regional HIOs where the HIO runs an equivalent set of services to NHIN. |
| 5/6/10 |
Not ready for consensus on the Content Packaging Spec, more discussion is needed about: the security & trust issue of encryption and signatures, and “Karen’s Cross” – i.e. how do you cross map between a minimal metadata model and sophisticated metadata model. |
| 5/6/10 |
Reached Consensus on the Abstract Model. |
| 5/6/10 |
Reached consensus on Addressing Specification with the caveat that Karen Witting’s question should be addressed (change authenticate to double arrow and list/push should be combined into one transaction). |
| 5/6/10 |
Reached Consensus on User Stories, with the caveat that Individual involvement WG needs to continue work on the patient to provider story. |
Introduction by Farzad Mostashari
· Keep powder dry
· Be humble about the stuff government can do
· The world will change
· Don’t be arrogant about our ability to see the future
· Want people to have the information they need
· Can’t afford to have a single one size fits all approach to this
o NHIN Exchange
o Many organizations (small doctor’s offices will not participate across the country, gain advantages that the full implementation will require
o Would be irresponsible of us – not that HITECH has changed us, do something better than fax
o Challenge for us will be not going down dead ends
o Making sure that while
o Make it stupid simple, but not stupid
o Don’t exceed the policy bounds
o Most important thing is the trust that policy is not outstripping technology (or visa versa) in which the enabling organization doesn’t peak in the packaging
Introduction by Arien Malec
· Making life better for the country
· We need to keep firmly in mind the clinical/quality/access outcomes and be confident that this work is good for the country and for our children
· Round of Introduction s
· Timeline
· Documenting the story
Peter DeVault about User Story
· Call for consensus
o Rich Elmore
§ Ability for patient to send to provider – or have a story
o George Komatsoulis
§ Scope question
§ Do these user stories contain the content?
o Arien
§ Sending content to content packaging
o Farzad
§ Policy issues that haven’t been surfaced
§ MU state I
· Reached Consensus on User Stories, with the caveat that Individual involvement WG needs to continue work on the patient to provider story
Brett Peterson about Abstract Model
· Change Abstract Model based on other WG
· Edge-backbone-Destination
· Open debate about what these protocols are, how many there are
· Not a single, core directory/server – could be DNS
Karen Witting’s concerns
· Destination isn’t a pull
· Edge made more generic to allow for a push and a pull
· Diagram hasn’t changes, but the language “neutralizes it”
· Change Authenticate to a double area
· List/push should be combined into one transaction
· Conceptually as a WG we need to have a discussion about details
· Reached consensus with the caveat that Karen Witting’s question should be addressed (change authenticate to double arrow and list/push should be combined into one transaction)
Wes Rishel about Abstract Model
· Abstract notion of health internet address with health domain name and health endpoint address
· Health endpoint name varies
· Person can have multiple emails
Comment from John Moehrke & Karen Witting
· XCM isn’t a problem, it is an enabler
· Not email, health internet name and email
· Can we anchor it in the domain name system? (don’t want to say architecturally
· Is it a real problem to use the email encoding?
Comment from Dan Kazzaz
· URL
· Discovery of the URL is the complicated part (table this discussion for later)
· Reasonable to believe that mapping could exist between them
Comment from Farzad Mostashari
· SMTP, SOAP, REST, IHE – can they all communicate?
· Feasible
Comment from Tim Andrews
· Is there a requirement from DNS? How do domain names match up
Comment from Leroy Jones
· Carried out by concrete implementations
Call for consensus on http://nhindirect.org/Addressing+Specification
· Reached Consensus on the Abstract Model
David McCallie, Content Packing Workgroup
· Abstract level that needs coalescing as we go towards the concrete details
· However – big issues we need to identify
· Leverage as much of the internet as we ca
· Support simple email clients as edge applications
· Tension – some transport protocols
· Health content container shall be an instance of an Internet Message Format textual object
· Sender – multipart/mixed and optional of multipart/signed & multipart/encrypted
· Receiver
o Basic processing
o Email processing
o XDS Metadata processing
§ Wanted to indicate that a group of documents were all related on one patient, could do so with this
· Some open questions
o Certain transport protocols may operate better with “native” content specification, rather than RFC822
o Simple text formatting minimums?
o How will we implement /signed and /encrypted?
o XDS Metadata – what about “affinity domain” specific params?
o Multipart/related – disallowed?
o List of expected content (mime) types for healthcare
Question from John Moehrke
· With you on spirit
· Intricacies that could cause a problem
· Corse assumptions
o Reuse do Mime types
o Stay with text objects
o Details like the headers will depend on concrete implementations
o When it comes to simple text formatting, will all the concrete models identify the MIME type?
o Transport specification – we’ve transported it
Comment from Sean Nolan
· Sign/encrypt
· Specification says that basic processing must be able to handle signed/encrypted
· We can decide on a concrete implementation that everything must be encrypted or signed
· Don’t want to go back to the packaging thing and see that we haven’t seen this before
Comment from John Moehrke
· Say nothing about message signing/encrypting because that is part of security & trust WG
Comment from Farzad Mostashari
· No PHI in the header
· May be some organizations that may not wish to receive any message in which they are not confident that the content is compliant
· What harm is there to have a certificate or a signature that the content is what we are saying that it is …
Arien restating
· 1) I can reject it if it isn’t XDM wrapped
· 2) I may only want to trust certain people tabled for this afternoon’s conversation
· Not ready for consensus on the Content Packaging Spec, more discussion about:
o Security & trust issue – encryption and signatures
o “Karen’s Cross” how do you cross map between a minimal metadata model and sophisticated metadata model
Comprehensive HIE Interoperability WG with Vassil Peytchev
· Goals
o Define usage similarities and difference between direct and discovery/access capabilities
o Propose implementation specification of the abstract model using IHE/NHIN transactions – now falls under the IHE Concrete Implementation Subgroup
o Describe possible intersections between direct and discovery/access capabilities within an HIE and across HIEs
o Answer the question: What is the best way forward to ensure the collaborative co-existence of the NHIN Direct and NHIN Exchange capabilities?
· Discussions
o Where is the intersection between Comprehensive HIE capabilities and NHIN Direct
o Distinguishing features of the NHIN Exchange
o End points of NHIN Exchange and NHIN Direct transactions:
· Mapping of the Abstract Model to IHE/NHIN transactions
o Three variations
§ End-to-end push (using XDR)
§ Polling at the source/destination (using XDR/MPQ + extensions)
§ Polling at the source/destination (using XDR/XDM)
· Feedback to larger group
o Main goal – seamless use of both NHIN Direct and NHIN Exchange
o Trust model – need to bridge the gap between the simplified model for NHIN Direct and the capabilities of NHIN Exchange
o Concrete implementations and packaging – provide mapping to and from the metadata needed in NHIN Exchange
o Abstract Model – provide functional requirements for the actors (e.g. mobile sources/destinations, “always-on” HISPs)
Comment from Karen Witting
· How can we change the document so that Dr. B can email to Dr. A, source?
· How do we functionally bridge these two sections?
· What conversions need to happen
· Who does these conversions?
·
Comment from Noam Arzt
· There are HIE’s out there that aren’t NHIN Direct based
· HIE’s are confused – they want to know what this means for them in their world
· Make sure comprehensive HIE mandate includes state/regional HIOs where the HIO runs an equivalent set of services to NHIN
· Think beyond just NHIN exchange, and think through HIO glasses
Comment from Dan Russler
· Don’t use these abstract models – they are confusing
Comment from John Moehrke
· Third model for a regional HIO – but would that mean that there is extreme scope creep?
· Allow us to have some stupid simple transactions
· If you are an HIO participant and you do have a mechanism for managing consent/patient ID
· HIO nationwide or not to run a set of services, but exclude a set of amorphous technology
Comment from Lin Wan
· HIO/Regional RHIO’s are well positioned to be nodes/HISPS
· If I really care, can I bounce something?
· Not a transport layer decision – a content decision
Commend from David McCallie
· How do we create gateways?
Comment from Brett Peterson
· At the code-thon, there is an XMTP interest group at NHIN Workgroup
Comment from Farzad Mostashari
· What is the policy guidance around this – aka what does it mean for HIOs – sate/regional?
· NHIN Exchange participants – minimal impedances mismatch and shoe that that works
· Some utility to this
· Maybe there should be a push protocol – getting NHIN exchange participants getting the highest level of NHIN Direct Exchange specs to push a message
· Step up the impedance mismatch
· Getting to concrete implementation that uses the full capabilities on the SOAP side
Question from Dan Kazzaz
· Minimal Automation to more automation
· This is about standardizing a push
Comment from Steven Waldren
· How will clinicians get paid? What is the motivating piece of this?
· Issues of liability
· More conversation needed for the Comprehensive HIE including looking at a mapping between a minimal metadata model and sophisticated metadata model and also ensuring the mandate includes state/regional HIOs where the HIO runs an equivalent set of services to NHIN
Sean Nolan on Concrete implementation WG
· Overview of approach and timeline
· “Minimum Threshold” requirements for implementation groups
o Proposed Requirements
o Community of Supporters
o Software “Map”
o Description of end-user experience for all actors
o Community of Supporters
o Software Map
o End User Experience
· Early observations and learning
o Code is a great way to resolve ambiguity!
o Folks are moving forward with an assumption of MIME content
o We are quickly bumping up against S&T issues that need resolution
· Status updates from implementation groups
o REST
o http://nhindirect.org/REST+Implementation+Development+Team
§ Two projects:
· Java based project – 100% written
· Arien’s Ruby on Rails
· Very simple, but there is hard stuff we haven’t gotten to yet
o SMTP
o http://nhindirect.org/SMTP+Implementation+Development+Team
o IHE / SOAP
§ http://nhindirect.org/IHE+Implementation+Development+Team
§ Initial model based on XDR, XDS and XDM
§ A lot of work still needed
o XMPP
o http://nhindirect.org/XMPP+Implementation+Development+Team
§ Update on the Wiki
§ Instant messaging protocol
· Discussion
Comment from Karen Witting
· Concerned about calls for consensus
· Arien and Karen need to have a conversation about putting out open source
· Conversation about deliverables on the 18th
Comment from Wes Rishel
· Firmer at criteria for the cut
Comment from Vassil Peytchev
· One protocol vs. any protocol
· We made a distinction between backbone protocol and edge
· Variation on the edges for different reasons
· Simplicity sake --- wanted to say there is “one backbone”
Comment from Lin Wan
· Substantially different than other MIME?
· Content packaging workgroup has a specification that is XDM in an internet message format
· Allows to go simpler
Comment from Dan Kazzaz
· Open source
· Code contributed to the project is for everyone
· It would be ideal/desirable to say that the entire infrastructure can be run on open source
Comment from Rich Elmore
· Request – make visible, what is important to quality
o Unacceptable: minimal threshold doesn’t work
· How do we get to providers with a low level of adoption?
o Integrated HER on big side
o Email on small side
Comment from Will Ross
· Concerned about where we are taking this for the one implementation process
· Concerned because it seems like this is starting from scratch
o Where he sits, he isn’t finding it appropriate to hop to the next project
o How can we integrate what we’ve learned from connect?
Comment from Kris Oldberg
· How is the content married to the transport?
· Implementation WG meeting in October of last year – one provider testified that they had a patient moving to Arizona and recommended a provider who the same HER, but couldn’t get it to them
· Content is really important, but stupid simple transport is very important as well
Comment from Wes Rishel
· We’re not trying to decide which baby is ugly, but which one is going to grow up to be an ugly adult
· Hung up on a few issues:
o Cultural – better to wait? Once you get information flowing then you can demand the semantics
o 1) Chosen backbone protocol that is the one that IHE is using and supported by CONNECT
o 2) Different one is chosen and those responsible by CONNECT see a way to bridge through it
o 3) Picked one
Comment from Lin Wan
· Security thing – can make or break and without knowing
· Hasn’t been a “crisp” discussion
· Why can’t people just use email now (SMIME is hard to do for clients, and if we make it not hard then the whole thing will be easier).
· We know we have a time issue – one month more
· More discussion around the Concrete Implementation WG is needed, including:
o Give a month to complete
o One implementation may not be the right decision
o Tighten up the acceptance criteria
Security & Trust WG with Sean Nolan
· Can we apply the raw material where people can select things they want and as they grow more comfortable they can add additional items
· Nothing about the operation of NHIN should require a single authority
· Want to be able to separate technology from policy
· Everyone that is willing to send to an endpoint doesn’t want to receive from an endpoint
· Ability to implement policy is different than the ability to dictate
· Circle of trust
· Users don’t manage their own certificates
Comment from Devon McGraw
· Hard to divorce policy from technology
· Leaving the decision open changes things
· Don’t want people to be obstacles to exchange
Comment from Farzad Mostashari
· Stay within policy bounds of the HITSC
· Leaving optionally in leave the risks
· Incumbent on this group to be aware
· The HITSC Policy recommendations will be implementable
Questions from Sean Nolan
· Tension is that there is a set of NHIN policy that will be handed down over time
· How can I make myself belief that this technology will be implemented across the country – widely
· Consider later: do we want to say that we want technology that supports those and only those?
Question from Wes Rishel
· Problem of different people having different opinions of what a signature is
o Signing of work vs. authentication
· Signatures of a point of Origin?
· This more than others – language gets read by people who have not internalized difference
· Trust assertions
· Agreement: we are talking about “I am who I say I am”
Comment from Dan Russler
· “Keys for Consensus” should be “Policies for Consensus”
o We should make policy choices that are within policy bounds of the HITSC
o Farzad wishes that there was more acknowledgement of the HITSC policies and then a greater understanding of how we fit within it
· Table discussion: what are we extending on what has already been approved
Comment from Lin Wan
· Will it only be read from end user to end user?
· Intent is to say that only the endpoint who are expected to see the content of the message will see the content of the message
o Technology can’t make this decision true
· Policy guidance – intermediaries can’t break open the message
o What is meant by an intermediary
· To have sufficient trust, there will have to be a governmental role to do organizational vetting
· People have to be responsible at some point
· Tried to define a model that isn’t moving down individual certs
Comment from David McCallie
· Table this discussion until Farzad/Devon tell us about what we would have to meet
· Why do we not wait?
Comment from Farzad Mostashari
· There have already been policy bounds that have been put in place
· Trust us!
· Security and Trust WG needs more conversations, specifically around the following:
o Harmonization of HITPC recommendation language with Security and Trust WG outputs
o Exploring out the concrete proposals – i.e. how they would work in the real world and then present to the NHIN Workgroup and Privacy & Security Workgroup with technology/policy tradeoffs for each option
Richard Elmore for Individual Involvement
· More than just a patient
· Purpose is to clarify technology issues and policy implications for individual involvement in direct transport
· “Individual” = Non-provider participants in care
· 2011 Stage 1 MU
· Provider sends a reminder, health information, clinical summary or discharge summary to an Individual
· 2013 Stage 2 MU
· Individual sends message to a provider
· User Stories
o Five confirmed Individual Involvement User Stories (Must Haves)
o One User Story is being refined and prioritized
· The Role of the Patient / Individual
o An engaged patient is more likely to take steps to maintain and improve her health.
o Standardization of NHIN Direct transport protocols can apply to individuals in communication with their clinicians.
o Individuals who communicate with their clinicians asynchronously and electronically are potentially more engaged at potentially lower costs
· The Role of the Patient / Individual:
o 2011 Meaningful Use provides for an eligible professional to send a summary of the clinical information or reminder chart to an individual
o However, support for an individual to electronically message her clinician is not included until 2013.
· Considerations
o Unreliable Identities
o Indistinguishable Trust Levels
o Clinician Refusal
o Patient Expectations
o The Role of the Patient / Individual: Considerations
· Guidance to Content & Packaging
o Anticipate self-describing file types will evolve
o Individual “friendly” content descriptions
o For the bundle
o For individual attachments
· 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.
Arien Malec for Implementation Geographies
· Purpose is to plan for early implementations demonstrating real-world information exchange following existing care delivery patterns
· Leader: Paul Tuten
· Deliverables:
· Finalized set of key geographies for early real-world implementations
· Template operational plan identifying stakeholders, success criteria, and project considerations
· Updates
o DRAFT early list of potential geographies: http://nhindirect.org/Potential+Implementation+Geographies
o DRAFT early list of operational considerations
· http://nhindirect.org/Implementation+Operational+Plan
· Identify regions of the country
· Identify set of anchors that are referrals
· Engaging with key stakeholders
· Don’t use the word “pilot”
· Another meeting on the 11th – a two day meeting?
o Dan Kazzaz – Vegas/SSI
o Sean Nolan – Seattle
Structured Discussion
· Security & Trust
· Point of view: really important to tie individual signed assertions in the wrapper of the transaction itself to express security down to the organization level
o Done through WS security signatures
o Signed SAML assertion
o Mandates mutual TLS
§ Was the risk we tried to mitigate – but was it even a risk?
§ Tie to a specific address?
§ Counter assertion is TLS
· The system must enable trust assertions at either the organization or address/endpoint level. It is a matter of policy and preference whether organizations use a single certificate for all of their addresses, or assign individual certificates for each address.
· Pre-discussion – do we need to have PKI identity in our framework?
Comment from Lin Wan
· If we want to make sure it is a secure communication from the source to the HISP-Destination, or are we willing to accept that we have a trust fabric and it will security get to the destination without anyone having seen the data
Comment from Dan Kazzaz
· Providers/individuals need to think about our policy
· Sending PHI by email isn’t totally illegal
Comment from Farzad Mostashari
· Functions that need to be enabled that will need secure routing and identity assurance
· HSPS will need to be vetted
· Technical compliance
· Identity assurance
· Extension of chain of trust to the end
· How do you do identity assurance for a non-carbon based life form?
· 1) Policy onus on the HISP client routing
· 2) Highly leveraged port
o Economic decision on both sides: hard do adopt if we just start with HISP to HISP
o Use the word organization to organization?
Comment from Wes Rishel
· Are HISPS business organizations?
· HISP can represent more than one healthcare organization
· HISP responsible for secure routing, and we just set the requirements, but they do
· Policy decision – if the policy side says something than we might need to comply
· Those who are going to hook into it are those that have already done secure routing
o They have already built this stuff
o Concerned about if there is another system, we don’t want to ruin what they already have in place
Comment from Rich Elmore
· Decision to end up with an initial implementation of this
· Less concerned about what happens HISP-HISP
· Provide more flexibility on this – different capabilities
Wrap up from Arien
· End stage of this is to deliver higher quality, more efficient, more engaging health system
· Improving the healthcare delivery system
· Thank everyone for involvement and participation
· Theme:
o Technology/Policy conversations
o Need to make sure that decisions that have already been made at HITPC are fed back and we are using the appropriate terminology