As Massachusetts prepares a Request for Response (RFR) to procure healthcare information exchange infrastructure and applications, many stakeholders have been hard at work documenting requirements.
The Provider Directory and Public Key infrastructure are some of the hardest specifications to write since they have not yet been widely deployed for healthcare information exchange anywhere in the country.
The leaders of the Massachusetts HIE effort have held 3 major vendor and user forums over the past month and have been told that no vendor has a standards-based provider directory in production at any customer site.
Here's our best thinking about Provider Directory and Public Key infrastructure services.
Provider Directory
The Directory will have a schema within a relational database that enables lookup of entities, which could include a person (John Halamka), an organization (BIDMC), a department (The BIDMC Department of Emergency Medicine), a state entity (Massachusetts Department of Public Health), a payer (Blue Cross Blue Shield of Massachusetts), a vendor (The Massachusetts eHealth Collaborative Quality Data Center), or a PHR infrastructure trusted by the HIE (Microsoft Healthvault). There will be two ways to query this database - Lightweight Directory Access Protocol (LDAP) for use within the Massachusetts state government firewall and SOAP-based web service APIs for all users external to the firewall. The response to a query will include the node name for communication to the entity i.e. John Halamka will not have a node, but the BIDMC Department of Emergency Medicine or BIDMC could. Digital certificates are not stored in the Provider Directory.
Public Key Infrastructure
Certificates will be issued by a single Certificate Authority and will be stored in one of many Domain Naming System (DNS) services capable of supporting certificate queries such as BIND or Microsoft's special implementation of DNS created for the Direct Project (http://directproject.org/). For example, BIDMC could offer a DNS service called Direct.bidmc.org which hosts the public keys for all our nodes.
Here's how it would be used. An EHR would look up an entity in the Provider Directory and then use DNS services to retrieve the certificate for the entity's node.
We're also considering an alternative approach using the open source tools available in the Direct Project's Reference Implementation. These tools include administrative tools to store and manage certificates and an adapter that links the directory store to a DNS responder. Participants could upload their certificates to this centralized data store. For example:
DNS Responder <--DNS Web Services--> Direct Reference Implementation Web Services <--BIDMC adaptor--> BIDMC datastore
The vendor community has told us that they want a single simple directory and public key infrastructure specification they can implement one time for an entire state. We'll give that to them and I'll write about their responses in future posts.
Subscribe to:
Post Comments (Atom)
2 comments:
There's an easier way: Allow the patient to be the sole token/key owner for any exchange scheme. If John Halamka visits a healthcare facility, John can share access for the duration of the encounter.
It's just nuts to try and figure out good ways to let a whole series of caregivers be access stewards for health information tied to the patient who actually owns the information.
Why just LDAP and SOAP? Especially as the NwHIN power team recommendations include the use of REST based services. Frankly after going through some of the Provider Directory documentation it really feels skewed toward what Direct needs to operate and not a lot of consideration for other ideas.
A REST based service could easily do everything that is required so why is this approach be disregarded? Why oh why DNS? I get the idea of having an id that can easily be dereferenced but there are better ways to to this that do not require DNS. OpenID Connect Discovery for one.
Post a Comment