Wednesday, December 17, 2014

Digital Signatures on FHIR

Within the FHIR community there has been many disconnected discussion on Digital Signatures. These discussions have made it formally an action item for the Security WG to come up with a better guidance than exists today. This discussion has also come up with a listing of the problems that FHIR presents, an incomplete listing. This discussion has come up with a few solutions, but none that work for everything.

Document Signatures

With Document Signatures, we have a completely self-describing blob that we hash, and that hash is included in a Digital Signature block. This signature block can be managed in at least three distinct ways:

  • Detached – Signature block is managed as an independent document from the document(s) it signs Possibly using a Document Sharing system like XDS which also has ‘association’ linkages that can identify the signature relationship between signed document and the signature document.
  • Enveloping – Signature block is managed as a document that contains the document that it signs. The signed document is ‘enveloped’ inside of the signature block. This ‘new’ object can be managed and communicated in many ways. The signed document and the signature are bound together through this containment. However to access the signed document, one must be able to take the signature envelop off of the document.
  • Enveloped – The Signature block is inserted inside of the signed document. This means the signed document must have a defined place to hold the signature block, and the signature must exclude this place. The signed document and signature are bound together through this form of containment. However to access the signature block, for validating the signature, one must have the ability to extract the signature prior to sending it to a standards based signature verification algorithm.
I will say more about this in the future, as IHE has just approved a new version of the IHE Digital Signature (DSG) profile for “Public Comment”.

FHIR are Resources

FHIR could use the above mechanisms, but the dynamic nature of FHIR causes many problems.

FHIR Resources can and will be made into Documents

First the good news: If one were to create a “Document” using FHIR, rather than CDA, it would (should/shall) have the same characteristics of a “Document” and thus be self-describing blob.

Resource fixup breaks Signatures

But most of the time with FHIR, the expectation is that the Document or any set of Resources will be decomposed and managed independently. Thus we don’t have a “Document” for long, we have a set of Resources that are ‘fixed up’ by the server. We have a set of Resources that are moved around, and thus more ‘fixup’ happens. The first problem that FHIR presents is this concept of ‘fixup’. What I mean by ‘fixup’ is this: Any FHIR Resource that contains pointers, either Reference or URI or Attachment or other; these pointers might need to be adjusted by any system that is going to persist or further process. An example is that sometimes a bundle will be created that contains all the necessary Reference resources, all pointed to through relative-URI. The recipient will break these resources out of the Bundle and as it stores them it will create a absolute-URI and thus adjust the uses of the previous relative-URI to the new absolute-URI. This is a specific example of ‘fixup’. There are others elements of a Resource that might need to be adjusted by a recipient. These ‘fixup’ are expected, and normal. They should not be changing the meaning originally intended. A digital-signature would see this as a change and thus flag the change as breaking the signature. If the change is expected and normal; then the signature needs to ignore these changes. However the signer does also need to make sure that the ‘fixup’ was done accurately.

An interesting, and simple, solution to one deployment scenario goes like this: For a client that wants to create a signature across a Resource that it is going to publish, it could manage the ‘fixup’ problem using the following method: From the perspective of a FHIR client

  1. The client creates a new instance of some resource(X) 
  2. The client Posts X onto server Y
  3. The HTTP Response indicate successfully created, returning the URL to X’
  4. The client retrieves that instance X’ from the server Y resulting in a local copy of X’
  5. The client confirms that the essence of what is intended to be recorded has been recorded. Thus allowing the server to do things like fixing up references.
  6. The client then calculates the signature S across that X’
  7. The client then creates a Provenance resource P pointing at X’, with the signature calculated S.
  8. The client could then retrieve the Provenance instance P’ and validate X’ and included S’ with the current X”

This does not address all problems. It does address one of the ‘fixup’ problems, the first server need to ‘fixup’ the resource. It doesn’t address cases where that server further needs to forward a copy of the Resource to a system that can’t access the server, as that introduces a new fixup problem. But it is an elegant solution to one of the problems we are presented with. And this just might be the highest important problem to solve.

I think the above interaction would work for a Bundle of Resources too. Just more involved.

Transforms break Signatures

Next problem that FHIR brings in is the ease with which it transforms a Resource from JSON to XML and back. There is new work going on in HL7 to now bring in a third form of RDF. And many applications will use JAVA, and thus only see the resource in the JAVA form. There is great effort in FHIR, enforced by the publication tooling, that these translations are lossless. But from a digital-signature perspective they are all different. Digital-signatures operate on the binary level, not the semantic level. When one actor signs some Resource, they can’t know (or dictate) that all users of that Resource use the same transform. The publisher might use XML, the reader might only be able to read using RDF. 

A proposed solution for this is to force the Signer to include in the Signature a signature block for all possible transforms. The drawback of this is that the Signer likely can't validate each of those transforms as valid.

Another proposed solution is for the Verifier -- the one using content and wanting to get proof that the content has been signed -- be forced to be able to use ALL transforms, thus verify the transform that was signed. There would be trust-in-the-server that it transforms all other versions reliability.

More issues and solutions to come

Surely there will be more. I encourage comments on my blog, but I also encourage participation in FHIR efforts. The FHIR efforts are being cataloged on the HL7 Wiki at 

Friday, November 28, 2014

Fwd: Call for Participation; #MHD - #XDS on #FHIR

The MHD profile, which is most quickly described as XDS on FHIR, is getting revised this winter. I have been working with a small group of IHE members to align the original MHD concept with the Resources that I worked with Grahame to model in FHIR, soon to be controlled by a joint IHE-HL7 workgroup. Since this profile is not following the normal IHE lifecycle, it is not ready for formal testing at IHE-Connectathon. But we want to do some testing at IHE-Connectathon, so we are going to use what IHE calls "New Directions". The new MHD pairs nicely with PDQm and IUA.

Note I removed the webinar details from this post, but they are available upon request.

As you are no doubt aware, there is a great deal of industry buzz around the application of RESTful technologies and FHIR Resources to IHE profiles. MHD is a profile that is considered a prime candidate, and according to the interest received to date, is likely to garner a high level of adoption.

We are contacting you as a potential participant in an exciting opportunity to collaborate on the testing & development of the new Mobile Access to Health Documents (MHD) IHE profile, utilizing HL7's emerging FHIR® standard. "XDS on FHIR" is one of several innovation projects comprising the New Directions program during the IHE North American Connectathon being held in Cleveland OH, January 26-30, 2015.

Be part of a handful of selected vendors that realize the potential of being an active contributor and an early adopter. Here is your opportunity to get the jump on your competitors and get in the game!

You are invited to join program sponsors IHE USA, HIMSS, NIST and HealtheWay in a webinar that will explain the "MHD on FHIR" opportunity in January, and what is required in order for your company to participate. We have prepared a slide deck for the webinar, which is attached for your advance perusal.

Please join us for the webinar on Tuesday, December 02, 2014 @ 12:00 Noon – 1:00 PM, CST (Central Standard Time). This webinar will be recorded .
The plan at a glance:
  • Testing of MHD on FHIR in New Directions will take place for 2 days only, on Wed January 28 10am-5pm and Thurs Jan 29 9am-noon during the IHE North American Connectathon week of January 26-30, 2015. The event will be held at the Cleveland Convention Center and HIMSS Innovation Center, 1 St. Clair Ave NE, Cleveland OH 44114.
  • Participants will be testing submission of documents using FHIR technology, as defined for IHE's MHD profile. Participants will be testing with a tool developed by NIST as well as with each other peer-to-peer.
  • A candidate for participation is a developer for a company that has successfully tested an XDS Document Registry, Document Repository, and/or Document Source actor at a North American or European Connectathon within the past 3 years. We would expect the participant to bring an implementation of an MHD Source to make a Document Submission, and/or an MHD Recipient to receive a Document Submission.
  • Prior to face-to-face testing on Jan 28-29, participants will be expected to participate in periodic calls to stay apprised of developments in the MHD specification and to test with the NIST tools as they are released.

Thursday, November 13, 2014

IHE ITI Plan for 2015

The IHE ITI slate for 2015 has just been agreed to. This is a balancing act between the Planning Committee that evaluates the need and desire for the item to be Profiled by IHE; against the Technical Committee that evaluates the technical feasibility of creating the Profile in a way that will be used. The Technical committee thus evaluates if there are standards available to be profiled, as IHE really should not invent a standard. The Technical committee evaluates how mature those standards are, where standards like FHIR are considered risky but usable. The Technical Committee also must worry about availability of expertise to complete and review the work.

The Planning committee asked for 10 items to be worked on, which is simply too many things to work on. So we looked at how we could change-the-scope, or move ‘when’ the item is worked on. We laid out the work items into a calendar to make sure we were not working on too many items at any one time. Preferably no more than five work items at any point in time.

This is not intended to be a formal chart, it was just used to help us balance the workload. The color is not that important, although it does make it an eye-popping chart. The intensity of the color, or lack of intensity is an indicator of low load by that work item at that month. The number is the number of phone meetings on the topic.

This shows that we are expecting to complete early, for a January Public Comment phase, the MHD, DSG, and XDW-XCA work item. While also delaying start on a De-Identification project and a Documentation cleanup project.

Introduction to Work Items:

  1. RESTful ATNA – This work item proposes to provide a way that a reporting application can query into an ATNA repository for various use-cases. Likely to use the FHIR SecurityEvent resource, but there is a desire to expand beyond those specific types of logged events.
  2. Alerts targeted at Humans – This work item proposes to create a way to send alert messages (Not life critical) to one or more recipient. It is a very scaled down proposal that will start a family of solutions. First up is to determine what our scope actually will be.
  3. RESTful PIX – This work item proposes to provide a query into a PIX Manager for a cross-reference. This is just the query transaction from the PIX profile, but using FHIR. This will likely be based on FHIR Patient, and be similar to PDQm.
  4. MHD-2 – This is the version 2 of MHD. The goal is to get this out to Public Comment in January so that the USA IHE Connectathon can do some limited and targeted testing, under “New Directions”.
  5. DE-ID (for Family Planning) – This work item starts with a QRPH profile on Family Planning, and create a De-Identification profile that shows how the data could be de-identified for specific purposes. This will be the first formal use of the De-Identification handbook.
  6. DSG – This is a project I started last year to update the Document-Digital-Signature profile to the current IHE documentation template, and possibly improve it. Not intended to take on major new use-cases, but some.
  7. Re-Documentation – This is an effort similar to the Volume 3 cleanup we have done, but this time focused on fixing up Volume 2. The intention to make the XD* transactions more readable, and harmonize the wording. No intention to change any technical detail.
  8. XDW-XCA – This is an item started a few years ago to extend XDW capability beyond one XDS domain. The proposal creates two new supplements to do this support.
  9. German/French National Extensions – Both Germany and France have provided national extensions to the PAM profile. These need to be managed and ultimately published in Volume 4.
  10. Change Proposals – There is always change proposals to work…

Wednesday, October 22, 2014

CDA Digital Signatures inside

HL7 has been working on an Implementation guide that explains how one would use a Digital Signature inside of a CDA document. This is an implementation of XML-Signature in Enveloped form. 
This has completed a round of ballot and now enters 24 months of DSTU. 
  • Signature, Enveloped -- The signature is over the XML content that contains the signature as an element. The content provides the root XML document element. Obviously, enveloped signatures must take care not to include their own value in the calculation of the SignatureValue.
Note, I can't find the current DSTU version of the text... When I find it I will provide a link.
The HL7 CDA Digital Signature Implementation Guide shows a model where the Digital Signature is treated as a blob that is then inserted into the CDA document. This means that it is restricted to only signing CDA documents. The advantage that this CDA internalized digital signature is that it is carried inside the CDA document throughout any transport that conveys the CDA document.

DSTU Publication Approvals  
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1 for Structured Documents WG of SSD SD at Project Insight 1005 and TSC Tracker 3639 requested DSTU publication for 24 months. The Digital Signature and Delegation of Rights Implementation Guides provide a standardized method of applying Digital Signatures to CDA documents.  The standard provides for multiple signers, signer’s declaration of their role, declaration of purpose of the signature, long-term validation of the Digital Signatures and data validation of the signed content.
This Digital Signature is not a conflict with the IHE-DSG profile, but rather a different model. IHE-DSG profile is a standalone Digital-Signature that references a standalone document of any type. So the IHE-DSG profile can sign a CDA document, but can just as well sign a PDF or any other format of document. The limitation that the IHE-DSG profile has is that it can only sign by reference. This model has been extensively discussed in IHE and on my blog. See IHE-DSG profile,

IHE Does have a proposal that I am working on to add XML-Signature Enveloping.
In this case there would be one document that is an XML-Signature document, with the signed content inside of the document. In this way the content is carried inside the signature. The opposite of the CDA Enveloped DSTU. This method can Envelope ANY type of document, it is not restricted to CDA documents. It is also, like the CDA Enveloped DSTU, completely independent of Transport.
  • Signature, Enveloping - The signature is over content found within an Object element of the signature itself. The Object (or its content) is identified via a Reference (via a URI fragment identifier or transform).
Signature - Digital, Electronic

Tuesday, October 14, 2014

FW: IHE IT Infrastructure "MHD" Technical Framework Supplement Published

IHE has updated the MHD profile. This is an administrative formality that should have been done almost 3 months ago. The text published is updated Volume 1, and totally erased volume 2. This removal of the Volume 2 text is a notice to developers that IHE is currently re-developing the technical profile. This technical work has been in progress for many months now, moving very slowly because of day-job and summer vacations by everyone who is helping.
The current status of the updating of MHD can be found on the IHE "MHD Status" page.

Associated with this is a formal “Hackathon” at the IHE-Connectathon where developers will be encouraged to work on MHD implementations. This is not called a Hackathon, but rather "New Directions". The goal is to improve and mature the MHD profile. The MHD profile is not well enough matured to be formally tested at IHE-Connectathon.


IHE IT Infrastructure Technical Framework Supplement Published for Trial Implementation

The IHE IT Infrastructure Technical Committee has published the following supplement to the IHE IT Infrastructure Technical Framework for trial implementation as of October 14, 2014:
  • Mobile access to Health Documents (MHD)
This profile may be available for testing at subsequent IHE Connectathons. The document is available for download at Comments on all documents are invited at any time and can be submitted at

Wednesday, August 27, 2014

Healthcare Patient Consent -- Lessons learned from Creative Commons

I have learned lately that Creative Commons is working on some specific applications of Patient Consent. There are not much details on what they intend to target or create. The only details I can find are at “CC Science - Sharing V. Privacy”.

There are two very cool things. They recognize Security-Tags, and have a good process that will help us.


The first one is that they refer to “Data-Tagging”, which is general IT discussion toward a solution. This is very similar to the “Healthcare Privacy & Security Classification System” that we have defined and created profiles for – One example is the DS4P. This concept of Security-Tags has been integrated into XDS (XCA, XDM, XDR), and also into HL7 FHIR. This is a useful vector for the purpose of enforcing Access Controls including Privacy aspects.

This is, as Creative Commons indicates, not sufficient.

Consent Language Communications:

The more cool thing is the concept of applying the methodology that Creative Commons have done for Copyright/License to Privacy Consent.  They have created a reasonable set of Licenses that can be used in a very useful and actionable way. For example, my blog is published under the
"Attribution-NonCommercial-ShareAlike 3.0 Unported" License. Which is understandable by many means of reading and processing.

With Patient Consent, we struggle with a similar problem to the Copyright/License problem that Creative Commons initially addressed. The language that organizations want to use is written once, by them, for their purposes; thus the language at each organization must be read and understood. Most of the time the language is in legal terms and thus not very consumable by non-lawyers, and also not consumable by computers. The result of this confusion is that the humans involved are not well informed. Also true is the failure in the computers that should be protecting the data, which includes providing access to those that are authorized.

Creative Commons have come up with a very useful “Design and Rational” that creates three layers that are very useful with Patient Consent.. There is the “Legal Code” that includes the legal specifics. There is the Human Readable, which is specialized for normal humans to read, possibly translated into multiple languages and such. There is a Machine Readable form, that is structured and coded.

I will note that the current Machine Readable form is very much like what we did with IHE-BPPC; that is it is most of the time simply an established URL per policy. Thus all that is necessary for the computer to know which license is applicable is to see which of the Creative Commons URLs are applied. The main difference is that they host and thus create the machine readable URLs. Whereas with IHE-BPPC the creation and publication is a ‘local matter’. Creative Commons "REL" is a similar container as the CDA structure defined by IHE-BPPC, or the potential future HL7 FHIR ConsentDirective could be..

As applied to Healthcare Privacy Consent:

So, the result of Creative Commons effort might be a set of boilerplate Privacy Consent policies. The equivalent of what I have referred to as Opt-IN, Opt-OUT, OPT-OUT-breakGlass, etc.
Using the Creative Commons methodology this would result in a set for each of these: Legal Code, Human Readable, and computable URL.

This is not an easy thing to write. I have been involved in many workgroups that have worked on these. In each case a number of people, mostly lawyers, wanted to have special wording in for their special cases. I presume that Creative Commons has mechanisms to work through these differences.

We might even get some cool icons like they have for the License, where the icons visually represent the essence of the language.

Patient Friendly Interview Process:

Going one step further, Creative Commons have created an interview process for people that want to apply a Creative Commons License to their works.
The interview process walks the person through a set of decision points. This results in a recommended CC Mark.

This today is not all that 'friendly' and the population that are Patients (healthcare consumers) likely need far more 'friendly' interfaces. However the concept is similar in that one tends to narrow the choices over time.

There are a few pilots that have attempted this, including one from HHS/ONC that resulted in some very interesting observations.


I have said all the above before, in 2009,  Consumer Preferences and the Consumer.  The difference is that Creative Commons might bring their methodology and thus some maturity to the conversation.

Blog resources: Patient Privacy controls (aka Consent, Authorization, Data Segmentation)

Tuesday, August 19, 2014

Performance vs Privacy

Sadly this week we hear about a HUGE breach of Patient Identities. This did NOT NEED TO HAPPEN!!!

What happened? Community Health Systems (CHS) pulls ALL identities from their partners so as to do patient cross-reference matching. This results in a Centralized Identity Knowledge database, that was not protected well enough. There are better deployment architectures that I will explain.
200 Hospitals Hit Affecting 4.5 Million Patients (August 18, 2014) Tennessee-based
CNN Money 
Community Health Systems (CHS) says that intruders accessed its system over a three-month period earlier this year, compromising patient names, addresses, and Social Security numbers
(SSNs) of 4.5 million people. The company maintains that medical and financial information was not affected. CHS operates more than 200 hospitals in 29 US states. The company claims that the attacks emanated from China. Information in CHS's Securities and Exchange Commission

There are two models of patient record locator service (RLS). That is, how do I learn of all the locations that have patient data for the specific patient I am interested in. This is more important today where patients have had many home cities, patients travel on business and pleasure, and specialty healthcare practices are easy to get specialist care. The two models of location discovery are very different and carry very different Privacy impacts.

Federated Identity Knowledge Discovery:

If Privacy was most important, a Federated Identity Knowledge Discovery model would be used. This is the model that IHE has defined for Cross-Community Access exchanges (XCA). The Cross-Community Access (XCA) is the model defined for federating multiple regional exchanges. The XCA model defines the XCPD Profile, as explained by Karen earlier in my blog.

That is a model where one discovers the locations that have data on a given patient when you need to know. This model does not try to pre-coordinate patient identities as the identities are created and updated. This model, when the patient is seeking care, asks everyone if they know of the specified patient. As such this model does mean the answer might take a long time to come back, and might be missing some locations that didn't respond in time or didn't have enough data to make an exact match.

The failure to match due to not enough information isn't unique to this model, but this model does make these failures more likely as the match does need to be made quickly.

The failures to match can also be detected as the patient can indicate the various locations they know of, and if the results seems to be missing those locations more refined query can be done. In this case the refinement would be based on the patient knowledge of how they were known at the time they were cared for in that location.

The bigger problem with Federated Identity Knowledge Discovery is that the response time is potentially many minutes long, and really is not deterministic as to when one has all the responses from everyone.

Centralized Identity Knowledge

The second model is to centralize all knowledge about the patient. This is the model that IHE has defined for use with in an XDS Health Information Exchange. The solution that IHE defines for a regional exchange. Note that not all regional exchanges should use XDS, one can actually make a federation exchange using XCA within a region. So you could use the above model. However within a region one often has many instances of the Patient visiting multiple sites within that region. So the benefits of Centralized Identity Knowledge might be worth the risk.

The Centralized Identity Knowledge model leverages HL7 “ADT” – Admit, Discharge, Transfer. Which is actually more than just those three verbs. In the Centralized Identity Knowledge model we use the IHE Profiles of PIX and PDQ. In these models whenever a new patient identity is created somewhere, knowledge of that patient identity is forwarded to some central authority. Similar when that patient is registered at a site, discharged, transferred. Similar when mistakes in the identity are corrected, including Merge or Link events. All of these actions on the Patient Identity are forwarded to the central authority. This central authority is receiving identity information from ALL of the sites participating in the Health Information Exchange, and will do a match of identity as it receives the identity knowledge.

This model, can also involve humans when the matching algorithm detects a potential match. The human can do some research and fix the match as needed. So this model is often seen as more accurate. Less prone to False-Positive and False-Negative matches.

One advantage of this is that it is easy for hospitals to simply copy their ADT feed and send it to the Centralized Identity Knowledge store. The hard processing is centralized.

The biggest advantage of the Centralized Identity Knowledge is that the “Cross-Reference” is known well in advance of someone needing to know. So a Patient Record Location Service call is very quick and deterministic. This model is best when Performance is most important. We hear much about how unlikely Doctors are to wait a few seconds.

The Privacy disadvantage is that ALL patients are known in a centralized database. This is regardless of if the information is needed ever. Think about a patient that never has moved, always sees the same doctor, never needs the HIE service. Thus a breach of this database breaches ALL Centralized Identity Knowledge.

On the positive side, the Centralized Identity Knowledge is just identities, no medical information is needed in this database. However that is not to say it doesn't also get centralized.

Patient Centric

There is another model, and that is that the Patient mediates all information flow. This is the model where the patient is the only one that knows who all have interacted with them. This is where the patient provides all the information. This is also the model where the system totally fails if the patient is in an emergency situation. The patient can also better hide information they don’t want to share, which is a privacy benefit, but a potential risk to patient safety and quality of care.


I hear of new exchanges being put together that choose to use the Centralized Identity Knowledge method. Their excuse is that it is faster, which it is. They also point out that it is easier to get quality results, which is somewhat true. 

Privacy Matters. It is important to consider Privacy and Security up front. They are way too often left to an after-thought. It is when they are left to an after-thought that they become burdensome and are seen as nothing but trouble. When one considers Privacy and Security up front, they can be enablers of workflows and most importantly things that make the Patient happy. 

Is waiting a bit longer for a query to happen, followed with a discussion with the patient really that hard for Healthcare Provider -- Professionals?

Nationwide Health Exchange (HealtheWay).

I will note that the Federated Identity Knowledge Discovery is the model that is used by the NwHIN-Exchange, now known as HealtheWay. Thus this breach did NOT come from here, and couldn't.

Updated August 21 -- added an introduction, graphic from CNN Money, and more links to articles.

Tuesday, August 5, 2014

IHE Digital Signature Profile - updated -- Need COMMENTS

The IHE Digital Signature (DSG) profile has been updated. Well it is out for Public Comment through the IHE Change Proposal system -- Ballot 24 -- as Change Proposal 412.

IF YOU ARE AN IHE MEMBER, PLEASE COMMENT!!!! We need constructive comments on this proposal. It was not intended to be a breaking change, but reality is that there is no unified understanding of what the old DSG supplement was defining. The old DSG supplement must be considered fundamentally broken. So this CP must be considered a breaking change.

The goal of Change Proposal 412 is four very important things, none of them are related to failures of the original.
  • The original supplement was written before IHE had a concept of a Content Profile, so it was never written this way. Now that we have a concept, we can write it in a way that is more readable. There was also some loose-ends related to the now deprecated NAV profile.
  • The current supplement template has some other formatting requirements. Actually we also needed to do proper section number reservation and management. So many simple 'editorial' needs.
  • The original only supported a Detached signature, where the content was managed in an XD* environment and the linkage to the signature was done by the XDS Association type "SIGN". This is still needed but we also need an Encapsulating signature that can be used where no XD* is available to hold the things together, so encapsulating signature is an outer envelop of the Digital Signature that holds the signed document inside.
  • The digital signature standard has been updated and now includes everything we needed. So we now specify XAdES-L-T, which brings inside the certificate and a timestamp; and we utilize the CommitmentTypeIndication for Purpose Of Signature. Thus we just bind in a vocabulary specific to Healthcare needs.
  • We did not include the new CDA digital signature. This is not because it isn't useful or interesting, but more because that would have been a very different technology. Those that want this profiled by IHE, should bring a New Work Item Proposal to profile it.

I have had this Change Proposal on my plate since I wrote that it was needed back in 2009. It didn't happen because there simply was not enough use of Digital Signatures in healthcare. However now there is more interest, driven by some Anti-Fraud use-cases.

The main problem with Digital Signatures is NOT the standards, it is the Policies and overhead in issuing proper Digital Identity (PKI). Once there are Digital Certificates issued for the purpose of Digital Signatures, then there are many use-cases that can be enabled. However that first justification of the costs is very hard to do, and somehow combining justifications just never seems to happen.

Review the proposed new supplement as Change Proposal 412.

The changes to the IHE DSG profile are significant should be considered a breaking-change from the original DSG supplement published in 2009. The DSG supplement has remained in “Trial Implementation” since 2009. Breaking changes during “Trial Implementation” are proper and should be expected.
The Document Digital Signature (DSG) profile is a Document Content profile that provides general purpose methods of digitally signing of documents for communication and persistence. This method can be used within a Document Sharing infrastructure (e.g., XDS, XCA, XDM, XDR, and MHD). There are three methods of digital signature provided: Encapsulating (An encapsulating signature is a signature approach that encapsulates the signed content within the signature syntax.), and Detached (manifest).

Electronic documents are being increasingly relied upon in healthcare. Signatures have been a part of the electronic documentation process in health care and have traditionally been indicators of accountability.  Reliable exchange of data between disparate systems requires a standard that implements non-repudiation to prevent document creators from denying authorship and rejecting responsibility.

This second revision of the DSG supplement addresses the following:
  • Puts the profile into the current supplement template
  • Puts the profile into the current Document Content format
  • Adds Encapsulating signature, which is especially useful when Document Sharing are not used. For example: RFD based output.
  • Update the signature standards: XaDES specifically that now includes profiles for Long-Term signatures

Other Digital Signature Blog Posts