Data Standards - Flexibility in Code-Sets

There are important points being made regarding possible physicians' revenue impacts related to capturing better, clearer, patient health data - and whether this may jeopardize our success. International comparators might shed some light on whether we should be genuinely concerned about this. Notionally, if doctors in peer countries can capture coded data, then it may be reasonable to anticipate that Canadian doctors can capture coded data.

My sense is that it may be useful to hear what are the views of the clinical Colleges on this topic. We should not and cannot compromise patient safety. And we don't need, ever, to accommodate practices (including common practices) that put care quality at risk in favour of increasing physician revenue.

These are not simple challenges. Thanks, all. I'm so impressed by the really insightful discussion on this thread.

Hi Linda,

Thanks for providing the response from the Infoway Standards Team.

I would like to ask that this item get added to the next Patient Summary workgroup meeting for a more fulsome discussion with the jurisdictions.

I believe we all support moving towards international/global coding systems, but there there are practical issues about adoption of coding standards in the clinics that need to be considered. At present Alberta does not require codification of any data in the EMR record beyond fee codes, and while the capability exists in many EMR systems to code information it is not widely used by the physicians. Requiring coded data has implications for clinic workflow and will likely become a barrier to submission of patient summaries. From past experience we know this will result in calls for additional compensation, and Alberta is not prepared to have those discussions with physicians.

We need to find a compromise that allows us to move codification forward, but accommodates the situation today.

Best regards,

Michael
Project Director, Community Information Integration (CII)
Alberta Health

Hello everyone,

Thank you for sharing your thoughts and comments on this important topic around a coded pan-Canadian Patient Summary. Here is the response from the Infoway Standards team:

The FHIR objects are bound to certain valuesets and code systems. In some cases, those bindings are mandatory and fixed, which cannot be relaxed. If we want to set ourselves up towards international standards and move the needle on semantic interoperability, we need to have encoded data. We do not want to experience the same challenges and issues that currently exist with free text and/or string data.
Encoded data has several benefits for clinicians, including minimum data that is comparable, higher data quality and reduced time and effort to select a code concept. Additionally, if we want to do French translations of Patient Summaries in the future, it will be an advantage to have coded concepts as opposed to having to translate free text and/or string data.
We understand that some vendors may feel that the burden falls upon them to map their local codes to a International/Global code system (e.g. SNOMED CT). We don’t want to be overly onerous on our stakeholders, including the vendor community, but we must recognize the effort required to incrementally move towards the end state of semantic interoperability. To adapt and modernize our interoperability capabilities, we need to start including elements around semantic interoperability and conformance in the design of the pan-Canadian Patient Summary solution. We need your support to provide means to transition to International standards seamlessly for our clinicians.
We intend to work with all our stakeholders on an overall release plan and roadmap for the pan-Canadian Patient Summary, where we will have opportunities to discuss the scope of each release. Part of the discussion will be the readiness of our vendor community and jurisdictions to test against the scope.

We hoped to have addressed some of your questions and concerns. Please let us know if you have any feedback or additional comments for consideration.

Thank you,
Linda P., Manager, SNOMED CT
Joel F., Manager, FHIR & Technical Interoperability

The URI defined in the ISO standard includes OID as one of its presentable forms.
In FHIR standards, URI can also be presented in different forms. Among them, URL is a preferred choice; this is because of its friendly readable format to human consumers and possible direct resolvable reference to the represented resource.
However, there is still a possibility that could cause a URL to become an invalid/mispresent URI, such as the desolation/reuse of the URL. Comparatively, the OID will never have such an issue.
One of the merits of FHIR is its support for multiple URIs, which gives users an option to implement both OID and URL in the FHIR resource profile.
The FHIR messaging IGs for the project can serve multiple functions in a staging manner for both short and long-term perspectives.
Just like what Brandon suggested that the implementation of the code system work could be progressive, which needs to identify what can be archivable at the current stage and what should be mandated down the road.
Besides that, another question is on the mapping table between the jurisdiction valuesets and the federal valueset. This is more of a govanance question.

Derek brought in a free text topic. A coded PS is a good suggestion. My question is who will hand in the conversion. My perception is the service providers might not be willing to take such extra work. Besides the two proposed efforts, theoretically, the Clinical Natural Language Processing engineer could handle the work to extract clinical information from non-structural/semi-structural text into structural data.

The goal of having good, encoded, data is important when sharing that data across multiple systems.

The problem with forcing the end user to encoded these fields is the that they just do not have time for it.

Consider physicians who see 50 patients a day and only have 15 minutes (at most) to provide care and complete their charting. In my experience, the majority of physicians do not look up medications using the provided search capabilities (which would provide some encoded values), and instead just use the medication name field to free type all the medication information required by the pharmacist because it's faster and easier.

If we are discussing forcing physicians to clean up their medications in order to be able to submit a PS, then I think we are going to face push back from physicians who don't have time to go back through possibly dozens of old medications to modify them and clean them up. Modifying old prescriptions (without reactivation) is not a use case that we account for in our EMR, and we would generally not recommend changing historical data. Perhaps this could be limited to new, active, or recently active medications?

In the end, the likely response from physicians will be that they don't want to be bothered with the bootstrapping required submit a PS, or they will just omit the sections that will be cumbersome to encode. We could end up in an eco-system where PSs are not reliable because they are generally incomplete.

I do think a good job has been done to keep the number fields in the data set minimal. I guess it just feels like the encoding requirements are a bit disconnected from the end user at this point... On the other hand we need to start somewhere

---

As an aside:
The PS MDS has notes for the first 3 sections with clear instructions that if the data is not available, a reason, or "no known" must be specified. Is there a reason these three sections have these instructions and the rest do not? If not, can we ask for consistency across the sections? Perhaps this should be more of a display logic issue than a data requirement issue.

For my EHR system, we do map to a lot of data and allow customers to update those maps as needed to fit their specific needs. There are many U.S. regulatory requirements that require mapping so we already have that capability. We understand that Canadian code sets differ, and I would advocate for using international code sets as much as possible. I will say that if mapping is required, it just needs to be clearly laid out in the requirements as to what data needs to be mapped and with what code sets and it looks like the draft PS does have that information. If there are specific value sets that need to be used, then that should also be published. If standards are to be used, they need to be used by everyone and laid out clearly, but also add the flexibility to use the codes that make since for that specific facility or clinic. I for one don't see the point of sharing a patient summary if your not going to standardize the information that gets included.