Every Tuesday, the NHIN Direct Implementation Group holds a teleconference to update the entire team on the progress of the technical workgroups. This week, we discussed the completed addressing specification.
As I've said many times in my blog, the most important standards implementation problem to solve right now is transport, not only the basics of transmitting data securely but also transaction orchestration and the constellation of supporting functions such as addressing the messages.
In previous blogs, I've described one way to solve the addressing problem - give every patient a voluntary opt in "Health URL" that they could use to receive all healthcare data from hospitals, offices, labs, and pharmacies.
For use cases such as sending data from provider to provider, hospital to provider or provider to public health we need some similar approach to ensure data is delivered to the right place.
The NHIN Direct Addressing specification proposes five ways to do this - secure email addressing (SMTP plus TLS), REST, SOAP, and the HL7 routing schemes XCN and XON.
First, two definitions. A "Healthcare Internet Address" is made up of a Health Domain name and a Health Endpoint Name
Health Domain Name
A Health Domain Name is a string conforming to the requirements of RFC 1034.
A Health Domain Name identifies the organizations that assign the Health Endpoint Names and assures that they correspond to the real-world person, organization, machine or other endpoint that they purport to be. For example, my organizations (BIDMC and Harvard Medical School) could control nhin.bidmc.org or nhin.hms.harvard.edu
A Health Domain Name MUST be a fully qualified domain name, and SHOULD be dedicated solely to the purposes of health information exchange.
Organizations that manage Health Domain Names MUST maintain NHIN Direct Health Information Service Provider (HISP) Address Directory entries for the Health Domain Name, as specified by the Abstract Model, and corresponding to rules established for concrete implementations of the Abstract Model. Organizations that manage Health Domain Names MUST ensure that transactions are available for Health Endpoint Names, either through proprietary means or following the Destination role transactions of the Abstract Model. Organizations may take on the HISP role or assign this function to another organization playing the HISP role (such as GoDaddy does for hosting regular email on behalf of other organizations).
Health Endpoint Name
A Health Endpoint Name is a string conforming to the local-part requirements of RFC 5322
Health Endpoint Names express real-world origination points and endpoints of health information exchange, as vouched for by the organization managing the Health Domain Name. For me, that could be a person such as Dr. John Halamka, an organization such as BIDMC Emergency Department or an aggregation point such as BIDPO Quality Data Center. Here are examples of each address type
Email
Jhalamka@nhin.bidmc.org for health information exchange (not regular email) directed to me at BIDMC
REST (example of a possible format)
https://nhin.bidmc.org/nhin/1_0/nhin.bidmc.org/jhalamka/
1_0 refers to the REST API version.
SOAP (example of a possible format)
https://nhin.bidmc.org/nhin/1_0/wsdls/messages
the person or organizational endpoint would be specified in the SOAP message itself.
1_0 refers to the SOAP API version.
HL7 XCN (extended composite ID number and name for persons)
urn:nhin:nhin.bidmc.org:jhalamka^Halamka^John^D^DR^MD^^&NHIN OID&OID
The XCN representation could be used in multiple contexts, including the intendedRecipient in an XDS/XDR web service call or in an HL7 2.x message to refer to the sender or receiver of a message (e.g., in a PV1 segment)
HL7 XON (extended composite name and identification number for organizations)
Beth Israel Deaconess Medical Center^^^^^&NHIN OID&OID^^^^urn:nhin:nhin.bidmc.org:emergency_department
Note that XCN and XON are included for compatibility with the IHE XDR spec, NHIN Document Submission, and HITSP T31.
Imagine if every EHR could send data to every other EHR using a simple addressing mechanism like Email, a consistent REST implementation or a well described SOAP WSDL. Interoperability would follow rapidly because novel packages of data will be sent to support real business needs without any barriers of how to get the data from endpoint to endpoint.
The NHIN Direct process is working well and builds upon the work of the past. It does not compete with, diminish, or in any way represent a replacement of the hard work done by so many people over the past years in HITSP, IHE, and the SDOs.
I'll continue to provide NHIN Direct updates as reference implementations with running code are deployed. Massachusetts, through NEHEN and the Massachusetts eHealth Collaborative has volunteered to test these techniques with other surrounding states. Let the testing begin this Summer!
Email is certainly a good idea as it is generally accepted that it is the most widely used computing activity. However there would need to be forms designed (e.g. an Access email form) to capture field data. Both client-side and server side scripting would be necessary to validate business rules of EMR data collection.
ReplyDeleteThis approach would likely be much more feasible for LTPAC staff as even direct-care workers are increasingly familar with email based systems. At the ICF-MR where I work we are using Microsoft OWA accounts for over 1,000 program staff.
I do use some email forms to collect database records and it has worked very well. If using browser-based email forms to collect EMR data, less training would be necessary.
free text is the problem with email? we have to lead the patient to give necessary data for each type of function, this method could also help in triage and diognostic processes, apply the right questions on a ipad for example and extract the right data for the staff to prepare correct plan of action, or something like that?
ReplyDeleteNHIN Direct would get the most value right out of the gate if you specify that anyone who has an NPI number already should use that as their Health Endpoint Name. I’d suggest specifying prefixing it with the letters NPI for clarity and to reduce the chance of interfering with someone who uses, for example, numeric staff user IDs as the way of addressing data to their secretaries. So my address would be:
ReplyDeleteNPI1912971037@NHIN.FallonClinic.org
The beauty of this is that no one needs to build an NPI directory addressing service since the directory is already publicly available, and we’re all already required to use the NPI numbers in all of our transactions. So I already have in my EHR the NPI number of all of my community’s referring physicians, as well as the NPI number of anyone I send patients to. So using the NPI number as the Health Endpoint Name would enable me to automate the addressing and routing of referral "letters" and consultants' "reports".
@Anonymous: Actually, email is not as widely used among younger, upcoming professionals as previously. I know many high school and college kids who almost never check their email; social media like Facebook has caused them treat their inboxes like their mailboxes: a place to ignore junk mail. Just this morning, FierceHealthIT reported on a CDC recommendation that the government engage in more SM to engage citizens (http://www.fiercehealthit.com/story/cdc-official-government-must-embrace-social-media-inform-populace/2010-04-26).
ReplyDeleteWhatever we use to electronically engage users, rest assured it will change. The question is whether we'll be able to keep up with where the conversation moves to.
Instead of a URL, how about individuals getting assigned IP numbers on a global basis?
ReplyDelete