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.

No comments:

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.






1 comment:

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
No comments:

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.

No comments:

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.
No comments:

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. 
No comments:

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



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

No comments:

Tuesday, November 14, 2017

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.

No comments:

Friday, November 10, 2017

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:
No comments:

Tuesday, October 10, 2017

Granularity of FormatCode

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

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

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

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

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

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

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

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

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

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

No comments:

Wednesday, September 27, 2017

#FHIR and Bulk De-Identification

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

Bulk Data Access

The addition of a Bulk Data Access in #FHIR was a hot topic at the San Diego workgroup meeting. Grahame has explained it on his blog. What is not well explained is the use-cases that drive this API request. Without the use-cases, we have simply a "Solution" looking or a "Problem". When that happens one either has a useless solution, or one ends up with a solution that is used in appropriately. The only hint at what the Problem is a fragment of a sentence in the first paragraph of Grahame's blog article.
"... in support of provider-based exchange, analytics and other value-based services."
Which is not a definition of a use-case...  But one can imagine from this that one use-case is Public Health reporting, or Clinical Research data mining, or Insurance Fraud detection... All kinds of things that Privacy advocates get really worried about, with good reason.

De-Identification

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

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

De-Identification is a Process

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

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

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

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

De-Identification as a Service

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

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

De-Identification Algorithm Consideration

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

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

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

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

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

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

Just a hint of what it will take...

Conclusion

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

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





1 comment:
Subscribe to: Posts (Atom)