Healthcare Requirements: How Does CREDS work?

[ad_1]

You can view the original post here

I am getting again to some requirements writing, this time on the CREDS mission. In case you have not heard of this one, the (b)acronym decodes to Clinical Registry Extraction and Data Submission. The problem that CREDS is seeking to resolve for Medical Registries is a quite common one. Information must be collected from medical data, packaged up, after which be despatched someplace.

There are three key questions that any implementer has to reply in this type of effort.

What information?
The place is it despatched?
How is it formatted?

On this put up, I'll be targeted on the primary query. The following two will range by registry, however we are able to usually specific the solutions to 2 as “To the registry that's asking for it”, and on this case, CREDS is a FHIR IG, so the reply to three is FHIR, but it surely's additionally a bit bit extra difficult than that.

What Information?

The what query is available in a number of components:

Who has it?
In what (standardized we hope) type or types can it's discovered?
How do we discover it?

Solutions to the primary query for medical registry reporters embody:

My EHR System
My Previous EHR System
My Laboratory Info System
My Radiology or Imaging data system (RIS or PACS)
An ambulance (not ambulatory) data system. Sure, you might need to dig by means of transport data in a standardized format.
The affected person's main care or specialty supplier (of their EHR, RIS, or PACS)
In a 3rd occasion's data system
By means of an HIE
By means of some type of nationwide information trade community
The affected person's payer (sometimes an insurer, or a state or nationally funded program).

The second query can varyingly be answered as:

FHIR, and if that's the case, downside solved
^ (practically, extra on this later)
CDA
HL7 Model 2
DICOM
NCPDP
X12
or varied others, and eventually
the worst case Digital paper … e-mail, pdf, printed textual content experiences — which I'll take a tough go on for this weblog put up.

The third query (how do we discover it within the information) will not be fairly so easy, and but has one reply, no less than for CREDS, and is the important thing to how CREDS works. You see, CREDS depends not simply on FHIR, but additionally FHIRPath. FHIRPath is a declarative programming language that permits one to specific a pointer to a number of items of knowledge in an information mannequin, or carry out a computation based mostly that information, or reply a sure or no query about it. It originated as a technique to level into FHIR Sources to specific issues like the situation of search parameters, or constraints on a refined mannequin (a profile of a FHIR Useful resource) that should be met for a useful resource to adjust to the profile. For these which have been round for some time, you may see that FHIRPath appears to be like very very similar to XPath, and for some constrained variations of FHIRPath, there are some quite simple transformations from FHIRPath to XPath expressions.

I have been working with XPath (and XSLT which depends very closely on it as a metamorphosis language) earlier than it was a W3C Commonplace, whereas it was being invented, with the inventors working in cubicles or workplaces proper subsequent to my very own. You are able to do absolutely anything with XPath that you would be able to in some other programming language, although I am not fairly certain you'd essentially wish to. It takes a twisted mind to assume in declarative type. It takes a bit much less twisting in FHIRPath as a result of the creators of that language had comparable experiences and already had some concepts about what labored and what does not.

However declarative has its personal worth. The purpose of a declarative program will not be in specifying easy methods to get the reply in stepwise type, however reasonably to outline what you need the result to be, and let the system resolve easy methods to get there. The worth add of the system is in defining how easy methods to carry out these operations effectively. Programmers use methods like this all the time. Contemplate SQL (additionally primarily a declarative language, although it has some procedural parts).

CREDS says {that a} registry defines a logical mannequin describing its information, and that logical mannequin is made out there to customers of the CREDS IG by way of an data system. This can be nothing greater than an excel spreadsheet with component names and information varieties, or it is likely to be an entity relationship mannequin expressed in quite a lot of normal types. Since CREDS is utilizing FHIR, CREDS requires that these logical fashions be expressed in a FHIR format. For that, we've the FHIR StructureDefinition. Sure, the identical creature that defines the logical mannequin for FHIR Sources and extensions and FHIR Datatypes can also be used to outline logical fashions. If you wish to discover a logical mannequin for a registry, you've gotten greater than 2 dozen search parameters on StructureDefinition you need to use to seek out it.

FHIRPath, curiously sufficient, is also designed to work with logical models, though it's principally meant to be used with FHIR, it's NOT restricted to that mannequin. I will present why that is vital in only a bit.

Every component in a FHIR logical mannequin (StructureDefinition useful resource) will be mapped to a number of different normal codecs. The language wherein this mapping is expressed is left unrestricted within the base FHIR Commonplace, although it ought to have a mime sort (which is outlined by FHIR to be text/fhirpath [and is recognized by IANA as such). CREDS says that you must use FHIRPath in your mappings. Why? Because with those mappings, you can now locate the actual data element in the mapped to standard that reflects the intent of the author of the definition for the registry data model … in a computable manner.

Furthermore, to successfully use CREDS, the mapping identifiers used in the StructureDefinition resource for the logical model must also be bound to a separate logical model that describes the mapped-to standard. And that logical must be defined using StructureDefinition resources. This is important because it makes it possible to automate queries to extract the necessary data from the larger assets that contain them (CDA Documents, V2 messages, et cetera).

So, now to the meet of how CREDS actually works:

Download the Registry's logical model from a FHIR Server by querying for the StructureDefinition resource(s) you need.
For an identified patient, and for each system that might have data, collect the relevant data for that patient from the system.

By first mapping the patient identity you know to the patient identity in the system that you are going to query.
And then query for and extract the relevant data assets (FHIR Resources, CDA documents, or V2 messages).

To query for FHIR Resources in this example, it is enough to request Patient/$everything, and let the FHIRPath mapping perform filtering. This is a naive implementation, you could be smarter, and CREDS will have some guidance both about writing mappings and how to use those mappings to get to the document you need. A key assumption in CREDS is that the mapping is explicit, it does not assume that anything other than patient identity and date are available as pre-established contextual cues to extract the data.
To query for CDA documents, well, you have a couple of options, but the one I'd start with is already FHIR enabled, and is basically the equivalent MHD query for all patient documents for a given time range for the patient. And if you happen to need to query to an XDS/XCA based registry / repository (as might be the case for QHINs under TEFCA, or most national networks already today), there's a way to bridge from MHD to XDS/XCA queries. I built one in personally in 2016, I worked with a team that shipped another one to production a few years later. It's baked into the design. After all, MHD started out with the XDSEntry resource. Others have done the same, including Grahame Grieve.
V2? CDA showed the way. While there is NO “standard” way to do the same for V2 messages, I've also built (and shipped) a FHIR based query modeled after MHD to an HL7 V2 message repository. This is not rocket surgery, it's more like brain candy.
Got another format (e.g., NCPDP, X12)? Same thing, different format.
Finally, for each element in the Registry's logical model, apply the appropriate FHIRPath expressions over the extracted resources to collect the information in the logical model.

Having collected the data to populate the registry's logical model, you could just send it in logical model form and let the registry take it, but that's no longer FHIR, it's just FHIR-like, or perhaps even FHIR-lite. So …
A smart registry will define their logical model in (as close to as possible) a FHIR format. That's a small lift, but certainly worthwhile. Registries which define their submission models in FHIR format don't need the final CREDS step of transforming the data.
We sort of cheat on the very last step for registries which don't do that work, and say, the submission to the registry goes only so far as FHIR as a standard, so if the registry logical model isn't already written in FHIR (and the various regional standards such as the HL7 FHIR US-Core or USCDI (or USCDI+), then they must also supply a computable transformation using the FHIR StructureMap to convert information structured in their logical model format to the FHIR Bundle. CREDS won't go into much detail there, and it really need not do so. There are implementations that can apply a structure map to perform transformations from one logical model to another.

That's enough on CREDS for tonight and it's NOT what my project manager wanted me to do, but it's really about getting my thoughts down in pencil before I whip out my pen.

Surely there's more to be written, I have a list. Here's a few of the topics I plan on taking up shortly:

How to go from a mapping to a queryable repository in FHIR. In this, I'll answer the question about how a registry can specify mappings in a way that makes it possible for different institutions to query different repositories or networks for assets to collect.
Optimizing queries. The principles of writing FHIRPath expressions in a format that enables users to distinguish between the initial query to send to an external part and the filter to apply after asset retrieval to collect the data, and some thoughts on how to merge queries for the same kind of asset (e.g., a FHIR Resource type, a CDA document or a V2 message). I suspect that the first implementation I work on in any way will be naive (Patient/$everything), but I'm certain I can do better. FluentQuery would be a big help here, but at the moment, I've got the only implementation I know of from the SANER Project.
FHIRPath for CDA. If I get to this one in 2022, I will declare the year a grand success, because it means I will be writing an implementation or better yet, that someone else beat me to it.

Personally, I think CREDS project will result in a visionary IG, but it's goal is NOT to boil the Atlantic Ocean, or even Lake Ontario. I'll settle for Lake Kerr* for now, understanding that if I but turn up the FHIR, I could use it take on anything.

For those that don't know, the main inspiration for how we are doing things in CREDS is based on the work I did over the last two years with the SANER Project. For that project, we needed to do two things:

Extract data from patient medical record in various places, and
Count the things that we extracted.

CREDS is just refining how to do the first part, and not just for data that exists in FHIR. Because lord knows, it's not all in FHIR yet, and it will probably remain that way through my lifetime.

Keith

* Lake Kerr is within sight of where I wrote Happy Tears, and I walked by it with my mother last week a few days after her successful cancer surgery.

[ad_2]

You can view the original post here