Extra software/transaction details in FHIR AuditEvent / ATNA Audit Message

I have been in a few discussions lately where the question came up on how to add additional information to an ATNA Audit Message (aka FHIR AuditEvent). This additional information is not the kind of information that needs to go into an 'extension', as the Audit Message schema has support for what needs to be recorded. But there is a need to setup some things.

Here are the use-cases

1. In a service oriented transaction there is a 'transaction identifier' that is specific to that transaction. When all audit events are recorded with their transaction identifier, then one can see all the audit events caused by one transaction. This transaction identifier might be in  SOAP header, or might be in an HTTP header, or might be elsewhere. For the purpose of this article it doesn't matter were it comes from, but rather that many different audit logging events can record the transaction identifier so that later the many different audit log entries can be correlated.
2. In a layered software environment there are various software 'applications' (aka services) that might be involved in an 'event'. It would be good to record all of these applications so that an analysis of the audit log can show the involvement. For example: During the audit logging, it is possible to walk the call-stack to see all the layers involved. 

First thing to think about is if this additional information is appropriate. This is an important step because sometimes initial thinking is to put data into the audit log. One should keep data out of the audit log, and rely on metadata as linkage to the data that is managed more formally in a database. In the use-cases here these are both metadata, and not data. They explain what was involved, hence 'meta'.

Note that both of these use-cases are addressing similar realities, that when looking at an audit log one finds that it is useful to be able to understand how the event was processed. Realistically BOTH of these are likely to be needed. That is to say that every piece of software that touches a transaction could record their participation in that transaction, this would produce a large number of audit events, possibly too noisy.  The software "architecture" could be understood so well that only one event is recorded, with complete details. Most likely it is a combination of all of this.

IHE defined Audit Message is minimally transaction focused

Normally an Audit Message from IHE asks that the critical Who, What, Where, When, and Why (W5) are recorded. A specification like IHE will explain the most likely specifics about this for a given transaction. The unfortunate reality is that IHE is limited to the Interoperability layer of the software design, so they can only mention things that IHE manages; which is Actors. 

Such an example is where a XCPD Query on the server would record for this event: (Using IHE/DICOM Audit Message terms, similar map to FHIR AuditEvent)

• Event Description: Defining this kind of an event
• ActiveParticipant: the Initiating Gateway would be described by IP address, possibly the ReplyTo value if async web services are being used.
• ActiveParticipant: the Responding Gateway by IP Address, and SOAP endpoint URI. The Process ID can be recorded to tie to local system logs.
• AuditSource: identity of the system recording the audit event
• ParticipantObject: The patient identity(ies) if known
• ParticipantObject: The query parameters 

The closest thing to what this article is about is that the Responding Gateway can hold the local machine Process ID so that the event can be correlated with local audit logs (in non-IHE format)

You should also notice that this specification only mentions "Actors" (i.e. Initiating Gateway, and Responding Gateway). IHE can't specify a software architecture, so it doesn't know what the software architecture is. It is expected that the Software Architect can add these details.

Layered specification

I want to point out that IHE does augment the audit message expectation based on layered 'grouping' of actors. For example if the XCPD server above had received a XUA assertion, then there is the expectation that the above audit message would be augmented with an additional ActiveParticipant with the UserName element composed of the parts of the identity in the SAML assertion. See section ITI TF-2:3.40.4.2

    +  ActiveParticipant: 

           UserIsRequetor == TRUE  (this indicates the ActiveParticipant is describing the user)

           UserId ==  alias"<"user"@"issuer">" 

           RoleIdCode == roles from the SAML

           PurposeOfUse == from the SAML

Note that this is not a whole new Audit Message, but rather additional detail that gets added to any Audit Message when there is an XUA assertion. This additional information is expected to be added to ALL audit messages.

In looking at this. The specification should have been more clear that this should be done with a dedicated ActiveParticipant. The way the XUA specification describes it, one could just add the detailed UserName to any existing ActiveParticipant. I would rather it be a dedicated ActiveParticipant. Given that there is an infinite number of ActiveParticipant elements that could exist, and each one added only adds the elements populated, this doesn't make it much bigger of an Audit Message. Let me know what you think, should we CP this?

Where to put the transaction ID details?

In the first use-case the extra detail is is some kind of transaction identifier. In my example of XCPD there is a transaction identifier in the WS-Addressing MesssageID element in the query that goes into the WS-Addressing RelatesTo element on results returned. Recording this identifier might be useful to help relate responses with requests. This however is not part of the current IHE Technical Framework. I wonder if it should be?

In http REST, like FHIR, one could have an X-Request-Id that might also be good to record. See the FHIR chat discussion.

So the transaction identifier does not seem like an Active participant (AditEvent.agent) in the transaction, so it must be simply a ParticipantObject (AuditEvent.entity). The difference between these two is the "Active" part. That is if something/someone takes action then it is an ActiveParticipant (AditEvent.agent), else it is just some object that was part of the event being recorded.

Thus I would add a ParticipantObject that does nothing but hold the Transaction ID. By adding a ParticipantObject that only holds the Transaction ID it is easier to find all messages that have this ParticipantObject.

    + ParticipantObject: 

          ParticipantObjectTypeCode == 4 (Other)

          ParticipantObjectTypeCodeRole == 21 (Job Stream)

          ParticipantObjectIDTypeCode == transaction number type

          ParticipantObjectID == transaction identifier

Where to put Application Software Identifier details?

The next one is about where to place various layers of software. I would worry if this list gets long, especially if it is repetitious. It would not be helpful to list all the required layers that would be processing. But it does seem logical if there are different services that may or may-not be called upon, or where there are different instances that would need to be identified. 

In this case I think the application software is actively involved in the processing, so I would recommend this be recorded as a ActiveParticipant. So adding an additional ActiveParticipant would look like:

    + ActiveParticipant:

          UserId == the software identifier

          UserIsRequestor == FALSE 

          RoleIdCode == 110150 (Application)

There would be one of these for each layer of software actively involved. Thus care must be taken to not include all layers, just those that are useful. The other elements in the ActiveParticipant might also be used for some other purpose.

Conclusion

So the exiting ATNA Audit Message and FHIR AuditEvent can easily carry these additional details. This additional details can help resolve when there are failure-modes in a system, or to keep track of proper processing. Thus these additional details seem reasonable to incrementally add to existing Audit logs.

Note that there are some interpretations of what an audit log entry MUST or SHOULD contain. Sometimes these rules are considered too tight, and thus there have been some cases where an audit log entry has been declared non-conformant because it contained additional detail (or less detail). This is unfortunate, and wrong. An Audit Event log entry should record anything useful that is known at the time the audit log entry is recorded. This is a case where recording everything that is known is more important than recording everything theoretically possible, or failing to record because there is some data that is not known but is considered required by some tooling.

Healthcare use of Blockchain thru creative use of Smart-Contracts

I went to a blockchain conference yesterday. All the experts were clear that this early days. Caution, but excitement. They were all full of encouragement to try stuff out. All recognized that there is much misinformation and hype. All recognized anyone using blockchain is taking a big risk. None would state any prediction of the future. They also all recognized that those that have succeeded have reaped great rewards. They are all fully committed and excited...

No surprise, I have said this too:

What are THEY doing?

The experts that presented are focused on the financial flows. Not just money, like bitcoin. They are working on other financial flows including bank-to-bank money transfers, insurance payments,  payments based on contract terms, etc.  When pressed it was because these things can be made fully virtual, leverage the fact money is a concept in blockchain, and the biggest problem these flows have is the double-spend problem. The double-spend problem is well addressed in blockchain.  Also, when these kinds of things go wrong it results in simply loss of money. This loss of money can be huge, but it is still just a loss of money.

 keeps fidgeters occupied while not bothering others around them

That is to say they are not protecting an individual's Privacy, where a failure here is permanent loss of privacy. They are not protecting an individuals health, where a failure might be pain, loss of function, or death.

What should Healthcare do with blockchain?

This does not mean there is no room for blockchain and healthcare. just that we need to be careful about how we approach the topic. I have covered a set of Blockchain considerations for healthcare

Don't put medical data into the blockchain.

I am more convinced that putting healthcare data into a blockchain is a really bad idea.  Seems this is also a consensus that is coming together. Thus there will be many FHIR Servers that hold your data (might be others than FHIR, but why bother mentioning them).  For any specific use of data related to the blockchain, there might be one server or there might be many.That is to say that it is fully possible that the FHIR server associated with a blockchain project might have centralized the data prior to exposure through blockchain, or might proxy and make it appear as if there is only one. However probably best to presume many FHIR servers. In initial experimentation, experiment with one, but keep open as a gap expansion to many.

Don't use blockchain for direct Treatment.

I am equally convinced that using blockchain for direct Treatment use-cases is also a bad idea. Treatment has many expectations. The data must clearly be identified with a specific human, can't use pseudonyms. There must be no delay in getting to the data (urgency). There must be clear provenance of the data (where did this data come from, etc...). Treatment use-cases require that new events, observation, interactions are recorded; that any mistake detected is corrected. And there is also medical-emergency break-glass. etc.

Treatment related workflows

There are some Treatment like things that don't have these expectations. Such as participating in a clinical trial, where they can treat you as a pseudonym (strongly identity proofed). There are other Treatment scenarios where one also don't need actual identity, like a laboratory or pharmacy supply. Some of these are already given only the MRN, thus they don't have much more than a form of pseudonym.

Smart-Contract is the key

I think the biggest opportunity is focused on creative ways to use the smart-contract. Smart-contracts can exist elsewhere, indeed our FHIR Consent and OAuth (UMA) are two examples of smart-contracts. 

The difference being that various blockchains have specific smart-contract language, and mechanism to execute that specific language. These languages are usually very basic, like in bitcoin; but are getting more comprehensive. 

Legal contacts are not as easy as they seem

This is the space that needs to mature. It starting with putting a legal-will into a blockchain. Motivation is to unlock coins that an individual holds upon death in a way defined by that individual. This motivation is strong by that individual, and those benefactors who would receive the coin. It is also strongly motivated by the coin community as otherwise those coins go permanently out of circulation. It would seem this is not unlike a normal coin transaction smart-contract like is the foundation of bitcoin. But it is not that simple. Key improvements needed is that these contracts need to interact with sources-of-truth from outside the blockchain, the proof of death, the proof that the death was not caused by a benefactor. First these don't exist, but also these are external sources of truth. Blockchain wants to have the community 'be the source of truth', and not use external sources of truth... 

Patient data for sale for Clinical Research

 So a patient might offer access to their data (which is elsewhere) to anyone that can satisfy a smart-contract they put into a public chain. Unfortunately this best opportunity is what I described over a year ago given Grahame's original ask  Healthcare Blockchain - Big-Data Pseudonyms on FHIR

The smart-contract would include:

• Upfront payment for the access (some micro-payment)
• Requirement for escrow of coin to be unlocked to the Patient if other terms are violated
• Terms of protection of the data
• Kind of clinical trial allowed (heart conditions, but not brain)
• Agreement to keep all research public
• Agreement to contact patient if the patient could benefit from new treatment detected
• Agreement to contact patient if some treatable medical condition not previously known is discovered
• Agreement to not contact patient if terminal condition is detected

A clinical trail that can meet these, could satisfy the contract and gain access. If they violated any of the terms, the smart-contract would automatically transfer the escrow coin to the patient.  Based on some sunset term (like possibly the natural death of the patient), the escrow coin goes back to the research organization. So clearly that legal-will is important to this use-case...

Variants on smart-contract based on de-identification capability

It is possible that the patient publishes multiple flavors of the smart-contract. Each offering different types of pseudonym blinding: Some flavors would expose MORE information, and have higher contract requirements (like shown above). Some would expose very well de-identified data, and have less strict contract requirements.  

Highly de-identified data, where ALL direct and in-direct (Quasi identifiers) are removed. Including fuzzing completely dates, patient characteristics, location, etc. If the data is highly de-identified it is less valuable for clinical trials, but it also wold not need to be as strongly protected. So it is possible for this offering the smart-contract does not require an escrow of coin.

These variants would require that the authorized access to the data enforce these variations. Thus one would need some access method to the data where the de-identification can be accomplished. This might be done by different servers hosting the various flavors, confirmed by a human statistical analysis. This might be done by some automated de-identification service as I describe in
#FHIR and Bulk De-Identification

Healthcare Financial transactions

I any financial related transactions might certainly be good blockchain, even if it is healthcare related. Still privacy and safety concerns, but these are a step away. For example 

More reading:

• Healthcare Blockchain use?
• Blockchain and Smart-Contracts applied to Evidence Notebook
• Healthcare Blockchain - Big-Data Pseudonyms on FHIR
• #FHIR and Bulk De-Identification

Granularity of FormatCode

A Question was asked regarding FormatCode granularity, especially given that the IHE defined FormatCode vocabulary seem to be defining much smaller concept relative to HL7 defined FormatCode for C-CDA. Where the combined list is available in FHIR as a ValueSet of FormatCodes (updated in current build)

Important background :: Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE) and Healthcare Metadata

The FormatCode is there to differentiate 'technical format'. It is a further technical distinction more refined than the mime-type. So it is related to mime-type.

FormatCode is not a replacement for class or type. In fact it is very possible to have the exact same type of content available in Multiple-Formats. Including FHIR Documents in XDS

It is true that IHE defined FormatCodes tend to be one-per-Profile, where as all of C-CDA R2.1 is one FormatCode. This difference in scope seems like a very big difference, but is at the technical level not different. That is to say that the IHE XPHR profile defines a unique set of constraints on the format of the content, where as C-CDA R2.1 similarly defines a unique set of constrains on the format of the content.

This is a good time to explain that what IHE calls a "Profile" is commonly what HL7 would publish as an "Implementation Guide". Thus they are often very similar in purpose.

While it is true that XPHR has only one type (34133-9 Summary of Episode Note), where as there are a set of unique use-cases that are each unique clinical 'type' of document in C-CDA R2.1. This is a good example of why formatCode is not the same thing as 'type'. Type expresses the kind of clinical content, where as FormatCode expresses the technical encoding used.

So the FormatCode focuses on the technical distinction as a sub type on mime-type; and should be as specific as necessary to understand the Profile (or Implementation Guide) set of constraints.

HL7 could have defined a set of FormatCodes for the second-level deep technical format within their C-CDA. They didn't, I was not there to explain why they didn't. However this should, in theory, not be a problem. It simply means that at the technical encoding level there is only one FormatCode, rather than a set for each sub-format. I don't know how useful this would be, but I would be glad to help the committee understand the benefit.

I am the one that maintains these vocabulary. Not because I am a party to the creation of the vocabulary values, but simply because I am willing. If there are problems with any of these locations or values; please let me know. I hear rumor that there are problems, but until the problem is pointed out in specific detail, I can't fix it. This is especially true in FHIR where a Change Request (CR) must be filed.

• Health Information Exchange: Centralized, Federated, or Distributed
• Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)
• Healthcare Metadata 
• Other articles on HIE 

#FHIR and Bulk De-Identification

Might be time to dust off a concept that hasn't been discussed for a while. But first let me explain two factors that bring me to that conclusion.

Bulk Data Access

The addition of a Bulk Data Access in #FHIR was a hot topic at the San Diego workgroup meeting. Grahame has explained it on his blog. What is not well explained is the use-cases that drive this API request. Without the use-cases, we have simply a "Solution" looking or a "Problem". When that happens one either has a useless solution, or one ends up with a solution that is used in appropriately. The only hint at what the Problem is a fragment of a sentence in the first paragraph of Grahame's blog article.

"... in support of provider-based exchange, analytics and other value-based services."

Which is not a definition of a use-case...  But one can imagine from this that one use-case is Public Health reporting, or Clinical Research data mining, or Insurance Fraud detection... All kinds of things that Privacy advocates get really worried about, with good reason.

De-Identification

There have been few, possibly unrelated, discussions of De-Identification (which is the high level term that is inclusive of pseudonymization and anonymization). These are also only presented as a "Solution", and when I try to uncover the "Problem" they are trying to solve I find no details. Thus again, I worry that the solution is either useless, or that the solution will get used inappropriately.

I have addressed this topic in FHIR before, FHIR does not need a deidentify=true parameter . Back then the solution was to add a parameter to any FHIR query asking that the results be deidentified. The only possible solution for this is to return an empty Bundle. As that is the only way to De-Identify when one as no use-case. 

De-Identification is a Process

De-Identification is a Process that takes a use-case 'need' (I need this data for my use-case, I want this data for my use-case, I need to re-identify targeted individuals, my use-case can handle X statistical uncertainty, etc). This De-Identification Process then determines how the data can be manipulated such that it lowers the Privacy RISK as much as possible, while satisfying the use-case need.  IHE has a handbook that walks one through the Process of De-Identification.

All De-Identification use-cases have different needs. This is mostly true, but some patterns can be determined once a well defined set of use-cases have been defined. DICOM (See Part 15, Chapter E) has done a good job taking their very mature data-model (FHIR is no where near mature enough for this pattern recognition). These patterns, even in DICOM, are only minimally re-usable. 

Most detailed use-cases need slightly different algorithm, with different variability acceptable.  For example IHE applied their De-Identification handbook to a Family Planning use-case and defined an Algorithm. Another example is Apple's use of Differential Privacy (a form of fuzzing). These are algorithms, but they are not general purpose algorithms. These examples show that each De-Identification algorithm is customized to enable a use-case needs, while limiting Privacy Risk. 

Lastly, Privacy Risk is never brought to zero... unless you have eliminated all data (the null set).

De-Identification as a Service

What I propose is that a Service (http RESTful like) could be defined. This service would be defined to be composable, thus it would be usable in a pipeline. That is the output of a #FHIR query (Normal, or Bulk) is a Bundle of FHIR Resources. This would be the input to the De-Identification Service, along with a de-identificationAlgorithm identifier. The result would be a Bundle of data that has been de-identified to that algorithm, which may be an empty Bundle where the algorithm can't be satisfied. One reason it can't be satisfied is that the algorithm requires that the output meet a de-identification quality measure. Such as K-Anonymity. 

The De-IdentificationAlgorithm would be defied using a De-Identification Process. The resulting Algorithm would be registered with this service (RESTful POST). Therefore the now registered algorithm can then be activated on a De-Identification request.

De-Identification Algorithm Consideration

So, what kind of Algorithms would need to be definable? Best is to look at the IHE Handbook which defines many data types, and algorithms that are logical.

For #FHIR. We would first need to an assessment of each FHIR Resource, element by element. Identify if this element is a Direct Identifier, Indirect Identifier (Quasi Identifier), Free Text, or Data.  This effort would best be done as the FHIR resources approach maturity. It could be represented within the FHIR specification, much like the _summary flag is represented...

Direct Identifiers -- Remove, Replace with fixed values, Replace with faked and random data, Replace with pseudonym replica, Replace with project specified identifiers, Replace with reversible pseudonym, etc...

Indirect Identifiers -- Remove, Fuzz, Replace, Generalize, Unmodify

Free Text -- Remove, Unmodify, interpret into codes removing unknown text

Quality Output -- Analysis of output to determine if it meets quality such as K-Anonymity

Just a hint of what it will take...

Conclusion

Plenty of good work to do, but the basis is well known.

Bulk Data -- De-Identification can be much more reliability (lowering Risk reliability) when the De-Identification process is executed on a Data-Set. Meaning the larger the number of Patients in the data-set, the more likely that one can protect Privacy. As this data-set approaches ONE, the risk approaches 100%.  This fact is usually the downfall of a de-identification result, they overlook how easy re-identification can be, especially where there is motivation and skill.

My other articles on De-Identification 

FHIR Connectathon of the IHE-MHD Profile

There were three brave soles willing to try IHE-MHD Profile here at the FHIR Connectathon.

• Diego Kaminker (ALMADOC project / Argentina)
• Fernando Campos (ALMADOC project / Argentina)
• Simon Knee (NHS Digital / UK)

They did all the hard work. I just answered questions and such...

They had a specific goal: They wanted to test the IHE-MHD Profile against general purpose FHIR Servers. Specifically FHIR Servers that have not declared IHE-MHD Profile, but which do declare support for the fundamentals that IHE-MHD needs. This task is important as it is a way of testing how well I did at writing the IHE-MHD profile. How well did I stick close to FHIR (STU3), and how well did I inform the audience of the deviations.

I tried really hard to write IHE-MHD in away that a general purpose FHIR Server would work. However this was not the intended scope for IHE-MHD. The intended scope or IHE-MHD was as an API to an XDS, XDR, or XCA environment. Thus when I wrote IHE-MHD, I did have to constrain it in ways that a general purpose FHIR Server might not support.

This said, there was some big surprises.

I will summarize the reportout, It is available, with the actual XML examples and evidence.  

Test Procedure

1. Document Source: New Document (1 binary attachment included in the bundle)
2. Document Source: No binary attachment in the bundle – binary file referenced from external server
3. Document Consumer: Search by Filter Combination

1. Subject  by identifier
2. Document Class / Type
3. Document Creation Date Range
4. Document Consumer: Direct Binary Document Retrieval 

Notes: For this connectathon, we had not specified security / authentication requirements, like token / RBAC / etc.

Testing: Servers: with HAPI, Vonk, Grahame's server

Clients: plain REST with Chrome Restlet Client (Almadoc), Postman/Eclipse (LDP)

 Results

1 - During a ITI-65 "Provide Document Bundle", that carries both a Binary and a DocumentReference that points at that Binary, MHD expects that the DocumentReference.content.attachment.url would be "fixed up" by the server. That is when the server persists the Binary, and thus fixes up the Binary id from a URI (GUID) to a URL on the server, that new URL would be placed into the DocumentReference.content.attachment.url, which previously held the same URI (GUID) from the Bundle. This behavior does work when the FHIR Reference datatype is used, and did work in prior versions of FHIR (Prior to the Reference becoming a complex datatype vs just a flavor of URL), and the example in the FHIR specification shows this fixup behavior.

• I created a CP to fix this See GF#13823
• Recommend that in a Transaction, that URL fixup is done just like it is with Reference.
• some zulip chat recommended that DocumentReference.content.attachment.data be used, but there are many problems with that. Most of all that it is very counter to the IHE XD* use-case need.
• If this isn't resolvable, then the next revision of MHD might need to define ITI-65 as a FHIR Operation, rather than using the Transaction. I don't think this should be done until FHIR STU4. But I would entertain someone wanting to define this as an option. However I would remind everyone that IHE-MHD is not trying to use general purpose FHIR Servers, it is as an API to XD*.
• One cold just do two transactions. One to create the Binary, then create the DocumentReference with a client fixedup URL. This can be done with general purpose FHIR Servers, but would be counter to the target for IHE-MHD being an API to XD*.
• I will write a CP to MHD to make this more clear as an MHD imposed requirement of MHD servers.

2 - Already known issue #MHD_048 -- This was not a new issue, since we knew of it. But this issue was not obvious in the MHD text, so it caused issues. The default behavior for a general purpose FHIR Server is that one can't search against "contained" resources. In IHE-MHD we just left this as an open issue, we didn't try to solve it completely.

• Turns out that one CAN query on contained resources. 
• The bad news is that one can't tell if this will work from a servers conformance resource. 
• I will write a CP that uses this feature that I didn't notice.

3 - Search on Patient.identifier -- An issue I simply didn't expose as much as I could have. This is a chained search, and will only work when the server you are querying against also hosts the Patient resources. For example: Imagine a FHIR Server that holds all of the DocumentReferences (the MHD server), and a different FHIR Server that holds the Patient resources (likely available via PDQm or PIXm). You can do a PIXm or PDQm query against this second server, and use the resulting URL in your MHD queries against the first server. This is just URL matching. But if you try to query the MHD server using Patient.identifier, that server will not know how to find the Patient.identifier.

• This might be an important problem, or might not. It depends on deployment needs and capabilities.
• I will likely write a CP to make this more clear in MHD

Conclusion

Overall this was really cool to do this kind of testing of the MHD specification. Especially since it resulted in some CR to FHIR, and likely a CP to IHE.

Remedial FHIR Consent Enforcement

I have been working with some of the teams wanting to do something with Privacy Consent and are coming to the FHIR Connectathon in San Diego. Here is a few stepping stones that I think are educational to move from zero to a reasonable set of Consent possibilities. Basic Consent is a necessary and powerful step:

Pre-conditions:

1. Some form of Business Access Control are already in place to support basics of separating the kinds of things that various users (roles) are allowed to do; like Clinicians, or administrative staff, or billing staff, or cleaning staff, or dietary staff, etc. For example: Role Based Access Control (RBAC), or Attribute Based Access Control (ABAC) . This layer is responsible for separating those users that are allowed to Order drugs or procedures, vs those that are allowed to update clinical information, vs those that are given access to billing information, vs etc... An example of this is -- SMART-on-FHIR. 
2. There is some Privacy Policy written: I will give a few for example purposes only. These are not complete, or comprehensive. They are defined well enough to illuminate the various stepping stones that I will outline below.
   * Explicit Consent -- if no consent is on file, then no data is shared outside the organization.
   * OPT-IN -- Patient has positively given consent to share without restrictions
   * OPT-IN with named organizations allowed access
   * OPT-IN with identified time/date range within which no data authored can be shared
   So, any Consent in the system must be from one of these patterns. Mixing of patterns, or going beyond these patterns is simply not allowed by the consent gathering application.
   **** Sorry, I have to use "OPT-IN" and "OPT-OUT", against my rule... but I do have them explained.
3.  There is some consent gathering application that presents these Privacy Policies to Patients, and records the Consent ceremony as a FHIR Consent resource. I am not going to try to describe this ceremony. The user experience is very critical. The Patient must be well educated on the ramifications of their choices. I like the idea in GDPR where the consent rules presented to the Individual must be in human language terms that are specific to that person's language abilities. I am not short-circuiting this, but rather wanting to focus on the enforcement side.
   *** Note that if the patient changes their mind, this application handles this. Leaving only ONE active Consent resource. Thus there is no conflicts to resolve in real-time. If the patient wants to OPT-OUT after being OPT-IN; then a few solutions could happen. The existing record be updated to become Consent.status=rejected. Better for record keeping if a new Consent record is created with an OPT-OUT policy...

YES, I know that we all want more complex consents, we will get there. But for now we must get started. Stepping stones are important to the journey. Stepping stones are useful, but one does not stand on them for very long.

Some past articles to this point

• Consent Process
• Controlling Big-Data feeding frenzy with Privacy Consent Authorization
• Vectors through Consent to Control Big-Data Feeding frenzy
• Consent Basis in Controlling Big-Data Feeding frenzy
• Privacy Constraints in Controlling Big-Data Feeding Frenzy

Consent Enforcement Models

There are two major models today, very different.

Privacy Access Control decision engine

Privacy Access Control decision engine using OAuth. In this model, one offloads the Access Control decision to an OAuth authorization service. This is the model that HEART is focused on. Another example has been shown as "Cascading OAuth". The idea is that there is some OAuth authority (or a set of them) that focus on giving Access Control decisions purely along Privacy Consent lines. If this is 'cascaded' with the business OAuth Access Control decisions; then one has the combination of both.. I am not going to further explain this model in this blog article.

One could have an Access Control engine that is based on XACML...

In both of these solutions, the rules of the Patient specific Consent are not in any FHIR 'Consent' resource form. These solutions take care of steps 1-4. They only expose a 'decision' endpoint.

As such, their decision endpoint must be able to return complex obligations. PERMIT, but not to organization ABC, not the data authored during XYZ, etc... These in OAuth would be done with "Scopes", in XACML would be done with 'Obligations'. Which ever one uses, this is complex... and I would argue this is the same complexity one sees in the FHIR Consent resource today.

Interaction between FHIR Consent resource and Privacy Access Control decision engine

In both of these solutions, there might be a FHIR Consent that is simply there to indicate the endpoint of the Privacy Access Control service. This might be quite empowering. The Consent would not indicate anything other than the specific service to use. Thus enabling the Patient to choose from various Privacy Access Control services to use. The FHIR Consent resource would not indicate in any way what their Privacy rules might be.

I should model this.. and I might do it this week... but I want to focus on a solution that leverages the Consent resource... and this Privacy Access Control decision service solution hardly uses the Consent resource at all.

The FHIR Consent way:

Reminder we are working on Stepping Stones, and starting simple
* Explicit Consent -- if no consent is on file, then no data is shared outside the organization.
* OPT-IN -- Patient has positively given consent to share without restrictions
* OPT-IN with named organizations allowed access
* OPT-IN with identified time/date range within which no data authored can be shared

Lets first just work out the first two: No active consent on file, vs opt-in.

In the FHIR specification we already have examples of these:

* OPT-IN -- http://build.fhir.org/consent-example.html

A system can using FHIR query (RESTful) to determine if there is any Consent on file for a given patient. For the example below we look for if there is a OPT-IN consent for patient 'f001'

GET [base]/Consent?patient=f001&status=active&category=http://hl7.org/fhir/v3/ActCode#OPTIN
(((Note that one can't query on policyRule, so I propose either that be added, or that the OPTIN code goes into category. I seem to recall committee discussions that put it into category)))

If this above query returns ZERO result, then there is no OPTIN consent on file. Thus no access is granted. DONE
If there is a Consent, then we need to look to see if there are any Consent.provisions. If there are none, then we grant Privacy PERMIT access. DONE

The second stepping stone is to enforce the provisions.

Each provision will have a provision.type of either PERMIT or DENY. This means that if the constraints in the provision are matched, then the provision.type (PERMIT vs DENY) is to be enforced.

We have an example which is an OPTIN but denying access to a named organization.

http://build.fhir.org/consent-example-notOrg.json.html

Well, looking at this example, I see it is missing some critical parts that I just said would be there. The one provision this example has in it is that it is specific to an Organization named 'f001'. From the name of the example, it is clear this provision should have a .type="deny".

This kind of a provision can be enforced on the REQUEST, as that organisation is denied any access because of a Privacy Consent directive.

Date Range:

The Date Range provision is something that is much harder to enforce, as it really must look at the results that are about to be returned, and filter out any data that was authored within the given date range. I am not going to go deeper right now, but am pointing out that sometimes provisions can be enforced on the REQUEST side, denying a request or allowing a request with no further action. Some provisions require further work be done on the RESPONSE side.

Other articles:

• Consent to deny Sharing for Treatment and Emergency Break-Glass
• Consent topic
• FHIR topic

MDS2 -- Revision Comment Opportunity

Updated: They moved the deadline for signup to September 15th, 2017

I have been involved in the original creation of the MDS2 (Manufacture Disclosure Statement for Medical Device Security).  This was back in 2004, before I was blogging...  The first revision was a major change to align with IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network in 2010. The second revision to improve usability Major upgrade to MDS2 to align with IEC-80001 in 2013

It is being revised again, and there is a call for participation. Hurry, there is only a week to signup -- September 8th deadline.

This is intended to be a Security Disclosure statement from a Medical Device (any health software too) to someone purchasing. It is intended to explain the security capability, environmental expectations, and residual risk that would need to be managed by the purchasing organization. Security is a critical collaboration between the manufacture and the user of any system. This form is intended to enable this collaboration.

The Medical Imaging & Technology Alliance (MITA) is announcing an effort to revise the existing HIMSS/NEMA Standard HN1-2013 and develop it as an American National Standard. This standard consists of the Manufacturer Disclosure Statement for Medical Device Security (MDS2) form and related instructions how to complete the form. The intent of the MDS2 form is to supply healthcare providers with important information to assist them in assessing the vulnerability and risks associated with protecting private data transmitted or maintained by medical devices and systems.

If you are interested in participating in the development of this standard, please fill out the information requested below and return to Peter Weems (pweems@medicalimaging.org) no later than August 31, 2017 September 8, 2017.

• Name
• Organization Represented
• Brief Description of Organization
• Email Address
• Telephone Number
• Interest Category
• Interest Category Descriptions

General Interest—Organization or individual that has an interest in the use of equipment included in the scope of this Standard, but neither produces nor uses it directly.

Government—Government agency or department that has an interest in the use of equipment included in the scope of this Standard. Please note that a government agency or department that uses this equipment should select the USER category.

Insurance--Insurance agency or department that has an interest in the use of equipment included in the scope of this Standard. Please note that an insurance agency or department that uses this equipment should select the USER category.

Producer—Manufacturer of equipment included in the scope of this Standard.

Testing Laboratory—Organization that tests equipment included in the scope of this Standard to established specifications.

Trade Association—Trade Association or society that represents the interests of manufacturers or users of equipment included in the scope of this Standard.

User—Organization (company, association, government agency, individual) that uses equipment included in the scope of this Standard.

User-consumer—Where the standards activity in question deals with a consumer product, such as lawn mowers or aerosol sprays, an appropriate consumer participant’s view is considered to be synonymous with that of the individual user – a person using goods and services rather than producing or selling them.

User-industrial—Where the standards activity in question deals with an industrial product, such as steel or insulation used in transformers, an appropriate user participant is the industrial user of the product.

User-government—Where the standards activity in question is likely to result in a standard that may become the basis for government agency procurement, an appropriate user participant is the representative of that government agency.

User-labor—Where the standards activity in question deals with subjects of special interest to the American worker, such as products used in the workplace, an appropriate user participant is a representative of labor.