ONC (G)(9) generate ccda operation in FHIR #5284
Comments
|
Looks like this is already supported with the $docref operation in US-Core. http:https://hl7.org/fhir/us/core/StructureDefinition-us-core-documentreference.html#mandatory-operation http:https://hl7.org/fhir/us/core/OperationDefinition-docref.html What we will do is return an empty data set for any search parameter other than our CCD for now as this operation is intended to generate/create new documents. We can add additional documents that are needed to be generated as future needs require. For CCDA we will use the LOINC code of 34133-9 (Summary of episode note) for a C-CDA Clinical Summary of Care (CCD). If no code is provided we need to return the most current CCD that exists for the patient. The operation takes a start and end date so it works fine for (g)(9). |
Added the infrastructure for the $docref operation. Added scopes, rest endpoint, and service classes. Currently the endpoints just return an empty DocumentReference. Need to build it to return the DocumentReference for the generated ccda. Moved the Export operation into a sub folder where we can keep our future operations that we support.
|
I created a new sample module that people can use to play with both the SMART on FHIR apis and export a ccda using the apis. Here is the link available on composer https://packagist.org/packages/adunsulag/oe-module-g9-ccda-exporter Here are some sample screenshots of what this module does: Adds menu options to set the registered client id and client secret key. (Eventually I'd like this to auto-register an app, but for now in the interest of time, you have to do this step manually). Next it adds a menu item under the Modules table that takes you to this index page (instructions for redirect_uri and launch_uri are in the Registration Instructions link). Clicking on launch CCDA exporter takes you to the oauth2 authentication screen. It's using the launch/patient permissions so once you authenticate you need to select a patient. Once a patient is selected you authorize your permissions. note under the DocumentReference permissions it shows the $docref permission to generate a CCD document. Next is shows an example of retrieving and display the patient resource and gives you the ccda generate options. See the generated CCDA here: Hit the download button to get the generated file: Snippet of downloaded xml file. |
* WIP FHIR $docref operation #5284 Added the infrastructure for the $docref operation. Added scopes, rest endpoint, and service classes. Currently the endpoints just return an empty DocumentReference. Need to build it to return the DocumentReference for the generated ccda. Moved the Export operation into a sub folder where we can keep our future operations that we support. * (g)(9) ccda gen, (b)(1) sort/truncate ccda Implemented generating a ccda via an event in the system so fhir can create the ccda for the $doc-ref FHIR operation. Refactored the ccda generation pieces from the Encounterccdadispatchcontroller into separate classes so we can call it from the event cleanly without having to deal with a ton of POST / controller logic code. Refactored the ccda document generation so that it uses the document class for encryption, couchdb storage, and retrieval. This means a generated ccda now generates a file in the patient CCD/CCDA folder. Implemented a view ccda event that allows the Carecoordination module to sort and truncate the ccda sections for the ccda that is being viewed. This is necessary in order to meet the b1 requirements of a user being able to set how many sections they want to see as well as the sort order of the sections. Began the work of adding a new globals field for displaying a list of options and adding that list to the globals. The options are saved in the globals table as a semi-colon delimited string. Added the beginnigs of the ccda-sections list options that people can select from in the globals user settings table. Modified the FHIR Document Binary api to use uuids instead of ids for the document. Made the ids backwards compatable so old Documents using the id columns will still work. Added a method to the CodesTypeService to parse codes into codeable concepts so we can use them in FHIR. Updated the CCR/display.php file to use the user preferences and ccda view event so that we display CCDs with the newest stylesheet that @sjpadgett implemented. Added to the CCR/display.php checks to make sure the document exists and that the ACLs are being properly checked. Added documentation to some of the Carecoordination modules. Added to the GlobalsService the addUserSpecificTab method in order to be able to add additional tabs to the user preferences section. * CCDA improvements, new global settings list type Modified ccda node service to skip observation interpretations that are empty for lab results. Modified the encounter ccda controller to catch ccda node service errors and message the user to check their ccda node service installation instructions. Implemented a ccda sort feature needed for (b)(1) using the user preferences globals. Updated ccda to support standard units (inches,lbs) with the right unit codes. Cleaned up the ccda createDocument per code review suggestions. Added the capability to the globals to have a list+add option that is sortable. Made it possible to have additional field options for global settings. Added the ccda-sections list option that has all of the sortable sections we implement in CCDA. * Style fixes * CCDA zip/saved file filename changes Changed up the CCDA generation filenames so we have date timestamps and the type of ccda that is being genreated in the filename and the zip. Changed up the direct email attachment filename to include the ccda filename if one is present so we have the exact file sent that we downloaded. Changed up the CCDA result object to have the filename that was generated for the file. Refactored the sendTo.js::send() method to break up the download_all and direct send into their own functions that can be better reasoned about and that transmit the document type needed to generate the xml / zip filename. Changed out the Document filename for the generated ccda to being a human readable name and not just a uuid. Fixed a bug in the amc logging that would fail if a ccda is sent w/o there being a created referral record first. Modified Direct transmission to include a filename if one is available * style fixes * Fix db upgrade extra sql
|
Here is the same thing that can be done with swagger, first register a client provide the patient scopes and launch selector Make sure we can grab the patient information, DocumentReference, and Document scopes. Now go to authorize in swagger. Make sure to request the same scopes that was done in registration Login with an openemr user and then select a patient (this is what launch/patient) scope does.
Now authorize the scopes Now we need to get our patient id as swagger doesn't show this. We'll do this by just hitting the patient endpoint. Since we selected a patient with launch/patient our fhir/Patient endpoint will return just the patient we want. At that point we grab the patient uuid and plug it into our $docref endpoint to generate a new ccda. Dates can be specified here as part of the test When we run the test we get back a generated DocumentReference. The URL to download the CCDA is in the entry.content.attachment.url field as highlighted in this screen shot. We copy the uuid for the Document and then hit the swagger /fhir/Document/{id}/binary endpoint to grab the URL. When you hit the execute button on the endpoint swagger will fetch the file and give you a download link to download the file: |
|
@bradymiller with my changes in #5488 you should be able to run through swagger to do the $docref operation to generate a ccda for g9. I realized that instead of making people use a module we could run everything through swagger which is a better option anyway. Although my module is a good use case of a SMART app. |
|
Is this running off the ccda generate event or the generate() method? |
|
We completed this issue. |
We need an operation to generate a ccda with a patient uuid and a date range added to our FHIR. Perhaps something like $generate-ccda or $export-ccda. We will need to add it to our FHIR documentation as well. This meets the criteria for our (g)(9) data export for generating a Continuity of Care document.
-- Edited on June 18th
Outstanding Sub Issues
The text was updated successfully, but these errors were encountered: