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.

Saturday, November 25, 2017

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. 

Friday, November 24, 2017

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



Wednesday, November 22, 2017

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

Tuesday, November 21, 2017

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.