esMD AoR L1 Digital Credentials, Identity Proofing, and Digital Signatures /
Delegation of Rights SWG Community Meetings
Date of Meetings: 10.10.12 / 10:00am EDT; 1:00pm-3:00pm
Decisions
Discussions from all three sub-workgroups focused on the Author of Record Use Case 1&2
workflow presentation. Notes from all three sessions have been combined into one document.
The notes follow roughly the slides from the SWG meetings.
Provider Registration
- A “registration entity” is the same as the “provider agent” defined within Use Case 1. A
registration entity creates and signs the transaction, and is either the provider or some
entity acting on behalf of and authorized by the provider to do the registration. This would
include an HIH, a parent organization, or an individual provider. While there is potential
for confusion over not using the same terms, there could be more than one level of agent.
The SWGs will need to be clear what is meant by “registration entity” and tie it back to the
Use Case.
o On slide 6 (Provider Registration), number 1, “Registration Entity is
authenticated” was changed to “Registration Entity (Provider / Provider Agent /
HIH) is authenticated.”
- ‘Delegation of Rights’ has been broadly defined as when the holder of a right gives that
right to act on their behalf to someone else, and it manifests in several ways. In the
registration transaction, it refers to the ability to register on behalf of the provider or the
intermediary.
- For signing at AoR L1, the delegation of right is from the provider who is the subject of
the eMDR (which could be an entity, organization, or individual) to whoever is going to
sign (which could include an HIH). The signing responsibility will change significantly as
we get into AoR L2 and L3.
- If the signing and responding entity are different, a delegation artifact may be required to
establish an unbroken chain. Because the signature artifacts and payload are intact and
provable cryptographically, it’s possible not needed for another delegation of rights
element.
Signatures
- Response and signing may be done by different entities—one which does signing on
behalf of the provider and one which is responsible for communicating the signed bundle
back to payer.
- Currently, CMS does not require cryptographic proof of delegations of rights on inbound
transmissions. Such a requirement, while onerous, may be appropriate, as it would mimic
current requirements for paper records. An ideal model would show an unbroken trail
from the subject of an eMDR to the transaction itself, but such a model may require a
more incremental approach. If there is an easy way to create these delegations, it would
create an audit trail that is confirmable by the recipient of the transaction.
Encryption
- Whether or not the payload is encrypted depends on the kind of access needed by
intermediaries between the sender and receiver.
- Encryption should utilize the public key of the payer (or payer’s agent), which would
prevent an intermediary from seeing PHI, but PHI will likely always be in the metadata.
There is potential for encryption of PHI of the payload independently of the encryption
that happens during the transaction.
- If the provider does the encryption, an intermediary like an HIH would act as a router, as
the payer is the only one who can decrypt. If the intermediary is acting as the signing
-
-
-
-
entity, then they would also be the responding entity. In either scenario, encryption
occurs along with the signing and assembling.
If we are we using the intermediary for a purpose that needs access to the
documentation, encryption may not be feasible. But if we can encrypt, it opens the door
for less-secure methods of transmission, where the endpoints can see info in clear text.
For example, within Direct, HISPS would be able to see the transactions and allow them
to pass through completely encrypted from sender to receiver.
Intermediaries like network service vendors are not HIPAA-covered entities, and they
only route data. If the function of the intermediary is an outsourced job of validating that
bundles are complete and appropriate, encryption may stand in the way.
Intermediaries sometimes do pre-processing. If they make any changes to the bundle,
the signatures are rendered invalid. This has implications for the encryption of metadata,
which needs to be readable.
Bob will begin working on a diagram illustrating the theoretical levels and
workflow for encryption.
It may be best to have encryption be optional, and include a field that indicates whether
encryption is allowed.
Slide 9 (AoR L1 Signature) was changed to reflect a more accurate flow (italicized words
indicate additions):
o Number 1, bullet point 1, “Provider delegates right to another Signing Entity to
sign responses to eMDR”
o Number 1, bullet point 2, “Responding Signing entity is authenticated”
o Number 2, “Responding Signing Entity creates document bundle…”
o Number 2, bullet point 1 was re-written, “If the Signing Entity is not the provider
then the Signing Entity adds delegation of rights artifact(s) to establish unbroken
chain to provider that is subject to the eMDR”
o Number 2, bullet point 2 was added, “If the Signing Entity is not the Responding
Entity then the signing Entity sends signed bundle and any delegation of rights
artifacts to the Responding Entity (Do we need a delegation of rights from the
Signing Entity to the Responding Entity if they are not the same – CMS does not
appear to have a requirement other than an audit trail)”
o Number 3, “Responding Entity (e.g., HIH) creates and sends the response
transaction to the eMDR to the payer.”
o Number 6, “Payer creates response to transaction from (3) and signs payload…”
o Number 7, “…eMDS submission response (5)…”
o Added to bottom of slide, “Discussion regarding encryption of payload by the
Signing Entity – create graphic of this process for review next week”
Validation
- Federal Bridge is not a trust anchor. Slide 10 was changed to reflect the correct process
of chaining.
o Number 1.c was changed, “Do we trust the certificate issuer: Chain to issuer /
trust anchor CA root certificate or Federal common policy CA”.
o Number 3 was changed, “Compute hash of message signed payload”
o Number 5 was changed, “Verify that signed hash matches computed hash of
message signed payload”
o Step 6 added: “If necessary, decrypt payload using recipient’s private key”
- In later discussions for AoR L2 and L3, there will need to be discussion around what
happens with signing bundles which contain signed documents, since then we would be
encrypting signed documents along with any artifacts / public certificates, and then
signing it again.
Identity Proofing – Individual Provider
- Credentialing doesn’t have to occur inside the organization; it can be outsourced, and
there are hundreds of credentialing companies in the US.
-
Group certificates are more like individual certificates—there is a ‘sponsor’ who has
responsibility for overseeing the group that has access to a key.
The following changes to slide 15 were made:
o Added to 3) b), “d), FDA process” and “e) Private Companies such as DAON”
o Added to 3)b)a), “(e.g. for delivery of services to a hospital)”
o Added to 6) at end, “(e.g. verify address associated with NPI or other Payer
Identification) (Note: demographics / address must be maintained/updated prior
to identity proofing as part of this process)”
Digital Credentials
- Some voice transcription software can authenticate via voice recognition and incorporate
the authentication into the transcription / digital recording.
- There is some specification of revalidation/re-issuance of credentials in Federal Bridge.
There is an antecedent process, but proofing must still be re-done in-person every third
renewal (or every 9 years).
- Derived credentials (FIPS 201-2): Providers may get a certificate on mobile devices
based on a credential they previously got. It may be possible to obtain derived credentials
on the basis of either a previous identity proofing process or a previous certificate at a
certain level of assurance. This could also be applicable to organizational certificates,
where an individual could derive credentials for the organizational certificate based on
his/her individual certificates, or vice versa.
o For example, some health care providers making house calls do all the
documentation on devices at patients’ homes. Data is sent back to a central
server in central office and put into digital record at that time. Requests for
documentation from an organization of this type would go to a location indicated
when the NPI holder registered.
Authentication
- A username and password combination alone is not a sufficient 2-factor authentication.
Additionally, 2-factor authentication also requires two different types of authentication
methods. In NIST SP 800-63-1, the term “multi-stage” is used rather than “multi-factor.” A
certificate itself can be the second factor.
- An operational consideration to note is whether re-authentication is necessary every time
an EHR is accessed, or if doing it only once per session is allowed. (This is addressed
somewhere in NIST SP 800-63-1.)
- One-time keys are used in practice—passwords can be generated from both software
and hardware sources.
- The signature event could be a biometric, however if you’ve signed onto a system using a
biometric instead of username and password, you can’t then use the biometric again to
sign.
- The Methods section of slide 19 was rewritten:
1. “Two factor to access the software token:
a) Password
b) One time key
c) Hard token
d) Biometric
 Do you need to access software token once per session or with each
use?”
Action Items
Name
Bob
Bob
Task
Begin to work on a diagram illustrating the theoretical levels
and workflow for encryption.
Review NIST SP 800-63-1’s standards for re-authentication.
Due Date
10/16/12
10/16/12