I've spent the last several days using HL7® FHIR® tooling to build the Guideline Accountable Ordering profile in PCC to go along with the CDS for Radiology work that is happening in that domain. Imaging is the principle use case for this profile, given the need for CDS to be used on imaging orders paid for by medicare based on recent legislation [see section (q)] passed in the "Doc Patch" last year.
Building the profile is fairly straightforward, except that the build process is not really designed for single profile development. That will have to change at some point. There are times when I have to wait 25 minutes to find out that I have another syntax error.
The basic outline of GAO is that there is a request, comprised of an order for a diagnostic test, and a response that indicates whether the order is appropriate. The order at this stage is "proposed", not yet "requested", so that the ordering physician can be "guided" by the CDS implementation if he/she so chooses.
The order contains various pieces of data, including the ordered service, the identifier of the ordering provider, a timestamp, an identifier, and various data elements providing indications, reasons, and related clinical data that might help a CDS service determine appropriateness. Little about the patient need be exchanged initially (e.g., gender and date of birth), and little detail about the service, it's code, a code for indications, and perhaps other data known to be necessary (patient weight might also be important for example).
The service can response with an affirmative "within guidelines" response, indicating that the order is appropriate (and which guideline it was evaluated against), a negative "outside of guidelines" response, or a "no guidelines apply" response, indicating that no guidelines are available to evaluate the request against. The service can also provide a link to a request for more information, either as a questionnaire which can be responded to, or as a web based service which could be invoked to guide the clinician through more questions and answers (essentially the web-based implementation of the questionnaire).
Right now, I'm looking at the response which comes back. The closest thing that I've found is the Provenance resource. This is a bit of an edge case for provenance, and some have suggested that an "Authorization" resource might be appropriate. This would of course have to wait for DSTU 2.1, so I'm going to stick with the present approach because it is fairly close to what we determined were our requirements. If it turns out we need to change it, we can.
In the meantime, I'm going to go back to playing with this profile and the FHIR build tools. I think my most recent build is finished. I wish I knew why it keeps doing a full build every time.
Keith
Building the profile is fairly straightforward, except that the build process is not really designed for single profile development. That will have to change at some point. There are times when I have to wait 25 minutes to find out that I have another syntax error.
The basic outline of GAO is that there is a request, comprised of an order for a diagnostic test, and a response that indicates whether the order is appropriate. The order at this stage is "proposed", not yet "requested", so that the ordering physician can be "guided" by the CDS implementation if he/she so chooses.
The order contains various pieces of data, including the ordered service, the identifier of the ordering provider, a timestamp, an identifier, and various data elements providing indications, reasons, and related clinical data that might help a CDS service determine appropriateness. Little about the patient need be exchanged initially (e.g., gender and date of birth), and little detail about the service, it's code, a code for indications, and perhaps other data known to be necessary (patient weight might also be important for example).
The service can response with an affirmative "within guidelines" response, indicating that the order is appropriate (and which guideline it was evaluated against), a negative "outside of guidelines" response, or a "no guidelines apply" response, indicating that no guidelines are available to evaluate the request against. The service can also provide a link to a request for more information, either as a questionnaire which can be responded to, or as a web based service which could be invoked to guide the clinician through more questions and answers (essentially the web-based implementation of the questionnaire).
Right now, I'm looking at the response which comes back. The closest thing that I've found is the Provenance resource. This is a bit of an edge case for provenance, and some have suggested that an "Authorization" resource might be appropriate. This would of course have to wait for DSTU 2.1, so I'm going to stick with the present approach because it is fairly close to what we determined were our requirements. If it turns out we need to change it, we can.
In the meantime, I'm going to go back to playing with this profile and the FHIR build tools. I think my most recent build is finished. I wish I knew why it keeps doing a full build every time.
Keith
