Tuesday, July 10, 2018

7 Things to Know about Mesothelioma Survival Rate

7 Things to Know about Mesothelioma Survival Rate

Looking at isolated statistics, like mesothelioma survival rates, can be disheartening, and don’t paint the whole picture for how long someone diagnosed can expect to survive. To help make all the statistics and data easier to digest and understand, we compiled a list of 7 basic facts about mesothelioma survival rate.
What is Survival Rate?

Survival rate, prognosis, and life expectancy are related terms that can often be confused for one another, since each relates to the same general idea: how long can patients expect to live once diagnosed with mesothelioma or another condition. But when looking at the numbers, confusing these terms can make it difficult for patients to understand their own expected survival or see beyond the data.

Survival rate indicates the portion of people with the same type of cancer, for instance pleural mesothelioma, who survived a certain amount of time after diagnosis. Essentially, survival rate is a statistic that can provide a bigger picture of what a patient may expect in terms of length of overall survival and if their treatment may be successful.

Get a Free 2018 Mesothelioma Treatment Guide
Survival Rate Alone Can Be Misleading

Considering these statistics on their own, however, can be a bit misleading. Survival rates are data estimates looking at a wide array of patients during the particular time frame, like 1 year or 5 years after diagnosis. This data doesn’t take into consideration any of the individual factors that influence how long an individual could survive, such as their overall health or the stage of the disease.

Survival rates may also be skewed due to the lack of data available, especially for a rare cancer like mesothelioma that only has around 2,400 – 2,800 new cases each year. For mesothelioma, much of the national survival rate data includes up to around 2014. While this is still rather current information, it may leave the most current research and treatments unaccounted for, possibly making survival rates appear lower than they actually are.

So while patients and their families look at these statistics, they should also keep in mind this only shows part of the picture. Individual prognosis or life expectancy will be more specific to the patient, as the doctor will be able to assess how the disease is expected to progress and treatment opportunities based on specific patient characteristics, like age and gender, in combination with diagnosis specific details like cell type.
Understanding Overall Mesothelioma Survival

When looking at the broad spectrum, mesothelioma survival statistics can be rather intimidating. Across all mesothelioma patients in the United States, regardless of what type and the stage of cancer, only 55% of patients survive one year after diagnosis. After three years, only about one-third of patients are expected to survive. The 5-year survival rate is only estimated at about 9%.

These isolated statistics are understandably disheartening, and can be difficult to come to terms with. The good news is each patient’s case is unique, and there are a number of factors that can indicate a better chance of long-term survival. The disease progresses differently in each individual, and treatment can also greatly influence one’s likelihood of survival.
Factors Impacting Your Survival

As previously mentioned, there are a number of factors that go into determining an individual’s expected survival and there is no one answer for how long mesothelioma patients will live. All these factors together will help a mesothelioma doctor determine how the disease will progress, what treatment options are available, and ultimately, the patient’s expected survival.

The stage of mesothelioma when diagnosed is one of the most important factors in determining survival rate. Early stage mesothelioma, such as stage 1 mesothelioma, indicates a smaller tumor size and that the cancer is localized to one part of the body. This makes it much easier to treat, and patients see a better survival of on average 1.5 to 3 years after diagnosis. Unfortunately, most mesothelioma patients aren’t diagnosed until a later stage that have more limited treatment options. Stage 4 mesothelioma patients, for example, on average survive only about 12 months as the cancer has likely spread to the lymph nodes and other parts of the body.

Type and cell type of mesothelioma also significantly impact mesothelioma survival rate. Pleural mesothelioma, which originates in the lungs, is the most common type, but doesn’t have the best survival rate. Researchers estimate about 73% of patients survive one year, but survival drops drastically to just 23% at three years after diagnosis. Peritoneal mesothelioma, which affects the abdomen, isn’t as common but has the best survival rates of all the types. About 92% of patients survive one year after diagnosis, with still about 65% of patients surviving at least 5 years after diagnosis. Since pericardial mesothelioma is the most rare and often not even discovered until posthumously, survival rates are much poorer, with only 51% of patients surviving one year.

With cell type, epithelioid mesothelioma responds the best to treatment, so generally indicates a better survival. Overall, patients with peritoneal mesothelioma with epithelioid cells have the longest survival, on average about 54 months. Sarcomatoid cells are the most rare, don’t respond well to treatment, and are known to spread aggressively. Patients with tsarcomatoid mesothelioma have a median survival of only around 5 months. Biphasic mesothelioma, which is a mix of epithelioid and sarcomatoid cells, has varied survival, depending on which cell type is more predominant.

Survival can also be impacted by a number of characteristics like the patient’s age, gender, and genetics.

  • How to Improve Survival Rate

Though early detection is the best way to improve expected survival, it isn’t always possible because of how mesothelioma develops. A long latency period after asbestos exposure and nonspecific symptoms can lead to misdiagnosis, and ultimately delay treatment. As such, having the appropriate treatment plan is crucial to extending survival.

Treatment has the potential to extend survival by years, especially if patients are able to withstand more aggressive treatment options like extensive surgery. For peritoneal mesothelioma patients who undergo cytoreductive surgery combined with a heated chemotherapy wash called hyperthermic intraperitoneal chemotherapy (HIPEC), survival rates can be as high as 67% of these patients surviving 5 years or more beyond diagnosis. Pleural mesothelioma patients who underwent surgery in combination with chemotherapy also saw survival rate improve by about 20% compared to patients who only undergo chemotherapy. Clinical trials can also offer patients the chance to try promising new treatments that have the potential to extend survival when conventional treatments may not be working for their case.
It is Possible to Beat the Odds

Though the survival rates may paint a rather bleak picture, it is possible to beat the odds. While there aren’t nearly as many long-term survivors of mesothelioma compared to other types of cancer, there have still been some who have lived well beyond their initial poor prognosis. Heather Von St. James, for example, is a 12-year mesothelioma survivor, though her initial prognosis was just 15 months. As a new mom, Heather decided to seek out aggressive treatment in the hopes of extending her life that combined invasive surgery, heated chemotherapy and radiation. Though grueling, the treatment has helped Heather live beyond even her best prognosis.

Stephen Henley was first diagnosed with pleural mesothelioma in 1999, and underwent surgery followed by radiation therapy. After three months of recovery from treatment, life essentially went back to normal for Henley and he has been in remission ever since. Other patients have seen hope in treatment through clinical trials after Mavis Nye went into remission following inclusion in an immunotherapy clinical trial. When the trial began, Mavis saw it as a last hope after she stopped responding to regular chemotherapy. After the trial, Mavis has been in remission for over a year. Other patients have seen success with immunotherapy, and there continues to be a lot of research around the promising treatment.

  • Mesothelioma Survival Rates Are Improving

Within the last few years especially, mesothelioma research has had some great advancements in new ways to diagnose and treat the disease, like biomarkers in the blood for earlier diagnosis and the potential of immunotherapy. Thanks to these promising advancements, survival rates for both pleural and peritoneal mesothelioma have improved slightly in recent years.

Hopefully as research continues and doctors can continue to improve current treatments and develop, survival rates will continue to improve. One day, researchers around the world hope to find a cure. Until then, it’s important for people to be aware of the dangers of asbestos and for patients to be well informed on the disease and all of their treatment options to extend survival.


Monday, June 25, 2018

FHIR patient extensible data portability

Discussions at FHIR DevDays raised this question of a basic way to leverage FHIR API capability to enable the Patient beyond the limited Apps their provider has approved.

If a healthcare provider offers a FHIR API (e.g. argonaut) -- meeting the Meaningful Use "API" requirement. Would it be reasonable to expect that the Meaningful Use "Download" (from View/Download/Transfer) capability would be offered in FHIR format?

Proposed quick-and-dirty solution?

This could be something like a zipped Bundle containing the results of $everything for that Patient, given that patient as the user.  The zipping would help with the potential huge size.

The amount of data would be limited to that which is available on the FHIR API offered, which is often not all possible data.

Concern would come up when this export of $everything includes other data such as documents and images. The theory is that they are all necessary to export, but the problem is the overwhelming size that might result. (Unfortunately compression would be less helpful with documents and images where they are slight variations that are mostly the same, but because of the base64 encoding they all look very different)

Should this be a FHIR Document?

It might be more well-formed to have this be a FHIR Document, but it is not clear to me that adds much benefit over simply an export of all data that is known (aka $everything). 

There would be benefit that the Bundle would then be far more identifiable as coming from a specific Organization on a specific Time for a specific purpose. This could also be simply a Provenance resource on the bundle. This might be very important to a downstream recipient of this blob so that it can be authenticated and proven as complete (Principles of a Document)

Essentially the CCD provides this today, and is often the solution for "download", so this is just a different mime-type (FHIR).

I think just getting an export is more important than making sure it is a FHIR Document.

Why would anyone do this or want this?

The reason why this is useful is for patients that want to use Apps that are not (yet) approved by that provider.  Waiting for each of their providers to approve a useful App can be limiting on the Patient and on the Marketplace.

Counter this with the potential stupid patient that doesn't realize what they are doing with their data... This is going to happen, and when it does there will be an outcry. This outcry will complain that the provider was not acting as a parent to that child, but this kind of an outcry should not be a reason not to do this. Better that the patient be warned, but not forbidden from getting all their data in an download of FHIR format.

Who does this?

If this is reasonable, who does this today? 


Note that this would also be helpful in support of GDPR Article 20 - Right to data Portability

Saturday, June 9, 2018

Presenting IHE on FHIR at FHIR-DevDays

I am getting excited to give two IHE on FHIR tutorials at FHIR DevDays in Boston. The FHIR DevDays event is focused on educating IT professionals in the newest standard in healthcare, FHIR – Fast Healthcare Interoperability Resources. The FHIR specification may be the newest standard in healthcare, but it is backed by all those that have developed the previous standards (e.g. HL7, CDA, IHE, XDS,  DICOM), taking the best from experience and using the latest in RESTful API technology. For more on FHIR Dev Days https://www.fhirdevdays.com/ 


Both tutorials will focus on IHE use of FHIR. The first tutorial will focus on a high-level view of how IHE and FHIR interact, and a broad view of the current 22 IHE Profiles that leverage FHIR. This tutorial will be most interesting to a general audience interested in Standards organizations and evolution of IHE Profiles. This tutorial is a shortened version of the IHE-on-FHIR tutorial I gave at the HL7 Workgroup meeting in Cologne.


The Second tutorial will go deeper into the IHE use of FHIR to enable API access to Document Sharing infrastructures based on XDS and/or XCA. These Document Sharing environments exist within USA, Canada, Europe, and elsewhere. The Document Sharing environment provides a way for Clinical Practitioners to publish documents (e.g. CDA, C-CDA, DICOM, PDF, etc) such as medical summary, episode of care, discharge summary, laboratory results, x-ray, CT, MRI, and other. The IHE MHD Profile defines how FHIR enabled apps can discover these documents, retrieve them, and publish new documents.

Advanced IHE Profiles that will be discussed show how these documents could be decomposed into FHIR Resources that are more naturally made available, with Provenance linkage back to the source document from which the FHIR Resource information comes.


The emergence of HL7 FHIR is very exciting, and the collaboration with IHE shows a strong endorsement. I am always excited to work with this new platform to accelerate the advancement of Healthcare.

My blog articles on the topic of FHIR, Document Sharing, and Privacy

Friday, May 18, 2018


I just finished a very long week in Cologne at the HL7 workgroup meeting and FHIR Connectathon. I had the idea that I could host a discussion of how to use FHIR in a GDPR compliant organization. So I created a FHIR Connectathon track. This track was hopeful that we could do testing with various parts of the FHIR specification. We ended up talking more about generally how to use the various capabilities that exist in FHIR to meet the various Articles in GDPR.

FHIR is GDPR enabled

The Security Workgroup and the Privacy (CBCC or CBCP) are global workgroups, so we have been aware of GDPR for many years. As concrete needs came up we would add that capability. Thus FHIR includes many capabilities that can be leveraged to meet GDPR needs. From a purely geek perspective the GDPR is not technically unusual, it simply places some higher emphasis on Privacy and Security capabilities. Thus overall the GDPR is a good thing to me, as it validates and will leverage the work I have spent 20 years developing in HL7, IHE, and DICOM.

More on this later in this article

GDPR is more than Privacy

I have heard a few people express that GDPR is more than Privacy and Security. I think that these people are misguided at the extent of the real definition of Privacy. The Privacy Principles that are generally included in many standards and guidance are inclusive of giving the Individual the right of Access, the right of Correction, and the right to control how their data are used.  Too often people think Privacy is only about restricting access. The HL7, IHE, and DICOM workgroups I have participated in have always used the more expansive definition of Privacy Principles.

Even the GDPR right to Erasure, related to the EU Right to be Forgotten, is an extension of the Privacy Principles rights to control data about the individual and the rights of the individual to correct improper information.

Adding emphasis: GDPR is very much patterned after "Privacy by Design", indeed it requires that "Privacy by Design" is used.  I have lots of experience with Privacy by Design, and like it. In my GE days, I made it the backbone of the Security and Privacy guidance for all products at GE Healthcare.

Thus GPDR is primarily about Privacy...

GDPR is more than technology

This is a fundamental truth. GDPR will drive far more work in the space of writing Policies, Procedures, Communications, and such. There are many publications, consultants, and lawyers that can help with this. There are many publications that will explain GDPR to you. I am not going to try to explain GDPR.  The law itself is not that hard to read.

So at this point I assume the reader is knowledgeable in GDPR. If not, then go learn that much first....

How is FHIR GDPR enabled?

This week we agreed to write a whitepaper that will explain this. It has the general ouline

  1. Introduction and Scope -- that will explain we are only addressing FHIR specific topics
  2. Mapping of GDPR Articles to the existing Security or Privacy capability in FHIR -- this section will provide terse guidance on how we visualize the use. 
  3. Identification of some gaps we identified -- nothing critical, mostly nice-to-have operations
  4. Conclusion -- FHIR is GDPR enabling

We are targeting the audience that is aware of FHIR and GDPR, that just needs some help extracting out the specifics. This paper should be about 8-10 pages.

The expectation is that once published, the external community may ask for clarification, or for specific actions. We might revise the paper. We might make it more visible through balloting as informative. We might convert it into an Implementation Guide.

Which parts of FHIR are useful?

Not to get ahead of myself. The following are the capabilities that we have already in the FHIR Specification today:

  • Provenance, Resource
    • Includes a signature mechanism that can be leveraged in many comprehensive ways.
  • AuditEvent Resource, and Guidance
  • Consent, Resource
  • any Resource can be tagged with Security/Privacy tags
  • De-Identification guidance
  • Secure Communications
    • Common recommended use of TLS (HTTPS)
    • May use Client Authentication
    • Recommend follow good TLS principles such as BCP195
  • Authentication and Authorization
  • Identity -- various FHIR resources are tied to identities that can be used in Policy (e.g. Consent), and would be used in AuditEvent and Provenance to record Who did some action.
    • Patient
    • RelatedPerson
    • Practitioner
    • PractitionerRole
    • Group
    • Organization
    • Location

Gaps -- those that we found this week.

We did identify some gaps. But all of these gaps are 'nice to have'. They all are new functionality that helps automate an Organization's actions on the Individual actions:
  • Operation that would provide response to an Individual "Right of Access" Article 15
    • assemble all the PurposeOfUse the organization utilizes, which would be beyond those used in the FHIR infrastuture
    • For each PurposeOfUse assemble the types of data utalized
    • And how the data are processed
    • etc...
  • Operation that would provide response to an Individual "Right to Data Portability" Article 20
    • assemble ALL the data in the best encoded format. 
    • This includes data not found in FHIR format
      • Possibly that data can be just described in meta terms
      • Possibly that data can be encapsulated in DocumentReference + Binary
    • etc...
  • Operation that would provide capability and response to Individual "Right to Erasure" Article 17
    • NOTE that Erasure does not override other regulated reasons to keep the data. Thus Medical Records are not subject to Erasure.
    • Erasure affects all data, not just FHIR data
    • Identity must be confirmed. 
    • Action must be confirmed
    • Various Erasure methods might be used
      • simple delete
      • de-identification
      • etc
    • An Erasure Receipt might be useful to define as a standard.
  • Possibly others...
Although these were discussed, it is very unclear how realistic their use would be.


I assert that FHIR is ready for GDPR use. I welcome engagement that helps enlighten me.

Monday, April 16, 2018

IHE Perspective on EU GDPR

I just became aware of a Whitepaper published by IHE Europe in January on "IHE perspective on EU GDPR".

I did not have a hand in writing this whitepaper. It looks good to me. My evaluation only on the Security & Privacy capabilities IHE offers, not on GDPR interpretation. All of the IHE profiles available to support security and privacy are outlined on this IHE page. Their whitepaper does not mention the Document Digital Signature (DSG) profile, or the Document Encryption (DEN). Both would only have a supporting role in GDPR compliance. I mention them only for completeness.

Other IHE Europe publications

Their Conclusion

The examples discussed [above] highlight the complexity of applying the GDPR to processes in health care and how the requirements are interwoven with IHE Profiles. The good news is that even today IHE Profiles provide solutions by combining security and privacy specific IHE Profiles such as ATNA, IUA, XUA, BPPC and APPC with the Profiles focused on information exchange in cross-border, national or regional ehealth deployments.

In conclusion the GDPR can be an effective catalyst to significantly extend the reach and use of IHE Profiles. Some Profiles or combinations of Profiles already meet GDPR’s security and privacy requirements. Others enable the portability of health information which will become a topic for any vendor providing solutions. 

The users of IHE Profiles can be assured that the IHE community will work on evaluating and enhancing the Profiles to meet the GDPR requirements.

GDPR impact beyond EU

I look forward to GDPR. I think that it will bring a focus to Security and Privacy topics. I hope that enforcement drives adoption, while reasonable enforcement drives reasonable reaction. I fear that an overly strict interpretation of GDPR could drive away some very important advancements in healthcare, and social networking. I welcome the extensive and painful penalties for non compliance.

Thursday, April 12, 2018

De-Duplicating the received duplicate data

Everyone is frustrated by duplicate data. In Healthcare space there is a fresh cry from Clinicians around their frustration at seeing duplicate data. On the bright side, this means that they are now getting data. So we in the Interoperability space MUST be succeeding with all the efforts to create Health Information Exchanges, and to enable Patient to access their data.

We standards geeks are quickly put in our chair because we failed to prevent this duplicate data problem... Well, yes and no. Each standard we created included mechanisms that are there specifically prevent duplication. However when those standards are used, shortcuts are taken. It might be a shortcut in the software development. It might be shortcuts in deploying a network. It might be shortcuts in deploying a network of networks. It might be a shortcut when the data was created. It might be a shortcut when the data was exported. It might be a shortcut when the data was 'Used'... But it is shortcuts, that is where the standard was not used the way it was intended to be used.  

Are these shortcuts bad???? Not necessarily. Many times a shortcut is taken to get a solution working quickly. If no shortcuts were taken, then we wold not be where we are today. Thus shortcuts are good, in the short-term. Shortcuts are only bad when they are not fixed once that shortcut is determined to be presenting a problem. Some shortcuts never present a problem.

Standards solutions to Duplicate Data

Let me explain the things that are in the standards we use today (XDS, XCA, CDA, and Direct) that can be used to prevent duplicate data:
  • Patient Identity -- the protocols used to create the virtual identity out of the many identities given to a Patient by many different organizations. (XCPD, PIX, PDQ, etc)
  • Home Community ID – unique identifier of a community of organization(s) 
  • Patient ID Assigning Authority (AA) – uniquely identifies the authority issuing patient identifiers. Usually one per healthcare organization, although can be assigned at a higher level.
  • Document unique ID – uniquely identifies a document regardless of how it was received (Including when received through Direct or Patient portals)
  • Document Entry Unique ID -- A document entry is metadata about a document, including the document uniqueID. A document entry has a unique ID.
  • Element ID – unlikely to be used today, but the standards support it. Fundamental to FHIR core
  • Provenance - unlikely to be used today, but would uniquely identify the source

Elaboration of these points

This is a complex problem, and many layers are used to solve various parts of that complex problem. Where each layer addresses a specific portion of the complexity.

Discovering the virtual Patient Identity

The protocols like IHE PIX, PDQ, and XCPD are designed to discover the various identifiers that the patient is known by. This is a reality, even in a case where government dictates  national identifier.

Duplicate network pathways

Broadest reason for duplicate data is that there are multiple pathways to the same repository of data (documents). Such as HealtheWay, CommonWell or CareQuality. Use just one of these and you don't have multiple pathways, use more than one and you might. The reason to use more than one is caused by the fact that each network has a subset of overall healthcare providers. The duplication is that some participate in more than one network... just like you are... Thus if no one participates in multiple networks, there is no duplicate pathways. 
Heat-Map for CareQuality Network

You might end up finding that you have two or three pathways to the same healthcare organization. You could just disable specific endpoints through specific networks. Pick to talk to a partner only through one of the networks. I would argue that this method of avoidance will be low tech, and initially effective. However as the network matures and expands we need a method to recognize when a new duplicate pathway happens.

I would argue that having multiple pathways is possibly useful to address major disasters that take out one of the networks, or one of the pathways.

Duplicate pathways are detectable, and when detectable, can be automatically prevented.

Detecting duplicates by homeCommunityID. This is the most reliable, but not perfectly foolproof. This however does require that the participants in these networks use the homeCommunityId as it was intended, as an identifier of a community that uniquely holds data.

Special case of hiding communities: Most configurations of XCA behave, but there are some communities that hide many sub-communities behind them. If these sub-communities are only attached through the one community interface, then there is no problem. This is the likely case for these configurations. These configurations are done this way as convenience to the sub-communities. that is to say the sub-communities like that the larger community adds value and connects them to the world. If one of these sub-communities ever decides to connect to another network, then they must become a full community everywhere, else they become a duplicate data source knowingly.

Preventing duplicate data using the homeCommunityID: So the point is that homeCommunityID is a strong indicator of duplicate pathway that would result in duplicate data. Given that in Patient Discovery (XCPD) you target the patient discovery question to a specific homeCommunityID(s), you are in control of which communities you target. Where you have already gotten a response back from a homeCommunity, you can skip the potentially duplicative Patient Discovery (XCPD) or can ignore the secondary results if you already sent out the question. By having a secondary pathway choice, allows you to dynamically detect that the primary pathway is failing. Yes you would need to identify primary vs secondary preferences; logic for delayed attempts; and handling of delayed responses.

Duplicate Patient Id Assigning Authority (AA)

I first mentioned that there are protocols used to discover all the identifiers that a single patient has. This is made up of a Patient ID and the Assigning Authority (AA) that issued that patient ID.  The patient ID assigning authority (AA) is the second level indicator of a unique organization. This can be used today, because everyone does indeed manage their own patient identities, and thus must have a globally unique AA.

Special case is where a community aggregates patient identities into a community patient identity. Such as will happen in an XDS Affinity Domain. Like the sub-community issue above, this is likely not a problem as those that participate in XDS Affinity Domain tend to be small and only want one connection.

Where a nation issues patient identifier, the Assigning Authority (AA) becomes just the national Assigning Authority and no longer would be useful for de-duplicating. In this case many organizations and communities would use the same assigning authority and patient identity. This does not cause duplicate data, but does make the Assigning Authority less helpful at detecting duplicate data.

Duplicate Document UniqueID

The Document UniqueID is an absolute proof of duplicate documents. The Document UniqueId is readily available in the Document Sharing (XDS/XCA) metadata, so can be used at that level to keep from pulling a document unnecessary. With other networks, like Direct or Patient apps, the Document UniqueId can be found within document types like CDA or FHIR. If a case is ever found where this can’t be used as an absolute proof of duplicate document, then the source of that document must be fixed.

This solution will work regardless of the network. This will work with XDS/XCA based networks, but will also work with FHIR based networks, or where the Patient uses an app of any kind. 

A special mention of on-demand documents, but I will address them below.

Duplicate data element identifiers

The solution that would work absolutely the best, happens to be the one least likely to be available today. 

The standards (CDA and FHIR) include the capability to uniquely identify data elements (resources). However, like a good standard, they allow you to not uniquely identify the data element. Yes, I said this was a good thing. It is a good thing for low-end scale. It is a really bad thing for a mature market. This is where Implementation Guides and Profiles come in. In the case of CDA there are implementation guides that do require each data element be uniquely identified, and that Provenance proof always accompany data. 

However uniquely identifying at the data element level is very expensive. That is it is hard to code, makes the database bigger, adds validation steps, and such. When that data is only used within the EHR, there is no value to all this extra overhead. Thus it is often never designed into an EHR.

Duplicate data thru Provenance

Special mention of Provenance... This is supported by the standards, but very poorly implemented. It is expressly important when a unique piece of data is used beyond the initial use. For example where a lab result was taken for one condition, but it also was found to be helpful in a second diagnosis. Both for the same patient, different conditions or different episodes. This is especially true when that original data was exported from one system and imported into another. So a historic CDA was used at a different treatment encounter. That second use needs to give credit to the first, Provenance. How this factors ino duplicate data is that a CDA document from the second encounter will include the very same data from the first. Now two different documents from two different organizations carry the same data but that data has different element identifier as it exists in two places. The solution is Provenance can show the second instance is a copy of the first.

I have worked with EHR that could tell you where the data came from. If it was imported from a CDA received from some other organization, this was noted. Most of the time these Provenance were empty, thus you assume the data was internally generated. But the capability was there on Import, the database had support for Provenance. Using this data on export is another task, thus an opportunity for shortcut...

I also am the owner of the Provenance resource in FHIR.

Clinically same

This is what most deduplication engines work on, they detect that the data found is already known and presume the data is duplicate.  They leverage any identifiers in the data. But ultimately they are looking at the clinical value and determining that they have the same clinical value.

This works except for longitudinal repetition that is clinically significant (an observation presents and resolves over and over)

Duplicate On-Demand Documents

On-Demand documents present the hardest to deal with case of duplicate data. These are also detectable if they follow the IHE on-demand profile. In that the document entry that advertises the availability of on-demand data has a globally unique and stable identity. Thus you can know that you should NOT request a new on-demand instance be made, because you already know about the data. The problem is that you don't know that that new instance would not contain new data. 

So using the unique ID of this on-demand document entry would need to be carefully handled. Never pulling a new on-demand document, will prevent you from ever learning of new data. However pulling a new on-demand document unnecessarily will cause you to spend energy determining that all the data it contains is data you already knew. This is a false-positive and false-negative.

There are poorly implemented on-demand solutions, that don't follow the IHE specification. They create a new on-demand document entry each time they are queried. This is not correct. There should be one uniquely identified document entry that everyone gets the same. When that document is requested, is when the on-demand generation of the specific document is done. And, that generated document should be stored as a 'snapshot'.  These poorly implemented on-demand solutions will present two totally different document entries each time you query, so if you are querying via duplicate pathways, you will think you have found two totally different sources of unique data.

Good news is that if the generated document is of the highest quality, then the content can quickly be separated into data you know from data that is new. That is to say tha the element level identity and/or Provenance can prevent unnecessary duplication.

Detecting a Duplicate

As you can see there are many identifiers, that when they are found to be EQUAL then you know you have duplicates. I present them from largest scope to smallest scope. The larger scope you can use the less energy it takes to stop processing duplicate data. This solution breaks down when the identifiers are not equal, in that case you are not assured that you do not have duplicate data. Thus the whole spectrum must be used, one level is not enough. Ultimately there will be false-positives and false-negatives.

Organizational Policy driving Maturity

Now that we have Interoperability, we need to address over-Interoperability.  I think that identifying the need for HealtheWay, CareQuality, CommonWell, DirectTrust, and any other networks to have reasonable and good control of their identifiers. There is already strong push to move to more coded documents like C-CDA R2.1. There are efforts around Provider Directories.

I don’t think this is a big effort, most do the right thing already today. What is needed is governance that says that the right behavior is expected, and when improper behavior is found it must be fixed. The current Sequoia specifications do not address this level of detail.

Improvement is always good, but we must recognize that much of the health data is longitudinal, and it is very possible a document was created 10 years ago according to the best possible guidance at that time. That historic document likely contains good data, but does not conform to current best-practice. Postel’s law must guide: Be specific in what you send, liberal in how you receive from others.

IHE Mobile Cross-Enterprise Document Data Element Extraction

I have worked on projects within both IHE and HL7 on these topics. I can’t claim they have solved the issue, but they have raised up the common set of issues to be resolved and gathered good practice as I outline above. The most recent project is one in IHE that starts with the Document Sharing infrastructures (XCA, XDS, and CDA) much like above, and presents the de-duplicated data using FHIR API (QEDm). This solution built upon the family of Document Sharing profiles and FHIR profiles IHE has.

See https://wiki.ihe.net/index.php/Mobile_Cross-Enterprise_Document_Data_Element_Extraction

Tuesday, April 10, 2018

IHE on FHIR tutorial

I will be giving a face-to-face tutorial on the topic of "IHE on FHIR" at both

  1. HL7 Workgroup meeting in Cologne, May 12-18
  2. FHIR Dev Days in Boston, June 19-21 
So, if you are in Europe, sign up for the tutorial at HL7 workgroup meeting.  If you are in the USA, sign up for the tutorial at FHIR Dev Days. 

There is a difference in time available to me. At the FHIR Dev Days I will need to focus only on the IHE Profiles available from IHE that leverage FHIR. Where as at the HL7 meeting I will also be able to discuss the overall relationship between HL7 and IHE and the IHE Profiles available from IHE that leverage FHIR.

Here are the IHE profiles that leverage FHIR today...
  • Radiology
  • Pharmacy
    • Uniform Barcode Processing (UBP) -  describes a way to send the information contained in a barcode and in return receive the parsed content of that barcode in the form of a FHIR resource instance - a medication, a device, a patient, or staff.
    • Mobile Medication Administration (MMA) - defines the integration between healthcare systems and mobile (or any other) clients using RESTful web services. This allows connecting EHRs with smartphones, smart pill boxes, and other personal or professional devices.
  • QRPH
    • Mobile Retrieve Form for Data Capture (mRFD) - provides a method for gathering data within a user's current application to meet the requirements of an external system
    • Vital Records Death Reporting (VRDR) - defines a mRFD content profile that will specify derivation of source content from a medical summary document. by defining requirements for form filler content and form manager handling of the content.:

I have succeeded to get the IHE Profiles listed on the FHIR.org registry of Implementation Guides. This is a manual step today, but will likely continue to be a manual step to assure that what gets published has passed the IHE Governance for being listed.

See my other articles on FHIR