FHIR Catalog-to-Composition Comparison
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Catalog RequirementsFHIR CompositionAsk
2
Attribute PathTypeCardinalityAttributeTypeCardinality
3
Catalog.identifierIdentifier0..1Composition.identifierIdentifier0..1
4
Catalog.subCatalogReference(Catalog)0..*Composition.relatesToConsider using relatesTo and broaden the relatesTo.code value set as it is required (or make code value set an example binding). Need to add a code 'include'.
5
Catalog.document1..1Flat in FHIR - no structure to hold metadata
6
Catalog.document.statusCodeableConcept1..1Composition.statuscode1..1Codes would need to be harmonized and possibly expanded to support catalog.
7
Catalog.document.providerReference(Organization)1..1Composition.custodianReference(Organization)1..*
8
Catalog.document.contentTypeCodeableConcept1..1Composition.typeCodeableConcept1..1Not sure if these are exactly the same but seems to be close in semantics. To discuss with SD. Also propose making this field optional if we retain it or specify a value set with a single code of "Catalog". Open question: would we have terms such as 'Medication Catalog'.
9
Catalog.document.updateModeCodeableConcept1..1A catalog extension most likely since it is particularly unique to catalogs. Would be handled in catalog profile on Composition. Let's discuss whether this should be an attribute in composition with SD. How will SD handle things like differential update, new compendium, etc...
10
Catalog.document.identifierIdentifier0..1How is this different from Catalog Identifier? Resource IDs are different beasts so this may be redundant. Suggest removing this one.
11
Catalog.document.contentVersionIdentifier0..1Different from 'technical versioning' such as FHIR version. This versioning is based on the content development process of the catalog provider. Propose adding as attribute in FHIR or handle with an extension (to discuss with SD). I assume this is a human assigned version vs a version handled by an update on a backend.
12
Catalog.document.issueDatedateTime0..1Composition.datedateTime1..1Aligns except for the definitions. One seems to be an issue date (Catalog). The other is a 'last edit date'. I propose that we rename this attribute in FHIR to lastEditDate and add a new attribute called issueDate or publicationDate, etc... If not, it would be an extension in our profile.
13
Catalog.document.validFromdateTime0..1Need to add. Why not an attribute called 'valid' of type Period.
14
Catalog.document.validTodateTime0..1See above.
15
Catalog.entry0..*
Composition.section.entry
Reference(CatalogEntry)In composition this would be nested in section. We should ask for both possibilities in FHIR or know that we will always nest entries in a section.
We will need to add a CatalogEntry resource in FHIR and in our profile constrain entry to only Reference(CatalogEntry).
16
Catalog.entry.typeCodeableConcept0..1Add to proposed CatalogEntry resource.
17
Catalog.entry.referencedItemReference(Medication|Device|Procedure|CarePlan|Organization|Practitioner|HealthcareService|ServiceDefinition)0..1Add to proposed CatalogEntry resource.
18
Catalog.entry.identifierIdentifier0..1Add to proposed CatalogEntry resource.
19
Catalog.entry.additionalIdentifierIdentifier0..*Add to proposed CatalogEntry resource.
20
Catalog.entry.classificationIdentifier0..*Add to proposed CatalogEntry resource.
21
Catalog.entry.statusCodeableConcept0..1Add to proposed CatalogEntry resource.
22
Catalog.entry.validFromdateTime0..1Add to proposed CatalogEntry resource.
23
Catalog.entry.validTodateTime0..1Add to proposed CatalogEntry resource.
24
Catalog.entry.lastUpdateddateTime0..1Add to proposed CatalogEntry resource.
25
Catalog.entry.additionalCharacteristicsCodeableConcept0..*Add to proposed CatalogEntry resource.
26
Catalog.entry.additionalClassificationCodeableConcept0..*Add to proposed CatalogEntry resource.
27
Catalog.entry.relatedItem0..*Add to proposed CatalogEntry resource.
28
Catalog.entry.relatedItem.relationshipCodeableConcept1..1Add to proposed CatalogEntry resource.
29
Catalog.entry.relatedItem.typeCodeableConcept0..1Add to proposed CatalogEntry resource.
30
Catalog.entry.relatedItem.identifierReference(Medication|Device|Procedure|CarePlan|Organization|Practitioner|HealthcareService|ServiceDefinition)0..1Add to proposed CatalogEntry resource.
31
Catalog.entryGroup0..*Composition.section0..*Propose that we add this to our own Catalog resource if we retain it. Otherwise, we are covered by FHIR.
32
Catalog.entryGroup.entryReference(Entry)0..*
Composition.section.entry
Reference(CatalogEntry)0..*Propose that we add this to our own Catalog resource if we retain it. Otherwise, we are covered by FHIR.
33
Composition.classCodeableConcept0..1We would retain this attribute but will define our own value set.
34
Composition.subjectReference(Any)1..1This is a problem. Need to relax to 0..1.
35
Composition.encounterReference(Encounter)0..1Constrained out in profile
36
Composition.authorReference(...)1..*Relax cardinality in FHIR Resource to 0..*. May need to profile practitioner to be a catalog author. Discuss this with FHIR and SD.
37
Composition.titlestring1..1We will retain it. Otherwise FHIR requires us to provide a title.
38
Composition.confidentiality
code0..1Constrain out in a profile. If we consider adding this to Catalog Entry it would be an extension and would need to be driven by a use case.
39
Composition.attester0..*Consider keeping as this is also potentially useful to catalogs.
40
Composition.relatesTo0..*Suggest we consider as well.
41
Composition.event0..*Suggest constraining out in our profile of Composition.
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...