Wednesday, February 21, 2018

Maturing FHIR Connectathon without confusing the marketplace

Grahame, being the fantastic Product Manager for FHIR that he is, is asking the FHIR community for input on how FHIR Connectathon should evolve. I started to write a few lines but realized that I had more to say than a few lines. (yeah, I know... blah blah blah)

IHE has been doing Connectathons for almost 20 years (First was in 1999 with Radiology). IHE did NOT invent the concept of Connectathon. I was involved in TCP, IP, UDP, NFS, TELNET, and FTP connectathons back in the late 1980s. They were almost exactly the same kind of events.   I have a detailed article on what a Connectathon is, and is not... please review it - What is Connectathon?  I have also written about how nice it is to see FHIR Connectathon changing.

I think IHE and FHIR need to be as distinct as possible, But clearly there will be overlap. Each holds a unique position today that those of us that are involved in both see clearly. However the outside world finds it hard to differentiate already. This perspective to the outside world should be seen as a very important factor. If the consumers of our standards and connectathons don't understand the value, or are confused by it; then it is not valuable or clarifying.  

This does not mean that the overlap should be avoided, it should just be deliberate and clearly communicated.  So far, FHIR Connectathon has been more of a 'hackathon', and that has been exactly what FHIR community needed. The value today: very quick (agile) testing of the specification, proving ground for app development ideas, safe place to share ideas and push oneself. A critical part of this success is that it is short (1.5-2 days), very inexpensive (compared to IHE Connectathon), very informal (compared to IHE Connectathon).  These are strengths of FHIR Connectathon today that we should not forget.

The mature part of that FHIR community is ready to move to a new step. I don't think that new step is all the way to what IHE Connectathon does, and certainly far away from certification (which is also what IHE Connectathon does for certain tracks).  The less mature parts of FHIR community do need a less formal place to play, however things like FHIR Dev Days are possibly filling this need?

So, where possible, cooperate with IHE Connectathon. Leverage the same tooling where possible. Leverage the same process and event space where possible.

IHE should focus on multi-standard use-cases, and domain specific use-cases. IHE should focus on end-to-end flows that are documented in a Profile or Implementation Guide. 

FHIR should focus on building block use-cases that use FHIR alone, and generally re-usable use-cases. FHIR Connectathon would be more the place to prototype, to investigate, to develop a concept, to build a consensus.

FHIR Connectathon should continue to advance the complexity of the scenarios, the Integration of small scenarios into larger ones.  Mature the testing of building block scenarios such that they can be held up as complete, something that can be used to do BDD or TDD. A 'standard' modularity beyond what we see today as a 'standard', that is not just the 'encoding', but also testing and block building.

This does not mean FHIR Connectathon doesn't do full end-to-end workflows. Just like it doesn't mean IHE would never do hackathon like things. The overlap will exist, it should just be clear.

Keep our eyes on the Purpose of a Connectathon

To a standards organization, a Connectathon is a way to mature the standard. Both IHE and FHIR have connecathon as a required part of their governance of maturity.

The purpose of a connectathon to a participant is to gain experience interoperating with your potential future partner in a real-world exchange. By focusing on testing in a safe place like a connectathon, one can push the limits of ones own software. The take-away is a confidence that when a customer needs your software to talk to that specific peer, you have high confidence that it will work right away, and if it doesn't then you have experience that guides your reaction including possibly calling on that personal relationship you created at connectathon. 

Formal checkmarks, or certification, are far less valuable than this. Mostly because reality will happen, and that checkmark or certification means nothing when reality isn't working.

Other articles of mine 

Sunday, February 4, 2018

Apple should have a HEART


Apple has re-entered the Healthcare space with their new announcement about support for a person to maintain their health data on their iPhone. There is really nothing technically new, but new or not is not the important bit. What is important is that any visibility given to the Health Data portability problem is good for making changes.

My understanding of what has happened is that Apple has moved from their own proprietary API support, to support for Argonaut defined APIs. These Argonaut defined APIs would qualify as a 'standard', they are based on #FHIR at an older version - DSTU2. So their adoption of a standard API is big. It is not hard, many have done exactly this. But it is big because it is Apple; and with Apple we get marketing of the usefulness of the concept, and we get a motivation for Providers to support the Argonaut API.

The bad news is that this is DSTU2, and that brings a risk that these APIs will be frozen at a non-Normative version of FHIR. I hope this doesn't actually happen. I hope that they evolve as FHIR evolves to Normative. The fact they started with DSTU2, and are ignoring the current STU3, is not good news for this hope of future normative FHIR.

Consumer empowerment aspect

My understanding of what Apple has done is adopt the SMART-on-FHIR security method, and the Sync for Science privacy method. They expect the Patient (their user and iPhone owner) will navigate to each of their supported Healthcare Providers, interact with their portal to give authority to release the records to that iPhone application. This is a model defined as "Sync for Science", a really unfortunate name as the name came from the original scope but the solution is generally useful. 

The benefit for Healthcare Providers is that they manage everything about the identity linkage, they own the username (password) the patient uses at their portal, and they own the linkage from that username to their Patient ID, and they manage the Consent holding the patient authorization to release to a specified and future authenticatable application on the iPhone..

The Healthcare Providers usually mange the Identifiers by sending their known patients a postal mail letter with a username and a one-time-secret. The person logs into their portal, gives the secret, and then proceeds to create the password they want. Once this is done, the Healthcare Provider has confidence they can manage the username/password, and that they know strongly which patient that represents.

The Healthcare Provider manage consents using whatever system they have internally. The consent never needs to be in a standard form, or any specific form or availability beyond what their organization needs. It just needs to utilize OAuth mechanism to bind the instance of the application the patient is using with the patient authorization (consent).

Lastly, because it is a relationship with the Patient themselves, when the Healthcare Provider release the data, they are logically releasing the data to the patient themselves. So no Business Associate concerns.

Apple in this case is just hosting an application, they are also the author of that application. They never need to know the Patient Identity, but they will be given highly sensitive patient data.

Why Apple changes everything?

So why is the fact that Apple is just doing what many applications have done before a big thing?

Apple has a huge number of people in the Apple ecosystem. Therefor the effort that existing Healthcare Providers need to do to support Apple is a better return on investment. Even if one only considers the 'bang for the buck' in terms of the number of that Healthcare Providers patients (bang) for the level of effort to do the work (even if high).  Note this is a motivation for Apple previous architecture that used proprietary API, but use of standards add to scalability.

Apple people trust Apple will keep their information and information about what they do on Apple private. This is unlike other big identity providers like Google, or YAHOO. The Apple people are special in this way, but so is the Apple organization. They have a proven track record (unlike YAHOO) of keeping their data secure, and they have a proven record of not letting their data get mined for advertising opportunities (unlike google).  Therefore the people are less worried that Apple will know what healthcare providers they are seeing. 

HEART

So the current solution is absolutely fine. The problem it has is the ability to scale. This is where HEART comes in. HEART is a standard specification, for which I have participated in the standard development, and have blogged about it.

The basic explanation is that HEART leverages OAuth, specifically a configuration called User Managed Access (UMA), to enable an "Authorization Server" that is selected by the Patient to represent Privacy access control decisions according to rules the Patient chooses. Essentially moving the Privacy authorization decision out of the Healthcare Provider. 

This is done by giving high assurance to the Healthcare Provider that the patient has chosen a specific HEART server as their authorization decision service. Thus the Healthcare Provider can trust any PERMIT or DENY decision that authorization decision service (the HEART service) makes for that patient in that circumstance. This enables the Patient to establish rules ONCE, where in the Sync for Science model the Patient must set the rules as many times as there are Healthcare Providers holding data on that Patient. Some patients have a small number of Healthcare Providers, others have many.

Apple should have a HEART!

This is an elegant solution, but it needs some major new player to make it come to life. Enter Apple. The two factors I mention above are critical. Patients trust Apple, and Healthcare Providers like Apple. These two are unique, as I mention above, but that is not enough.

The third factor is critical. Apple knows high quality identity information about their customers. Thus it is more likely that as an Identity provider, they will be able to more accurately, and more authoritatively, build the binding between their Identity (apple ID) and the various Patient Identifiers at the various Healthcare Providers. This patient identity problem is the biggest 'technical' problem in ALL of the Health Information Exchange (HIE) solutions. Binding a realworld identifier with a Patient Identifier in a way that has few false-positives (hopefully zero), few false-negatives (hopefully zero), and can't be abused by malicious actors (authenticatable and traceable).

Further, the Apple ecosystem is a place where some trust can be placed. If there are malicious misuse of the healthcare data exchange, the Apple ecosystem can be used to find the malicious actor. This is to say that there is trust that Apple knows what the Apple user is doing, and can find Bad-Apples. (sorry, had to).

Conclusion

Is it critical that Apple start to build out their HEART solution? No, but it is exciting that there is finally someone that I think could pull it off.


Wednesday, January 31, 2018

FormatCode granularity

I was asked the following question:
Confused as to the granularity required for formatCode.
The HL7 link seem to be at a course level:
http://wiki.hl7.org/index.php?title=CDA_Format_Codes_for_IHE_XDS
but a recent update has format code at a document specific level:
https://wiki.ihe.net/index.php/IHE_Format_Codes 
This links to FHIR and I assume MHD
http://hl7.org/fhir/valueset-formatcodes.html

Any advice?
----------------------------------------------------
My response


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.
See article: Multiple Formats of same document

Including FHIR Document See article on 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.

---------------
Further questions are welcome.

Saturday, December 30, 2017

HIE Future is Bright - stepping into 2018

This is my overall summary of the Healthcare Standards, Privacy, and Security space. It happens that the framework for explaining why the future is bright for HIE comes from the Wisconsin HIE (WISHIN) fall summit. Note slide decks are now available.  They used the following diagram to show what they viewed as the HIE future. I like it, so will use it here


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.

I have written articles about each of these transitions and more. Here they are

My Perspective

The big factors as I see it:
  1. The Document model is still very important, even if it is frustrating. This is especially true of historic episodes and visits. These historic events need to have the full context of them, which is what a Document model provides.  
    • The good news is that FHIR has a Document model, and the FHIR Document model has a directly convertible data model
    • A FHIR Document travels an HIE easily
    • CDA will fade, but never disappear. It is just way too hard to get right.
  2. The future will be more about automating the consumption. Up to now we have focused on getting EHR to publish or simply make available the data they have. This first step is critical to Interoperability. We now need to focus more on data consumption, as the way we consume Documents is not optimal or even functional.
    • The good news is that FHIR is a fantastic API for consuming data. So there is a rich opportunity to make the consumption experience better 
    • Enterprise class API  ==>  FHIR API to Document Sharing
    • FHIR has subscription model, to make service-to-service API more efficient and responsive
    • FHIR has ability to bundle and disassemble without conversion or loss
  3. The future will connect the nation. Today there are a small number of very large networks, but there are no linkage between them. So if you happen to live in a part of the country where you need to go to doctors within different networks, then you must manually transfer the data yourself
    • The good news is that there are talks and actions to unite eHEX, CareQuality, CommonWell, and others.
    • Not just technically, but also logically. We need nation wide policies on the use of Vocabulary, Document formats, and Care Planning
  4. The bad news is that Security and Privacy are going to get worse before they get better. This is more a statement of security than Privacy. I don't see any of these future benefits abusing Privacy, but I am worried that Privacy-By-Design isn't ingrained. I am more worried about Security, in that the security model for FHIR is very immature, and the junction between FHIR and the other worlds where the data exists.  This is not to say that OAuth is bad, but rather the healthcare use of OAuth is not mature, and the healthcare needs of OAuth are well beyond what OAuth was designed to do.
    • The good news is that there really is plenty of time in the coming years to work this out. What we need is interested bodies to get involved with open consensus prototyping, trial, documentation, and improvement.

The future might get the Patient more center to their own care. Today the GP drives everything. I don't think they want to, but it is just too hard to do anything else. Some say there is business pressure to keep control within that doctors office, I don't think this is all that true. I think it is more simply too hard. First, most patients are not technically savvy, that is changing. Second, most patients are not feeling well, so it is hard to take leadership. MOST important it takes a community to put the patient at the center, and we don't yet have a connected community.

These will not happen in 2018, I am just predicting they will be the central motivations that will influence change. If they happen, all the better. We must remember that change takes far longer than one expects it should.

Some blog articles I am working on:

  • Direct HISP on FHIR - replacing XCA api with a FHIR api
  • Meaningful Use means IHE PDQm, MHD, QEDm, and mXDE
  • Reverse MHD
Please contact me if you have a topic you would like me to cover.

Monday, December 18, 2017

IHE PDQm and MHD - FHIR conformance resources

I have been pushing IHE to add FHIR conformance resources to their publication mechanism. I now have published the full set of FHIR conformance resources for PDQm and MHD profiles. Also available is mCSD by Luke.

A bit of background. FHIR conformance resources are available to carry programatically the constraints that historically IHE has written narratively into an IHE Profile. An IHE Profile is a standard that takes a Use-Case and creates an Interoperability solution. This is done using long standing IHE Governance through a standards selection process, standards development process, public comment review, trial-implementation phase, and connectathon testing.

An IHE Profile is very similar to an HL7 Implementation Guide. Each organization has variances, but both can do similar effort. IHE has been doing Profiling since 1998

IHE as an standalone organization can very easily and cleanly Profile large use-cases that require the interaction with many different standards. Profiling that needs to simultaneously invoke HL7 v2, DICOM, and eb-Registry are the biggest strengths of IHE. Where as HL7 is more limited to writing focused Implementation Guides around the HL7 specific standards like FHIR (US-Core) or CDA (C-CDA). Much more is likely going to be said about this in the future. HL7 and IHE are working to find a good way to cooperate and complement.

Patient Demographics Query for Mobile (PDQm)

I will be clear the reason this is an IHE profile is because of long standing set of Profiles of the exact same use-cases that show how to constrain HL7 v2 messaging, and HL7 v3 messaging. Thus, they are historically in IHE from 2003 (14 years ago). Given that IHE had PDQ and PDQv3 published, the IHE audience wanted to see the FHIR flavor. Thus PDQm exists. The reality is that this profile is about as unconstrained as a profile can be. But because it exists, we need to publish FHIR conformance resources.

The best place to go is to the IHE wiki page for PDQm, as any updates that happen in the future will be updated on that page. There is a section on this wiki page dedicated to PDQm FHIR resources. That page is also what all of the FHIR conformance resources point to as the narrative 'implementation guide'.

Informatively the PDQm profile is also published on Simplifier. See https://simplifier.net/IHEPDQmimplementatio

These conformance resources are also registered at https://registry.fhir.org

The following links are to current copy in Simplifier. The canonical URI is also given as the permanent URI. The canonical URI is not usable in a browser, but may be used at the FHIR registry

Note that previously we did publish a StructureDefinition for the PDQm Patient Resource. This has been removed as IHE PDQm does not constrain the Patient Resource at all, and therefore the STU3 Patient StructureDefintion is now referenced.

The conformance resources are also available on the FTP site ftp://ftp.ihe.net/TF_Implementation_Material/fhir/

Mobile Healthcare Documents (MHD)

The MHD profile is also an IHE profile due to the history of IHE XDS/XCA/XDR/XDM etc. The Document Sharing family. Thus IHE shows how to use the FHIR standard as an API to these XD* environments.

The best place to go is to the IHE wiki page for MHD, as any updates that happen in the future will be updated on that page. There is a section on this wiki page dedicated to MHD FHIR resources. That page is also what all of the FHIR conformance resources point to as the narrative 'implementation guide'.

Informatively MHD profile is also published on Simplifier as a set of FHIR conformance resources, that are also registered at https://registry.fhir.org

Note the following links are to current instances maintained in Simplifier. This URL may change over time, which is why the canonical URI is provided. The canonical URI can not be used for browser navigation, but can be used for lookup at registry or simplifier as search capability allows.

Prior conformance resources have been registered, they should now be marked retired

Conclusion

I likely have made mistakes... Please point them out to me so I can fix them. I am very open to opportunities for improvement.






Tuesday, November 28, 2017

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

Sunday, November 26, 2017

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.