Difference between revisions of "Use Cases"

From IHE-UK
Jump to: navigation, search
(IHE metadata items comments)
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
Please list any use cases, including personal involved and the data they need on this page.  Do not worry if you have trouble editing for style, formatting etc. - that can be corrected/edited by others!
 
Please list any use cases, including personal involved and the data they need on this page.  Do not worry if you have trouble editing for style, formatting etc. - that can be corrected/edited by others!
  
−
I'm not sure where these comments belong, but here seems as good a place as any. I'd categorise these comments as "Using XDS for a national metadata". This is predominatley aroung using XDS with ITK. At present ITK's interest in metadata (generally) is around correspondence (discharge summaries, ED reports etc.).
+
I have moved Dave Barnet's very much appreciated comments to the [[Comments]] Page, and added by own feedback to them.
  
−
I've been through the document produced by Dave Harvey "XDS Meta-Data UK2" - which I think is an attempt to define a core set of metadata for a national context?
+
More use cases as below would be much appreciated, but can you please SIGN them by adding <nowiki>~~~~</nowiki> to the end of each one.
  
−
This does beg the fundamental question in all this for me - is cross enterprise data sharing only across a Trust (or group of Trusts), or across a national healthcare service? The answer I think has profound implications on what we recommend as a national metadata solution.
+
* I am a Social worker in an out of hours team. I have been called to perform an assessment on someone who night be detained under the Mental Health Act. I need to find: The person and their support network; any medication they might be on; any risks to me or other that this person might present. (from Dave Barnet I think)
 +
*I am the principle carer for a person with a long tern condition ( say diabetes) I need to check any changes to medication that might have been recently made. I also need to check any hospital appointments that might be upcoming. I will need to contribute to the patients PHR with any interactions that I might make and I need to make sure I reference these so other fins them.(from Dave Barnet I think)
 +
*I am junior doctor in A&E a patient has jus come in and they are very confused and cannot explain what is wrong with them. I need to find out whether this person has a Mental health Condition and if there is any supporting documentation. if there is I need to finds and medication they might be on and any contra indications.(from Dave Barnet I think)
 +
* I am a radiologist reporting on a CT mastoid. I wish to review the Audiogram, Clinic Review Letter sent to GP. I wish to be presented the documents in a timeline. Filter/search for the word "ENT" in the metadata to see documents related to ENT. I also wish to arrange and sort doc in a date order, specialty, doc class, doc type etc I will then read the ones I need to issue a high quality report.--submitted by Neelam Dugar
  
−
The below imagines a CDA document being stored onto a document repository - for example a discharge summary being added to the repository (which is the only current use case in the ITK).
+
=====
  
−
Running down the data items, here's my thoughts.
+
Perhaps we can consider use cases that have already been written and thought through with regard to IHE profile fit and scaling. Take a look at the PDF in the link here:
 +
[http://www.antilope-project.eu/wp-content/uploads/2013/05/D1.1_RefinementofAntilopeUseCases_v0.9g.pdf]
 +
Of these, the Patient Summary, Referral and Discharge Reporting and Patient-Participatory Healthcare use cases have clear alignments to RCP demand in our platform projects. I will seek further views on rank order priority and relevance of others, but have a look at these in the interim.  
  
−
'''PatientID''' - I think nationally this has to be the NHS Number. I can't see any other option for inter-trust data sharing (as local trust patient numbers will be meaningless to Trusts outside their locality). Plus as only 1 identifier is allowed, it surely must be the national identifier. I'd also add that if no traced NHS number is available, the document would not be reliably retrievable (this in my view is a mandatory NHS Number)
+
A general assumption here for “value” of use cases is they play a part to step-change interoperability and thus assist beneficial business transformation. We are trying to think “JoinedUp” i.e. whole system patient-centred interoperability, functionally dovetailing use cases and vendor neutral system inputs are part of that. We have to clearly express the logic of a common sharing platform (based on XD*) to benefit patients.
  
−
'''SourcePatientID''' - The ITK CDA specs do allow for local identifiers. XDS allows 1 local identifier. SourcePatientID MUST have the assigning authority documented. It would be useful to agree the format of the assigning authority - all the examples I've seen have an OID (who assigns these OIDS?) - ITK uses the assigning authorty attribute with an ODS code and name - for example "assigningAuthorityName="V39XF:North Lane Clinic, Chatham""
+
Naturally implementation will also require many non-technical policy alignments (which locally we would steer through a JoinedUp initiative with all relevant senior decision makers). The use cases need to be reasonably well thought-through to illustrate future "end-game" scenarios and engage business transformation leads.
  
−
'''SourcePatientInfo''' - is the name, gender, address, telecom, DoB of the patient as held on the system from which the document is generated - no issues with this.
+
COMPARATIVE NOTE: The use cases are only starting points for national / regional level implementations and there will be currently undocumented regulatory constraints and fit to existing infrastructures to take into account. In the Netherlands - where there are six Regional Affinity Domains (AD’s) that use XDS as their central infrastructure - that "policy list" is being considered along with the above use case catalogue. Indeed Nictiz is writing a central guideline document to define (in as much detail as possible) ALL the agreements and alignments that have to be set up on the different levels in addition to the technical interoperability (such as conformity statements to ISO and other standards, but also templates for contracts, business agreements, workflow alignment, content definition and formatting, infrastructural functionalities and technical configuration). This experience is likely to be valuable in coordinating UK AD(s) development in this wiki. --submitted by Ed Conley
  
−
'''TypeCode''' - ITK and IHE say that this should be populated with one of the CorrespondenceDocumentType codes. These form part of the document code (ClinicalDocument\code@code). However, this format of document code isn't mandated in ITK specs. The DMSs currently have a definite choice of a single (post-cordinated) SNOMED code, a compositional SNOMED expression using CorrespondenceDocumentType & CorrespondenceCareSetting, and in the nonCoded spec, document code is loosened to CWE, so you can use any code. The issue here is that somewhere along the way the use of the compositional document code need to be firmly stated.
+
=====
−
 
+
−
'''classCode''' - IHE document suggests that this is difficult to define a usfule set of codes for this item. I agree. IHE document suggest that the current range of ITK specs would attract a value of "Clinical Document". The issue for me is that this value cannot be harvested from the document being processed (for storage), and the value comes from an external affinity domain. The issue with affinity domains a the broad concensus of agreement on the value list from all interested parties.
+
−
 
+
−
'''Author''' - Only contentious bit as far as I can see is the Specialty. In the last meeting this was highlighted as important. The ITK document specs lean towards putting in a job role, or the SDS profile. The IHE document suggests using the NHS Data Dictionary set of specialty codes. This is reasonable in that there's already reporting according to these code (Commissioing data sets for example). However the clinical documents don't currently carry the specialty of the author (we'd need a change to the ITK specifications, creation of an OID, and a mandation to populate it)
+
−
 
+
−
'''Legal Authenticator''' - we rarely see this populated. The IHE document says this should be populated in the same way as author/person. However (& I may be wrong) - I think Legal Authenticator is defined as a slot, whereas author/person are classifications?
+
−
 
+
−
'''EventCodelist''' - IHE document says this is extremely flexible, and used to hold clinical acts. The definition of what populates this field need tightening up to be consistent scross care settings (I think its OK for specialties to use this in different ways, but within a specialty there should be consistent use). Currently the ITK metadata recommendation does not include this field. I think we need more discussion on this.
+
−
 
+
−
'''Healthcare Facility Type Code''' - IHE document says thiscould use the NHS Data Dictionary org type list. In ITK CDA specs, I think this comes from the CDACareSettingType SNOMED subset from the encompassing encounter. Where populated, this is defined as CNE, so should be a consistent set of values.
+
−
 
+
−
'''Practice Setting Code''' - The IHE document points to CorrespondenceCareSetting as a list of values (used as part of the compositional grammar statement for document code) - see TypeCode above for the issues.
+
−
 
+
−
'''Title''' - no issues
+
−
 
+
−
'''Comments''' - no issues
+
−
 
+
−
'''Confidentiality Code''' - I agree we need a simple set of codes for cross repository document searching.
+
−
 
+
−
'''Format Code''' - Currently in ITK, we say use the CDA messageType to populate this item. So this gives you "Ambulance Report", "Discharge Summary" etc. (quite a high level document type, not typically involving the detailed care setting). This idea falls down when using the nonCoded specification, as the messageType here says "NonCodedCDA" document (so some guidance / discusssion is needed).
+
−
 
+
−
'''Mime Type''' - no issues
+
−
 
+
−
'''Reference ID List''' - not sure how his would be used in the context of correspondence. ?
+
−
 
+
−
'''Limited MetaData''' - i think we need to define the "minimum metadata" before we can decide whether a document has Limited Metadata?
+
−
 
+
−
---------------------------------ENDS------------------------------------
+
−
 
+
−
Having written this, I have the feeling that a lot of what I've said & commented on is an "administrative" view of document retrieval. For example a clinician might want to find all the documents relating to Mrs. Miggins' Cardiac care since the year 2000. To do this we could search for documents from 2000 that have an author from a cardiac specialty (but we'd miss any emergency department reports that may be relevant). Maybe someone could explain to me how this sort of query would work?
+
−
 
+
−
I also think we could do something around anatomy within the registry. For example, for reports that are body-part centric. When Great Ormand Street (GOSH) were implmenting XDS for radiology, they identified 12 regions of the body to classify reports (I think it was 12 - it may have been more or less). However, these 12 boidy parts are not going to me of much use to a specialist hospital such as moorfields eye hospital. (Whereas GOSH may have gone as far as classifying eyes as head structures, Moorfields would want to classify their documents according to the detailed structure of the eye). This make cross-repository querying seemingly difficult, as different organisations classify documents according to their local requirements.
+
−
 
+
−
However, i think that there are unifying ways forward on this. One answer could be to use a classification hierarchy (such as SNOMED), so a query of "left Cornea" would produce documents relating to left cornea, and a query of "left eye structure" would produce a document list of all left eye structure reports. The idea being that you could query for documents up a known (and common) hierarchy until you get the reports you're looking for. If all instantiations of the document registry implement the same hierarchy, you would get cross-repository querying.
+

Latest revision as of 10:20, 17 July 2014

Please list any use cases, including personal involved and the data they need on this page. Do not worry if you have trouble editing for style, formatting etc. - that can be corrected/edited by others!

I have moved Dave Barnet's very much appreciated comments to the Comments Page, and added by own feedback to them.

More use cases as below would be much appreciated, but can you please SIGN them by adding ~~~~ to the end of each one.

  • I am a Social worker in an out of hours team. I have been called to perform an assessment on someone who night be detained under the Mental Health Act. I need to find: The person and their support network; any medication they might be on; any risks to me or other that this person might present. (from Dave Barnet I think)
  • I am the principle carer for a person with a long tern condition ( say diabetes) I need to check any changes to medication that might have been recently made. I also need to check any hospital appointments that might be upcoming. I will need to contribute to the patients PHR with any interactions that I might make and I need to make sure I reference these so other fins them.(from Dave Barnet I think)
  • I am junior doctor in A&E a patient has jus come in and they are very confused and cannot explain what is wrong with them. I need to find out whether this person has a Mental health Condition and if there is any supporting documentation. if there is I need to finds and medication they might be on and any contra indications.(from Dave Barnet I think)
  • I am a radiologist reporting on a CT mastoid. I wish to review the Audiogram, Clinic Review Letter sent to GP. I wish to be presented the documents in a timeline. Filter/search for the word "ENT" in the metadata to see documents related to ENT. I also wish to arrange and sort doc in a date order, specialty, doc class, doc type etc I will then read the ones I need to issue a high quality report.--submitted by Neelam Dugar

=

Perhaps we can consider use cases that have already been written and thought through with regard to IHE profile fit and scaling. Take a look at the PDF in the link here: [1] Of these, the Patient Summary, Referral and Discharge Reporting and Patient-Participatory Healthcare use cases have clear alignments to RCP demand in our platform projects. I will seek further views on rank order priority and relevance of others, but have a look at these in the interim.

A general assumption here for “value” of use cases is they play a part to step-change interoperability and thus assist beneficial business transformation. We are trying to think “JoinedUp” i.e. whole system patient-centred interoperability, functionally dovetailing use cases and vendor neutral system inputs are part of that. We have to clearly express the logic of a common sharing platform (based on XD*) to benefit patients.

Naturally implementation will also require many non-technical policy alignments (which locally we would steer through a JoinedUp initiative with all relevant senior decision makers). The use cases need to be reasonably well thought-through to illustrate future "end-game" scenarios and engage business transformation leads.

COMPARATIVE NOTE: The use cases are only starting points for national / regional level implementations and there will be currently undocumented regulatory constraints and fit to existing infrastructures to take into account. In the Netherlands - where there are six Regional Affinity Domains (AD’s) that use XDS as their central infrastructure - that "policy list" is being considered along with the above use case catalogue. Indeed Nictiz is writing a central guideline document to define (in as much detail as possible) ALL the agreements and alignments that have to be set up on the different levels in addition to the technical interoperability (such as conformity statements to ISO and other standards, but also templates for contracts, business agreements, workflow alignment, content definition and formatting, infrastructural functionalities and technical configuration). This experience is likely to be valuable in coordinating UK AD(s) development in this wiki. --submitted by Ed Conley

=

Retrieved from "http://wiki.ihe-uk.org/index.php?title=Use_Cases&oldid=98"