HIE future bright -- FHIR API to Document Sharing

I think the most useful value-add that an HIE can add is an API that is based on FHIR. This is true of an XDS based HIE, Regional Exchange (XCA), Vendor based EHR, nationwide Exchange, and Direct HISP. It is something I expected to be more included in the WISHIN Future is bright conference.

At an HIE level:

• Initially I would focus on enabling Apps to query for and read the data available in the HIE. 
• Later adding capability to publish new content.
• Initially I would focus on Document sized objects, 
• Later moving to more element level.
• Likely move to publishing Documents before element level access
• For targeted Apps, that is the most highly vetted and trusted, they will be Reading and Writing at the Organization level. 

Documents

There has been much focus lately on the publication side of Document Sharing. Great advancements in CDA content formatting. This work done largely by a set of people that work within IHE Patient Care Coordination (PCC) and the HL7 StructuredDoc workgroup. Both of these groups do much of their work together. Trying to keep up with the number of calls that they have will fill half of your week, every week, week after week.

So today we have really good specifications of how various types of Documents should look like. The C-CDA Implementation Guide is considered the pinical of this work.

Why Documents? Well I covered that before, but the short answer is that because we are looking at communicating data outside of one organization, we need to carry with the data a good amount of context of that data. Not just Provenance (Who, What, Where, When, Why), but also care setting, intention of the event, duration of the event, etc... This context is very important to the meaning of the data contained. Especially if the data is historic.

Note that Documents does not just mean CDA. A Document Sharing environment can share FHIR documents.

Apps accessing Document Sharing (HIE)

In the case of a Document Sharing exchange (XDS, XCA), the API would enable an App to query for a specific Patient, and any Documents that are available for that patient. The IHE PDQm and MHD profiles are defined to do just this. One just needs to define carefully which parts of these profiles that are implemented. These parts are separately defined in the profiles so that they can be chosen alone.

The HIE would implement the PDQm Supplier actor. This actor has an API that can be used to query for a Patient record using a set of query parameters. There is no special magic in the IHE PDQm profile, it is just a FHIR Patient. By being an IHE Profile, the capability that is needed is easily specified as simply an IHE PDQm Supplier actor. The only other actor in the profile is the IHE PDQm Consumer, which is what the App would implement to execute searches.

The MHD profile needs to be approached similarly. In this case the IHE MHD profile contains four Actors, only two of which are needed for Query/Read. The other two are used for Publication.

The Document Consumer actor is the one that the App would implement, and the Document Responder is the actor the HIE would implement. This mirrors the Query/Retrieve side of XDS and XCA; so this same specification works for an XDS based HIE as a XCA based HIE or Community Exchange.

Another simplifying step that the Document Responder can do if it knows that SubmissionSets / DocumentManifests are not all that useful to implement the "Find Document Manifest [ITI-66]" as a stub that always returns an empty Bundle. This is not a recommendation in the IHE MHD profile, but it is a fact that if there are no SubmissionSets / DocumentManifests available then zero results is a valid response.  An App that uses the "Find Document Manifest [ITI-66]" transaction will get zero results found. More likely is that there will be no realistic Apps that look for SubmissionSets / DocumentManifests. This is not to say that they are not useful, but rather that they are useful only in specific and highly complex use-cases.

This kind of a situation can exist in an XCA environment, as there is no mandate that all Communities are XDS communities. It can also happen when the API is being served by an EHR, PHR, or other data source. The only time that SubmissionSets / DocumentManifests are expected is when the Document Responder is an API to an XDS environment. This setting does have an Option "XDS on FHIR".

Direct on FHIR

The last configuration I want cover in this article is to express how the MHD profile can be used as an App API to a Direct based HISP. If you don't know what a "Direct HISP" is, then this section is not useful to you. But if you know what a Direct HISP is, then I think that adding a MHD API to your HISP is a great way to enable Apps that use MHD as a consumer to also be able to use your HISP as a document source.

In this case I might suggest that both sides of MHD be implemented, so that the App could Send Direct messages using the Publication API defined in MHD. This is done just like is done with XDR today, but using the more easy to implement FHIR objects.

Security and Privacy

As with any Interoperability API dealing with Healthcare information, Security and Privacy
are important. IHE doesn’t mandate a specific Security or Privacy model, as that would be Policy. But IHE does encourage the use of ATNA, and IUA. This also described on the FHIR Site on the Security page. The SMART solution has a large following, and thus I need to recommend it over the IHE solution at this time. There is also HEART. I am hopeful they eventually merge and improve.

Conclusion

First step is to add a Document based Query/Retrieve interface to the HIE. This leverages all of the existing infrastructure, and all of the existing documents that have been published and made available. It benefits from all the characteristics of a Document, while leveraging the ease of implementation of FHIR.

So, an HIE regardless of architecture should implement a PDQm Source, and a MHD Document Responder. Wrap that in security from either IUA or SMART.  Because the Apps are already being written to this API...

Also see my FHIR Topic

HIE Future is Bright -- Payers and Providers

The last item on the WISHIN future list is moving to "Shared Responsibility for Managing Care" from "Providers & Payers working Separately" . This seems to be an indication that is mentioned elsewhere, where Payers are being added to the WISHIN network.

It is mentioned

Payer access with WISHIN will become a reality Q1-2018

I wrote a short note about this in the Single Connection Hub article. In that article I emphasized that the technology is enabled for many purposes, including "Payment" purposeOfUse.  So the technology is not going to get in the way. 

Managing Care is a team sport

I think the point of this item is that getting Payers more actively aware of what is happening with the Patients they cover will help improve the Care outcome. This is controversial, and indeed most Privacy theories use just this scenario as a forewarning of bad things. These stories say that when the Insurance company gets too much knowledge of the Patient they will increase the cost of Insurance, and drop support for the kind of medical problem the Patient is suffering from. I am not going to counter this point. I am just going to fully acknowledge that it is possible.

I think though that we could take an optimist view. First, lets use "Privacy by Design" to indicate that the Insurance company access SHOULD be only allowed when the Patient has authorized it. This is not strictly necessary, especially in the USA under HIPAA; as HIPAA fully allows "Treatment, Payment, and normal Operations". But lets assert that a good "Privacy by Design" step would be that the Insurance would have HIE like access only with authorization from the Patient. It might not be mandatory, but it sure would alleviate some worry. I also suspect that a large number of patients would authorize it, enough so that the concept of "Managing Care" by including the Payers is a sound concept.

Second Privacy-By-Design thing I would like to see is Transparency. That was discussed by me many times, it is the function where the Patient is made aware of all accesses to their data regardless of why. In this way the Patient would see when accesses were made by a Payer, and thus feel better the positive outcome. They would also be enabled then to see the negative outcome if it happens. Again, the Transparency helps with proving that the Payer should be trusted, and that the outcome is for the benefit of not just the Payer but also the Patient.

Please don't give Payers unconstrained access to all Patient data. That is a Payer should be constrained to the Patients that they have a Legitimate Relationship with. The alternative is that Payers will troll the HIE for Patients that are rich and healthy, so that they can target marketing.  This Legitimate Relationship is a difficult thing to do, by what authority is this Legitimate Relationship maintained? One solution is that Patient Consent solution I give above. It is however a bit slow. I might not have a solution, but I am worried about the risk.

What benefits?

I think that the Payer has good data on how they are losing money by badly behaving Patients. Things like seeing many doctors for no better diagnosis, such as a hypochondriac might do. Things like drug-seeking through visiting many doctors. I am sure there are many more that I am unaware of, and couldn't quite imagine just how creative Patients are at screwing Payers. All of these are not just ways that the Payer gets screwed, we all are affected. Money lost one way, must be found another way.

Patients, well meaning as they might be, don't always do as they are instructed by their Clinician. I am guilty of this myself. The problem with non-compliance is that it results in sub-optimal recovery. Sub-optimal recover means that a future injury to that area is easier and will result in worse harm. Thus it is in the interest of the Patient to follow the Clinician's instructions, but sometimes it doesn't happen. One of the big ways is that we patients stop our treatment when we feel better, which might be before we actually are better. The well compliant Patient is also in the interest of the Payer, as the payer understands the benefit of optimal recovery, and the future problems of sub-optimal recovery. Thus the Payer really has an incentive to keep the Patient compliant.  It is strange to recognize the fact that the Clinician has no incentive to keep you compliant, except through Meaningful Use disincentive around re-admission. 

Conclusion

I have no question that getting Payers involved can improve care outcome. I am equally suspicious that it could be a benefit only for the Payer. The Privacy-By-Design using the Privacy Principles would be the right thing to do. 

I would love to hear other perspectives on this. Please comment.

HIE Future is bright - single connection to hub

The next item on the HIE Future is Bright list is movement from "Multiple Point-to-Point Connections" to "Single Connection to Hub". This change is purely administrative, but is still significant.  Again, I will state that I was not at the WISHIN meeting, so I don't know what they said about this. I will guess, but will keep my guesses here limited. I welcome comments to fill in details on what you think this transition means.

I suspect that this is more a statement about what the WISHIN organization will do to help the remaining organizations get connected. The existing organizations already have the connections, and are likely not going to gain anything by reducing 3 interfaces to 1 interface. A healthcare provider organization that has not yet connected would find one interface vs 3 interfaces to be a significant reduction in work.

WISHIN is three networks

I picked on the number three because it is the number of big services, but there are many services. The following is probably similar to many regions (e.g. state HIEs): 

1. Direct Secure Messaging -- They have a a HISP, and ability to issue Direct addresses on the WISHIN domain; all as part of DirectTrust.  
2. Wisconsin wide network -- They connect Wisconsin sites within WISHIN. And maintain Patient Privacy Consents that they enforce.
3. onramp to eHealth Exchange 
4. Wisconsin Provider Directory
5. Wisconsin wide Patient Record Locator
6. Public Health Reporting
7. Hospital Visit report
8. Provider Portal access to all of this

Beyond Wisconsin

In the slide deck they also look at other nationwide exchanges:

• CareQuality -- a newer flavor of eHealth Exchange. Both are managed by Sequoia Project. Both use IHE XCPD and XCA standard
• CommonWell -- a EHR vendor consortium. Uses mostly the same IHE XCA standards, but has a different method of doing Patient Discovery that they call "Record Locator Service", and is based on centralized Master Patient Registry (MPI) feed constantly by HL7 ADT feed.
• Epic CareEverywhere -- Network maintained by Epic, mostly for the benefit of Epic customers. It is also based on XCA, but has some advances that are being integrated into CareQuality.

Unfortunately for me, the conclusion is not in the slide deck. I suspect what they concluded is that WISHIN should connect to these additional networks so that each Provider Organization in Wisconsin doesn't need to. This is logical, and why the XCA standard expects multiple Communities and nested Communities. 

Note also that there is efforts within these three networks to merge the capability. The would likely stay as independent networks, but automatically bridge seamlessly. Enabled by the XCA Community concept.

Beyond Providers

There is one mention in the slide deck that shows another vector WISHIN is looking to get connected. 

Payer access with WISHIN will become a reality Q1-2018

The underlying standard (XCA) is designed to support many kinds of access, most exposed by the PurposeOfUse assertion. In the case of most HIE traffic today it is for the PurposeOfUse of "Treatment". When Payers come on we can get probes of "Coverage", or queries for "Payment". This capability of the standard can be expanded to support various Clinical Research purposes too.

FHIR?

Very minor mention of FHIR.. but surely they are working on adding MHD and QEDm like APIs?

Conclusion

There is almost always some opportunity to remove unnecessary complexity. 

If you have other ideas about what "Single connection to hub" means, please comment.

HIE future is Bright -- Notification and Alerting

At the WISHIN conference this discussion would have interested me most. I might then have become distracted. By the title, and given my background, I would have thought that this was a mechanism to inform the Patient of when their data was used. A really important Privacy Principle. However I think that it is more a growth of a very interesting use-case that drove the very early HIE within Wisconsin, well before the push in the last decade.

Wisconsin, as I understand, had a network among the large hospital systems in the South-West (Milwaukee, Racine, Kenosha). This was Pre-ObamaCare. This was Pre-HITSP. I think this was back in the 90s. The network was created to help detect malicious patients that would go to various Emergency Room sites seeking dispensing of narcotic drugs. The network would be used in the Emergency Room to detect these patterns, and stop them. Two benefits: A bit of paternalism effort to cut down on drug use, but the main benefit is that any drugs dispensed would not be reimbursed and thus these hospital systems were loosing money. Thus, follow the money...

WISHIN started in 2009, and leveraged this network. Given the slide decks given a the WISHIN conference, it seems that this concept is going state wide. Not only that but they are finding that this kind of a system might be useful for other administrative things.

I don't have the background to better explain this "future". The Patient Activity Notification Report is described. I do see enough "value-add" described to understand why it is being worked on, and why it would be a selling point for the WISHIN service. This gets to the very fact that a HIE is a very useful thing, but it costs money to build, run, manage, and support. This money needs to come from somewhere, so it is a common discussion within HIE organizations on how they can build value that can provide income to support the network.

The potential link to Patient Care is through notification of the Providers when their Patients receive treatment elsewhere. This seems to be being developed. It is not a core function of a Query model network like XCA. I suspect a more robust mechanism should be developed, especially as it supports CarePlans and CareTeams; the last improvement on the WISHIN list.

Conclusion

It would be so much better if these HIE networks cost nothing, but the reality is that they cost something and thus need to be supported.

If you have a different idea, please comment. 

HIE transition to Patient-Centered from Provider-Centered

The whole concept of  Health Information Exchanges, that I have been involved with, is there to improve Health outcomes for the Patient. So I often get frustrated when someone says that the HIE needs to become Patient Centered. I am a Patient in Wisconsin, and I feel the impact of WISHIN. There is no other purpose of an HIE besides the Patient. I have to take a few breaths and remind myself that better outcomes for the Patient is fantastic, but that the Patient doesn't 'feel' like they have any say or involvement. It is this that needs to improve.

In Wisconsin we do have Consent, specifically there is a state wide system for a Patient to choose to NOT allow their data to be shared over the exchange. This does not give them much other than ON vs OFF. But it is more than some.  So, this is usually first step in moving from a Provider-Centered to a Patient-Centered model.

This level are not fantastic, but it is far better than what we had a handful of years ago when there was no network. There is a bright future for the Health Information Exchange too. I want to expand upon the future transition from Provider-Centered to Patient-Centered, as a trend that is already underway.

Provider-Centered

First I need to address this statement. There is nothing in existing HIE that is "Provider-Centered". Today's system is highly "Manual", outright hard to use. But that is the last article. I truly feel sorry for Providers that are going out-of-their-way to use an HIE for the benefit of their Patient.

I will say though that this is exactly along the same lines as why "Patient-Centered" is not a good statement either. That is to say that today the Provider gets to interact with the HIE, where as the Patient is just a passenger. Thus Patient-Engaged vs Provider-Engaged might have been the better phrase.

Patient-Centered (aka Patient-Engaged)

So, let me say "Patient-Engaged" as the more clear two word statement. I think the goal of this initiative is to get the Patient more engaged. This might be more actual engagement, but might also be the feeling like being engaged. 

The pretty picture, Wisconsin is a pretty state, on the right shows how well WISHIN has included Patients. Odd choice of colors, as I would have chosen green to be the best case, and red to be the areas where more work was needed.  This graph is a current state, and included means that the given percentage of the population have their data accessible within WISHIN (and thus eHEX). 

The prime Patient need in Wisconsin is to support our tendency, especially the elderly, to fly-south in the winter (Arizona, Texas, Florida, etc). WISHIN has that priority covered through eHEX and direct HIE-to-HIE engagements.   They don't have good coverage with all states, but the southern ones where we tend to retreat to were clearly seen as a priority.  Also, some of the other states that have people that come up to Wisconsin in the summer and fall are also covered. 

The WISHIN system also includes support for Direct-Secure-Messaging, so the theory is that anyone that supports Direct is reachable. 

Here are some other ways to engage the patient more:

1. Provide an Access Log. I would say Accounting of Disclosures, but there are simply too many exceptions that this results in a useless log. I want an Access Log, that is a log of every time my data was accessed (Direct or Exchange) using the WISHIN infrastructure. Who requested the access? What did they ask for? What did they get? When was this? Where was this? Why did they access (PurposeOfUse)?  There no network that I know of that provides a view of how the HIE was used to expose the Patient data. I recognize the concern that Covered Entity have that gives us "Normal Operations" exceptions. I don't like these exceptions, but I understand why they exist. I think that ALL accesses over an Exchange need to be reported to the Patient.
2. Provide API access for applications the Patient chooses and authorizes. In the past this would be covered by a statement of "PHR", but that concept is too limited today. This item is inclusive of the older concept of a PHR, but is also inclusive of newer health Apps. Where a PHR was a system that would copy the patient data and give the patient the ability to connect apps to that copy of the data; now we are looking to use FHIR as a way to connect these Apps directly to the data.  These apps will tend to just need read-only access, but...
3. Provide capability of the Patient to author data. Many patients, myself included, are using many home-care devices, personal-care devices, health-monitoring devices, and sports related devices. These are producing a wealth of information, much of it is just background measurements. These measurements are not accessible to Providers unless they can be contributed on-behalf of the Patient.
4. Provide the Patient to challenge the validity of data. Once we can see the data, we will surely find some mistakes. Being able to challenge the validity of the data is essential. Even HIPAA acknowledged the need for the Patient to 'Amend" their data. I say challenge as to be closer to "Patient-Centered" or "Patient-Engaged". 

I'm sure there are others. I base these on the Privacy Principles

Summary

Caution. I have a long history in Patient-Safety, and Security. Thus I recognize the need to be careful with adding any capability. We must do "Risk Assessments" and mitigate the risks.  The new capabilities are clearly helpful for Patients that want to use them to better their health. However these new capabilities can be used maliciously too. Someone might use these new capabilities to gain advantage on someone else. Someone might use these new capabilities to gain themselves an advantage. We must consider someone who is Motivated, Capable, and Funded; along with mixtures of these. Engaging the Patient, means enabling abuse.

Benefit. Many patients can help with their own health if only they could get accurate data. Healthcare is about the Patient, it should be not just about the patient but with the patient.  Every living creature is a potential Patient, this should be obvious as an important priority.  The cynic would say that the law recognizes corporations as entities, well that kind of entity is never a Patient.  Humans are so much more important.

What is your ideas????? Please post comments

HIE Future is bright - Automated not Manual

I think it is important to celebrate what we have today in Health Information Exchanges. They are not fantastic yet, but they are far better than what we had a handful of years ago.  However there is a bright future for the Health Information Exchange too. I want to expand upon the future transition from Manual to Automated, as a trend that is already underway.

Manual HIE

Today we have Health Information Exchanges that enable Providers to send Directed Secure E-Mail messages to other Providers. This s a conscious thought, usually when referring a patient, or when a patient asks for this to be done. This is basic PUSH capability. The word basic should not be viewed as easy or trivial. There is a huge progress that gets us to the point of being able to say that this capability exists and is mostly ubiquitous.  We should celebrate getting to this point. But we should not stop here.

The Query model of Health Information Exchange also enables a Provider to publish a document they created under the hope that someone might find it useful. This is available, but who really has the extra time to publish something under the hope that someone might find it useful in the future.  But this Query model does have documents that are available, and those documents are found to be useful.

Most of these documents are not documents that are written and published. Most of these documents are documents that someone asked if they existed, and then the document was created. So even in a Query model, it is a manual step of someone asking if a document exists, followed by a document being assembled at that time.  This is either "On-Demand", or "Delayed-Document-Assembly".   In the case of "On-Demand", a prototypical document is published as available, which when Retrieved causes a fresh document to be created from current information. In "Delayed-Document-Assembly" a prototypical but specific document potential is published, which when Retrieved causes that specific document to be created. The big difference is that the "On-Demand" is made from current information, where "Delayed-Document-Assembly" is made from historic information.

The manual part in this case is that the recipient is manually choosing to Query the network to see if anyone has documents available for a specific patient.

Manual is not bad. Manual is the first step. We must go through Manual to get to Automated. It is time...

Future is Automated

In all of the Manual use of an HIE, there is a conscious effort to take action and use the HIE. This is really bad User Experience. What we really want is that the HIE capability, availability of patient data, is automatic. There should be no effort to consciously use the HIE. If the HIE can be useful, the 'system' should just use the HIE.

1. When a Patient is scheduled for a appointment or procedure; the 'system' should gather all the data available. Not just gather it, but process it into useful information, perhaps using a new mXDE profile from IHE.
2. When a Patient is at a registration desk; the 'system' should gather all the data....
3. Inappropriate activities are detected and appropriate authorities engaged. Such as Providers using break-glass, unusual billing patterns, or drug seeking patients. These patterns would not be noticeable within any single organization, but can when viewed across a region.
4. When a decision on a CarePlan is made for a Patient, the 'system' should look for potential experts in the local region, that are covered by the patient's health plan, and have characteristics that the patient has expressed.
5. When a CarePlan progresses, the members of the CareTeam should be appropriately notified. What is appropriate notification will depend on their role. Some will see the Patient show up in their census. Some will have time on their schedule reserve to review the CarePlan activity...
6. When a clinical research project is initiated, and where the Patient has expressed interest, that Patient's pre-arranged preferences (on the blockchain using smart-contracts) for participation will engage. That is the Patient will express interest, and conditions. This might mean that the Patient allows their fully-identified data to be used, partially-deIdentified data to be used, etc.. Including conditions of contact, conditions of notification. The preference might be to just notify the patient and nothing more.

I expect many more automated use-cases. These however are ones I know are actively being worked on. Like how about an automated analysis of treatment to discover better outcomes, and promote the plan of care that got that better outcome?

The Future is bright, but it must be appropriately designed

The point of Automated is that the HIE needs to move from something we think about, to something that is automatically used, but used in an appropriate way. Used in a way that is comprehensively more productive, more privacy respecting, more safety protecting, and more efficient. All of these must be considered. We can't automate and give away Privacy. We can't automate and give away Safety. We can't automate and give away better treatment outcomes. We can't automate and give away financial efficiency.

What is your ideas on how HIE can be made more Automated? Please post comments...

Future of HIE is bright

The Wisconsin HIE (WISHIN) held a summit last week. I signed up, but was unable to make it due to schedule conflicts. Their slide decks are now available and I am very sad I missed it.  The following diagram clearly shows Wisconsin leadership

This is such an exciting perspective of what the Wisconsin HIE delivers today, and where they are targeting for future support.

The other slide decks further elaborate on this plan. It is driven by delivering Value, not just Volume.  They had a segment that focused on Care Coordination as a driver of these changes.

They also have a comparison of nationwide HIEs, that is hard to disagree with the slide deck as there is so little detail present. There does seem to be a decidedly Wisconsin bent to the comparison. Focused on CareEverywhere (Epic solution), and on viewing WISHIN themselves as a solution. This is all expected, but not very helpful for use of the evaluation elsewhere.

I also found interesting the statistics slides. I don't have much to compare them to, so don't know if this is good, bad, or indifferent. It seems to me that the statistics show a really strong and healthy HIE. Widely implemented, with really good engagement.  But, then again I am a proud Wisconsinite. Also, I must note that I was on the Technical Advisory Committee in the early years. I think I am still listed, but have not heard about any meetings of that committee in a long time.

Note they are not ignorant of FHIR, I suspect it is going to be engaged in some of these future capabilities. I suspect it is more likely to be engaged in capabilities beyond this future.

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