Hi Everyone,
Matthew here from the OpenEMR project. I am excited to share this bit of knowledge with the rest of the open source healthcare community.
OpenEMR + a small/independent open source team named Epsilon are working with the leaders of the Apache cTAKES project to create an easy to use REST service to transform unstructured clinical data into structured clinical concepts. We’re making the solution run in Docker and an HTML5/JS viewer so any system can use it even though the first use case is to get it working within OpenEMR (do let me know if this would be something your project would like to implement… we can do parallel work + expand the team!).
Anyways, onto the bit of notable knowledge that I’d like to share. The REST service takes in raw clinical text and returns a JSON payload of all of the parsed out concepts with medical codes (CPT/ICD/SNOMED/RXNORM/etc). To better understand this, check out a quick screenshot of the viewer sending a request to the backend and displaying the results visually (https://raw.githubusercontent.com/GoTeamEpsilon/ctakes-friendly-web-ui/master/demo.png)
We have been returning a custom JSON payload to represent each concept (nothing fancy, just a custom POJO serialized into JSON). However, Sean Finan from cTAKES started to carve out a solution to get it to be FHIR JSON. The problem is there’s no good FHIR structure that can specify where a medical concept is in a corpus. This problem is solved by extending FHIR. Check out this example of the term “pelvic” being identified in a corpus:
{
"resource": {
"resourceType": "Basic",
"id": "claudication_AnatomicalSiteMention_1600",
"extension": [
{
"url": "http://org.apache.ctakes/fhir/text-span",
"valueRange": {
"low": {
"value": 137
},
"high": {
"value": 143
}
}
}
],
"code": {
"coding": [
{
"system": "ctakes-type-system",
"code": "AnatomicalSiteMention"
}
],
"text": "pelvic"
}
}
}
The concept “pelvic” starts at character 137 and ends at 143 (inclusive). This example is using the internal coding system “ctakes-type-system”, but it can support any coding system that works with cTAKES (UMLS as the data source).
Although subtle, this is amazing because it really shows the flexibility of FHIR. Unlike older HL7 formats, we can extend FHIR as needed and don’t have to misuse existing fields.
Thanks,
Matthew Vita