I see a trend of interoperability and patient access spreading worldwide. Emerging guidelines are being formed to support interoperable, seamless, and secure access as well as the use of electronic health information with a focus on patients and payers.
The guidelines are designed to give every patient, along with their healthcare providers, secure access to see, obtain, and use all electronically available health information that is relevant to their healthcare.
Common guidelines for interoperability aim to increase the speed of innovation and competition by fostering an ecosystem of new applications to provide patients with more choices in their healthcare.
To see these guidelines being implemented is so important for patient access, however I fear that the complexity of implementation to its full extent is underestimated. I’m seeing challenges for many healthcare providers that come with the urged need for implementation.
But I’m positive this is doable, and it is with great happiness I’m now introducing the Lyniate HealthTerm on FHIR solutions. Implementation can be achieved rapidly in a cost-effective and resource saving way, while ensuring high data quality.
What are the risks of underestimating the complexity of implementation?
The patient is at the center of healthcare and putting patients in charge of their health records is a key piece of patient empowerment in healthcare. Patient benefits of new guidelines such as CMS Interoperability and Patient Access Final Rule include:
- Ease of access to their records via any app of their choice implemented via API based interoperability between any payer, provider software apps
- Protecting patient privacy and security by allowing patient access through highly secure protocols
- Promoting the ability to shop for care and manage costs
Likewise, there are benefits for the providers, such as:
- Making patient record information requests easy and inexpensive for patients and providers
- Allowing choice of apps
- Information blocking
- Improving patient safety
The guidelines intend to support the seamless and secure access, exchange, and use of electronic health information (EHI). To meet the criteria of these guidelines the following must be made available by the actors in the system.
- Standardized API access for patient and population health service using FHIR standards.
- Support FHIR Release 4 standard (4.0.1)
- Respond to requests for data specified in the USCDI v1 according to the US FHIR Core implementation Guide (US FHIR Core IG) for FHIR Release 4
So, does this mean that you can now comply by the rules only by using the FHIR APIs? Will I comply by taking my data and transforming it to the above-mentioned formats?
The simple answer is no! You also need to express your data using the right interoperability language. Interoperability language for healthcare is not only the large standard code sets, such as Snomed CT, RxNorm, and LOINC.
It is also all the small meta-data sets that define the FHIR message sent through, and to be understood by, the recipient. Each actor in the system will also want to limit the choices for the codes defined by the guidelines to fit their internal way of working. This is what we call value sets. These value sets need to be defined somewhere in the system and continuously updated.
This is where a terminology solution comes in that supports FHIR. A FHIR terminology solution provides you with definitions of code systems, value sets, and concept map resources. It can support the operations defined for each resource utilizing the code system’s content.
So basically, what you really need in order to meet the criteria of the guidelines, is a terminology server which houses content of external code systems such as SNOMED, LOINC, NDC, and all necessary code sets in your ecosystem. The terminology server should also store local code systems and standard FHIR code systems as well as
Lyniate HealthTerm is an interoperability solution covering all the vocabulary code sets and terminology areas you need to standardize within, all in one solution with tools for mapping and automatization and future proof updates. HealthTerm also supports FHIR APIs and more than 90 APIs.
This solution offers you the possibility of normalizing your data and mapping it to the right format. HealthTerm can be an integrated component to the ecosystem you are present in, acting as a filter on the way from source to target data to accept standard format and ensure that you are compliant with the guidelines.
For further reading, check out these resources: