Monday, June 26, 2017

GDPR Privacy about more than just confidentiality

Rene Spronk published an excellent and very detailed article on a unique perspective drawn from the new General Data Protection Regulation (GDPR) -- aka: European Privacy Regulation. That it requires that Patients be given access to data about themselves, in a standardized, and usable form. Thus the regulation makes Interoperability Standards a requirement. Please see his article: Impact of GDPR on the use of Interoperability Standards

This perspective is driven by Privacy Principles, which are more than just Confidentiality.

The GDPR also requires that any Consent given must be understood by the subject regardless of their age, education, or human language issues. Thus any organization gathering data must provide various forms of their consent language that can be proven to be understood by that patient. The FHIR Consent supports this by having a place to record the actual text presented to the patient. Clearly deriving that text originally is not a FHIR issue. It is a very difficult task, and I feel for small organizations. Similar capability to record the actual text presented to the patient is also available in IHE BPPC which supports APPC for this purpose.

As with any Privacy regulation one must have good Provenance proof of where all data came from, including when it was imported from the Patient themselves. One must also have good AuditEvent records to show where and why the data was used.

See my Privacy Consent topic table of contents
And my FHIR topic table of contents

Tuesday, June 20, 2017

Human Names - remedial testing

Humans around the world have very difficult to deal with names. But even the most simplistic names can be problematic. Here is a specific case I have run into lately. We have had a problem where a person had a apostrophe in their name, and it caused failures. This because in the API (string based API), a person name is quoted using single quote... yet if it includes a quote, that terminates the string early... oops.

So I poked around, and don't find a test bench that does much of a good job at testing string elements that are intended to be human names. I did find a fantastic QA article from W3C. But I would consider what they have outlined as "advanced". 

Remedial would be a far more basic set... The closest I find is the definition in LDAP. That definition for PrintableString.

      PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
                           PLUS / COMMA / HYPHEN / DOT / EQUALS /
                           SLASH / COLON / QUESTION / SPACE
      PrintableString    = 1*PrintableCharacter
      IA5String          = *(%x00-7F)
      SLASH              = %x2F  ; forward slash ("/")
      COLON              = %x3A  ; colon (":")
      QUESTION           = %x3F  ; question mark ("?")

   <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in

PrintableString has a few characters in it that are uncommon in a human name (never say never). But it does clearly indicate the 7-bit ASCII alpha, number, hyphen, space, period, and apostrophe. This set would work fine for many countries, okay it would only work for USA... But that is why I call it remedial.

      RemedialCharacter = ALPHA / DIGIT / SQUOTE / HYPHEN / DOT / SPACE
      RemedialName    = 1*RemedialCharacter

Beyond this one mostly needs all the alpha from unicode...See the W3C QA specification. but I haven't quite figured that one out.

Mostly, I am thinking that for Provider Directory, and Patient Directory.... that testing should have test script that test for this remedial, and optionally for the full unicode...  And, they need to deal with searching, and sorting... topics well beyond advanced, but very very important.

Again... I don't think remedial is enough, but if one can't get past remedial they are clearly not ready for real person names

Friday, May 26, 2017

Privacy toolkit - W3C Privacy Assessment

This is a short article simply to point toward W3C "Specification Privacy Assessment". I watch many standards bodies, and interact with a few. W3C is most mature "Standards" organization with regards to considering privacy impact that their standards have. Others are working toward having some process for considering privacy while writing a standard specification. But the others are more aspirational, where W3C is 'doing it'.

The best introduction is a presentation. This is fantastic presentation, very detailed. I would love to present these slides as there is so much depth on each page.

They have a set of Questions that each W3C specification writing team must consider. These questions are not intended to short-circuit a real Privacy Impact, but rather to focus on some of the obvious top issues. Here is an excerpt:
  • can the information be used (alone or in combination with other APIs / sources of information) to fingerprint a device or user?
  • may I access to the information I created?
  • may I record it myself (locally)?
  • am I able to have actions on this personal record?
  • may I block partly or totally the record of the information?
  • may I fake it? (think about fuzzy geolocation or voluntary fake location)
  • Is the data personally-derived, i.e. derived from the interaction of a single person, or their device or address? (If so, even if anonymous, it might be re-correlated)
  • Does the data record contain elements that would enable such re-correlation? (examples include an IP address, and so on)
  • What other data could this record be correlated with? (e.g. the ISP)
  • If you had large amounts of this data about one person, what conclusions would it enable you to draw? (e.g. maybe you could estimate location from many ambient light events by estimating latitude and longitude from the times of sunrise and sunset)
  • Am I likely to know if information is being collected?
  • How visible is its collection and or use?
  • Do I get feedback on the patterns that the information could reveal (at any instant, over time) so I can adjust behaviors?
  • if a background event about the device is fired in all browsing contexts, does it allow correlation of a user across contexts?
  • can code on a page send signals that can be received by device sensors on nearby devices?
You can see that W3C considers all of the Privacy Principles, not just confidentiality.

They also have defined some re-usable Privacy Considerations. Such as the "Web Applications Privacy Best Practices"
  • Best Practice 1: Follow "Privacy By Design" principles
  • Best Practice 2: Enable the user to make informed decisions about sharing their personal information with a service.
  • Best Practice 3: Enable the user to make decisions at the appropriate time with the correct contextual information.
  • Best Practice 4: When learning user privacy decisions and providing defaults, allow the user to easily view and change their previous decisions.
  • Best Practice 5: Focus on usability and avoid needless prompting.
  • Best Practice 6: Active consent should be freely given, for specific data, and be informed.
  • Best Practice 7: Be clear and transparent to users regarding potential privacy concerns.
  • Best Practice 8: Be clear as to whether information is needed on a one-time basis or is necessary for a period of time and for how long.
  • Best Practice 9: Request the minimum number of data items at the minimum level of detail needed to provide a service.
  • Best Practice 10: Retain the minimum amount of data at the minimum level of detail for the minimum amount of time needed. Consider potential misuses of retained data and possible countermeasures.
  • Best Practice 11: Maintain the confidentiality of user data in transmission, for example using HTTPS for transport rather than HTTP.
  • Best Practice 12: Maintain the confidentiality of user data in storage.
  • Best Practice 13: Control and log access to data.

The "Device API Privacy Considerations". Which includes a nice breakdown of the Privacy Principles to those that impact Device design.

The "Mobile Web Application Best Practices". Which not just itemizes a fantastic set of Best Practices (cookie use, client storage, robustness, informing user, avoid redirects, etc...). But goes into detail on these best practices
    3.1 Application Data 
    3.2 Security and privacy 
    3.5 User Experience 

see also my articles 

Friday, May 19, 2017

Clarification of Affinity Domains

The Question: I've worked with the XDS.b and XCA profiles for a few years now, but am no means an expert. I've never understood exactly what an affinity domain is. Could someone give an explanation of an affinity domain?

XDS Affinity Domain

Affinity Domain is more properly an "XDS Affinity Domain". The term is specific to XDS. It does not apply to XCA, as XCA uses the term "Community" in a rather similar but more expansive.

an XDS Affinity Domain -- derived from the word "affinity". Which among the many definitions has these -- These from Merriam-Webster definition for "affinity"
  • sympathy marked by community of interest : 
  • an attraction to or liking for something 
    • people with an affinity to darkness — Mark Twain 
    • pork and fennel have a natural affinity for each other — Abby Mandel
  • an attractive force between substances or particles that causes them to enter into and remain in chemical combination
  • a person especially of the opposite sex having a particular attraction for one
In the IHE Glossary
  • A group of healthcare enterprises that have agreed to work together using a common set of policies and which share a common infrastructure of repositories and a registry.
Essentially it is a term we use in XDS to encompass all the actors, systems, technology, policy, procedure, people, and ether. A set of XDS Metadata codes that the Registry will enforce. A set of document types that are considered acceptable by the Affinity Domain. Agreement on how Authorization will be done, including Consent, Role-Based-Access-Control, and Break-Glass.

See section 10.4.8 of volume 1 "Concept of an XDS Affinity Domain"

An XDS Affinity Domain is an administrative structure made of a well-defined set of Document Source Actors, set of Document Repositories, set of Document Consumers organized around a single Document Registry Actor that have agreed to share clinical documents.

Note: Document Sources, Repositories and Consumers may belong to more than one XDS Affinity Domain and share the same or different documents. This is an implementation strategy and will not be further described.

Note: The XDS Profile does not support the federation of XDS Affinity Domains directly, but the Cross-Community Access (XCA) Profile addresses the cooperation of multiple Document Registry Actors serving different XDS Affinity Domains.

A number of policies will need to be established in an XDS Affinity Domain in order to ensure effective interoperability between Document Sources and Consumers. Some of the key technical policies include (A more extensive list of policy agreements that need to be made by XDS Affinity Domains is discussed in ITI TF-1: Appendix L):

1. The document formats that will be accepted for registration

2. The various vocabulary value sets and coding schemes to be used for the submission of metadata of document, submission set and folders registration.

3. The Patient Identification Domain (Assigning Authority) used by the Document Registry.

See ITI TF-1: Appendix K for a detailed discussion of the concepts of XDS Affinity Domain.

For which the Handbook on XDS Affinity Domain planning is important.

XCA Community

The difference between "XDS Affinity Domain" and the XCA "Community" is that IHE has much less to say about the requirements of a Community. There are cases where a Community is an XDS Affinity Domain; but XCA allows for many other forms of Community. Common variant of a Community is a large hospital system (like the VA where I now work). In those cases the Community is understood only as the stuff behind the XCA gateways. There is no mandate about code validation by a Registry, no mandate about use of ATNA, no mandate about use of CT, etc. There is no defined way to create registry entries. There is no requirement to support folders, associations, and extensions.

The additional difference is that a Community can contain other Communities. IHE is rather silent on this. This silence was driven more by the desire to get experience with nested communities, routing communities, proxy communities, etc. We have heard of some interest in resolving this, and I would encourage a new work item.

In the IHE Glossary
  • A community is defined as a group of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing health information via an established mechanism. Membership of a facility/enterprise in one community does not preclude it from being a member in another community

Some more background articles

Thursday, May 18, 2017

Consent to deny Sharing for Treatment and Emergency Break-Glass

We have discussed in years past that Australia had a Privacy Consent where break-glass was not allowed. We understand that has changed to allow break-glass. Thus we didn't know of a case where a Consent forbid break-glass... I have been made aware of Utah HIE that has a checkbox on their Consent to forbid break-glass. This is a consent only for HIE, not for within a hospital environment; but it is relevant to our FHIR consent (and CDA consent) work. Thus I think it is useful for us to provide it as an example, and work through how it might be expressed.

The Utah HIE Consent Form is

Note, that in the context of a FHIR consent; this URL could be used as the Policy URI...  It is a general form that the Patient has some check boxes they can choose.

So given that we have an example that forbids Treatment but allows Break-Glass  (Note spell check needed)

We should likely create an example that forbids both Treatment and Emergency (Break-Glass). Something like this:

<Consent xmlns="">  <id value="consent-example-No-Emergency"/> 
<status value="generated"/>
<div xmlns="">
<p>   Withhold Authorization for Treatment and for Emergency Treatment  </p> <p>     
Patient &quot;P. van de Heuvel&quot; wishes to have no data shared for Treatment or Emergency treatment use.   
An overall consent Directive, with an exception 
&quot;Deny&quot; of purposeOfUse &quot;TREAT&quot; sharing use and
&quot;Deny&quot; of purposeOfUse &quot;ETREAT&quot; sharing use
at &quot;Infoway&quot; HIE.   </p>
<status value="active"/>
   <system value=""/>
<code value="57016-8"/>
<display value="Privacy policy acknowledgement Document"/>
<reference value="Patient/f001"/>
<display value="P. van de Heuvel"/>
<dateTime value="2017-05-08"/>
<!--   not bound by a timeframe - Consent.period   -->
<!--   I assume the example given is Canada Infoway wide???  AND I assume it is desired to   state that in the Consent.authority element   -->
<reference value="Organization/Infoway"/>
<display value="Canada Infoway"/>
<!--   the text terms of the consent in lawyer speak   -->
<title value="The terms of the consent in lawyer speak."/>
<!--   likely use url pointer to common text   -->
<!--       this is opt-out - e.g. nothing approved unless otherwise stated.    -->
<policyRule value=""/> 
<!-- this policyRule is a multiple use policy. The Patient has expressed       both deny Treatment and deny Emergency  -->
<type value="deny"/>
<system value=""/>
<code value="TREAT"/>
<type value="deny"/>
<system value=""/>
<code value="ETREAT"/>
I have filed a FHIR Change Request 13420

Other Privacy Consent topics 

Corrected the example to make more clear it is a "Privacy Consent" by specifying the Consent.category.

Wednesday, May 17, 2017

Two new IHE Profiles on #FHIR - Provider Directory and File Management

Public Comment opens for Provider Directory and File Manager --- both using FHIR STU3

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment

The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for public comment in the period from May 17 through June 16, 2017:
  • Mobile Care Services Discovery (mCSD)
  • Non-patient File Sharing (NPFS)
The documents are available for download at Comments submitted by June 16, 2017 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation version of the supplements. Comments can be submitted at IT Infrastructure Public Comments.

Wednesday, May 10, 2017

FHIR OAuth scope proposal using FHIR query parameters

In FHIR STU3 there are now some common query parameters. I propose that these common query parameters can be used to advance the OAuth scopes that are defined today. The current SMART scopes are based on simple vectors:

  1. Patient vs 'user' -- 
    1. Where a scope of 'patient' means all results must be from that one patient
    2. Where scope of 'user' means all results are relative to that user rights to data
  2. fhir-resource --
    1. Where a FHIR Resource named will limit results to only that Resource type
    2. This is a valueset of fixed strings (e.g. "Observation", etc)
  3. REST operation

Expressed in EBNF notation, the clinical scope syntax is:

clinical-scope ::= ( 'patient' | 'user' ) '/' ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' )

To understand the current OAuth scope see a few other articles:
So, if the OAuth authority authorizes the user to access the patient requested, as defined in the launch context, for only Observations, and only read operations. This would be a scope of
A problem with this is that the actual identifier of the "Patient" is undefined. For SMART this is handled by the 'launch context'.

Propose using common "patient" query parameter for patient scope

With the new FHIR STU3 common shared query parameters, we could identify the specific patient within the Scope. There is a common query parameter for "patient" against 35 different Resources. This has an advantage to be specific, but has a disadvantage that the scopes are not made up of static strings. I would like to suggest that this use of shared query parameters would be a replacement form the first part of the SMART scopes.

So, rather than relying on the SMART launch context to hold the patient identifier. The example with a patient of 'http://myserver.example/fhir/Patient/f5c7395'

or, we could add it to the end.  I think this more powerful."http://myserver.example/fhir/Patient/f5c7395"
Which is 

clinical-scope ::= ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' ) '#' ( query | '*')

I a proposing this without working out all the issues. I just want the scope to include the patient. 

Scope is Not Query parameters
This is NOT a proposal to force these query parameters and trust server search capability. This might be one thing done to make it efficient, but won't work perfectly as not all. The use of search parameters will just help with positive matches; but will not be perfect against false-positives or false-negatives. It will also fail when the other parts of the query are creatively authored to cause the wrong thing to happen.

The scope does need to be ENFORCED. The Resource server is expected to enforce the scope without fail. This is what I mean by more than just query. Most important is inspecting the resulting Bundle to assure that no content is contained in the Bundle that doesn't fit within the Scope.

More common query parameters

Some of the other common search parameters that might be useful:
  • _id -- when the scope is restricted to exactly ONE resource
  • _tag -- when the scope is restricted generally to some tag
  • _profile -- when the scope is restricted to some specific _profile tag
  • _security -- when the scope is restricted to some vocabulary from the HCS (e.g. confidentiality of "N" normal)
  • encounter -- when the scope is restricted to a specified encounter

Clearly missing but needed

There are some important vectors in Privacy space that are missing:
  • Timeframe for when the data was created - used to hide timeframe or enable a timeframe
  • Authored by - used when policy allows only data authored by some org or user
Note, scope is not everything. Where the user is forbidden, they get no authorization at all.

Also, I don't propose how to use negative scopes. Such as this user (Provider) can see any data but not patient Mary.

Not Done Yet

This is not a final solution. I am just putting this out there for discussion. Simply to bring up options for discussion on how to make improvements to Scope. The unfortunate facts of healthcare is that the needs for scope is a complex of multiple vectors; and failure is severe when not appropriately protected or when not appropriately available. Both false positive and false negative can have severe effects.

See my other FHIR articles

Monday, May 1, 2017


IHE ITI has a set of profiles on FHIR existing in Trial Implementation today. These were written against FHIR DSTU2. These have been updated to STU3, now in ballot for members of the ITI Technical Committee to comment and vote on.  Details and access to the ballot drafts of these documents is available from the ballot.
The IHE ITI Technical Committee is also working on new profiles using FHIR. These will be further discussed in later articles.
  • Mobile Care Services Discovery (mCSD)
  • Non-Patient File Sharing (NPFS)
  • Access to Document-extracted Data-elements (ADD) 
    • Formerly: Patient Centric Element Location
    • This is a profile that combines XDS/MHD and QEDm to describe how a Document Sharing environment can provide more fine grain access (Resource) to data shared as documents. 
    • This profile does rely on creative systems engineering to decompose the documents into the FHIR resources. This might leverage CDA-on-FHIR, or some other methodology. This methodology is not specified.
    • What is specified is that the fine grain details must have Provenance pointing at the Documents from which the data came. This enables a consumer to retrieve using XDS or MHD the document from which the fine grain details came from.
The IHE ITI and PCC are working jointly on one as well:
IHE ITI is also working on one non FHIR Profile
  • Remove Metadata and Document (RMD)
    • This is a profile on XDS for administrative ability to remove metadata entries and remove documents
Lastly IHE Document Digital Signature (DSG) Profile approved for Final Text

Thursday, April 27, 2017

IHE Document Digital Signature (DSG) Profile approved for Final Text

Today the IHE ITI Technical and Planning committees approved the Document Digital Signature (DSG) Profile be moved into Final Text. This Document Profile defines a way to support Digital Signatures, including when those Documents are managed in a Document Sharing infrastructure. This DSG Profile is referenced in many places where adding a Digital Signature to a document would be beneficial, such as Consent, Legal Evidence, etc.

There is more interest in digital signatures driven by some Anti-Fraud use-cases. I think there will be more interest driven by Patient Authored content.

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.

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).

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.

DSG supports:
  1. An Enveloping Signature is a Digital Signature Document that contains both the signature block and the content that is signed. Access to the contained content is through removing the Enveloping - Digital Signature. Among other uses, this method should not be used with Document Sharing infrastructure.
  2. A Detached Signature is a Digital Signature Document that contains a manifest that points at independently managed content. Detached signatures leave the signed document or documents in the original form. Among other uses, this method is recommended for use with a Document Sharing infrastructure to support Digital Signatures, as this method does not modify the original Document Content. This method uses the Document Sharing “SIGNS” relationship provide linkage.
  3. A SubmissionSet Signature is a Detached Signature Document that attests to the content in a SubmissionSet by: containing a manifest of all the other Documents included in the SubmissionSet, and a reference to the SubmissionSet. The Document Sharing “SIGNS” relationship may be used but is not required.
The digital signature standard is XML-Signature using XAdES-L-T profile, 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.

Reflecting FHIR FMM in IHE Profiles

IHE is creating many Profiles using FHIR. Given that FHIR is still "Standard for Trial Use" (STU), and thus there is a "Maturity" concern. This maturity concern is communicated in FHIR STU3 through a "FHIR Maturity Model" (FMM) evaluation number on each Resource and other parts. These FMM number indicate to the FHIR audience a stability and readiness for use. This is an important communication tool.

I am proposing within IHE that they reflect these FMM to the cover page of the IHE Profile so that the reader of the IHE Profile supplement understands the stability and readiness for use evaluation.

These FMM evaluations are only a construct for the STU and "Trial Implementation" phases. The FHIR Resources used must go to Normative, before the IHE Profile can go "Final Text".

So for example PDQm is based on Bundle, OperationOutcome, and Patient. All of which are at FMM level 5. So the title page of PDQm looks like:

Where as MHD is based on a broader set of  FHIR STU3 defined resources --  DocumentReference 3, DocumentManifest 2, List 1, Patient 5, Practitioner 3, OperationOutcome 5, and Bundle 5. FHIR Maturity Level (FMM) range 1-5

These updates to the IHE profiles will soon be seen in a CP ballot, and then published on the IHE web site. Right now they are being worked by the ITI workgroup.

Thursday, April 13, 2017

FHIR Security model is enterprise centric

NO! This is a false understanding. FHIR has no security model. And this is a good thing.

FHIR is designed first and most important as a data model with a few expected interaction models (REST, Messaging, Document). There is expectation that many security models exist, and application of those security models does not impact the most important priority of getting the data model correct. This is especially exercised with REST, but is not limited to REST. REST is just used as a most likely first interaction model, and one that is understood to drive for a good transport agnostic data model.

There are many workgroups working on specifications for how to apply OAuth to FHIR REST, but these are not fundamental to FHIR, they are alternatives. There are various variations of OAuth as well, those that might be more Patient centric, those that might be more enterprise centric, and those that might be cross-enterprise centric. There are work on OAuth scopes. There are others that are working on pure mutual-authenticated-TLS for organization to organization. There are others looking toward SOAP. There are others applying security to the packaging so that it can travel by many transports with end-to-end security. Others are looking to smart-contracts in blockchain. Others just focused on enabling Privacy. Others tagging data so that rules can be applied. All enabled by the very fact that FHIR is not bound to one security model. This is an important fact.

I am sorry that it seem to FHIR is bound to an enterprise OAuth security model. I suspect this impression comes from the most visible project -- SMART-on-FHIR... which is enterprise centric. SMART-on-FHIR is a fantastic project, very important, and the one that really has the necessary engagement to 'make it real'. That said, these other projects are also doing good work. Not all projects have, or could have, the marketing power that SMART has... 

FHIR has many security models, while having none

Tuesday, April 4, 2017

Stop using OPT-IN and OPT-OUT

In various conversations on Consent, including #FHIR Consent, discussions often get mixed-up because we use the terms "OPT-IN" and "OPT-OUT". These terms are trouble. We need to stop using “OPT-IN” and “OPT-OUT”.

I want to propose a set of terms. I will never get everyone to stop using opt-in and opt-out, but where better terms can be used, I propose better terms. Better, as in, more descriptive and accurate communications.

The reason is that these terms can mean very different things based on what the person listening is thinking. They can mean a consent ‘model’ or they can mean a consent ‘state’ or they can mean an 'action' by the patient. Especially confusing because there is a possibility for all thee to be the same and not the same.

State Model --

In this model we look to consent as a state-diagram, also called a finite-state-machine, or a directed-graph. In a state-diagram is made up of a finite number of 'states' diagrammed as circles, with arrows indicating events that can occur.  A state-transition-table, and uml representations can also be used.

At the most gross level of Privacy Consent we recognize that there is a 'state' where data is shared, for legitimate medical treatment purposes, with trusted partners, who are authorized by their licensing and role. And another state where data is NOT shared, except for legitimate and authorized medical emergency...

Note I am defining a Treatment purpose of use, setting parameter that indicate that the sharing would be for legitimate and authorize purposes. This is to counter distracting arguments, distracting from my point. Insert any caveats necessary, and there is still an understanding of OPT-IN and OPT-OUT as a state of consent.

as a State:
  • OPT-IN state – Permitted to sharing the patient's data for Treatment purpose
  • OPT-OUT state – Denied to share the patient's data for Treatment purpose
I think this is better said using the terms Permit and Deny

Event Model

This might also be called the 'action'.  It is often predominately determined by regulation. 

Some view OPT-OUT as a model where absent an indication from the Patient, their data can be used. This is to say that the patient must OPT-OUT if they don't want their data shared.

Some view OPT-IN model as one where absent an indication from the Patient, their data can not be used.

You will note that this model uses terms that are also aligned with the 'first action' that a patient can do.
I think this is better represented by the "event" or "action" of the patient giving authorization, that is to "Authorize"; or the patient revoking that authorization, that is to "Revoke".

First state

This perspective uses the term to define the starting point, as the state.
  • opt-in environment, the patient is automatically put into opt-in state. 
That is improper definition, as it uses the term to define the term. So I will re-write it using the "Permit" state term
  • opt-in environment, the patient is automatically put into Permit state. 
This perspective is important to understand, but does not help with any clarity. As once the patient has made that first action then the distinction is not valuable. That is to say, the second or third or fourth action just confuse the perspective.

I propose we use:

States (Leveraging these terms as used in XACML):
  • Permit – a ‘state’ data is shared 
  • Deny - a ‘state’ of NOT sharing 
Model - Initial State
  • Implied-Consent – A ‘model’ where without a consent the patient data sharing is Permitted.
    • Start in Permit state
  • Explicit-Consent – A ‘model’ where without a consent the patient data sharing is Denied
    • Start in Deny state
The Initial State is usually driven by regulation. Such as Such as HIPAA, which is a model where patient data is allowed to be used for Treatment, Payment, and Operations without getting a consent from the patient.  It is common for HIPAA to be called an Implied-Consent environment, for the patient has implied their consent by seeking treatment.

Where as EU has as an Explicit-Consent dominant model. That is that no action on data without consent from the individual that data is about.

Explicit-Consent is also common with sensitive topics, that are considered more sensitive than normal health topics. Likely due to stigma. These topics are often held to an Explicit Consent model, even where normal health topics follow Implied Consent.

Also some regions, or even organisations simply choose to use an Explicit-Consent model for various reasons. Explicit-Consent can be seen as more Privacy Principled, but can also impede progress that might be 'implied'

I propose a set of terms, while not defining terms for the 'actions'. This because the actions are what tends to be very realm specific. Some environments allow a verbal consent, others allow a web-form checkbox, others require digital signatures, others have very specific language, others have special technology, others allow for delegation and assignee, etc. So the actions, or 'state transitions' are much harder to agree upon.

And, there are certainly more states...

Updated: 4/6/2017 to include recommended "Event" description and diagram

Monday, March 20, 2017

Healthcare Blockchain use?

Today starts the "Healthcare Blockchain Summit". I wish I could be there. What makes a good use of Blockchain, while also helping Healthcare? What are the questions Blockchain proposals need to answer? Blockchain is the hot word right now, Gartner indicates that it is still on the Peak of Inflated Expectations.
Gartner estimates 90% of enterprise blockchain projects launched in 2015 will fail within 18 to 24 months. Part of the problem is that the majority of enterprise blockchain projects don’t actually require blockchain technology. In fact, these projects would probably be more successful if they did not utilize blockchain.
Gartner give fantastic reasons, that I very much agree with. I am not going to duplicate them here as they do a great job.

Blockchain is a public ledger that is maintained by an interested network of systems. One can make a private blockchain, with private parties; this is possible, but I would argue takes much of the value out of the blockchain system. The blockchain can be validated by anyone, regardless of if they are just looking, just joined as a participant, or are a long standing validating node.

So what does someone proposing a Healthcare use of blockchain need to answer?

  1. What problem being solved? Why is that problem not best solved with 'classic' database? The excuse that the problem has not been solved today is not an acceptable answer. The problem has likely not been solved yet because it is not valuable to solve, so throwing expensive infrastructure like blockchain at it is unlikely to succeed.
  2. How is Privacy protected? The nature of blockchain is that the information put on the block must be sufficient for all parties to Validate. Putting purely encrypted information, or just pointers to data protected elsewhere is not helpful. This is why I recommend NEVER to put healthcare data on the blockchain. Just because healthcare data can't be put on the blockchain does not mean that there is no use of blockchain in healthcare. It is just not a treatment use-case.
  3. How is Identity managed? The nature of blockchain is that it is a system that does not require Identity to be known. There is an Identity linked cryptographically to information and signatures on the blockchain. One can always expose your own identity. Is this necessary with the proposed system? Exposing Identity might not be a bad thing, but it must be addressed either way. This fact means that blockchain is a ready made Pseudonym, hence why I proposed it be used to advertise availability of de-identified data.
  4. How is value created? Blockchain are expensive. How do participants gain value from their participation in the Blockchain? With Bitcoin, the value is equivalent to money, and is gained through proof-of-work, where part of that proof-of-work grows the chain with blocks offered by other participants, where each of those participants offer some bitcoin to have their block included. With a proposal to use Blockchain for Healthcare, one must have a good answer for how value is created, transferred, and consumed. It does not, and likely won't, be the same system as bitcoin. Hence why it is likely a different use of Blockchain for a healthcare specific purpose. Like my proposal to use it for Research Notebooks

Blockchain is good for?

I don't think that healthcare data should go into the blockchain. But there is good value in using blockchain to ( a ) advertise availability of data, ( b ) publish terms (smart-contract) of use that when met unlock access, ( c ) Merkle tree signatures used to validate authenticity of data managed elsewhere, ( d ) track revisions, and ( e ) record (audit) access and use.

Healthcare Blockchain - Big-Data Pseudonyms on FHIR
Blockchain and Smart-Contracts applied to Evidence Notebook

Friday, March 3, 2017

Multiple formats of the same Document content

I propose that “The most technically advanced” document format be considered the Prime, with all of the other formats considered Transforms (XFRM) from that prime document. Thus if the Document Source can create a C-CDA 2.1; then that becomes the prime. Yet if a Document Source only can create a C32 and PDF, then the C32 would be the prime. In this way, regardless of if the secondary formats were actually derived from that prime document, they would be Registered as if they were. This enables a Document Consumer to follow the XFRM link to the Prime without needing to understand all the formats presented. The Document Consumer can also follow the XFRM links down to all the ‘equivalent’ formats to discover those to choose from.


Now that C-CDA 2.1 is emerging, the following situation becomes more prominent. The situation is that the same content could be encoded in various document format types.
  1. How do you publish in XDS/XCA a set of documents that cover the same content but are different in their encoding format? 
  2. How do Content Consumers perceive when they find a set of documents that seem to cover the same content but are different encoding format? 
  3. How do we prevent miscommunication, or misinterpretation, or worse duplicate attribution. 
Various document encoding formats:

C-CDA 2.1
C-CDA 1.1
CDAR2 structured

CDAR2 unstructured
FHIR Document

PDF - rendered view of C-CDA using publishers stylesheet



Bluebutton text

As you can see, C-CDA 2.1 is not really special, but it happens to be the thing that has just released and C-CDA 1.1 are laying around. As proof, FHIR Documents will re-open this discussion. Especially with the CDA-on-FHIR efforts. Thus although C-CDA 2.1 isn’t special, it is a nexus today.

Example using a Discharge Summary:

As an example of a document that might need to be published in multiple formats is a Discharge Summary for an Episode of Care. This use-case is the most clear as to why the very same content might be made available in multiple formats. Other document types are also possible.

Why publish multiple formats?

The main reason to publish multiple formats is for the benefit of various Document Consumer systems. Given a Health Information Exchange, or Nationwide Health Information Exchange, there will be a variety of capabilities and use-cases for the hundreds-thousands of various Document Consumers. Some of these Document Consumers might not be updated at each revision of the C-CDA specification, thus they can only consume an older format.

All this for the benefit of the Document Consumer, but it creates a problem for the Document Consumer too. How do they know that the very same content is represented in the different formats, vs that the different formats are actually about different content? Ideally they would have some way of discovering this short of retrieving all documents and comparing them.

A user should not be bothered by making a choice between various encoding formats, all for the same content. It would be best if the Document Consumer could automatically pick the ‘best’ format. This pick, might be:
  • simply because that Document Consumer only supports one format. Example might be an old piece of software that can only consume C32 (aka XPHR). 
  • might be because a Document Consumer is able to render one format better than another format for a given context. For example, a patient view versus a clinical view. A Patient Generated Health Data (PGHD) CDA document vs a CCDA CCD. 
  • might be a good workflow reason to show a PDF rendered view, as that specific rendered view was that of the Document Source (publisher). 

Not rewriting history

It should be noted that I am not talking about going back in history to create more formats of documents previously published. Revising history is against medical-records principle.

Those old formatted documents must forever be supported by Document Consumers. That is to say that a Document Consumer should never remove the functionality it has to consume older formats.

What I am focused on here is the front-edge of standards advancing. What happens as ‘new’ formats become supported by Document Source. And how to best support Document Consumer needs.

Potential Solution

It would seem that the closest representation in XDS is the transform (XFRM) association, because it means two representations of the same information, as opposed to RPLC, APND, etc. However, it may not always be right to say one is a transformation of the other. They could all have been created at the same time, from the same underlying EHR data, simply for the purpose of satisfying the largest range of clients. In this case, which one is prime?

That said, a Transform (XFRM) association in XDS does have a directionality component. It has a source side, and a transformed side. Thus to

use the Transform (XFRM) association we need to determine a directionality. I look to IHE PCC and IHE ITI to see if there is a precedent. There is similar use of Transform (XFRM) in XDS-SD, and also APPC. In both documented cases the directionality component is left to ‘local policy’. So it would seem that the IHE committees have not yet decided.

I propose that “The most technically advanced” document format be considered the Prime, with all of the other formats considered Transforms (XFRM) from that prime document. Thus if the Document Source can create a C-CDA 2.1; then that becomes the prime. Yet if a Document Source only can create a C32 and PDF, then the C32 would be the prime. In this way, regardless of if the secondary formats were actually derived from that prime document, they would be Registered as if they were. This enables a Document Consumer to follow the XFRM link to the Prime without needing to understand all the formats presented. The Document Consumer can also follow the XFRM links down to all the ‘equivalent’ formats to discover those to choose from.

This all said, there could be some policy reason why a different format is considered to be the prime by the Document Source. For example that the Document Source publishes in C-CDA 1.1, and uses a stylesheet transform to produce the C-CDA 2.1. This said, a Document Consumer should be able to rely on the top most (Prime) Transform as the most complete and accurate.

Robust Document Consumer

Given that whatever guidance we advocate would be adopted over time and not uniformly, a Document Consumer needs to handle whatever is available, and be robust to formats that are not understood. Unfortunately, there is probably not a fully deterministic way to go. For example, a given Document Source might adopt this guidance but other Document Source might not, so some but not all equivalent documents would have associations.

Unresolved technical issues:

The various formats are not fully equal. Clearly a PDF format doesn’t carry the fidelity of data that a C-CDA 2.1 can. There might be use case where this difference is not a problem, but any loss of fidelity is potentially problematic. Thus there must be some recognition that the various formats might all be “Transforms” (XFRM), but are not equal. This is why I recommend the prime be the most technically advanced, so that the number of hops away from the prime is an indication of potential loss of fidelity.

There is no obvious metadata place for this ‘completeness’ or ‘accuracy’ or ‘integrity’ evaluation recognition to be placed. There are Vocabulary available in the Value-Set (integrity) recommended for ConfidentialityCode… I am not yet ready to recommend this.


This is just a recommendation. It might kick off a discussion in IHE to write similar recommendations. Not clear if this is a ITI or PCC responsibility.

Attribution: Tone Southerland and Joe Lamy both helped me with the content. Thank you!

Keith covered this in a different way back in 2009. focused more on template inheritance -- Template Identifiers, Business Rules and Degrees of Interoperability -- with a cool graphic