CCS Issues and Resolutions

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).

(--Enrique Meneses 23:10, 16 March 2013 (UTC): other possible hooks for CDS exist when proposing actions and starting actions but these may just re-use the check for clinical appropriateness capability)

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).

(--Enrique Meneses 23:10, 16 March 2013 (UTC): the capability list as currently defined 3/16/13 require the ProposedAction and ImplementedAction and context. This should be enough for an implementer to trigger things like order entry. As long as the context is there the SFM allows for vendor flexibility and defers additional capabilities to the implementer of the future technical specification.)

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.

(--Enrique Meneses 23:10, 16 March 2013 (UTC):I think the provider is just invited to join the care team. Upon acceptance they have access to the shared care plan context.)

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.

(--Enrique Meneses 23:10, 16 March 2013 (UTC): The capabilities currently support closing of the plans. Clinical data is not typically deleted and I would expect plans to be there forever but vendors would design views in such a way that historical data which is not immediately relevant is hidden from most views.)

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. (--Enrique Meneses 23:10, 16 March 2013 (UTC): Agreed it needs to be globally unique. This issue should be revisited during the technical specification phase of the OMG effort).