Data Standards - Flexibility in Code-Sets

This is a highly strategic decision for us to make. Our challenge is that much of our existing data is not "good"... where "good" is measured along the axes of patient safety, and interoperability, and computer-processability, etc. If we relax our requirements for PS coding, then we may find we've preserved all the not-good aspects of our present situation... and we run the risk of foregoing all the benefits that are motivating our projects in the first place.

Taking on the job of doing wholesale data cleaning (a "big bang" approach) would delay our time-to-benefit by years... and that assumes we could keep up the interest and energy for long enough to ever get benefits at all, which is unlikely IMHO. A "bootstrapping" approach, however, could be a potential way to associate little spoonfulls of bother with little spoonfulls of durable benefit. If every time a clinician wanted to share a PS, the relevant free text fields needed to be coded, then that effort would:

• create a coded PS for that one patient (immediate benefit accruing to both the originating clinician and the PS recipient)
• add to a local library of TEXT->CODE (or LOCAL_CODE->ENTERPRISE_CODE) content maps in the clinician's EMR (future benefit to be realized by the originating clinician in the next PS-generation process).

I appreciate these are implementation issues and not data engineering issues... but choosing an "implementation metaphor" (like bootstrapping, for example), now, could usefully focus us on data model issues that do, or don't, preserve our value propositions.

My $0.02...
Derek

As I was reading through the proposed MDS document, the code sets were my biggest concern from an EMR vendor and usability standpoint. The vast majority of data entered in the EMR is done by free text, with no mapping to an underlying coding system (e.g. SNOMED). If those code sets are mandatory and enforced, it will definitely cause an issue for data coming from physicians and clinics. I would be a great proponent of relaxing those requirements!

Hello everyone,

We received a question from Alberta about whether the data standard will allow flexibility in code-sets, such that jurisdictions could choose from available published standards based on their needs?

Our standards team have drafted a response from structural and semantic perspectives that we wanted to share with you.

Structural:
FHIR does cater to have either different codes representing the same concept (CodeableConcept) or different codes from different codesystems representing the same concept (Slicing with System as discriminator). The only catch here is instead of using an OID, we would propose to use URIs instead.

Semantic:
We are aware that there are different code systems used in Canada for capturing health information and we are expecting to develop maps between source and target terminologies. As you might be aware there is a lot of discussions on using international standards that “fit the purpose” for new implementations. Hence why you see SNOMED CT and LOINC as the “preferred” clinical reference terminologies in the draft document you received. There is also a possibility to strengthen or relax the “(vocabulary) bindings” on the messaging specification like FHIR where possible, to accommodate again with the “preferred”, “required” or “example” code systems that is applicable for the Domain of use.

What do you think? Please let us know if you have any feedback or additional comments for consideration.