The Direct Project and IHE/HIMSS

"The Direct Project", formerly known as NHIN Direct, has officially changed their name, the specifications are maturing, the reference implementations are maturing, and the discussion is turning to the topic of where will the output of the Direct Project land and be maintained. I think that IHE is a very logical place and a place that I find many synergies between what the NHIN Direct project did and what an IHE US Realm would do.

The Direct Project (NHIN Direct) specifications are almost completely aligned with the IHE XDM – E-Mail option. They have simply added that sending a single document without the XDM wrapping is allowed. This is the kind of thing that I would expect a realm specific workgroup to acknowledge.

The Direct Project (NHIN Direct) have done some analysis of the IHE specifications and have provided feedback to the IHE ITI committee their recommendations on both XDM and XDR profiles. This analysis is done in the context of the the direct environment and intended audience. Most importantly this analysis was done in the context of a set of Privacy, Security, and Operational policies. Again, this is the kind of thing that a US Realm committee would be expected to do. For example: They have observed that the XDR and XDM metadata rules are too onerous for the direct PUSH use-cases, especially when applied to some specific use-cases that the IHE ITI committee did not looked at yet. The Direct Project also looked at the interaction between XDM and XDR at a gateway service and applied privacy policy in such a way as to question why XDR has integrated sender and recipient address inside the more sensitive metadata.

The Direct Project group is now struggling with Testing. They don’t have experts in writing test plans, test procedures, or test tools. The closest thing they do have is experts on unit-testing that comes along with the source code of their “reference implementation”. I think this is also a good place for a US Realm to focus a local Connectathon toward the local realm use-cases, and tie this to the local demonstration project (e.g. HIMSS Interoperability Demonstration). For this the IHE expertiese in test tools and testing events like Connectathon would be very valuable.

The Direct Project does have a component that IHE does not have today, this is the open-source reference implementation.  IHE does come close with the open-source Registry from NIST; but this was more of an individual effort (one that needs to be recognized often), rather than a formal part of specification approval. I think there is an opportunity for IHE to extend a welcoming hand to this style of specification validation.

The Direct Project also has the Implementation Geographies. It is not clear how well this will workout inside the IHE context. I think it is something unique to the NHIN Direct project at this time due to the style of solution vs the ‘pure interoperability specification’ that IHE tends to focus on. I know that there might be concerns with getting too close to implementations, thus presenting a conflict-of-interest.

The Direct Project is an excellent example of what a region can and should do with the IHE specifications. They deviated only slightly, and when they did they provided the feedback to IHE for discussion and iteration. There are some useful lessons to be learned by IHE on how to excite a region and to accelerate implementation through reference implementations and implementation geographies.

Engage with Grace

If you are reading this on Thanksgiving day in the US, print this out and read with your loved ones.



Really, read it. That is the message.  To learn more, see http://www.engagewithgrace.org/

John

P.S.  I am thankful that there are so many people who care so much for others that they are willing to work in healthcare. Top to bottom, thanks to everyone.

IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network

The history on IEC 80001 is best summarized by Nick Mankovich, Sr.Dir. Product Security and Privacy, Philips Healthcare, in a white paper he wrote for "Information Security Magazine". I have worked side by side with Nick on this standard and want to give him every credit I can at being the lead on the integration of Security Risks. He was recognized as one of the Information Security magazine Security 7 Award winners.

Less than five years ago, Brian Fitzgerald of the U.S. Food and Drug Administration called together a diverse mix of health care folks to talk about the harm that was being done from poor networking of medical devices in hospitals. His agency had reports of injury and death as a result of improperly connected networked devices. In that first brainstorming meeting of December 2005, there were biomedical engineers, IT professionals, regulatory specialists, medical device risk management specialists, security professionals, and medical device engineering staff. Brian urged us to organize and do something to help the world avoid this harm. To avoid international mismatches and "not invented here" issues in government regulatory authorities, he suggested this be pursued as a global standard. Five years later, we are very close to the final vote on the first international standard to address the Application of Risk Management to IT-networks Incorporating Medical Devices (IEC-80001-1).

It was approved September 24th. Nick continues:

This standard lifts security and privacy risk out of the afterthought category into the mainstream of health care delivery. It does this by building around the principle that decisions in any new device integration project in health care need to be built around some simple concepts. In the parlance of IEC-80001-1, medical IT-network risk management proceeds with a careful examination and understanding of three key properties: (1) safety, (2) effectiveness and (3) data and systems security. By considering all three, we can first "do no harm" while effectively delivering on the organization's health care mission. This is done with careful and explicit treatment of the appropriate level of confidentiality, integrity, and availability.

Of course, today's IT staff and biomedical engineers are skillful at keeping the highest levels of safety and effectiveness. However, with IEC-80001's explicit inclusion of data and systems security breach into its definition of harm, we have paved the way for an open and honest discussion of the C-I-A [Risks to Confidentiality, Integrity, and Availability] impacts of an interconnection project or a network change. It allows a consideration of the harm brought to individuals when confidentiality is threatened and, for the first time, consideration of the harm of privacy compromise is an essential part of the IT, biomedical engineer, caregiver, and compliance discussions.

There are specific requirements on Medical Device vendors that Nick explained in an email to the NEMA workgroup:

For medical device manufacturers, it includes requirements for risk disclosure to the Health Delivery Organization that are word-for-word consistent with the 60601 3rd edition. For the most part, this may evolve into a collection called a “80001 risk disclosure statement” that, for safety and effectiveness, would likely be culled from other places in existing manuals/instructions-for-use. Security risk disclosure may evolve into a “next generation MDS2” consistent with something like that described in the Security TR (see below). The establishment of an 80001-consistent “next generation MDS2” is the subject of a MITA/HIMSS working group that is actively discussing the content.

Further there are some anexes that are being written right now. Contact your ISO or IEC representative to get copies and to comment on these. The next meeting is in March at Best Netherlands immediately adjacent to the JWG3 meetings.

1. 62A/719/NP Step by step risk management of medical IT-networks; practical applications and examples (Karen Delvecchio of GE Medical)
2. 62A/720/NP Guidance for the communication of medical device security needs, risks and controls (Nick Mankovich and Brian Fitzgerald of FDA)
3. 62A/721/NP Guidance for wireless networks (Rick Hampton of Partners Med, Boston) 

IHE ITI Work set for 2011

The IT Infrastructure (ITI) domain of Integrating the Healthcare Enterprise (IHE) has started the Development Cycle for 2011. The process starts with the Planning committee evaluating "Proposals". This year the ITI committee had only a few proposals to choose from, so they choose to simply prioritize the list rather than eliminate some proposals.

The Technical committee meet this week to evaluate how hard each one is, including evaluating if it is even feasible. There was spirited debate about each one of them. There are some work items that are simple documentation but complex decisions to be made, where others have been discussed at length that result in convoluted textual changes.



The Technical committee ultimately decided to eliminate one proposed work item from the list given to them by the planning committee. The work item that was removed is the Document Sharing Directory Service - This proposal would have resulted in a way to publish service endpoints for building a Health Information Exchange using the IHE XDS family of profiles. This is a profile of the UDDI directory standard specific to the IHE XDS family services. This work is highly influenced by the NHIN-Exchange experience. The main reason it got killed was due to overall resource balance across the whole committee; there was also concern with the maturity of the standards with evolving new standards.

The resulting Work items for 2011

1 XDS Link/Unlink Support - This proposal will result in a profile that explains how to handle Link and Unlink in an XDS Health Information Exchange. This proposal will impact Health Information Exchange Infrastructure including Patient Identity Management and Registries.
2 Cross-Enterprise Document Workflow (XDW) - This proposal focuses on the Cross-Enterprise Workflow for Document Sharing in support of workflow document and status management. Key elements: Managing workflow specific status with relationship to one or more documents, Tracking the health care entity that change a status associated to a workflow step, and Tracking the past steps of the workflow related to specific clinical event. This is a BASIC profile that real workflows will build upon.
3 XCA Query & Retrieve - This is a proposal to add a new transaction to the XCA environment that would combine an XDS Query and a Retrieve of all documents identified by the Query result. This proposal likely will not be supported in XDS environments. The motivation for this is to make Cross-Community queries easier to process in the infrastructure.There is clear concern about the unintended consequences of adding this profile.
4 XD* Minimal Metadata - This proposal asks for the XDS Metadata requirements to be reevaluated relative to PUSH type transactions (i.e., XDR and XDM). This proposal is inspired by the NHIN-Direct project and will include other changes to XDR proposed by them. 
5 CDA Encryption - This proposal has been shaped and scoped by the Planning committee. It now focuses on adding Encryption capability at the document level. This solution will likely follow the IHE Radiology committee solution in PDI. This is to apply Secure e-Mail (S/MIME) content packaging around the XDM zip file. This results in a portable encrypted package that can be carried on any device or transport. This profile could also create an encrypted container for any document at the document level, similar to the DSG profile.
6 Pseudonymisation and De-Identification in IHE Profiles (Handbook) - This proposal will result in a handbook, a process that IHE domain committees can use, that can be used on domain specific use-cases to develop a de-identification and pseudonymization profile. This work will leverage similar work done in HITSP. This work will look closely at the QRPH white paper written last year on the subject. This handbook will also incorporate the process I have documented in De-Identification is highly contextual

Signing CDA Documents

I get asked about signing documents in healthcare every other month. Signatures in the electronic world is an area full of technology solutions, but fought with policy and expense issues.

Understanding the Paper world:

The paper world is full of signatures, and it is very important to understand these signatures in the paper form before we quickly jump to the electronic world. A signature in the paper world is not just ink on paper. There is a ceremony involved in the act of placing a signature on paper. This ceremony is not necessarily a hugely formal thing, but the physical act of being presented with the paper, reading of the text on paper (yes I know no one reads them, but it does imprint an image in the brain), finding a tool to do the signature (pen), and placing the signature onto the paper. This physical act is important, not just at the time that it is done, but also because it places memories into our memory about that ceremony. Thus 10 years later when someone presents us with that ink signature on that paper we have quick recall as to if we did that signature or not.


There is also different levels of signatures. I am sure everyone has an experience where initials have been requested, such as at hotel check-in or when renting a car. These initials are their way to make sure you have participated in the ceremony, and draw your attention to critical parts that you are agreeing to. For example initialing by the daily-rate, conditions of fuel filling, etc. These initials carry less importance than the final full signature at the bottom. This placement at the bottom (or end) is important as it is implying that you are signing everything from the top to the bottom.


Factors to think through:
Often times a signature in the electronic world doesn't think about all of these factors.


1) Is your use-case specific to Digital Signatures, or are you also including Electronic Signatures? Where Electronic Signatures are not using cryptography standards, and often are simply attributes. Digital Signatures use open standards so that the signed 'thing' can be verified using various and non-related tools.
-- I  am only going to talk about real Digital Signatures.

2) What is the goal of the signature? This leads to who/what is attesting to what to whom. Is the signature a transactional signature or a long-term signature. There is a Digital Signature function built into secure transports such as TLS/SSL; but these are only good for covering authenticity and integrity between the sending system and the receiving system. Once the data comes out the other end of the transport tunnel, it is no-longer protected by this transport based signature. Usually no one thinks about transport signature, but it is important to recognize that this is a specific type of signature.


3) How is the signed data to be used vs how the signature is used. There are use-cases for a digital signature across a CDA document, but when looked at closely there is good reason to keep the signature separate. In many cases where the CDA document is used, the signature is not important. This is not because the signature is not important overall, just that for that specific clinical purpose the signature is not important. The signature is there for legal challenge reasons. Back to the paper world, it is common for many people to use a signed document, but most of them don't do any validating of the signature. There is an assumption that the document exists because it is legitimately signed. At best they verify only that a signature is present. This is a good reason to keep the signature independent of the CDA document it-self. Thus the vast majority of uses of the CDA document don't need to be bothered with the signature.

4) What is the reason-for-signature? This is usually something that people forget to think through. There is some reason why the signer is signing the document. It might be because they are the author. It might be because they have over-read it. It might be simply to indicate that they reviewed it. It might be a signature by a software-service indicating only that it is authentic. The reader of a signature may care only about one of these purpose of signature values. They may be only looking for the authors signature. The reason-for-signature should be considered to be part of the signature. This is the main contribution that the IHE Document Digital Signature (DSG) Profile offered, through extension of XAdes. (that and the date/time stamp)

5) Where is the date/time going to come from, and why should the signature validator trust that the date/time is accurate? This is usually a chicken and egg problem; but does need to be considered. Often times the only way to solve this is through policy/procedure. There are technology ways to solve this, for example using a timestamp service that it-self signs the timestamp alone (reason-for-signature = attesting time/date). The signed date/time is only important to someone challenging the higher level signature. This is yet another use-case where having an external signature from the CDA document is helpful.

6) Is the signature only going to be applied to CDA documents? In the IHE Document Digital Signature (DSG) Profile case, they wanted to have a reusable signature that could be applied to any document type. This is an advantage of this model. Having one mechanism that is independent of document type is very helpful. However a drawback of this model is that it is not as useful for a partial signature. So the current IHE DSG profile covers the whole document only. For example the diagram at the left is the layout of the IHE DSG profile for use with a BPPC Consent Acknowledgment document.

7) Will counter signatures and co-signatures going to be needed? Again a functionality supported by IHE DSG.

8) Are partial signatures really needed? The XML-Digital Signature standard is very powerful and likely the right base standard (as IHE DSG used). * Be careful when using the partial-signature. This is academically possible with XML-Digital signature; but there are known problems with this. This does not mean you should not use partial-signature, but you should be very careful to evaluate if partial-signature is really needed. Often times the need for partial signatures can be handled with a good reason-for-signature.


9) There are ways to use XML Digital Signature that are embedded inside the CDA structure. This is done with a transform that excludes the part of the CDA document where the signature is stored, and thus the final digital signature is stored inside the CDA document. This is likely the most fully functional, but also the most complex. I know that there are known issues with partial signatures, so I worry about this in the short term. It is possible that this will eventually become mature enough to rely on.

10) Whole package Signature? S/MIME packaging vs IHE XDM are somewhat equivalent from the outside. But there are implementation maturity issues with MIME-Multipart-Related. Not with the specification, but with the implementations. This is why IHE choose to use ZIP as the packaging mechanism. The additional advantage of XDM is that the XDS-Metadata allows for documents of all kinds to have relationships, metadata, and lifecycle. IHE will likely add a S/MIME wrapper to XDM this year. But it will be encapsulating so that the whole package can be authenticated, encrypted, and verified. So, this will be yet another model for Digital Signatures. Most applicable to cover a point-to-point conversation, even if that conversation goes through a patients hands.


Available Technology solutions
So here is a list of possible technical ways to do a long-term Digital Signatures in healthcare.

1. XML-Digital Signature value inserted into the structure of the CDA document as an extension
2. XML-Digital Signature in Encapsulating mode (Where the outer XML is XML-Digital Signature, and where the contained CDA is untouched)
3. XML-Digital Signature in Detached mode (Where the XML-Digital Signature is it-self a document that signs the CDA document by reference) This is what IHE DSG does.
4. S/MIME Digital Signature on the the CDA Document and any images that go with it 

There are some other technology that are considered valid Digital Signatures, such as PKCS


I prefer either 2 or 3 methods. I like the IHE DSG model, as it has no impact on those actors that trust the transport and don't feel the need to validate the signature every time the document is used; yet the signature is available when needed.

Digital Signatures are Expensive
Most of what I have covered is readily available and mature Technology. But there is one more piece of Technology that causes Digital Signatures to be not implemented. This is not because the technology is expensive or hard to use. The thing that typically kills Digital Signature projects is the issues around managing the necessary Digital Certificates. It isn't just the Digital Certificate, but also the Private Keys associated with the Public Digital Certificate. I am not going to go into these issues in this article. But it is very important for people to include the expense of certificate management, especially as it relates to long-term digital signatures. Issues around identity verification, certificate issuance, private key protection, certificate expiration, certificate revocation, certificate purpose,  etc.

Food for thought: Validating a Digital Signature 20 years later includes making sure that the Digital Certificate used was valid at the time that the signature was made.


Reference:

• IHE Document Digital Signature (DSG) Profile
• NHIN Direct (The Direct Project)
• IHE XDM 
• IHE - Privacy and Security Profiles - Document Digital Signature 
• Using both Document Encryption and Document Signature 
• Non-Repudiation is a very old art

Re: How Open and Broad Should an Interoperability Project, like the Direct Project, Be?

David Tao asks on the Direct Project Blog:  How Open and Broad Should an Interoperability Project, like the Direct Project, Be?


Keith responds with a very measured standards based response that I very much agree with. Leave it up to Standards to have standards on being a standard... Leave it up to an uber-standards-geek to know about it. I am sure the non-standard google helped him out.

The Direct Project (I can't stop reminding everyone that this is the project formerly known as NHIN Direct) is being held up as a Best Practice. I think there have been some really good things that have come out of it, but I really can't say that the 'practice', that is the process used, is an improved or impressive process.


Too many participants, Really?

I would like to understand why some people feel that the Direct Project had too many participants. What evidence leads to this assertion? I was involved from the very beginning and participated in almost all meetings. I never saw a time when shear numbers got in the way.

Well there is one factor where shear numbers did cause trouble, that is the method choosen to run the Direct Project meetings.  It is not uncommon to take attendance at the beginning of a meeting. But the Direct Project experimented with a Process that had good intentions. When an issue was raised by the chair, the process was to poll everyone in order of their company (my sympathy to those with company names beginning with 'A'). This seems like a good idea as it forces people to listen and speak. But it didn't result in discussion, it resulted in disjointed comments. If this is the factor that people are using to assert that the Direct Project had too many participants, then I would far prefer to have a different process than less participation.


A way to deal with too many participants that are not contributing is to leverage the attendance list. There was far too few people in attendance at the meetings. We spent lots of time asking if there was anyone in attendance from XYZ company. The IHE process requires that you must attend in order to have voting privileges. This at least keeps everyone on the same page because they MUST join the calls. I don't know if this is the best solution, but it does work elsewhere.


Normal group behavior
While participating in this group, I didn't notice anything different than any other group. It was very clear to me how this group followed very nicely the four-stage model called Tuckman's Stages for a group. The Forming stage is always painful, the more often one creates totally new groups under new rules the more often the Forming stage wastes peoples time. Bringing in a mature Governance, like Keith mentions, can quicken this phase. I am sure everyone vividly remembers the meeting where we did the Storming, does Redmond come to mind?

Reinvention sometimes happens
My overall observation is that all of the arguments about RESTful vs e-Mail vs XDR... and today we have an open source Reference Model, in two different programming languages, that have successfully implemented ALL THREE!!!!  I am very excited and happy that we have an open-source reference implementation.

Seems to me this is proof positive that we have a clear and chronic case of Not-Invented-Here. Lets please stop the reinvention, and look to the governance established standards and profiling organizations. When reinventing the wheel, my guidance is that it should be circular in shape.

Presentation on overall IHE model for Security and Privacy

I have been asked by multiple people lately for an overview of the Security Model that IHE would apply to a Health Information Exchange. The last time I presented on this was back in 2008

2008 - IHE Webinar Session 10: IT Infrastructure: Security and Privacy  - Security and Privacy (ATNA, EUA, XUA, BPPC, DSG) - John Moehrke, GE Healthcare (.pdf | flash)

 I have been asked by the IHE ITI Committees to refresh this presentation. There has been a few updates since this presentation. Some clarifications about:

• Accounting of Disclosures -- 
• Accountability using ATNA Audit Controls
• ATNA and Accounting of Disclosures
• Updates to XUA++  - IHE ITI XUA++ - Trial Implementation
• Purpose of Use 
• Communicating roles
• Communicating existing Consents
• ConfidentialityCode -- Data Classification - a key vector enabling rich Security and Privacy controls.
• Evolution of understanding on Consent -- Stepping stones for Privacy Consent,
• Including TP30/BPPC presentation updates Consent Management using HITSP TP30
• Effects of confidentialityCode on availability of Consent Documents - Availability of Consent Documents and their rules
• Federation of Identity - Federated ID is not a universal ID  
• Healthcare Provider Directories.

I welcome comments and suggestions on what questions you have that the presentation should answer. What parts of the existing presentation communicate well, which parts don't work. This will be a project for me this fall, so stay tuned.

Healthcare Provider Discoverability and building Trust

The HIT Policy - Information Exchange Workgroup - Provider Directory Task Force - committee had a discussion today around Provider Directory. It is still not clear to me what use-cases they are trying to resolve. I have mentioned this in Healthcare Provider Directories -- Let's be Careful. I think they need to identify the use-cases and then prioritize these use-cases relative to how urgent it is that they solve these issues. For example in the case of Lab, there are well established methods. But there is a urgent need in the case of Community or Cross-Community based Provider to Provider referrals. Specifically where there is not a pre-existing relationship. This ad hoc need is more important than re-inventing where a solution is already available.

There is lots of conflating the need to discover

• an individual healthcare provider, with
• a healthcare providing organizations, with
• the Network Services of a healthcare providing organization.

Yes these could all be considered needs driving the abstract need for a Healthcare Provider Directory, but they are not all the same thing. If we really want to expand the

Discovering Healthcare Providers and Healthcare Services:
IHE has a Profile for Healthcare Provider Directory (HPD). This profile does cover the first two groups of use-cases as outlined in Healthcare Provider Directories. This is the list of use-cases included in the IHE profile.

• Yellow Pages Lookup: A patient is referred to an endocrinology specialist for an urgent lab test. The referring physician needs to get the contact data of close-by endocrinologists in order to ask whether one of them can perform this test in their own lab. The patient prefers a female endocrinologist who can converse in Spanish regarding medical information.
• Identification in planning for events: Emergency response planning requires the identification of potential providers who can assist in an emergency. Providers must meet specific credentialing criteria and must be located within a reasonable distance of the emergency event.
• Provider Authorization and lookup during an emergency event: During Hurricane Katrina, health care volunteers were turned away from disaster sites because there was no means available to verify their credentials. At an emergency site, the Provider Information Directory
• Forwarding of Referral Documents to a Hospital : A PCP refers a patient to the Hospital for admission. The PCP needs to send various documentation to the Hospital to be part of their EHR when the patient arrives. The PCP needs to identify the Hospital's electronic address such as email or service end point where the patient's documentation should be sent.
• Keeping agency provider information current: A German government agency dealing with healthcare services for its constituents wishes to keep its agencies healthcare provider information current. The agency determines that it will use the Provider Information Directory to access the most current provider information. The German agency only requires a subset of the Provider Information Directory available information. On a regular basis, the Provider Information Directory provides to the agency a list of the updated information needed.
• Providing Personal Health records to a new Primary Care Physician: An individual has changed health plans. As a result that individual must change his Primary Care Physician. The individual has a Personal Health Record and would like to provide that information to his new Primary Care Physician. The individual needs to determine where to have the Personal Health Record transmitted to.
• Certificate Retrieval: National regulations in many European countries require that an electronically transmitted doctor's letter be encrypted in a way that only the identified receiver is able to decrypt. In order to encrypt the letter, the sender has to discover the encryption certificate of the receiver.
• Language Retrieval: An individual who only speaks Italian requires healthcare services at an Outpatient Clinic. That individual would like to be able to communicate with the Clinic personnel, if at all possible. The individual or his caregiver needs to determine which clinic supports Italian and provides the service that is required.

Discovering Network Services:
IHE has another Profile under development for the third issue. This profile is highly influenced by the experience from the NHIN Exchange project, as well as many Health Information Exchanges. This profile is still under development so there is not much I can point at. This profile will not be using the same technology as the HPD, but will have appropriate linkage between them. The profile has very different uses and very different information needs. This profile will be constraining UDDI, as that is the standard used for services to lookup other endpoints.

Discovered, but not Trusted:
However just having a Directory entry does not mean you have trust. I often hear people discussing the scenario where a doctor needs to send something to someone else who they have never dealt with before. And in this case they want the doctors system to automatically discover the other system, attach securely, and communicate PHI to it. I don't find this use-case to be very reasonable.  Even in the case where there is regulatory oversight that all individuals found in the directory are fully compliant to very strict requirements, far more strict than HIPAA. This is because sending PHI to someone else is more than just assuring that the endpoint is secure. There is also business relationships that need to be built, including agreements by that endpoint to act on the package.

This is true both of cases like NHIN Direct (The Direct Project), as well as Health Information Exchanges (Directed Exchange vs Publish/Discover Exchange).

NHIN Direct might be less of a problem because their use-cases are primarily manually controlled cases of delivering one package at a time, however this limit could easy go away with automation. The "Trust" issue for NHIN Direct is embedded in the NHIN-Direct Privacy and Security Simplifying Assumptions. Having these embedded in preconditions does not mean they are trivial or easily automated. These are in preconditions because they are actually hard and not easy to automate. I think that it is far more normal that the Doctor will make phone calls prior to sending PHI, or prior to asking for PHI to be sent. These phone calls are very critical validation that the two parties do indeed intend to work together for this Patient. These phone calls will likely result in at least a gentlemen's agreement in not a fully signed agreement.

NHIN Exchange has an extensive process for 'onboarding'. This is not a trivial process and covers many levels of checks and balances. What is important to take away is that the process is not just about the technology. The technology is used to enable the process. The technology is used to certify that an organization has achieved validation, and is also used to indicate that this validation has expired or been revoked. Specifically the Digital Certificates used to 'secure' all communications are this technology. The issuance of a Digital Certificate from the NHIN Exchange authorized "Certificate Authority" is only achieved when the system has been validated against the onboarding process. If ever that system is determined to be compromised this certificate can be revoked. So, clearly technology (Digital Certificates and Public Key Infrastructure) can be a critical part of building trust. But this trust is built prior to technology being engaged.

Building trust is hard, and keeping trust is sometimes harder. Technology can help, but there is so much more to it.