Difference between revisions of "CCS Issues and Resolutions"
Jfarmerwiki (talk | contribs) |
Jfarmerwiki (talk | contribs) |
||
| Line 1: | Line 1: | ||
The table below outlines some of the major issues that required resolution during the course of creating the CCS functional specification. This table is included to provide explicit documentation of how concerns raised regarding the specification process have been, or are being, addressed. | The table below outlines some of the major issues that required resolution during the course of creating the CCS functional specification. This table is included to provide explicit documentation of how concerns raised regarding the specification process have been, or are being, addressed. | ||
| − | + | How to manifest clinical decision support in the API? | |
| − | - | + | Solution: Define an operation evaluate_clinical_appropriateness(plan item set). Then all other communications with the cds agent are via discussions. the CDS can answer this operation through it, and can even asynchronously speak up about some concern (for example when the knowledge module gets a late breaking FDA alert). |
| + | |||
| + | How does the API manifest process controls for planned actions? | ||
| + | Solution. API supports start, stop, suspend, resume on a planned action. but for arguments, it can pass it the object with as much detail as the CP DAM records for that item type. If that's not enough info for the server to take action on then so be it (it responds about its inability). but perhaps it can start an interaction with other apps in a loose coupled way (see "limitations" section). | ||
| + | |||
| + | How to support referral requests? | ||
| + | Solution: open a discussion topic. attached the planned item (referral) to the discussion, along with consents or other documents. invite the provider to that discussion. Same for consultations. | ||
| + | |||
| + | How to keep the current plan of to manageable size, if accumulating more and more plans of care? | ||
| + | Solution: keep accumulating, but by default, show only the root-node care plan and the current "open" plans of care and treatment plans. Let the user optionally specify an effective date or time window. Allow linking of supportive content (can point to EHR content). Do not include archive controls since storage is approximately free now, and can be left to the implementation anyways. | ||
| + | |||
| + | What type of identifiers to use for plans? | ||
| + | Solution: Require that they be globally qualified, but otherwise leave it to the server implementation deal with it. Possibly use or qualify the plan of care id that has been assigned already (in the originating system). If the server is just a wrapper, then for sure use the original. | ||
Revision as of 01:39, 16 March 2013
The table below outlines some of the major issues that required resolution during the course of creating the CCS functional specification. This table is included to provide explicit documentation of how concerns raised regarding the specification process have been, or are being, addressed.
How to manifest clinical decision support in the API? Solution: Define an operation evaluate_clinical_appropriateness(plan item set). Then all other communications with the cds agent are via discussions. the CDS can answer this operation through it, and can even asynchronously speak up about some concern (for example when the knowledge module gets a late breaking FDA alert).
How does the API manifest process controls for planned actions? Solution. API supports start, stop, suspend, resume on a planned action. but for arguments, it can pass it the object with as much detail as the CP DAM records for that item type. If that's not enough info for the server to take action on then so be it (it responds about its inability). but perhaps it can start an interaction with other apps in a loose coupled way (see "limitations" section).
How to support referral requests? Solution: open a discussion topic. attached the planned item (referral) to the discussion, along with consents or other documents. invite the provider to that discussion. Same for consultations.
How to keep the current plan of to manageable size, if accumulating more and more plans of care? Solution: keep accumulating, but by default, show only the root-node care plan and the current "open" plans of care and treatment plans. Let the user optionally specify an effective date or time window. Allow linking of supportive content (can point to EHR content). Do not include archive controls since storage is approximately free now, and can be left to the implementation anyways.
What type of identifiers to use for plans? Solution: Require that they be globally qualified, but otherwise leave it to the server implementation deal with it. Possibly use or qualify the plan of care id that has been assigned already (in the originating system). If the server is just a wrapper, then for sure use the original.
